BREAKING: NEO Unintentional Fork Took Place, Switcheo Reports
CryptoBit News Today3 min read
The NEO team initially disclosed there was a "temporary fork" in the blockchain due to a technical glitch while node operators and developers worked to resolve the incident.
The fork occurred when two blocks were simultaneously propagated as a valid top block, effectively creating a rare situation where two valid blocks were proposed, causing light wallets and exchanges to experience outages. However, despite the incident, the finality of NEO's blockchain was preserved, as no transactions had to be rolled back after the incident. As a result, the issue did not resemble a hard fork or a soft fork, which are commonly understood in the blockchain community.
Switcheo added that with NEO, all nodes are connected by P2P protocols to broadcast and propagate new transactions, and the consensus mechanism is supposed to work in such a way where a peer doesn't accept a block if it does not agree with the others.
The issue did trigger some similarities to a rare consensus problem. In conventional blockchain forks, an unanticipated fork between nodes on a blockchain occurs and results in two competing versions of the blockchain. After forks, one version of the blockchain survived, while the other was abandoned.
Conventional forks can occur due to software bugs, to patch software, before updating a blockchain protocol, or after a block that has more than one valid proposal. NEO’s technical glitch, however, occurred in a different way.
A bug in consensus message handling affected the execution of NEO’s consensus. In reality, while the nodes resolved the issue that impacted the network, the NEO consensus continued as normal, uninterrupted. During the event, an isolated node worked alone on its block before syncing back to the NEO blockchain main chain. There was no need to deal with divergent chains and no transactions were reversed in the process, according to NEO core developers.
The vulnerabilities and the "temporary fork" incident appear to fall under other categories, not the ones generally associated with forks.
In technical terms, the event concerns consensus mechanisms, what happens when a protocol accepts several transactions, and what happens when two valid blocks are proposed. These are not traditional forks or conventional consensus problems. As compared to the concept of hard forks, these problems can be rather complex.
The NEO team quickly coordinated software patches to fix the bug. They issued a reward of 1,000 NEO to the team for identifying the issue. The subsequent major upgrade was neo-cli v2.10.2.
Mainly, there were stability issues with the protocol when there was network stagnation or unexpected node disconnects. In a phenomenon dubbed “sporking,” this node would then become stuck on its own single forked block, dubbed a “spork,” while the remaining consensus nodes continued reaching consensus on their own.
When NEO deployed dBFT 2.0 in July 2019 via neo-cli v2.10.2, the software engineers eliminated the spork phenomenon and enabled the 7 master consensus nodes to reach consensus without delays. Each node must participate in block validation, and block times dropped from 20 to 30 seconds down to 15-20 seconds. Before passing, each transaction must pass the validation, in that way, it reaches a consensus between the nodes.
When notified, NEO founder Erik Zhang replied within 7 minutes to confirm the vulnerability and submitted a bug fix within an hour. Such an attempt violated expected execution patterns.
Nonetheless, some industry observers remained vigilant about potential challenges NEO faced due to forks and consensus mechanism edge cases. Switcheo, which launched Callisto as the first non-custodial exchange to support both NEO and Ethereum, noted that network stability remains essential. Erik Zhang and the NEO core developers collaborated continuously to ensure that NEO is protected against potential attacks and consensus stalls.
The neo-cli v2.10.2 release successfully addressed the block fork issue, ensuring consensus nodes remained synchronized and all transactions achieved immediate finality without reversals.
