SYNCHRONIZATION MODES
In order to keep up and authenticate data in the network, the Ethereum Client needs to sync with the latest network state. It is a 3-step process:
FULL
Downloads all blocks (including headers, transactions and receipts) and generates the state of the blockchain incrementally by executing every block from genesis.
- Minimizes trust and offers the highest security by verifying every transaction
-With increasing transactions, it can take days to weeks to process all transactions.
FAST
Downloads all blocks (including headers, transactions, and receipts), verifies all headers, downloads the state and verifies it against the headers.
- Relies on the security of the consensus mechanism.
-Synchronization takes only a few hours
LIGHT
Downloads all block headers, and block data, and verifies some randomly. Only syncs the tip of the chain from the trusted checkpoint.
- Gets only the latest state while relying on trust in developers and consensus mechanisms.
- Client ready to use with current network state in a few minutes.
SNAP
Snap sync is the latest approach to syncing a client, pioneered by the Geth team. Using dynamic snapshots served by peers retrieves all the account and storage data without downloading intermediate trie nodes and then reconstructs the Merkle trie locally.
- Fastest sync strategy, currently default in Ethereum mainnet
-Saves a lot of disk usage and network bandwidth without sacrificing security
Optimistic
Post-merge syncronization strategy designed to be opt in and backwards compatible, allowing execution nodes to sync via established methods. The execution engine can optimistically import Beacon blocks without fully verifying them, find the latest head, then start syncing the chain with the above methods. Then, after the execution client has caught up, it will inform the consensus client of the validity of the transaction in the Beacon chain.
Checkpoint
Also called a Weak Subjectivity Checkpoint. This mode creates a superior experience for syncing beacon nodes. It is based on the assumption of Weak Subjectivity. This enables a beacon node to sync from a recent weak subjectivity checkpoint instead of genesis. Initial sync time is quicker with the same trust assumptions as syncing from genesis. Nodes connect to a remote service to download the recent finalized state & continue verifying data from that point. 3rd party providing the data should be trusted and carefully picked.