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.
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.
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 (which includes the
Jakartanet built-in test network), 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.