Introduction
Chain Synchronization (or more known as Chain Sync) refers to the process by which a peer in a blockchain network catches up with the current state of the blockchain, ensuring it has the latest and valid copy of the chain.
In decentralized systems like Bitcoin, Ethereum, or custom blockchains:
- peers can join the network at differents times
- they may not be up-to-date with the current head of the chain
- blocks are produced continuously
- a longer/heavier chain has been discovered
To handle these cases, it must download and verify all or some blocks to catch up.
It is the bootstrapping and updating mechanism that ensures every node in a blockchain P2P network eventually shares a consistent, verified view of the blockchain.
Full Synchronization
Full Synchronization is the most thorough method, where a node downloads every block and transaction from the genesis block up to the current height. This allows the node to fully reconstruct the entire ledger by verifying each block and applying every transaction.
The result is a fully trustless and independently validated state, suitable for full nodes, validators, and anyone who requires complete historical data.
Fast Synchronization
Fast Synchronization is a bootstrap process designed for efficiency and low disk-space usage. Instead of retrieving the full transaction history, the node requests the current state of the blockchain from its peers.
This includes the set of keys (accounts / addresses), along with their balances, nonces, multisigs configuration, and any relevant metadata at the current chain height.
Fast sync is significantly quicker than full sync and is ideal for light clients or applications that only need access to the current ledger state.
However, because it skips verification of the entire transaction history, it relies on trusted peers or the assumption that the majority of peers are honest.
Once a fast synchronization has been made, a pruned point is set. It is a the current topoheight at which point we synced all the stable data and from which we can't go below as we may not have any history.
The advantages of the fast sync are:
- the chain can be fully synchronized starting the pruned point
- any future TXs can be fully validated / verified due to the ZK Proofs
- is secure as long as no 51% attacks with a Sybil attack occurs due to the ZK Proofs for the transactions
Transactions ZK Proofs enforces the validity of the fast synced account balances. Your node still validates every upcoming blocks and transactions, it only rely temporarily on the fast sync to get the past history one time. It is thus, recommended to fast sync with a trusted peer to ensures fully valid history.
As an experimental idea, to ensures fully valid chain despite fast syncing from an attacker, we could include the cumulative difficulty in the PoW of a block.
This would means that, as long as you are connected with at least an honest peer that shares you the real chain, the Sybil attack would not work without a 51% attack by trying to trick you to switch on another chain to forces you to validates inflated accounts in their hands.
Implementation
The local node randomly select a peer in the peer list which has a greater height than us and send him a chain request.
The chain request includes last CHAIN_SYNC_REQUEST_MAX_BLOCKS blocks hashes of the local node's chain with their topoheight spaced exponentially.
This data is used by the selected peer to try to find a common point with the local node's chain and his own (block hash must be at same topoheight as other peer).
If the selected peer finds a common point, it adds up to CHAIN_SYNC_RESPONSE_MAX_BLOCKS blocks hashes ordered by block topoheight.
Through the "ask and await" request object system, the local node asks for the complete block (block header with transactions included) and add it to the chain directly.
Chain sync is requested with a minimum interval of CHAIN_SYNC_DELAY seconds.