Update README.md (#7284)

Update description of stages
This commit is contained in:
Reinhard Schu 2023-04-10 02:46:10 +01:00 committed by GitHub
parent caadb16b42
commit cbe92dc6a4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -71,7 +71,11 @@ Most of the stages can work offline though it isn't implemented in the current v
We can add/remove stages, so exact stage numbers may change - but order and names stay the same.
### Stage 1: [Download Headers Stage](/eth/stagedsync/stage_headers.go)
### Stage 1: [Snapshots](/eth/stagedsync/stage_snapshots.go)
Download Snapshots
### Stage 2: [Download Headers Stage](/eth/stagedsync/stage_headers.go)
During this stage we download all the headers between the local HEAD and our peer's head.
@ -81,17 +85,21 @@ Most of the unwinds are initiated on this stage due to the chain reorgs.
This stage promotes local HEAD pointer.
### Stage 2: [Block Hashes](/eth/stagedsync/stage_blockhashes.go)
### Stage 3: [Cumulative Index](/eth/stagedsync/stage_cumulative_index.go)
Calculate how much gas has been used up to each block.
### Stage 4: [Block Hashes](/eth/stagedsync/stage_blockhashes.go)
Creates an index of blockHash -> blockNumber extracted from the headers for faster lookups and making the sync friendlier for HDDs.
### Stage 4: [Download Block Bodies Stage](/eth/stagedsync/stage_bodies.go)
### Stage 5: [Download Block Bodies Stage](/eth/stagedsync/stage_bodies.go)
At that stage, we download bodies for block headers that we already downloaded.
That is the most intensive stage for the network connection, the vast majority of data is downloaded here.
### Stage 5: [Recover Senders Stage](/eth/stagedsync/stage_senders.go)
### Stage 6: [Recover Senders Stage](/eth/stagedsync/stage_senders.go)
This stage recovers and stores senders for each transaction in each downloaded block.
@ -99,7 +107,7 @@ This is also a CPU intensive stage and also benefits from multi-core CPUs.
This stage doesn't use any network connection.
### Stage 6: [Execute Blocks Stage](/eth/stagedsync/stage_execute.go)
### Stage 7: [Execute Blocks Stage](/eth/stagedsync/stage_execute.go)
During this stage, we execute block-by-block everything that we downloaded before.
@ -113,23 +121,16 @@ This stage is disk intensive.
This stage can spawn unwinds if the block execution fails.
### Stage 7: [Transpile marked VM contracts to TEVM](/eth/stagedsync/stage_tevm.go)
### Stage 8: [Transpile marked VM contracts to TEVM](/eth/stagedsync/stage_tevm.go)
Translation each marked for translation contract (from EVM to TEVM)
### Stage 9: [VerkleTrie](/eth/stagedsync/stage_verkle_trie.go)
[TODO]
### Stage 8: [Generate Hashed State Stage](/eth/stagedsync/stage_hashstate.go)
Erigon during execution uses Plain state storage.
> Plain State: Instead of the normal (we call it "Hashed State") where accounts and storage items are addressed as `keccak256(address)`, in the plain state them are addressed by the `address` itself.
Though, to make sure that some APIs work and keep the compatibility with the other clients, we generate Hashed state as well.
If the hashed state is not empty, then we are looking at the History ChangeSets and update only the items that were changed.
This stage doesn't use a network connection.
### Stage 9: [Compute State Root Stage](/eth/stagedsync/stage_interhashes.go)
### Stage 10: [Compute State Root Stage](/eth/stagedsync/stage_interhashes.go)
This stage build the Merkle trie and checks the root hash for the current state.
@ -143,13 +144,22 @@ If the root hash doesn't match, it initiates an unwind one block backwards.
This stage doesn't use a network connection.
### Stage 10: [Generate call traces index](/eth/stagedsync/stage_call_traces.go)
### Stage 11: [Generate Hashed State Stage](/eth/stagedsync/stage_hashstate.go)
[TODO]
Erigon during execution uses Plain state storage.
### Stages [11, 12](/eth/stagedsync/stage_indexes.go), [13](/eth/stagedsync/stage_log_index.go), and [14](/eth/stagedsync/stage_txlookup.go): Generate Indexes
> Plain State: Instead of the normal (we call it "Hashed State") where accounts and storage items are addressed as `keccak256(address)`, in the plain state them are addressed by the `address` itself.
There are 4 indexes that are generated during sync.
Though, to make sure that some APIs work and keep the compatibility with the other clients, we generate Hashed state as well.
If the hashed state is not empty, then we are looking at the History ChangeSets and update only the items that were changed.
This stage doesn't use a network connection.
### Stages [12, 13](/eth/stagedsync/stage_indexes.go), [14](/eth/stagedsync/stage_log_index.go), [15](/eth/stagedsync/stage_call_traces.go) and [16](/eth/stagedsync/stage_txlookup.go): Generate Indexes
There are 5 indexes that are generated during sync.
They might be disabled because they aren't used for all the APIs.
@ -167,11 +177,15 @@ This index stores the mapping from the storage item address to the list of block
This index sets up a link from the [TODO] to [TODO].
**Call traces index**
[TODO]
**Tx Lookup Index**
This index sets up a link from the transaction hash to the block number.
### Stage 15: [Transaction Pool Stage](/eth/stagedsync/stage_txpool.go)
### Stage 16: [Transaction Pool Stage](/eth/stagedsync/stage_txpool.go)
During this stage we start the transaction pool or update its state. For instance, we remove the transactions from the blocks we have downloaded from the pool.
@ -179,6 +193,6 @@ On unwinds, we add the transactions from the blocks we unwind, back to the pool.
This stage doesn't use a network connection.
### Stage 16: Finish
### Stage 17: Finish
This stage sets the current block number that is then used by [RPC calls](../../cmd/rpcdaemon/README.md), such as [`eth_blockNumber`](../../README.md).