Share on Twitter
Share on Facebook
Share on Reddit
Share via Email
Share on LinkedIn
Share via RSS
Share on Google+

NEO’s dBFT version 2.0 has reached real-world deployment, and core developer Jeff Solinsky has made plenty of commits along the way. Currently on his second stint as a software developer at Amazon, Solinksy previously pivoted to becoming the development lead of the Aphelion wallet and exchange, and was named a NEO Core Developer in January 2019 after frequent code contributions on GitHub.

Solinsky’s contributions to the way NEO handles its pending transactions are well-documented, and after dBFT 2.0 was rolled out to MainNet as part of the changes included in NEO-CLI v2.10.2, he posted an overview of the consensus mechanism’s improvements.

Commitment Phase

Solinsky began by explaining the basic workings of NEO’s delegated Byzantine Fault Tolerance, which requires two-thirds of the consensus nodes to come to an agreement on each new block by checking the validity of included transactions. After two-thirds of the nodes sign the block, it is distributed to the network.

In dBFT 1.0, if a consensus node lost its network connection temporarily after receiving the other nodes’ signatures for the block it had proposed, it was possible for two different valid blocks to be published when only one block was called for. This was due to the remaining nodes recognizing a timeout and moving to create a replacement block.

In dBFT 2.0, a “commitment phase” ensures that consensus nodes will only approve one valid block at a certain block height, regardless of network latency, connection loss, or downtime.

Other additions to the consensus mechanism in the update include a “recovery message” that improves performance during a network outage or node hardware failure, and improved visibility of the consensus nodes’ behavior in real time via new auditing tools.

Point of Sale

Following extensive automated and manual testing in private networks and the NEO public TestNet, dBFT 2.0 was rolled out to the MainNet as part of NEO-CLI v2.10.2. Solinsky noted that following this deployment, the majority of issues that had created a barrier to NEO’s usage by various entities have been resolved.

By improving the availability of the NEO network and ensuring rapid finality, Solinsky commented that the NEO network has become viable for usage as a point of sale solution. The increased reliability should reduce headaches for noderunners, such as exchanges or dApps, and the single block finality provided by dBFT makes NEO a strong option for settling payments.

Jeff Solinsky’s full dBFT 2.0 writeup can be viewed at the following link:
https://medium.com/neo-smart-economy/neos-dbft-2-0-single-block-finality-with-improved-availability-6a4aca7bd1c4