Blockchain Syncing

区块链同步。
We describe here the different methods used by a new node when joining the network to catch up with the latest chain state. We start with reminding the reader of the following assumptions, which are all characteristics of Grin or MimbleWimble:

• All block headers include the root hash of all unspent outputs in the chain at the time of that block.
• Inputs or outputs cannot be tampered with or forged without invalidating the whole block state.

We're purposefully only focusing on major node types and high level algorithms that may impact the security model. Detailed heuristics that can provide some additional improvements (like header first), while useful, will not be mentioned in this section.

Full History Syncing

This model is the one used by "full nodes" on most major public blockchains. The new node has prior knowledge of the genesis block. It connects to other peers in the network and starts asking for blocks until it reaches the latest block known to its peers.

The security model here is similar to bitcoin. We're able to verify the whole chain, the total work, the validity of each block, their full content, etc. In addition, with MimbleWimble and full UTXO set commitments, even more integrity validation can be performed.

We do not try to do any space or bandwidth optimization in this mode (for example, once validated the range proofs could possibly be deleted). The point here is to provide history archival and allow later checks and verifications to be made.

Partial History Syncing

In this model we try to optimize for very fast syncing while sacrificing as little security assumptions as possible. As a matter of fact, the security model is almost identical as a full node, despite requiring orders of magnitude less data to download.

A new node is pre-configured with a horizonZ, which is a distance in number of blocks from the head. For example, if horizonZ=5000and the head is at heightH=23000, the block at horizon is the block at heighth=18000on the most worked chain.

The new node also has prior knowledge of the genesis block. It connects to other peers and learns about the head of the most worked chain. It asks for the block header at the horizon block, requiring peer agreement. If consensus is not reached ath = H - Z, the node gradually increases the horizonZ, movinghbackward until consensus is reached. Then it gets the full UTXO set at the horizon block. With this information it can verify:

• the total difficulty on that chain (present in all block headers)
• the sum of all UTXO commitments equals the expected money supply
• the root hash of all UTXOs match the root hash in the block header

Once the validation is done, the peer can download and validate the blocks content from the horizon up to the head.

While this algorithm still works for very low values ofZ(or in the extreme case whereZ=1), low values may be problematic due to the normal forking activity that can occur on any blockchain. To prevent those problems and to increase the amount of locally validated work, we recommend values ofZof at least a few days worth of blocks, up to a few weeks.