Last week, NEO developers upgraded their network’s mainnet consensus nodes, including the core consensus protocol. The updated delegated Byzantine Fault Tolerance (dBFT) consensus mechanism is designed to provide strict one-block finality, a challenge both in terms of technical specification and research.
The new features are expected to reduce the need for network maintenance and downtime, as well as their impact on the running processes of decentralized applications.
These instability issues may have delayed or prevented NEP-5 tokens from being listed on individual exchanges. Guardian Circle, which utilizes a NEP-5 token for their decentralized emergency response service, is a possible case in point.
According to Guardian Circle CEO Mark Jeffrey, “for a year, several exchanges we’ve spoken with refused to list $GUARD or any NEP-5 tokens because of the inherent instability of NEO nodes.”What was the problem?
The issues with downtime and maintenance became evident as far back as September of 2018, but were partially resolved in instances such as PR 320: Stage 3 of dBFT.
According to Vitor Coehlo of NeoResearch, the recent “network instability was due to lack of a recover mechanism, which [can now] recover [downed] nodes from local failures and network issues.”
Another problem affecting the previous version was block forks. According to EdgeDLT, a moderator of the r/NEO subreddit:
“block forks were caused when a consensus node would validate a block, but then lose its connection. The other nodes would start on a replacement block, but then if that faulty node reconnected, it could share that newly orphaned block to the rest of the network. Consensus itself would be fine, but network nodes that accepted the orphaned block would get stuck.”EdgeDLT, Moderator of /r/NEO
While these periods of downtime didn’t put project or dApp data at risk, they did cause transaction delays lasting for minutes and ...