Blockchain Synchronization - zoobc/zoobc-core GitHub Wiki

Blockchain Synchronization

Blockchain Synchronization is a mechanism to make sure that the states of all the nodes in the network are the same and synchronized. By the stes mentioned in this context is the Blocks, Transactions and other data stored in the individual nodes. It works on the basis of Eventual Consistency by which it means the nodes in the networks are allowed to diverge and have different opnion about the blockchain's state once in a while that may be caused by the network latency, rogue nodes, corrupted data, etc; but will eventually agree upon one state accross the network.

  • Synchronization Process

    When the node starts fresh:
  1. The node will try to connect to his peers.
  2. Then the node will try to download all of the spine blocks from its peers.
  3. After the download of the spine blocks completed, the node will start applying a snapshot from the latest snapshot the spine chain has.
  4. After that the mainchain will be downloaded from the blockheight for which the snapshot was applied.
  5. After the process finishes, the blockchain will continue either by receiving blocks from his peers, or catching up the chain of his peers (and resolving forks).

When the node restarted:

  1. The node will try to connect to his peers.
  2. Then the node will try to sync his spine chain with his peers. If the spine chain is out of sync for more than MaxRollbackHeight, it will exit the program and print the error message regarding that. Otherwise the node will try to sync the spine chain.
  3. After the syncing of spine chain finishes, the node will flush the data in his mainchain, and apply the latest snapshot contained in the spine chain.
  4. After that the mainchain will be downloaded from the blockheight for which the snapshot was applied.
  5. After the process finishes, the blockchain will continue either by receiving blocks from his peers, or catching up the chain of his peers (and resolving forks).

Blockchain Synchronization have 2 portion of mechanism:

  • Initial Block Synchronization

    The first time the node started, it will need synchronize its blockchain state with the state of the blockchain of the network. This process is also essential to happen before the node can smith a new block so that it will produce a valid block considering the network state of the blockchain. This process is performed by BlockchainOrchestrator service.

    The processs of Initial Block synchronization:

    1. When the node is started, it will have IsFirstDownloadFinished state as false, restricting smithing to be performed by the node.
    2. A node will sync the spinechain with other nodes.
    3. Once its spinechain is synchronized with the network, it will download the latest snapshot to start the mainchain block state.
    4. Once the snapshot is applied to the mainchain, the node will start synchronizing the mainchain state with his peers.
    5. Once the mainchain is in synched, the IsFirstDownloadFinished state will be set as true, then the node can start smithing operation.
  • Blockchain Download

    This mechanism download the blocks form the peers a node connects to. It downloads the blocks that are divided into several segments and spread accross multiple peer to ensure the correctness of the blocks downloaded.

    Steps of the process:

    1. A node will select one of the peers a node has.
    2. The node will ask the state of the blockchain of the peer selected before
    3. If the peer's blockchain state is found to be fresher than the node's blockchain, it will request try to communicate with the peer for finding common block which determines the lates block in which the node and peer have in common. It means, any blocks after the common block are new blocks for the current node.
    4. The node will start requesting the blocks he does not have in chunks and distibute the request to number of peers he has.
  • Process Fork

    Fork is a situation where the state of the blockchain of a node is different from of the whole network state. There are 2 categories of forks: "Soft fork" and "Hard fork". Soft fork is when forking condition is less than a predetermined value (e.g. 720 blocks). Soft fork often happens and is normal to occur. It is due to the problem of distributed system that may have different state at a given time, but will eventually resolves themselves after sometime. Hard Fork in the other hand, is a condition where the fork has reached more than predetemined value (e.g.720 blocks). Hard fork can happen because of the number of cases like: the nodes are running different version of blockchain software making some protocols do not match, or when a node (or a cluster nodes) got isolated from the rest of the netwrok for a reasonable of time making them thinking that their state while in isolation is the truth.

    This mechanism is part of the Blockchain Download process and it resolves difference in the blockchain states between the node's and the whole network's. It does so by comparing the current blockchain of the node and and compare he gets from the peer, if the blocks received from the peer is found to be "better", the node's chain is rolled-back and that peer's blocks are accepted and stored.

    Steps of the process:

    1. While downloading the blocks from the peer and finding different blocks from what we have, the different blocks are stored in a list, let's call it forkBlocks.
    2. The node will pop out his blocks until the common block (compared to the peer's blockchain) and try to push the forkBlocks into his blockchain.
    3. If the push of forkBlocks goes well, the node will accept the peer's blockchain and adds transactions that were inside the popped blocks of the node into the mempool to make sure the popped out transaction will be processed again.
    4. If the push of forkBlocks does not go well, the fork blocks from the peer will be concluded to be invalid, and the popped blocks of the node will be re-pushed to the node's blockchain, reverting to the state before processing the fork blocks.