The changes in Jakarta 2 with regard to the previous Jakarta proposal concern only fixing the reported bugs. In this section we shed more light into these issues, and detail how they were corrected for the new protocol proposal.
The first bug concerns rejection operations
, that is the Layer 1 operation which allows a honest node to refute an erroneous or malicious commitment in a TORU. A flaw in its implementation ultimately made it possible for an attacker to publish commitments whose refutation proofs would not fit within the maximal allowed size for Tezos’ manager1
operations batches — 32 KiB.
This limit underpins a design decision in the current implementation of TORUs: there is an upper-bound on the number of Layer 2 transaction batches from the same rollup which can be (ahem!) rolled up within a given Tezos Layer 1 block. For each of these batches, operators of the client rollup are required to include the batch’s hash in their respective commitment operation on Layer 1. Inserting too many batches from the same rollup in the same block would make it impossible to insert a valid commitment for it in a subsequent block, which would result in the incriminated rollup being stuck forever.
Rejection operations denounce a specific rollup commitment, which contains one hash per batch of Layer 2 transactions. Honest rollup accusers can trivially find the first hash that they disagree with, and craft a rejection operation to refute said batch. The rejection operations requires two key pieces of data: (1) the target batch itself, and (2) a collection of Merkle proofs which allow to replay said message. This raises an immediate concern. What if the provided Merkle proofs are just too large to fit within the size boundaries a Tezos Layer 1 manager operation? If the batch is large enough (that is, it contains enough transactions), this can definitely happen.
To tackle this risk, TORUs relies on two design choices. First, TORUs encode Merkle proofs using a format that allows to send truncated proofs. Second, a batch for which one can exhibit a valid, “large enough” truncated proof has to be considered a no-op.
In the first Jakarta proposal, the size boundary for Layer 2 operations batches was 5 KB, and a truncated proof larger than 30 KB was required, in order to prove that a batch should be considered a no-op. So, in order for an honest rollup node to prove that a batch of size 5KB was to be ignored, it needed to produce a refutation whose size was at least 35 KB (~36 KiB)… which does not fit within the 32 KiB limit on Layer 1.
The fix is straightforward: accept a truncated proof of 30KiB – sizeof(batch). In this way, rejection operations are guaranteed to fit within a single Tezos manager operation. The curious reader can have a look at the diff of the MR implementing this bugfix
The second bug concerns Tezos Tickets
. The latter are an abstract representation of tokenized assets, and in TORUs, they are used to represent the assets deposited and transacted within the rollup.
Tickets can be seen as a tuple consisting of: (1) its (typed) payload, (2) the address of the smart contract which has minted it — a.k.a its ticketer — , and (3) a quantity. A ticket can be split into two (and eventually more parts), assuming that the total sum of the quantities associated to each of the two resulting half-tickets is equal to the amount of the original one. Dually, two tickets with the same payload and issued by the same ticketer, can also be joined, adding up the quantities.