Developers discovered vulnerability on the Loki network just 5 days to a hardfork. The bug would have caused a consensus divergence in the service node of lists between the version 2.0.x and the latest update 3.0.0.
The potential impact stems from the fact that some operators have already migrated to version 3.0.0 even through majority of the nodes still run on the older version.
The proposed hardfork would enable infinite staking of nodes. The essence is to prevent anticipated spike in staking requirement from 10,000 to 15,000 thereby allowing node staking through curve modification.
The discovery of Bug
On the morning of March 21, a community contributor, Jagerman observed that the height at which staking requirement curve change was not adjusted to conform to the new hardfork date which had been scheduled for March 26. The Summer Sigyn hardfork entails hardcoding the new curve authorizing the infinite staking into the software on that day.
The effect of the discrepancy would have been that version 3.0.0 demands higher staking requirements than v. 2.o.x. this would mean that staking done on the older version would not be recognized by the v.3.0.0. as “full” so these would not be added to the Service Node lists.
Developers were left with no option than to create a new release that reverted the staking requirement cure back to the values of v.2.0.x until the proposed hard fork. The new release, 3.0.1 was distributed immediately to prevent service disruption that could result in de-registration by Service Nodes due to the divergence.
This was found not to be a complete remedy since the 3.0.1 still had to deal with nodes with the old staking requirements in their database. Users were therefore instructed to import the Loki-blockchain-import utility to force compliance through recalculation of the Service Node lists.
To create a uniformity and aid operators, a second release, 3.0.2 was implemented to automatically carry out the operation for the users. An additional dummy field created for the Service Node list code ensures that when users deploy the 3.0.2, the recalculation is automatically applied. This means that the 3.0.1 and 3.0.2 comply with the v.2.0.x.
The Loki community expressed optimism on the future of the network considering the prompt response of the developers to the bug. The window period in which the discovery and implementation of 3.0.1 and 3.0.2 was just 6 hours. The response of the operators was also impressive as most operators on 3.0.o upgraded hours after the discovery of the vulnerability.