Page 47 - MSDN Magazine, October 2019

Prepare Request Prepare Response Commit Create Block & Broadcast
00
11
22
33
The first version of dBFT was susceptible to a single block fork due to network latency in certain edge cases. Essentially, the fact that nodes could time-out after sending a PrepareResponse message meant that nodes could time-out and tran- sition at slightly different times. In the event that only one consensus node didn’t time-out and that node had already received 2f Prepare- Response messages, it would then generate a valid block while the other consensus nodes would’ve
Figure 3 The dBFT Consensus Algorithm Phases
actions from the memory pool into a new proposal for block b. Figure 1 illustrates the MakePrepareRequest method and Figure 2 illustrates the SendPrepareRequest method.
4. The N-1 remaining delegates receive the new proposed block b, verify it and then broadcast the verification. For brevity, the code snippets for the remaining steps aren’t included inline and are on GitHub at the link provided earlier.
5. Any consensus node, on receiving at least (N - f) verifica- tions reaches consensus and then publishes the new block. 6. Any node, on receiving a new block, deletes all the transac- tions from the in-memory pool, and if it’s a consensus node
starts on the next view (round of consensus).
With all that settled, let’s return to the three phases of the dBFT
algorithm. They are:
Pre-Prepare: The speaker for the view is responsible for broad-
casting the Prepare-Request message to the delegates and for initiating the new proposed block of transactions.
Prepare: On receiving the Pre-Prepare message, the delegates broadcast the Prepare-Response message if the proposed block is successfully verified. On receiving (N - f) successful block verifi- cations, the consensus nodes enter the next phase.
Persist: The nodes publish a new block and enter the next round of consensus.
The first version of dBFT was susceptible to a single block fork due to network latency in certain edge cases.
In the event that consensus isn’t reached in a certain round (view), the consensus nodes may initiate a proposal to change the view, with a new speaker (leader) and restart the activity of reaching consensus, after receiving at least (N - f) proposals to change the view with the exact same view number. The wait time to propose a new round increases exponentially in order to avoid frequent view changes and to ensure consensus within practical time bounds. msdnmagazine.com
moved on to the next view. There, those consensus nodes could in theory achieve consensus and sign another block of transactions at the same level. While this scenario could transpire without blocking consensus, one or more nodes could accept the forked block and stall.
dBFT 2.0 addressed this by adding a new commit phase. To prevent potential stalling, dBFT 2.0 also augments the consensus algorithm with a recovery message implementation. This recovery mechanism has the additional benefit of significantly improving block times in cases where network latency is degraded due to the network being compromised.
Wrapping Up
Distributed systems have been fundamental in transforming the computing industry, and by extension how we conduct commerce globally and how we universally engage as a community. The emergence of blockchains has spurred developers to study and to scrutinize well-established principles and paradigms in distrib- uted systems, and in doing so has catalyzed a wave of innovation that continues to break new ground in how developers build the next generation of software applications.
In this article we’ve focused on the topic of consensus and illustrated a pioneering new approach with the dBFT consensus algorithm. While we used C# to illustrate the dBFT algorithm for consensus, we’ve implemented the dBFT algorithm in C++, Python, Typescript and Go, to name a few languages. We hope this article provides developers with a better understanding of blockchain consensus and enables them to use and to build on top of the pioneering dBFT algorithm. n
Erik Zhang is founder and core developer of NEO, author of the dBFT consensus mechanism, expert on blockchain technology and computer security, and a cer- tified information system auditor (CISA). Previously he was engaged in Shanda Games and huobi.com, where he specialized in information security and R&D in digital currency.
John dEVadoss leads development for NEO Global Development in Seattle. Previously he built Microsoft Digital, .NET Patterns & Practices, and .NET Architecture Strategy. He also incubated Microsoft Azure when he was at Microsoft. Most recently, he launched two machine learning startups. deVadoss did his Ph.D. work in machine learning, specializing in recurrent neural networks.
Thanks to the following technical experts for reviewing this article: Chuan Lu, Harry Pierson
October 2019 43