jleony/nanoreth
1
0
Fork 0
mirror of https://github.com/hl-archive-node/nanoreth.git synced 2025-12-06 19:09:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore(db): modify state transition docs (#515)

Browse Source
This commit is contained in:
Roman Krasiuk
2022-12-20 11:31:23 +02:00
committed by GitHub
parent 82cd84eca7
commit c68a850c70
2 changed files with 40 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
crates/storage/db/src/tables/mod.rs
View File

@ -232,12 +232,12 @@ table!(
/// } /// }
/// ``` /// ```
/// ///
( AccountHistory ) ShardedKey<Address> | TxNumberList ( AccountHistory ) ShardedKey<Address> | TransitionList
); );
table!( table!(
/// Stores pointers to transactions that changed each storage key. /// Stores pointers to transactions that changed each storage key.
( StorageHistory ) AddressStorageKey | TxNumberList ( StorageHistory ) AddressStorageKey | TransitionList
); );
dupsort!( dupsort!(
@ -275,7 +275,7 @@ table!(
/// Alias Types /// Alias Types
/// List with transaction numbers. /// List with transaction numbers.
pub type TxNumberList = IntegerList; pub type TransitionList = IntegerList;
/// Encoded stage id. /// Encoded stage id.
pub type StageId = Vec<u8>; pub type StageId = Vec<u8>;

57
docs/design/database.md
View File

@ -25,18 +25,17 @@
# Table design # Table design
We do Transaction-granularity indexing. This means that we store the state for every account after every transaction that touched it, and we provide indexes for accessing that quickly. Historical state changes are indexed by autoincrementing enumeration called `TransitionId`. This means that `reth` stores the state for every account after every transaction that touched it, and it provides indexes for accessing that data quickly. While this may make the database size bigger (needs benchmark once `reth` is closer to prod), it also enables blazing-fast historical tracing and simulations because there is no need to re-execute all transactions inside a block.
While this may make the database size bigger (and we need to benchmark this once we're closer to prod) it also enables blazing-fast historical tracing and simulations because we
don't need to re-execute all transactions inside a block. State transitions differ from transaction level enumeration in order to account for block rewards.
e.g. If block #1 contains transactions from id 0 to 5 (inclusive) and has a reward, the reward will be assigned transition id 6 and transition ids in block #2 will start block index 7.
Two additional tables `TxTransitionIdIndex` and `BlockTransitionIdIndex` are introduced to enable reverse lookup of transition by transaction id and block number respectively. The transition id at block number denotes the final state transition of the block. If block has a reward, the state transition at block number `x` points at data about the state transition for the reward distribution. Otherwise, it points to the state transition at the last transaction in block number `x`.
Below, you can see the table design that implements this scheme: Below, you can see the table design that implements this scheme:
```mermaid ```mermaid
erDiagram erDiagram
TransactionHash ||--o{ TxChangeIdIndex : index
BlockChangeIdIndex ||--o{ ChangeSet : "unique index"
History ||--o{ ChangeSet : index
TxChangeIdIndex ||--o{ ChangeSet : "unique index"
Transactions { Transactions {
u64 TxNumber "PK" u64 TxNumber "PK"
Transaction Data Transaction Data
@ -45,24 +44,42 @@ TransactionHash {
H256 TxHash "PK" H256 TxHash "PK"
u64 TxNumber u64 TxNumber
} }
TxChangeIdIndex { TxTransitionIdIndex {
u64 TxNumber "PK" u64 TxNumber "PK"
u64 ChangeId u64 TransitionId
} }
BlockChangeIdIndex { BlockTransitionIdIndex {
u64 BlockNumber "PK" u64 BlockNumber "PK"
u64 ChangeId u64 TransitionId
} }
ChangeSet { AccountHistory {
u64 ChangeId "PK"
ChangeSet PreviousValues "[Acc1[Balance,Nonce),Acc2(Balance,Nonce)] Previous values"
}
History {
H256 Account "PK" H256 Account "PK"
u64 ChangeIdList "[ChangeId,ChangeId,...] Points where account changed" TransitionList TransitionIdList "List of transitions where account was changed"
} }
EVM ||--o{ History: "Load Account by finding first bigger ChangeId in List, and index it in ChangeSet table" StorageHistory {
BlockChangeIdIndex ||--o{ EVM : "Use state (by block Changeid)" H256 Account "PK"
TxChangeIdIndex ||--o{ EVM : "Use state (by tx ChangeId)" H256 StorageKey "PK"
TransitionList TransitionIdList "List of transitions where account storage entry was changed"
}
AccountChangeSet {
u64 TransitionId "PK"
H256 Account "PK"
ChangeSet AccountChangeSet "Account before transition"
}
StorageChangeSet {
u64 TransitionId "PK"
H256 Account "PK"
H256 StorageKey "PK"
ChangeSet StorageChangeSet "Storage entry before transition"
}
EVM ||--o{ AccountHistory: "Load Account by first greater TransitionId"
EVM ||--o{ StorageHistory: "Load Storage Entry by first greater TransitionId"
TransactionHash ||--o{ Transactions : index TransactionHash ||--o{ Transactions : index
Transactions ||--o{ TxTransitionIdIndex : index
AccountHistory ||--o{ AccountChangeSet : index
BlockTransitionIdIndex ||--o{ AccountChangeSet : "unique index"
TxTransitionIdIndex ||--o{ AccountChangeSet : "unique index"
StorageHistory ||--o{ StorageChangeSet : index
BlockTransitionIdIndex ||--o{ StorageChangeSet : "unique index"
TxTransitionIdIndex ||--o{ StorageChangeSet : "unique index"
``` ```