In today’s article in the Road to Neo3 series, we’ll cover past discussion on network optimization with a particular focus on improving the block synchronization process, followed by the exploration of a new block synchronization method for Neo3.

Block synchronization is the process by which a full node requests and receives block data from a blockchain network. Since full nodes are only able to validate and interact with the network once fully synchronized, this mechanism often represents the first experience with a particular blockchain that a full node operator will have.

Like most other blockchains, nodes on Neo currently synchronize new blocks using a header-first approach. This means before any block data is requested, nodes get on the same page about what blocks to expect by sharing messages about the block headers. The header of a block contains useful information such as version info, block index, the previous block hash, and consensus node public keys.

Header-first synchronization

Typically, most blockchain networks depend on Proof of Work or Proof of Stake consensus mechanisms, where at any time there may be multiple versions (forks) of the blockchain. Deciding which fork is the correct or truthful version of the ledger is usually determined by the block height—the longer blockchain wins.

Header-first synchronization is very beneficial to nodes on these blockchains, as they can use the information in block headers to determine the longest blockchain and therefore which blocks to acquire. Without this step, they could waste time participating on a fork that may be orphaned following network consensus.

Since the Neo blockchain is designed not to fork, this advantage is lost. In a proposal to abolish header-first synchronization by Neo core developer Erik Zhang, the potential upsides to its removal were noted:

“The consensus algorithm dBFT used by NEO determines that its blockchain will not be forked. So the advantages of header-first mode have become obsolete. If we no longer allow the header-first mode, we can save the network overhead of the header synchronization.”

Header removal

The proposal to abolish header-first synchronization also suggested the complete removal of headers. Since important information such as the consensus node public keys can be computed from the previous block state, Zhang noted that removing block headers could facilitate notable reduction in chain size:

“Currently there are 7 consensus nodes. So every block has 7 public keys. That is 7 * 33 = 231 bytes. If we increase the consensus nodes to 100, then we will have 100 * 33 = 3300 bytes for public keys in every block.”

Despite these benefits, initial experiments in removing headers yielded uncertain results. In addition to other header optimizations that could be used if headers were kept—such as signature aggregation for public keys—it was also noted that headers are very useful for cross-chain interaction and for simplified payment verification.

As a result of these tests and discussions, header removal was tabled, however research into block synchronization optimizations continued. In the next episode of RTN3, we’ll look at the context behind an alternate approach in development for Neo3; index synchronization.

Tags: