owned this note
owned this note
Published
Linked with GitHub
`Tx` Rollups: Merge Requests
============================
`Tx` rollups are a layer 2 solution to allow the exchange of tickets off-chain. The present document presents a series of Merge Requests intending to add a fully functioning implementation of `Tx` rollups to Tezos.
:::info
The **owner** of the MR is the person responsible for opening the MR, implementing the feedback of the reviewers, and making sure it ends up merged.
:::
## #1: Creation (Created on 24 November 2021)
:::info
- **Owner:** Sylvain Ribstein
- **Status:** Merged ([!3915](https://gitlab.com/tezos/tezos/-/merge_requests/3915))
:::
<details><summary>Backlog</summary>
In a nutshell, the scope of this feature is described as follows.
- In `proto_alpha`
- `Tx_rollup_create` L1 operation
- Assign a unique identifier to a rollup, derivated from the operation hash (similarly to what is done for contract origination) (missing from `oru@main`).
- Burn similar to contract origination
- A `tx_rollup_enable` feature flag only set to `true` in test scenarios. It controls whether or not `Tx` rollup operations are allowed or not
- A new command in the Tezos client to create a `Tx` rollups
- Tezt `lib_tezos` extension to write integration tests including the creation of a rollup
The presence of feature flag would allow to have this Merge Request being merged even if the implementation of the `Tx` rollup is not feature complete. Indeed, in the unfortunate event where the implementation is not fully ready for a protocol injection, the related L1 operations would be unusable.
Note that this is a novel approach wrt. Tezos development. The current intuition is that it should be safe to adopt this. This intuition needs to be hardened by a careful implementation and a even more careful review process.</details>
## #2.A: Layer1 Inboxes (Expected for 17 December 2021)
:::info
- **Owner:** David Turner
- **Status:** In development ([!4017](https://gitlab.com/tezos/tezos/-/merge_requests/4017))
:::
- In `proto_alpha`
- The notion of “rollup inboxes” for Tezos block level and “pending window”
- The “submitted operation” L1 operation (L2 operations treated as blackboxes)
- A new semantics for L1 transfer: implementing deposit of tickets as transfer to a rollup address
- only internal
- compatible with the table of tickets
- In the Tezos client
- Making sure it is possible to deposit ticket (*i.e.*, being able to send)
## #2.B: Layer2 Implementation (Created on 6 December 2021)
:::info
- **Owner:** Thomas Letan
- **Status:** In review (~~[!3921](https://gitlab.com/tezos/tezos/-/merge_requests/3921)~~, replaced by [!4360](https://gitlab.com/tezos/tezos/-/merge_requests/4360) and [!4453](https://gitlab.com/tezos/tezos/-/merge_requests/4453))
:::
- In `proto_alpha`
- A module type for the L2 storage
- A functor for the L2 apply function (plus a test-suite)
- A `Transfer` operation, a notion of atomic `transaction`, and the signed batches of transactions
- Tickets are identified with a hash as computed in the ticket of tables, where the owner is the rollup address
## #3.A: Commitments & Rejections (Expected for 28 January 2022)
:::info
- **Owner:** David Turner,
- **Status:** Commitments: [!4369](https://gitlab.com/tezos/tezos/-/merge_requests/4369), rejections: [!4459](https://gitlab.com/tezos/tezos/-/merge_requests/4459)
:::
- In `lib_tx_rollup`
- The `Prover` storage implementation, capable of producing a proof stream
- Based on Irmin
- In `proto_alpha`
- The `Verifier` storage implementation, capable of consuming a proof stream
- The storage necessary for remembering the commitments (by hashes) and the candidates for a given inbox
- The `Tx_rollup_commit` operation to insert a commitment
- The `Tx_rollup_rejet` operation to remove a commitment (based on a proof stream)
## #3.B: The Rollup Node (Expected for 28 January 2022)
:::info
- **Owner:** Xavier Van de Woestyne
- **Status:** Planned
:::
- A new executable: the rollup node
- Take a rollup identifier, a block hash, and a Tezos node entrypoint as arguments
- Check whether or not said rollup has been created in said block
- Track the head of the Tezos blockchain, and remember the set of block hash it has witnessed
- Interpretation of the rollup inboxes
- A notion of rollup blocks (absent from `oru@main`), a way to identify L2 operations, and to track their status
- RPC server
- Introspect the L2 state
- Submit (batch) L2 operations to a Tezos node
- Query the status of a given L2 operation
- Stream of rollup blocks
- A new executable: the rollup client
- Tezt `lib_tezos` extension to write integration tests including the creation of a rollup and l2 operation
## #4.A: Withdraw (Expected for 18 February 2022)
:::info
- **Owner:** Sylvain Ribstein, Arvid Jakobsson
- **Status:** In progress
- [**Design document :link:**](https://hackmd.io/AlYZVeCrSRK6A_6gFlMX3A?both)
:::
## #4.B: Commitments and Rejections from the Rollup Node (Expected for 25 February)
## #5: Enable `Tx` Rollup
Do we remove the feature flag? Or set it to`true` by default?
## Appendix
### Introduce a demonstrator smart contract
:::info
- **Owner:** Thomas Haessle
- **Status:** Planned
:::