NEO: Analyzing the Neo Blockchain’s Technical Architecture

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:

1. A Speaker begins the consensus process by broadcasting a Prepare Request message to the rest of the network’s nodes.

2. Delegates broadcast the Prepare Response message in reaction to the Prepare Request message.

3. 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.

4. 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.

NeoVM is designed for increased security and scalability, and is built to work in unison with the dBFT consensus mechanism and Neo’s smart contract framework in order to drive the overall growth and value of the Neo network ecosystem. Neo’s smart contract protocol, NeoContract, has the ability to execute and manage smart contracts using most of the mainstream programming languages, including industry standards Python, Java, C#, and JavaScript. This helps the system be used by almost any developer and encourages cross-platform functionality. Neo’s multi-language programming functionality contrasts with the programming functionality of smart contract leader Ethereum, which mainly uses its native programming language Solidity (not familiar to the majority of mainstream developers) for creating smart contracts.

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.