Transaction Rollups
The Transaction Rollup project aims ta providing a ad-hoc optimistic solution to Tezos with the following properties:
- Implemented at the protocol layer (that is, in OCaml), to have a gas- and space-efficient implementation
- Limited to transactions (no in-rollup smart contracts), to keep the scope of the project smaller
- Fast finality thanks to a non-interactive rejection scheme.
This board can make it easier to understand what is being actively worked on.
Thereafter, we explain the plan wrt. merge requests.
Completed phase(s)
Phase 1. Creation
-
!3915 (merged) adds the layer-1 operation to originate a transaction rollup -
!4198 (merged) improves the API related to a transaction rollup state
Phase 2. Layer-1-to-layer-2 communication
This phase introduces in the protocol the “inboxes” of the transaction rollups, along with the way to fill them, and to interpret them.
-
!4315 (merged) improves the documentation available in the Tezos manual to take into account the development of this phase.
2.A. In the layer-1
-
!4190 (merged) makes it easier for the project to rely on the global table of tickets infrastructure -
!4200 (merged) provides the API to register “messages” in the layer-1, that the layer-2 needs to interpret -
!4205 (merged) makes it possible to target something that is not a smart contract or an implicit account with a layer-1 Transaction
operation -
!4203 (merged) introduces a new layer-1 operation to submit batches of transactions the layer-2 needs to interpret -
!4431 (merged) introduces the notion of layer-2 addresses in Michelson -
!4017 (merged) allows smart contracts to deposit ticket to the layer-2 with a layer-1 Transaction
operation -
!4309 (merged) refines the fees logic implemented in !4200 (merged) to smooth the variation of the fees -
!4344 (merged) allows to provide an upper bound for the fees you are willing to pay
2.B. In the layer-2
Reference implementation can be found at !3921 (closed). The following MR are a revamp of this initial implemenation.
-
!4360 (merged) introduces the notion of layer-2 context, with extensive testing -
!4339 (merged) introduces a notion of compact encoding to be used by Transaction Rollup and SCORU alike. -
!4275 (merged) introduces the definition of the layer-2 batches, and a novel framework to write compact encoding for them (owner: @lthms) -
!4453 (merged) introduces the notion of layer-2 apply function, with extensive testing
Phase 3. Commitments
The goal of this phase is to provide the notion of commitments to the transaction rollups. A commitment is a way for a rollup node to advertise to the layer-1 participants the advancement of the layer-2. This also includes a way to reject erroneous or malicious commitments.
-
!4445 (merged) documents the commitments and rejections mechanisms in the reference manual.
3.A. In the layer-1
Reference MR is !4162 (closed). The idea is to gradually extract self-contained MR from it, to reduce the workload on reviewers, and the history-rewriting nightmare that can be splitting it in several MRs at once.
-
!4323 (merged) refactors yet another time the Ticket_hash
module. -
!4332 (merged) refines the implementation of inboxes to make them a linked list. -
!4369 (merged) allows to store commitments in the storage. -
!4499 (merged) makes appending messages more predictable wrt. gas consumption. -
!4508 (merged) changes the scheme of commitments to a one commitment per inbox at most. -
!4484 (merged) carbonate the hash of messages -
!4495 (merged) allows to identify inboxes with a hash -
!4446 (merged) adds the notion of commitment finalization -
!4583 (merged) implements the complete life cycle of rollups, including garbage collection -
!4548 (merged) restricts the number of messages in an inbox -
!4590 (merged) limits the number of commitments for a given rollup -
!4437 (merged) introduces a generic notion of bonds to be used both by TORU and SCORU -
!4703 (merged) use the stakable bound mechanism (cf. !4437 (merged)) to implement commitment bond / rejection reward
3.B. In the rollup node
-
!4357 (merged) introduces a passive transaction rollup node that reconstructs the inboxes. -
!4521 (merged) makes the node interprets the inboxes -
implements the infrastructure to send layer-1 operations (owner: @mebsout)
Phase 4.
4.A. Layer-2-to-layer-1 communication
The goal of this phase is to implement the mechanism which allows transaction rollup participants to withdraw their assets from the layer-2.
-
!4517 (merged) modifies the layer-2 apply
function to handle withdrawals orders -
!4523 (merged) introduces the L1 operation to actually do the withdrawals -
!4756 (merged) limits the maximum size of layer-1 ticket that can be deposit -
!4733 (merged) integrates the deposit/withdraw mechanism of TORU with the table of tickets. (@sribaroud) -
!4726 (merged) uses Irmin proofs for the rejection.
4.B. Layer-1 storage constrains
-
!4376 (merged) implements a mechanism to track allocation and deallocation of inboxes -
!4750 (merged) allows to “merkelise” an inbox to reduce the impact of the layer-2 onto the layer-1 context
Phase 5. Activation
The goal of this phase is to enable the transaction rollup feature flag, to make the implementation available on mainnet.
Nice to have
The following MRs are not blocking, and should potentially be added to TORU in another iteration of the protocol if need be.