We have discovered a critical bug within the new Tickets functionality in Edo.
Several mechanisms were considered to mitigate this problem; none were ultimately found to be satisfactory. We have therefore taken the step of producing and releasing version 8.2 of the Tezos node that includes a patched version of the Edo protocol that differs by only a few lines of code.
Nodes running 8.2 will automatically adopt the patched version rather than the original version of Edo when it activates on February 13th, 2021, around 19:30 GMT. We ask all bakers and node operators to please update immediately to 8.2, rather than 8.1 which most are currently running. Nodes running version 8.1 or earlier will not be able to communicate with the new chain.
The hash of the new version of Edo is: PtEdo2ZkT9oKpimTah6x2embF25oss54njMuPzkJTEi5RqfdZFA
We appreciate that this is coming at a very late stage in the Edo upgrade process, but we believe that this is the best choice available. It is safer to have the upgrade occur at a time when every bakeris already updating their software and planning to pay close attention to their node because of the impending adoption of Edo.
We do our best to prevent bugs from slipping inside our releases but unfortunately, as with any complex software, there is always a small chance of missing something. We intend to adopt several new quality control mechanisms to reduce the probability of similar bugs going undetected in the future.
Did we not learn from our last lesson? Here we are, once again, pushing through a last-minute change on a protocol which was not voted on by anyone. Anyone remember Baby and the giant cluster-f that ensued? Did we not promise ourselves that we would never do that again?
Excellent point if nobody voted for this how can they force it? Since itâs only 2 lines of code they changed maybe we could call this a unanimous vote since we were really voting for the logical implementation not the physical implementation. The logical implementation implies bug free code therefore making this last update a unanimous green light.
Tezos is still in infancy, I believe eventually they will find ways to extend release cycles and account for these last minute branches. For example if a last minute bug is found then the release date could be pushed back automatically to allow further time for retesting and revoting.
Anyways good point, I would love to hear others opinions on this matter. Governance is still in itâs infancy.
The governance is just an official method to get a pulse of what the stakeholders want. Nobody is really voting for the lines of code in the protocol, 99.9% of us do not look at the actual source code of the protocol nor do we even test the protocol before voting. We are voting for whether we want those features.
At this point this late in the edo voting process, it doesnât matter if itâs a complete rewrite or a few lines of code (as a dev, I roll my eyes when I see âonly a few linesâ of code as a justification for safety or assurance), the community wants the feature and the existing process already requires a lot of trust, that hasnât change regardless if protocol is voted in or hard forked. Should it stay this way in the future? I hope not and we should certainly improve the process. Current process wonât scale if we have many teams writing protocol proposals. But whether if the hard fork to address a critical bug the best choice available given the circumstances, I have to firmly agree.
That said, we shouldnât stay silent about these issues. But we still need to be constructive about how we voiced these opinions.
Agree with that. Voting is about the features we want to implement. And those features have to be as âsafeâ as possible!! And thatâs that critical patch is for.
I agree that weâre currently voting on intention rather than actual code. Perhaps that can change one day.
Iâm more concerned with how close a call this was. Had this bug sneaked through to mainnet seems like weâd have no choice but to hard-fork. This may not mean much in technical terms, but it would be detrimental to the image of the project since itâs one of its main âfeaturesâ.
We may want to evaluate the pros and cons of slowing down the upgrade process even further.
