Erigon3 user guide

RAM requirement is higher: 64gb. We will reduce it in next releases.

Golang 1.21

Almost all RPC methods are implemented - if something doesn't work - just drop it on our head.

Supported networks: all (except Mumbai).

E3 changes from E2:

• Sync from scratch doesn't require re-exec all history. Latest state and it's history are in snapshots - can download.
• ExecutionStage - now including many E2 stages: stage_hash_state, stage_trie, stage_log_index, stage_history_index, stage_trace_index
• E3 can execute 1 historical transaction - without executing it's block - because history/indices have transaction-granularity, instead of block-granularity.
• E3 doesn't store Logs (aka Receipts) - it always re-executing historical txn (but it's cheaper then in E2 - see point above). Known perf issues: https://github.com/erigontech/erigon/issues/10747
• --sync.loop.block.limit is enabled by default. (Default: 5_000. Set --sync.loop.block.limit=10_000 --batchSize=2g to increase sync speed on good hardware).
• datadir/chaindata is small now - to prevent it's grow: we recommend set --batchSize <= 2G. And it's fine to rm -rf chaindata
• can symlink/mount latest state to fast drive and history to cheap drive
• Archive Node is default. Full Node: --prune.mode=full, Minimal Node (EIP-4444): --prune.mode=minimal

Known Problems of E3:

• eth_getLogs fields index always 0: https://github.com/erigontech/erigon/issues/10324

E3 datadir structure

datadir        
    chaindata   # "Recently-updated Latest State" and "Recent History"
    snapshots   
        domain    # Latest State: link to fast disk
        history   # Historical values 
        idx       # InvertedIndices: can search/filtering/union/intersect them - to find historical data. like eth_getLogs or trace_transaction
        accessors # Additional (generated) indices of history - have "random-touch" read-pattern. They can serve only `Get` requests (no search/filters).
    temp # buffers to sort data >> RAM. sequential-buffered IO - is slow-disk-friendly
   
# There is 4 domains: account, storage, code, commitment 

E3 can store state on fast disk and history on cheap disk

If you can afford store datadir on 1 nvme-raid - great. If can't - it's possible to store history on cheap drive.

# place (or ln -s) `datadir` on slow disk. link some sub-folders to fast disk.
# Example: what need link to fast disk to speedup execution
datadir        
    chaindata   # link to fast disk
    snapshots   
        domain    # link to fast disk
        history   
        idx       
        accessors 
    temp   

# Example: how to speedup history access: 
#   - go step-by-step - first try store `accessors` on fast disk
#   - if speed is not good enough: `idx`
#   - if still not enough: `history` 

E3 datadir size

# eth-mainnet - archive - April 2024

du -hsc /erigon/* 
6G  	/erigon/caplin
50G 	/erigon/chaindata
1.8T	/erigon/snapshots
1.9T	total

du -hsc /erigon/snapshots/* 
100G 	/erigon/snapshots/accessor
240G	/erigon/snapshots/domain
260G	/erigon/snapshots/history
410G	/erigon/snapshots/idx
1.7T	/erigon/snapshots

# bor-mainnet - archive - Jun 2024

du -hsc /erigon/* 

160M	/erigon/bor
50G 	/erigon/chaindata
3.7T	/erigon/snapshots
3.8T	total

du -hsc /erigon/snapshots/* 
260G	/erigon-data/snapshots/accessor
850G	/erigon-data/snapshots/domain
650G	/erigon-data/snapshots/history
1.4T	/erigon-data/snapshots/idx
4.1T	/erigon/snapshots

See also: https://github.com/erigontech/erigon?tab=readme-ov-file#erigon3-users-guide

Upgrade from Erigon2

No. Please re-sync.