TL;DR: During continued stress-testing of the Jakarta protocol proposal, we discovered two critical bugs in the implementation of Transaction Optimistic Rollups. A new proposal —Jakarta 2— will be released in time to be considered in the ongoing proposal period. We encourage bakers to avoid upvoting of the initial Jakarta proposal, and to upvote Jakarta 2 instead.
Update: Jakarta 2 has been released. More details in its announcement blog post.
We recently announced Jakarta, a new protocol proposal for the Tezos blockchain which notably introduces the first, experimental, step in our scalability roadmap: transaction optimistic rollups (TORUs).
Despite significant unit testing, property testing, and integration testing of the new protocol features prior to injection, we have found two critical bugs in the implementation of TORUs during continued post-injection testing.
The first bug is an issue with the rejection operation, that is the Layer 1 operation which allows a honest node to refute an erroneous (read, malicious) commitment. A flaw in its implementation ultimately makes it possible for an attacker to publish commitments for which honest participants cannot provide refutation proofs. This is a critical security bug, but one isolated to TORUs. It has no impact on the security of Tezos’ Layer 1.
The second bug concerns Ticket withdrawals, the underlying mechanism allowing for tokens to be transferred back from the Layer 2 rollup to Layer 1. The bug enables an attacker to forge tickets accounting for 0 tokens.
In TORUs, tickets are used to internally represent assets deposited to the rollup. The design of tickets allows for zero-valued ticket accounting for 0 tokens, which in some use cases can make sense. However, due to the bug in Jakarta, zero-value tickets can be forged when withdrawing from a rollup. For other smart contracts where zero-valued tickets are indeed meaningful, the bug can be exploited by an attacker to create these for free. Hence, the bug renders any ticket accounting for 0 tokens inherently suspicious, and ultimately worthless. Thus, this is a critical bug which might affect existing or future applications building on Tezos’ Tickets.
Fortunately, we have been able to confidently fix both issues, using fairly small patches that were easy to review, and that are backed up with appropriate tests, which have now been added to the existing test suite.
A call to bakers
While the original Jakarta protocol proposal has already passed the minimal quorum, we are still early in the proposal period. There is sufficient time for Jakarta 2 to achieve enough upvotes for it to replace the original proposal as the one that will continue to the next step.
We encourage bakers who have still not voted to wait until the new Jakarta 2 proposal is released early next week. We also encourage bakers who have already voted for Jakarta to vote again for the new proposal once it is injected.
We have decided to delay the publication of the release candidate for
the next Octez version v13~rc1, so as to provide the baker and
accuser binaries for Jakarta 2 instead. The
Jakartanet test network
will thus be based on the Jakarta 2 protocol proposal.
We invite the community, specially developers of applications building
upon TORUs, to join Jakartanet from the beginning. Moreover, we want
to take the opportunity to advertise and advocate the usage of the
Dailynet and Mondaynet teztnets — feel free to reach out to us if you need help deploying your contracts and applications on the test networks.
As for future proposals, we have already taken actions to improve the specification and testing frameworks to better uncover similar flaws, and we intend to strengthen them even more. The occasional bug is unavoidable, some will be critical and others less so, but we strive to make it continuously less likely that larger bugs escape the nets. And when they do, its unique on-chain amendment process makes the Tezos blockchain uniquely equipped to react, fix, and upgrade accordingly.