solana-docs 0.0.0

package/src/developing/programming-model/runtime.md

@@ -0,0 +1,131 @@
+---
+title: "Runtime"
+---
+
+## Capability of Programs
+
+The runtime only permits the owner program to debit the account or modify its
+data. The program then defines additional rules for whether the client can
+modify accounts it owns. In the case of the System program, it allows users to
+transfer lamports by recognizing transaction signatures. If it sees the client
+signed the transaction using the keypair's _private key_, it knows the client
+authorized the token transfer.
+
+In other words, the entire set of accounts owned by a given program can be
+regarded as a key-value store where a key is the account address and value is
+program-specific arbitrary binary data. A program author can decide how to
+manage the program's whole state as possibly many accounts.
+
+After the runtime executes each of the transaction's instructions, it uses the
+account metadata to verify that the access policy was not violated. If a program
+violates the policy, the runtime discards all account changes made by all
+instructions in the transaction and marks the transaction as failed.
+
+### Policy
+
+After a program has processed an instruction the runtime verifies that the
+program only performed operations it was permitted to, and that the results
+adhere to the runtime policy.
+
+The policy is as follows:
+
+- Only the owner of the account may change owner.
+  - And only if the account is writable.
+  - And only if the account is not executable
+  - And only if the data is zero-initialized or empty.
+- An account not assigned to the program cannot have its balance decrease.
+- The balance of read-only and executable accounts may not change.
+- Only the system program can change the size of the data and only if the system
+  program owns the account.
+- Only the owner may change account data.
+  - And if the account is writable.
+  - And if the account is not executable.
+- Executable is one-way (false->true) and only the account owner may set it.
+- No one can make modifications to the rent_epoch associated with this account.
+
+## Compute Budget
+
+To prevent a program from abusing computation resources each instruction in a
+transaction is given a compute budget. The budget consists of computation units
+that are consumed as the program performs various operations and bounds that the
+program may not exceed. When the program consumes its entire budget or exceeds
+a bound then the runtime halts the program and returns an error.
+
+The following operations incur a compute cost:
+
+- Executing BPF instructions
+- Calling system calls
+  - logging
+  - creating program addresses
+  - cross-program invocations
+  - ...
+
+For cross-program invocations the programs invoked inherit the budget of their
+parent. If an invoked program consume the budget or exceeds a bound the entire
+invocation chain and the parent are halted.
+
+The current [compute
+budget](https://github.com/solana-labs/solana/blob/d3a3a7548c857f26ec2cb10e270da72d373020ec/sdk/src/process_instruction.rs#L65)
+can be found in the Solana SDK.
+
+For example, if the current budget is:
+
+```rust
+max_units: 200,000,
+log_units: 100,
+log_u64_units: 100,
+create_program address units: 1500,
+invoke_units: 1000,
+max_invoke_depth: 4,
+max_call_depth: 64,
+stack_frame_size: 4096,
+log_pubkey_units: 100,
+```
+
+Then the program
+
+- Could execute 200,000 BPF instructions if it does nothing else
+- Could log 2,000 log messages
+- Can not exceed 4k of stack usage
+- Can not exceed a BPF call depth of 64
+- Cannot exceed 4 levels of cross-program invocations.
+
+Since the compute budget is consumed incrementally as the program executes the
+total budget consumption will be a combination of the various costs of the
+operations it performs.
+
+At runtime a program may log how much of the compute budget remains. See
+[debugging](developing/on-chain-programs/debugging.md#monitoring-compute-budget-consumption)
+for more information.
+
+The budget values are conditional on feature enablement, take a look at the
+compute budget's
+[new](https://github.com/solana-labs/solana/blob/d3a3a7548c857f26ec2cb10e270da72d373020ec/sdk/src/process_instruction.rs#L97)
+function to find out how the budget is constructed. An understanding of how
+[features](runtime.md#features) work and what features are enabled on the
+cluster being used are required to determine the current budget's values.
+
+## New Features
+
+As Solana evolves, new features or patches may be introduced that changes the
+behavior of the cluster and how programs run. Changes in behavior must be
+coordinated between the various nodes of the cluster, if nodes do not coordinate
+then these changes can result in a break-down of consensus. Solana supports a
+mechanism called runtime features to facilitate the smooth adoption of changes.
+
+Runtime features are epoch coordinated events where one or more behavior changes
+to the cluster will occur. New changes to Solana that will change behavior are
+wrapped with feature gates and disabled by default. The Solana tools are then
+used to activate a feature, which marks it pending, once marked pending the
+feature will be activated at the next epoch.
+
+To determine which features are activated use the [Solana command-line
+tools](cli/install-solana-cli-tools.md):
+
+```bash
+solana feature status
+```
+
+If you encounter problems first ensure that the Solana tools version you are
+using match the version returned by `solana cluster-version`. If they do not
+match [install the correct tool suite](cli/install-solana-cli-tools.md).

package/src/developing/programming-model/transactions.md

@@ -0,0 +1,210 @@
+---
+title: "Transactions"
+---
+
+Program execution begins with a [transaction](terminology.md#transaction) being
+submitted to the cluster. The Solana runtime will execute a program to process
+each of the [instructions](terminology.md#instruction) contained in the
+transaction, in order, and atomically.
+
+## Anatomy of a Transaction
+
+This section covers the binary format of a transaction.
+
+### Transaction Format
+
+A transaction contains a [compact-array](#compact-array-format) of signatures,
+followed by a [message](#message-format). Each item in the signatures array is
+a [digital signature](#signature-format) of the given message. The Solana
+runtime verifies that the number of signatures matches the number in the first
+8 bits of the [message header](#message-header-format). It also verifies that
+each signature was signed by the private key corresponding to the public key at
+the same index in the message's account addresses array.
+
+#### Signature Format
+
+Each digital signature is in the ed25519 binary format and consumes 64 bytes.
+
+### Message Format
+
+A message contains a [header](#message-header-format), followed by a
+compact-array of [account addresses](#account-addresses-format), followed by a
+recent [blockhash](#blockhash-format), followed by a compact-array of
+[instructions](#instruction-format).
+
+#### Message Header Format
+
+The message header contains three unsigned 8-bit values. The first value is the
+number of required signatures in the containing transaction. The second value
+is the number of those corresponding account addresses that are read-only. The
+third value in the message header is the number of read-only account addresses
+not requiring signatures.
+
+#### Account Addresses Format
+
+The addresses that require signatures appear at the beginning of the account
+address array, with addresses requesting write access first and read-only
+accounts following. The addresses that do not require signatures follow the
+addresses that do, again with read-write accounts first and read-only accounts
+following.
+
+#### Blockhash Format
+
+A blockhash contains a 32-byte SHA-256 hash. It is used to indicate when a
+client last observed the ledger. Validators will reject transactions when the
+blockhash is too old.
+
+### Instruction Format
+
+An instruction contains a program id index, followed by a compact-array of
+account address indexes, followed by a compact-array of opaque 8-bit data. The
+program id index is used to identify an on-chain program that can interpret the
+opaque data. The program id index is an unsigned 8-bit index to an account
+address in the message's array of account addresses. The account address
+indexes are each an unsigned 8-bit index into that same array.
+
+### Compact-Array Format
+
+A compact-array is serialized as the array length, followed by each array item.
+The array length is a special multi-byte encoding called compact-u16.
+
+#### Compact-u16 Format
+
+A compact-u16 is a multi-byte encoding of 16 bits. The first byte contains the
+lower 7 bits of the value in its lower 7 bits. If the value is above 0x7f, the
+high bit is set and the next 7 bits of the value are placed into the lower 7
+bits of a second byte. If the value is above 0x3fff, the high bit is set and
+the remaining 2 bits of the value are placed into the lower 2 bits of a third
+byte.
+
+### Account Address Format
+
+An account address is 32-bytes of arbitrary data. When the address requires a
+digital signature, the runtime interprets it as the public key of an ed25519
+keypair.
+
+## Instructions
+
+Each [instruction](terminology.md#instruction) specifies a single program, a
+subset of the transaction's accounts that should be passed to the program, and a
+data byte array that is passed to the program. The program interprets the data
+array and operates on the accounts specified by the instructions. The program
+can return successfully, or with an error code. An error return causes the
+entire transaction to fail immediately.
+
+Programs typically provide helper functions to construct instructions they
+support. For example, the system program provides the following Rust helper to
+construct a
+[`SystemInstruction::CreateAccount`](https://github.com/solana-labs/solana/blob/6606590b8132e56dab9e60b3f7d20ba7412a736c/sdk/program/src/system_instruction.rs#L63)
+instruction:
+
+```rust
+pub fn create_account(
+    from_pubkey: &Pubkey,
+    to_pubkey: &Pubkey,
+    lamports: u64,
+    space: u64,
+    owner: &Pubkey,
+) -> Instruction {
+    let account_metas = vec![
+        AccountMeta::new(*from_pubkey, true),
+        AccountMeta::new(*to_pubkey, true),
+    ];
+    Instruction::new_with_bincode(
+        system_program::id(),
+        &SystemInstruction::CreateAccount {
+            lamports,
+            space,
+            owner: *owner,
+        },
+        account_metas,
+    )
+}
+```
+
+Which can be found here:
+
+https://github.com/solana-labs/solana/blob/6606590b8132e56dab9e60b3f7d20ba7412a736c/sdk/program/src/system_instruction.rs#L220
+
+### Program Id
+
+The instruction's [program id](terminology.md#program-id) specifies which
+program will process this instruction. The program's account's owner specifies
+which loader should be used to load and execute the program and the data
+contains information about how the runtime should execute the program.
+
+In the case of [on-chain BPF programs](developing/on-chain-programs/overview.md),
+the owner is the BPF Loader and the account data holds the BPF bytecode. Program
+accounts are permanently marked as executable by the loader once they are
+successfully deployed. The runtime will reject transactions that specify programs
+that are not executable.
+
+Unlike on-chain programs, [Native Programs](developing/runtime-facilities/programs.md)
+are handled differently in that they are built directly into the Solana runtime.
+
+### Accounts
+
+The accounts referenced by an instruction represent on-chain state and serve as
+both the inputs and outputs of a program. More information about Accounts can be
+found in the [Accounts](accounts.md) section.
+
+### Instruction data
+
+Each instruction caries a general purpose byte array that is passed to the
+program along with the accounts. The contents of the instruction data is program
+specific and typically used to convey what operations the program should
+perform, and any additional information those operations may need above and
+beyond what the accounts contain.
+
+Programs are free to specify how information is encoded into the instruction
+data byte array. The choice of how data is encoded should take into account the
+overhead of decoding since that step is performed by the program on-chain. It's
+been observed that some common encodings (Rust's bincode for example) are very
+inefficient.
+
+The [Solana Program Library's Token
+program](https://github.com/solana-labs/solana-program-library/tree/master/token)
+gives one example of how instruction data can be encoded efficiently, but note
+that this method only supports fixed sized types. Token utilizes the
+[Pack](https://github.com/solana-labs/solana/blob/master/sdk/program/src/program_pack.rs)
+trait to encode/decode instruction data for both token instructions as well as
+token account states.
+
+### Multiple instructions in a single transaction
+
+A transaction can contain instructions in any order. This means a malicious
+user could craft transactions that may pose instructions in an order that the
+program has not been protected against. Programs should be hardened to properly
+and safely handle any possible instruction sequence.
+
+One not so obvious example is account deinitialization. Some programs may
+attempt to deinitialize an account by setting its lamports to zero, with the
+assumption that the runtime will delete the account. This assumption may be
+valid between transactions, but it is not between instructions or cross-program
+invocations. To harden against this, the program should also explicitly zero out the
+account's data.
+
+An example of where this could be a problem is if a token program, upon
+transferring the token out of an account, sets the account's lamports to zero,
+assuming it will be deleted by the runtime. If the program does not zero out the
+account's data, a malicious user could trail this instruction with another that
+transfers the tokens a second time.
+
+## Signatures
+
+Each transaction explicitly lists all account public keys referenced by the
+transaction's instructions. A subset of those public keys are each accompanied
+by a transaction signature. Those signatures signal on-chain programs that the
+account holder has authorized the transaction. Typically, the program uses the
+authorization to permit debiting the account or modifying its data. More
+information about how the authorization is communicated to a program can be
+found in [Accounts](accounts.md#signers)
+
+## Recent Blockhash
+
+A transaction includes a recent [blockhash](terminology.md#blockhash) to prevent
+duplication and to give transactions lifetimes. Any transaction that is
+completely identical to a previous one is rejected, so adding a newer blockhash
+allows multiple transactions to repeat the exact same action. Transactions also
+have lifetimes that are defined by the blockhash, as any transaction whose
+blockhash is too old will be rejected.

package/src/developing/runtime-facilities/programs.md

@@ -0,0 +1,168 @@
+---
+title: "Native Programs"
+---
+
+Solana contains a small handful of native programs, which are required to run
+validator nodes. Unlike third-party programs, the native programs are part of
+the validator implementation and can be upgraded as part of cluster upgrades.
+Upgrades may occur to add features, fix bugs, or improve performance. Interface
+changes to individual instructions should rarely, if ever, occur. Instead, when
+change is needed, new instructions are added and previous ones are marked
+deprecated. Apps can upgrade on their own timeline without concern of breakages
+across upgrades.
+
+For each native program the program id and description each supported
+instruction is provided. A transaction can mix and match instructions from different
+programs, as well include instructions from on-chain programs.
+
+## System Program
+
+Create new accounts, allocate account data, assign accounts to owning programs,
+transfer lamports from System Program owned accounts and pay transacation fees.
+
+- Program id: `11111111111111111111111111111111`
+- Instructions: [SystemInstruction](https://docs.rs/solana-sdk/VERSION_FOR_DOCS_RS/solana_sdk/system_instruction/enum.SystemInstruction.html)
+
+## Config Program
+
+Add configuration data to the chain and the list of public keys that are permitted to modify it
+
+- Program id: `Config1111111111111111111111111111111111111`
+- Instructions: [config_instruction](https://docs.rs/solana-config-program/VERSION_FOR_DOCS_RS/solana_config_program/config_instruction/index.html)
+
+Unlike the other programs, the Config program does not define any individual
+instructions. It has just one implicit instruction, a "store" instruction. Its
+instruction data is a set of keys that gate access to the account, and the
+data to store in it.
+
+## Stake Program
+
+Create and manage accounts representing stake and rewards for delegations to
+validators.
+
+- Program id: `Stake11111111111111111111111111111111111111`
+- Instructions: [StakeInstruction](https://docs.rs/solana-sdk/VERSION_FOR_DOCS_RS/solana_sdk/stake/instruction/enum.StakeInstruction.html)
+
+## Vote Program
+
+Create and manage accounts that track validator voting state and rewards.
+
+- Program id: `Vote111111111111111111111111111111111111111`
+- Instructions: [VoteInstruction](https://docs.rs/solana-vote-program/VERSION_FOR_DOCS_RS/solana_vote_program/vote_instruction/enum.VoteInstruction.html)
+
+## BPF Loader
+
+Deploys, upgrades, and executes programs on the chain.
+
+- Program id: `BPFLoaderUpgradeab1e11111111111111111111111`
+- Instructions: [LoaderInstruction](https://docs.rs/solana-sdk/VERSION_FOR_DOCS_RS/solana_sdk/loader_upgradeable_instruction/enum.UpgradeableLoaderInstruction.html)
+
+The BPF Upgradeable Loader marks itself as "owner" of the executable and
+program-data accounts it creates to store your program. When a user invokes an
+instruction via a program id, the Solana runtime will load both your the program
+and its owner, the BPF Upgradeable Loader. The runtime then passes your program
+to the BPF Upgradeable Loader to process the instruction.
+
+[More information about deployment](cli/deploy-a-program.md)
+
+## Ed25519 Program
+
+Verify ed25519 signature program. This program takes an ed25519 signature, public key, and message.
+Multiple signatures can be verified. If any of the signatures fail to verify, an error is returned.
+
+- Program id: `Ed25519SigVerify111111111111111111111111111`
+- Instructions: [new_ed25519_instruction](https://github.com/solana-labs/solana/blob/master/sdk/src/ed25519_instruction.rs#L45)
+
+The ed25519 program processes an instruction. The first `u8` is a count of the number of
+signatures to check, which is followed by a single byte padding. After that, the
+following struct is serialized, one for each signature to check.
+
+```
+struct Ed25519SignatureOffsets {
+    signature_offset: u16,             // offset to ed25519 signature of 64 bytes
+    signature_instruction_index: u16,  // instruction index to find signature
+    public_key_offset: u16,            // offset to public key of 32 bytes
+    public_key_instruction_index: u16, // instruction index to find public key
+    message_data_offset: u16,          // offset to start of message data
+    message_data_size: u16,            // size of message data
+    message_instruction_index: u16,    // index of instruction data to get message data
+}
+```
+
+Pseudo code of the operation:
+
+```
+process_instruction() {
+    for i in 0..count {
+        // i'th index values referenced:
+        instructions = &transaction.message().instructions
+        instruction_index = ed25519_signature_instruction_index != u16::MAX ? ed25519_signature_instruction_index : current_instruction;
+        signature = instructions[instruction_index].data[ed25519_signature_offset..ed25519_signature_offset + 64]
+        instruction_index = ed25519_pubkey_instruction_index != u16::MAX ? ed25519_pubkey_instruction_index : current_instruction;
+        pubkey = instructions[instruction_index].data[ed25519_pubkey_offset..ed25519_pubkey_offset + 32]
+        instruction_index = ed25519_message_instruction_index != u16::MAX ? ed25519_message_instruction_index : current_instruction;
+        message = instructions[instruction_index].data[ed25519_message_data_offset..ed25519_message_data_offset + ed25519_message_data_size]
+        if pubkey.verify(signature, message) != Success {
+            return Error
+        }
+    }
+    return Success
+}
+```
+
+## Secp256k1 Program
+
+Verify secp256k1 public key recovery operations (ecrecover).
+
+- Program id: `KeccakSecp256k11111111111111111111111111111`
+- Instructions: [new_secp256k1_instruction](https://github.com/solana-labs/solana/blob/1a658c7f31e1e0d2d39d9efbc0e929350e2c2bcb/sdk/src/secp256k1_instruction.rs#L31)
+
+The secp256k1 program processes an instruction which takes in as the first byte
+a count of the following struct serialized in the instruction data:
+
+```
+struct Secp256k1SignatureOffsets {
+    secp_signature_key_offset: u16,        // offset to [signature,recovery_id,etherum_address] of 64+1+20 bytes
+    secp_signature_instruction_index: u8,  // instruction index to find data
+    secp_pubkey_offset: u16,               // offset to [signature,recovery_id] of 64+1 bytes
+    secp_signature_instruction_index: u8,  // instruction index to find data
+    secp_message_data_offset: u16,         // offset to start of message data
+    secp_message_data_size: u16,           // size of message data
+    secp_message_instruction_index: u8,    // index of instruction data to get message data
+}
+```
+
+Pseudo code of the operation:
+
+```
+process_instruction() {
+  for i in 0..count {
+      // i'th index values referenced:
+      instructions = &transaction.message().instructions
+      signature = instructions[secp_signature_instruction_index].data[secp_signature_offset..secp_signature_offset + 64]
+      recovery_id = instructions[secp_signature_instruction_index].data[secp_signature_offset + 64]
+      ref_eth_pubkey = instructions[secp_pubkey_instruction_index].data[secp_pubkey_offset..secp_pubkey_offset + 32]
+      message_hash = keccak256(instructions[secp_message_instruction_index].data[secp_message_data_offset..secp_message_data_offset + secp_message_data_size])
+      pubkey = ecrecover(signature, recovery_id, message_hash)
+      eth_pubkey = keccak256(pubkey[1..])[12..]
+      if eth_pubkey != ref_eth_pubkey {
+          return Error
+      }
+  }
+  return Success
+}
+```
+
+This allows the user to specify any instruction data in the transaction for
+signature and message data. By specifying a special instructions sysvar, one can
+also receive data from the transaction itself.
+
+Cost of the transaction will count the number of signatures to verify multiplied
+by the signature cost verify multiplier.
+
+### Optimization notes
+
+The operation will have to take place after (at least partial) deserialization,
+but all inputs come from the transaction data itself, this allows it to be
+relatively easy to execute in parallel to transaction processing and PoH
+verification.

package/src/developing/runtime-facilities/sysvars.md

@@ -0,0 +1,142 @@
+---
+title: Sysvar Cluster Data
+---
+
+Solana exposes a variety of cluster state data to programs via
+[`sysvar`](terminology.md#sysvar) accounts. These accounts are populated at
+known addresses published along with the account layouts in the
+[`solana-program`
+crate](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/sysvar/index.html),
+and outlined below.
+
+There are two ways for a program to access a sysvar.
+
+The first is to query the sysvar at runtime via the sysvar's `get()` function:
+
+```
+let clock = Clock::get()
+```
+
+The following sysvars support `get`:
+- Clock
+- EpochSchedule
+- Fees
+- Rent
+
+The second is to pass the sysvar to the program as an account by including its address as one of the accounts in the `Instruction` and then deserializing the data during execution.  Access to sysvars accounts is
+always _readonly_.
+
+```
+let clock_sysvar_info = next_account_info(account_info_iter)?;
+let clock = Clock::from_account_info(&clock_sysvar_info)?;
+```
+
+The first method is more efficient and does not require that the sysvar account be passed to the program, or specified in the `Instruction` the program is processing.
+
+## Clock
+
+The Clock sysvar contains data on cluster time, including the current slot,
+epoch, and estimated wall-clock Unix timestamp. It is updated every slot.
+
+- Address: `SysvarC1ock11111111111111111111111111111111`
+- Layout: [Clock](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/clock/struct.Clock.html)
+- Fields:
+
+  - `slot`: the current slot
+  - `epoch_start_timestamp`: the Unix timestamp of the first slot in this epoch. In the first slot of an epoch, this timestamp is identical to the `unix_timestamp` (below).
+  - `epoch`: the current epoch
+  - `leader_schedule_epoch`: the most recent epoch for which the leader schedule has already been generated
+  - `unix_timestamp`: the Unix timestamp of this slot.
+
+  Each slot has an estimated duration based on Proof of History. But in reality,
+  slots may elapse faster and slower than this estimate. As a result, the Unix
+  timestamp of a slot is generated based on oracle input from voting validators.
+  This timestamp is calculated as the stake-weighted median of timestamp
+  estimates provided by votes, bounded by the expected time elapsed since the
+  start of the epoch.
+
+  More explicitly: for each slot, the most recent vote timestamp provided by
+  each validator is used to generate a timestamp estimate for the current slot
+  (the elapsed slots since the vote timestamp are assumed to be
+  Bank::ns_per_slot). Each timestamp estimate is associated with the stake
+  delegated to that vote account to create a distribution of timestamps by
+  stake. The median timestamp is used as the `unix_timestamp`, unless the
+  elapsed time since the `epoch_start_timestamp` has deviated from the expected
+  elapsed time by more than 25%.
+
+## EpochSchedule
+
+The EpochSchedule sysvar contains epoch scheduling constants that are set in
+genesis, and enables calculating the number of slots in a given epoch, the epoch
+for a given slot, etc. (Note: the epoch schedule is distinct from the [`leader schedule`](terminology.md#leader-schedule))
+
+- Address: `SysvarEpochSchedu1e111111111111111111111111`
+- Layout:
+  [EpochSchedule](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/epoch_schedule/struct.EpochSchedule.html)
+
+## Fees
+
+The Fees sysvar contains the fee calculator for the current slot. It is updated
+every slot, based on the fee-rate governor.
+
+- Address: `SysvarFees111111111111111111111111111111111`
+- Layout:
+  [Fees](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/sysvar/fees/struct.Fees.html)
+
+## Instructions
+
+The Instructions sysvar contains the serialized instructions in a Message while
+that Message is being processed. This allows program instructions to reference
+other instructions in the same transaction. Read more information on
+[instruction introspection](implemented-proposals/instruction_introspection.md).
+
+- Address: `Sysvar1nstructions1111111111111111111111111`
+- Layout:
+  [Instructions](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/sysvar/instructions/struct.Instructions.html)
+
+## RecentBlockhashes
+
+The RecentBlockhashes sysvar contains the active recent blockhashes as well as
+their associated fee calculators. It is updated every slot. Entries are ordered
+by descending block height, so the first entry holds the most recent block hash,
+and the last entry holds an old block hash.
+
+- Address: `SysvarRecentB1ockHashes11111111111111111111`
+- Layout:
+  [RecentBlockhashes](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/sysvar/recent_blockhashes/struct.RecentBlockhashes.html)
+
+## Rent
+
+The Rent sysvar contains the rental rate. Currently, the rate is static and set
+in genesis. The Rent burn percentage is modified by manual feature activation.
+
+- Address: `SysvarRent111111111111111111111111111111111`
+- Layout:
+  [Rent](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/rent/struct.Rent.html)
+
+## SlotHashes
+
+The SlotHashes sysvar contains the most recent hashes of the slot's parent
+banks. It is updated every slot.
+
+- Address: `SysvarS1otHashes111111111111111111111111111`
+- Layout:
+  [SlotHashes](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/slot_hashes/struct.SlotHashes.html)
+
+## SlotHistory
+
+The SlotHistory sysvar contains a bitvector of slots present over the last
+epoch. It is updated every slot.
+
+- Address: `SysvarS1otHistory11111111111111111111111111`
+- Layout:
+  [SlotHistory](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/slot_history/struct.SlotHistory.html)
+
+## StakeHistory
+
+The StakeHistory sysvar contains the history of cluster-wide stake activations
+and de-activations per epoch. It is updated at the start of every epoch.
+
+- Address: `SysvarStakeHistory1111111111111111111111111`
+- Layout:
+  [StakeHistory](https://docs.rs/solana-program/VERSION_FOR_DOCS_RS/solana_program/stake_history/struct.StakeHistory.html)