The following terms are used throughout the documentation.
A record in the Solana ledger that either holds data or is an executable program.
The key may be one of:
- an ed25519 public key
- a program-derived account address (32byte value forced off the ed25519 curve)
- a hash of an ed25519 public key with a 32 character string
The address of the program that owns the account. Only the owning program is capable of modifying the account.
A front-end application that interacts with a Solana cluster.
The Solana program that owns and loads BPF smart contract programs, allowing the program to interface with the runtime.
A computer program that accesses the Solana server network cluster.
Some number of epochs after stake has been deactivated while it progressively becomes available for withdrawal. During this period, the stake is considered to be "deactivating". More info about: warmup and cooldown
See vote credit.
A call from one smart contract program to another. For more information, see calling between programs.
A multicast network used to efficiently validate entries and gain consensus.
An off-chain service that acts as a custodian for a user's private key. It typically serves to validate and sign transactions.
- The entry being generated after a duration of time
- The specified transactions are those included in the entry
- The entry's position with respect to other entries in ledger
See proof of history.
The fee account in the transaction is the account pays for the cost of including the transaction in the ledger. This is the first account in the transaction. This account must be declared as Read-Write (writable) in the transaction since paying for the transaction reduces the account balance.
A ledger derived from common entries but then diverged.
The first block in the chain.
A digital fingerprint of a sequence of bytes.
An increase in token supply over time used to fund rewards for validation and to fund continued development of Solana.
The smallest contiguous unit of execution logic in a program. An instruction specifies which program it is calling, which accounts it wants to read or modify, and additional data that serves as auxiliary input to the program. A client can include one or multiple instructions in a transaction. An instruction may contain one or more cross-program invocations.
A list of entries containing transactions signed by clients. Conceptually, this can be traced back to the genesis block, but an actual validator's ledger may have only newer blocks to reduce storage, as older ones are not needed for validation of future blocks by design.
A hash of the validator's state at a given tick height. It comprises a validator's affirmation that a block it has received has been verified, as well as a promise not to vote for a conflicting block (i.e. fork) for a specific amount of time, the lockout period.
A program with the ability to interpret the binary encoding of other on-chain programs.
A computer participating in a cluster.
See Proof of History.
A weighted credit in a rewards regime. In the validator rewards regime, the number of points owed to a stake during redemption is the product of the vote credits earned and the number of lamports staked.
The private key of a keypair.
The code that interprets instructions.
An account whose owner is a program and thus is not controlled by a private key like other accounts.
A stack of proofs, each which proves that some data existed before the proof was created and that a precise duration of time passed before the previous proof. Like a VDF, a Proof of History can be verified in less time than it took to produce.
The public key of a keypair.
A block or slot that has reached maximum lockout on a validator. The root is the highest block that is an ancestor of all active forks on a validator. All ancestor blocks of a root are also transitively a root. Blocks that are not an ancestor and not a descendant of the root are excluded from consideration for consensus and can be discarded.
Solana's parallel smart contracts run-time.
A 64-byte ed25519 signature of R (32-bytes) and S (32-bytes). With the requirement that R is a packed Edwards point not of small order and S is a scalar in the range of 0 <= S < L. This requirement ensures no signature malleability. Each transaction must have at least one signature for fee account. Thus, the first signature in transaction can be treated as transacton id
A past slot that did not produce a block, because the leader was offline or the fork containing the slot was abandoned for a better alternative by cluster consensus. A skipped slot will not appear as an ancestor for blocks at subsequent slots, nor increment the block height, nor expire the oldest
Whether a slot has been skipped can only be determined when it becomes older than the latest rooted (thus not-skipped) slot.
Collectively, slots create a logical clock. Slots are ordered sequentially and non-overlapping, comprising roughly equal real-world time as per PoH.
A program on a blockchain that can read and modify accounts over which it has control.
A library of programs on Solana such as spl-token that facilitates tasks such as creating and using tokens
2/3 of a cluster.
A system account. Sysvars provide cluster state information such as current tick height, rewards points values, etc. Programs can access Sysvars via a Sysvar account (pubkey) or by querying via a syscall.
A ledger entry that estimates wallclock duration.
A digitally transferable asset.
Transactions per second.
A set of transactions that may be executed in parallel.
A function that takes a fixed amount of time to execute that produces a proof that it ran, which can then be verified in less time than it took to produce.
See ledger vote.
A collection of keypairs that allows users to manage their funds.