AccountInfo represents a reference to AccountSharedData in either an AppendVec or the write cache.
AccountInfo is not persisted anywhere between program runs.
AccountInfo is purely runtime state.
Note that AccountInfo is saved to disk buckets during runtime, but disk buckets are recreated at startup.
Manage the map of slot -> append vec
Service to clean up dead slots in accounts_db
Persistent accounts are stored at this path location:
<path>/<pid>/data/
keep track of areas of the validator that are currently active
helpers for squashing append vecs into ancient append vecs
an ancient append vec is:
Persistent storage for accounts.
The bank module tracks client accounts and the progress of on-chain
programs.
Keep track of how many banks have been created and how many have been frozen or dropped.
This is useful to track foreground progress to understand expected access to accounts db.
The bank_forks module implements BankForks a DAG of checkpointed Banks
defines block cost related limits
Cached data for hashing accounts
Cached data for hashing accounts
’cost_model` provides service to estimate a transaction’s cost
following proposed fee schedule #16984; Relevant cluster cost
measuring is described by #19627
cost_tracker keeps tracking transaction cost per chained accounts as well as for entire block
The main functions are:
The Epoch Accounts Hash (EAH) is a special hash of the whole accounts state that occurs once
per epoch.
ReadOnlyAccountsCache used to store accounts, such as executable accounts,
which can be large, loaded many times, and rarely change.
calculate and collect rent from Accounts
Provide fast iteration of all pubkeys which could possibly be rent paying, grouped by rent collection partition
functionally similar to a hashset
Relies on there being a sliding window of key values. The key values continue to increase.
Old key values are removed from the lesser values and do not accumulate.
A wrapper around a root Bank that only loads from bank forks if the root has been updated.
This can be useful to avoid read-locking the bank forks until the root has been updated.
SharedBuffer is given a Reader and SharedBufferReader implements the Reader trait.
SharedBuffer reads ahead in the underlying file and saves the data.
SharedBufferReaders can be created for the buffer and independently keep track of each reader’s read location.
The background reader keeps track of the progress of each client. After data has been read by all readers,
the buffer is recycled and reading ahead continues.
A primary use case is the underlying reader being decompressing a file, which can be computationally expensive.
The clients of SharedBufferReaders could be parallel instances which need access to the decompressed data.
Information about snapshot archives
Helper types and functions for handling and dealing with snapshot hashes.
Used to create minimal snapshots - separated here to keep accounts_db simpler
This module implements clone-on-write semantics for the SDK’s StakeHistory to reduce
unnecessary cloning of the underlying vector.
Stakes serve as a cache of stake and vote accounts to derive
node stakes
trait for abstracting underlying storage of pubkey and account pairs to be written
at startup, verify accounts hash in the background