Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(storage): rename tables #6787

Merged
merged 8 commits into from
Feb 27, 2024
Merged

feat(storage): rename tables #6787

merged 8 commits into from
Feb 27, 2024

Conversation

shekhirin
Copy link
Collaborator

@shekhirin shekhirin commented Feb 26, 2024

Work on top of #6062, it had too many conflicts, and it was easier to do a find-and-replace all over again. h/t to @JosepBove for the initial impl.

Tables

tables! {
/// Stores the header hashes belonging to the canonical chain.
table CanonicalHeaders<Key = BlockNumber, Value = HeaderHash>;
/// Stores the total difficulty from a block header.
table HeaderTerminalDifficulties<Key = BlockNumber, Value = CompactU256>;
/// Stores the block number corresponding to a header.
table HeaderNumbers<Key = BlockHash, Value = BlockNumber>;
/// Stores header bodies.
table Headers<Key = BlockNumber, Value = Header>;
/// Stores block indices that contains indexes of transaction and the count of them.
///
/// More information about stored indices can be found in the [`StoredBlockBodyIndices`] struct.
table BlockBodyIndices<Key = BlockNumber, Value = StoredBlockBodyIndices>;
/// Stores the uncles/ommers of the block.
table BlockOmmers<Key = BlockNumber, Value = StoredBlockOmmers>;
/// Stores the block withdrawals.
table BlockWithdrawals<Key = BlockNumber, Value = StoredBlockWithdrawals>;
/// Canonical only Stores the transaction body for canonical transactions.
table Transactions<Key = TxNumber, Value = TransactionSignedNoHash>;
/// Stores the mapping of the transaction hash to the transaction number.
table TransactionHashNumbers<Key = TxHash, Value = TxNumber>;
/// Stores the mapping of transaction number to the blocks number.
///
/// The key is the highest transaction ID in the block.
table TransactionBlocks<Key = TxNumber, Value = BlockNumber>;
/// Canonical only Stores transaction receipts.
table Receipts<Key = TxNumber, Value = Receipt>;
/// Stores all smart contract bytecodes.
/// There will be multiple accounts that have same bytecode
/// So we would need to introduce reference counter.
/// This will be small optimization on state.
table Bytecodes<Key = B256, Value = Bytecode>;
/// Stores the current state of an [`Account`].
table PlainAccountState<Key = Address, Value = Account>;
/// Stores the current value of a storage key.
table PlainStorageState<Key = Address, Value = StorageEntry, SubKey = B256>;
/// Stores pointers to block changeset with changes for each account key.
///
/// Last shard key of the storage will contain `u64::MAX` `BlockNumber`,
/// this would allows us small optimization on db access when change is in plain state.
///
/// Imagine having shards as:
/// * `Address | 100`
/// * `Address | u64::MAX`
///
/// What we need to find is number that is one greater than N. Db `seek` function allows us to fetch
/// the shard that equal or more than asked. For example:
/// * For N=50 we would get first shard.
/// * for N=150 we would get second shard.
/// * If max block number is 200 and we ask for N=250 we would fetch last shard and
/// know that needed entry is in `AccountPlainState`.
/// * If there were no shard we would get `None` entry or entry of different storage key.
///
/// Code example can be found in `reth_provider::HistoricalStateProviderRef`
table AccountsHistory<Key = ShardedKey<Address>, Value = BlockNumberList>;
/// Stores pointers to block number changeset with changes for each storage key.
///
/// Last shard key of the storage will contain `u64::MAX` `BlockNumber`,
/// this would allows us small optimization on db access when change is in plain state.
///
/// Imagine having shards as:
/// * `Address | StorageKey | 100`
/// * `Address | StorageKey | u64::MAX`
///
/// What we need to find is number that is one greater than N. Db `seek` function allows us to fetch
/// the shard that equal or more than asked. For example:
/// * For N=50 we would get first shard.
/// * for N=150 we would get second shard.
/// * If max block number is 200 and we ask for N=250 we would fetch last shard and
/// know that needed entry is in `StoragePlainState`.
/// * If there were no shard we would get `None` entry or entry of different storage key.
///
/// Code example can be found in `reth_provider::HistoricalStateProviderRef`
table StoragesHistory<Key = StorageShardedKey, Value = BlockNumberList>;
/// Stores the state of an account before a certain transaction changed it.
/// Change on state can be: account is created, selfdestructed, touched while empty
/// or changed balance,nonce.
table AccountChangeSets<Key = BlockNumber, Value = AccountBeforeTx, SubKey = Address>;
/// Stores the state of a storage key before a certain transaction changed it.
/// If [`StorageEntry::value`] is zero, this means storage was not existing
/// and needs to be removed.
table StorageChangeSets<Key = BlockNumberAddress, Value = StorageEntry, SubKey = B256>;
/// Stores the current state of an [`Account`] indexed with `keccak256Address`
/// This table is in preparation for merkelization and calculation of state root.
/// We are saving whole account data as it is needed for partial update when
/// part of storage is changed. Benefit for merkelization is that hashed addresses are sorted.
table HashedAccounts<Key = B256, Value = Account>;
/// Stores the current storage values indexed with `keccak256Address` and
/// hash of storage key `keccak256key`.
/// This table is in preparation for merkelization and calculation of state root.
/// Benefit for merklization is that hashed addresses/keys are sorted.
table HashedStorages<Key = B256, Value = StorageEntry, SubKey = B256>;
/// Stores the current state's Merkle Patricia Tree.
table AccountsTrie<Key = StoredNibbles, Value = StoredBranchNode>;
/// From HashedAddress => NibblesSubKey => Intermediate value
table StoragesTrie<Key = B256, Value = StorageTrieEntry, SubKey = StoredNibblesSubKey>;
/// Stores the transaction sender for each canonical transaction.
/// It is needed to speed up execution stage and allows fetching signer without doing
/// transaction signed recovery
table TransactionSenders<Key = TxNumber, Value = Address>;
/// Stores the highest synced block number and stage-specific checkpoint of each stage.
table StageCheckpoints<Key = StageId, Value = StageCheckpoint>;
/// Stores arbitrary data to keep track of a stage first-sync progress.
table StageCheckpointProgresses<Key = StageId, Value = Vec<u8>>;
/// Stores the highest pruned block number and prune mode of each prune segment.
table PruneCheckpoints<Key = PruneSegment, Value = PruneCheckpoint>;
}

@shekhirin shekhirin added C-debt Refactor of code section that is hard to understand or maintain A-db Related to the database S-breaking This PR includes a breaking change labels Feb 26, 2024
@shekhirin shekhirin marked this pull request as ready for review February 26, 2024 13:02
Copy link
Member

@emhane emhane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super clean, very helpful descriptive names. a lot of work though, this is why it's nice to just do proper names from the start.

comments (not caught by rustdocs) seem to check out with new naming, good!

crates/stages/src/stages/sender_recovery.rs Outdated Show resolved Hide resolved
crates/storage/provider/src/providers/database/metrics.rs Outdated Show resolved Hide resolved
crates/stages/src/stages/sender_recovery.rs Outdated Show resolved Hide resolved
@emhane emhane merged commit 46bb03f into breaking-changes Feb 27, 2024
25 checks passed
@emhane emhane deleted the alexey/rename-tables branch February 27, 2024 00:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-db Related to the database C-debt Refactor of code section that is hard to understand or maintain S-breaking This PR includes a breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants