Erik Zhang, NEO co-founder, and John deVadoss, head of NGD Seattle, have co-authored an article on blockchain consensus mechanisms for the Microsoft Developer Network (MSDN) magazine. The article was published in the magazine’s October 2019 edition, and provides an introduction to blockchain technology, the role of consensus protocols, and the advantages offered by NEO’s dBFT.

NEO’s appearance in the MSDN magazine aligns with the project’s efforts to attract traditional developers to the blockchain industry, with a particular focus on .NET developers. In other recent news, NEO became the first blockchain project to join the .NET Foundation, another example of the ongoing outreach efforts.

Introducing Blockchain

The article, titled “Exploring Blockchain Consensus,” begins with an introduction to blockchain as a growing list of records linked using cryptography, highlighting the immutability and transparency of the ledger. Delving further, blockchain platforms like Ethereum and NEO are explained as programmable blockchains, using smart contracts to support decentralized applications across a variety of markets and use cases.

Noting blockchains as a new type of distributed system, the article also notes the importance of fault tolerance in ensuring continued operation in chaotic environments, which are to be expected for decentralized networks. Continuing, deVadoss explains that fault tolerance is usually achieved through state machine replication, which use consensus mechanisms to ensure that nodes agree on any state transitions.

In layman’s terms, state machine replication refers to running multiple copies of the same node/server. The more copies (replicas) that are created, the more can fail before the service is prevented from working.

Consensus Mechanisms

Consensus mechanisms are required to ensure that each of the state machine replicas agree on what the next chain state (block) will be in a deterministic manner. To be considered a fault-tolerant, three key properties must be satisfied:

  1. Termination – non-faulty nodes should eventually make progress in moving to the next state (liveness)
  2. Integrity – if all/most non-faulty nodes propose a certain output value, all non-faulty nodes should determine the same output values
  3. All non-faulty nodes in the network should eventually agree with the outputs (safety).

Zhang and deVadoss note two main approaches to addressing the challenge, such as Bitcoin’s Nakamoto consensus, which facilitates agreements in a probabilistic manner. However, this approach never provides true finality for a given state, allowing for forks to reorganize the blockchain, potentially involving the reversal or exclusion of transactions.

This lack of finality is what led Erik Zhang and Da Hongfei, co-founders of NEO, to pursue alternate consensus approaches, based on the belief that finality was of key importance for financial applications.

Delegated Byzantine Fault Tolerance (dBFT)

Building on the work done by Castro and Listov in developing practical BFT (pBFT), dBFT extends pBFT to state machine replication scenarios, enabling it to be used in blockchains. Initially authored by Zhang himself, he highlights that dBFT provides transaction finality within a single block, typically 15 seconds.

Zhang explains dBFT and pBFT as examples of leader-based consensus mechanisms, which elect primary nodes to send proposals to other nodes, which use a view change system to assure liveness. In NEO’s case, these proposals contain a new potential block, which the other consensus nodes may then validate and sign. If ⅔ of the nodes agree with the block’s validity, it is then broadcast to the network and a new consensus round begins.

Message requests between four nodes in three-phases of dBFT

This process is split into three phases; pre-prepare, prepare, and persist. Together, these phases ensure that a sufficient number of replicas are in agreement before blocks are verified or published.

If consensus is not reached (due to communication failure or an invalid block being proposed), the view change mechanism is used to signal the election of a new leader, who will propose a new block.

Zhang also mentions an issue discovered in the initial dBFT version; before the addition of the third “commit” phase, an edge case existed that could cause a single block fork. This happened when the active leader received enough signatures to validate its block, but failed to propagate it through the network.

The other nodes could change view and achieve consensus as expected, however the original leader may manage to broadcast its now-abandoned block to other nodes on the network. If accepted, these nodes would then stall on the forked block, which in some cases could interfere with the operation of servers used by light wallets or blockchain explorers.

The third phase of dBFT consensus was added during the dBFT 2.0 update was also accompanied by a regeneration strategy that allows nodes to be automatically recovered after a fault. More information on dBFT 2.0 may be found here.

The original article may be read at the following link:
https://msdn.microsoft.com/en-us/magazine/mt833527?f=255&MSPPError=-2147217396

Tags: