NEO: Analyzing the Neo Blockchain’s Technical Architecture
Neo’s underlying technical architecture employs an adapted version of Proof-of-Stake called Delegated Byzantine Fault Tolerance (dBFT).
Updated July 22, 2021 • 4 min read
The Neo 3.0 blockchain makes use of an upgraded version of dBFT (dBFT 2.0), which has several distinct node types including: Consensus Nodes, Normal Nodes, Speakers, Delegates, Candidates, and Validators. The Neo network also combines features such as NeoID, Neo’s Virtual Machine (NeoVM), and Neo’s smart contract framework to enable scalability, adaptability, power, and usability of the system for real world applications. By interconnecting this wide variety of components and technical properties, Neo has positioned itself as a solution for mainstream enterprise usage.
The Ambitious Neo Blockchain Vision
Neo’s vision is to optimize a comprehensive and interconnected blockchain platform of digital identities, smart contracts, and digital assets in order to foster a more equitable, digital, and accessible “smart economy.” To help make this a reality, Neo designed its smart contract framework, NeoContract, to work with NeoID, Neo Virtual Machine (NeoVM), and other ecosystem components needed to facilitate various enterprise blockchain use cases. These use cases include decentralized finance (DeFi) applications such as data exchange marketplaces, streamlined investment management tools, and new processes for creating and interacting with decentralized exchanges (DEXs) and liquidity provider (LP) tokens.
Neo was designed to serve not only as a secure communication protocol, but also as a system for issuing and managing digital assets like stablecoins, security tokens, non-fungible tokens (NFTs), and synthetic assets (all of which are designed to be verifiable through the NeoID framework). Neo 3.0 relies on successfully integrating these multifaceted solutions and this growing ecosystem is underpinned by a number of innovative technical components, including Neo’s upgraded dBFT 2.0 consensus algorithm.
The dBFT Consensus Mechanism on the Neo Network
The Neo blockchain uses a highly advanced consensus framework similar to Proof-of-Stake (PoS) called Delegated Byzantine Fault Tolerance (dBFT). This framework is designed to achieve consensus via proxy voting through a specialized node delegation process. Byzantine Fault Tolerant mechanisms are commonly implemented in the design of fault-tolerant distributed systems. Neo’s dBFT consensus mechanism is adapted from a type of BFT protocol called Practical Byzantine Fault Tolerance (pBFT). With the help of its dBFT system, blocks on the Neo network are validated by stakers of NEO coins (typically via Consensus Nodes or validator nodes) who receive GAS coins as a reward for their services. Gas fees on the Neo network are paid in GAS.
Neo’s dBFT 2.0 is intended to address several inefficiencies that the network’s initial version of dBFT struggled with. Version 1.0 was occasionally susceptible to a single block fork, meaning that messaging problems between system nodes could occur, resulting in network inefficiencies. To help fix this problem, dBFT 2.0 includes a Recovery Message option, upgrading the functionality of the messaging request system that allows nodes to communicate with each other. This process helps the network’s main Consensus Nodes recover faster and achieve consensus more effectively. Additionally, dBFT 2.0 continuously audits Consensus Nodes while they operate, with the goal of increasing the trust, security, and scalability of the protocol. This auditing process reduces the risks of poor network connectivity and allows Consensus Nodes to restart on their own or initiate a full network restart in the event of a power outage, hardware failure, or another system issue.
As of 2021, Neo’s dBFT consensus mechanism is able to generate new blocks in 15-20 seconds, and transaction throughput clocks in at 1,000 transactions per second (TPS), which surpasses most similar solutions. That being said, through proper optimization the Neo network is capable of achieving 10,000 TPS, which is more than enough to support the usage requirements of large-scale enterprise applications.
Node Types and Neo Network Consensus Structure
The Neo blockchain’s dBFT 2.0 protocol uses several different types of nodes and other structural components to ensure that the network functions optimally. The primary elements are:
Consensus Nodes: As the name suggests, Consensus Nodes are responsible for helping the Neo blockchain maintain a balanced network consensus mechanism. They are designed for proposing new blocks on the network and for voting to accept or reject proposed blocks. There are seven main Consensus Nodes responsible for ensuring the integrity of the Neo crypto protocol.
Normal Nodes: Normal Nodes are mainly used for creating and transferring transactions on the Neo blockchain. They are designed to help balance the system and ease the computational load on Consensus Nodes, validators, and other nodes in the network. However, they do not directly participate in network consensus.
Speakers: Speakers are validators that are responsible for creating and broadcasting proposed blocks to the network. Speakers also send Prepare Request messages to determine which Consensus Nodes will participate in subsequent rounds of consensus.
Delegates: Delegates allow the dBFT algorithm to choose the nodes participating in upcoming consensus rounds through a real-time voting process. Delegates also help Speakers and the other nodes maintain balanced operational efficiency.
Candidates: Candidates are user accounts that are nominated to possess a validator node through Neo’s validator election process. Candidates have the potential to become validators and may eventually even become Consensus Nodes.
Validators: Validators are accounts elected from a set of candidates to contribute to network consensus, and have the possibility of becoming main network Consensus Nodes. They are chosen through a delegated election process. Typically, the node that holds the most NEO coins is chosen to become a network validator.
Views: Views are datasets used to complete a round of consensus from beginning to end. In each round of consensus, the view number starts at 0 and increases incrementally until the approval of the next proposed block in the round. Once completed, it resets to 0 for the next round.
In order for the different nodes in the system to continually maintain consensus, Neo makes use of six different consensus messaging types: Prepare Requests, Prepare Responses, Commits, Change View Requests, Recovery Requests, and Recovery Messages. Working in concert, these messaging types help propose and propagate blocks on the Neo crypto platform. A typical round of consensus on the Neo blockchain takes place in four main steps:
A Speaker begins the consensus process by broadcasting a Prepare Request message to the rest of the network’s nodes.
Delegates broadcast the Prepare Response message in reaction to the Prepare Request message.
Validators broadcast a Commit after receiving enough Prepare Response messages from other nodes in the network, signifying they are ready to proceed to the next step.
Validators produce and broadcast a new block on the ledger after receiving enough Commit messages from the other nodes within the network.
Neo Blockchain dBFT Node Election Parameters
As noted above, Neo’s dBFT consensus mechanism is designed to achieve consensus through proxy voting via a node delegation process. Since the Neo network aims to be open and transparent, anyone can initiate a transaction, apply to become a validator candidate, and vote to help decide which validator candidates become Consensus Nodes.
On Neo, all committee members and network validators are elected through a voting process. Committee members also have the right to vote on amendments to the Neo network, including changes to the network’s maximum block size, transaction limits per block, and network fees.
There is no specific relationship between committee members and validators. However, because there are 21 default committee members (more than the seven total network Consensus Nodes), validators are typically chosen from a subset of committee members. Every address present on the Neo network has the right to vote for only one address (whether it is a candidate or not), and a candidate’s votes are equivalent to the sum of NEO coins held by its corresponding voter.
The Neo Virtual Machine (NeoVM)
Adding to the capabilities of dBFT 2.0, the Neo Virtual Machine was designed to allow the protocol to create, execute, modify, and upgrade smart contracts that interact with the Neo ecosystem and other blockchain networks. NeoVM is a lightweight virtual machine with a computationally universal framework designed to facilitate consistent communication through a series of smart contracts and nodes, while also providing developmental support for software engineers building decentralized applications (dApps) on the Neo blockchain platform.
Looking Ahead: Neo 3.0 and Beyond
Using dBFT, the NeoVM, NeoID, NeoContracts, and other interrelated components, the Neo team is striving to develop a blockchain capable of supporting their vision for a global smart economy. Neo 3.0’s intended purpose is to make the Neo network more secure, scalable, and adaptable for widespread enterprise use. The Neo team expects that dBFT 2.0 will significantly improve the project’s ability to provide a fairer and more transparent global economic system.
Cryptopedia does not guarantee the reliability of the Site content and shall not be held liable for any errors, omissions, or inaccuracies. The opinions and views expressed in any Cryptopedia article are solely those of the author(s) and do not reflect the opinions of Gemini or its management. The information provided on the Site is for informational purposes only, and it does not constitute an endorsement of any of the products and services discussed or investment, financial, or trading advice. A qualified professional should be consulted prior to making financial decisions. Please visit our Cryptopedia Site Policy to learn more.
Is this article helpful?