Difference between revisions of "Network synchronization"

Latest revision as of 08:32, 16 July 2014

Network synchronization is achieved in 4 steps:

1. Acquire proof chain with the highest cumulative difficulty.
2. Acquire mini-blockchain which is associated with proof chain.
3. Build account tree by requesting slices and verifying the hashes.
4. Use recent transactions to complete sync of account tree.

First the node will use a “headers first” approach to locate the chain with the highest cumulative difficulty. Then it will acquire a collection of the most recent blocks connected to those block headers. Then it will attempt to acquire slices of the account tree until it has a complete tree. The account tree structure allows the node to prove it has received complete slices so that the node can be sure it has the all the accounts. Finally, the node can use recent transactions to update all slices of the tree to the latest master hash.

No one is required to store old account tree data but the node must build an account tree which is fully consistent with the master hash they have; they can't mix and match slices associated with different master hashes. That is why the height of each slice must be determined, so that we know what transactions need to be applied in step 4. Since all slices contain the master hash, when a node requests a particular slice it can match the slice against a particular block by comparing the hashes.

Nodes will generally attempt to acquire slices synced near the point where it becomes safe to discard old transactions. Other nodes are able to provide these old slices because because they can undo recent changes to the account tree and generate old slices upon request. New nodes will attempt to build an account tree at such an old point because they need to be able to create a large “inversion database” which holds instructions for undoing changes made to the account tree, which is useful for generating old slices and handling forks.

In simple terms, new nodes will attempt to build a complete account tree around the point where old blocks can be pruned, then it will “fast forward” using transactions from the most recent blocks and at the same time build an inversion database, so that it has inversions going back to the point where inversions are no longer needed. Of course this description of the process is very much simplified and you'd have to read the source code of Cryptonite for a more detailed technical understanding of how synchronization works.

Notice this process does not rely upon much examination of blocks, one trusts the blocks they have because the proof chain backs them. It's extremely easy to verify the proof chain and once that is complete the node only needs to make sure the blocks it gets match the proof chain. As the account tree is being built the only thing which matters is that it ends up having the master hash of the latest block. Once that is complete and the node is synchronized it can begin to update the account tree normally by accepting valid blocks.