---
# System prepended metadata

title: TX rollup design

---

# TX rollup design

Rollups proceed in blocks, just like L1.  L1 needs to know when rollup blocks are final, so that it can apply their L1 effects.  A L1 block is final 30 blocks after its first non-rejected commitment is received.  So L1 needs to store all commitments until either they are rejected, or they are final.

A block is broken into batches of operations to reduce the size of commitment rejections.

## L1 Storage (per rollup):
- Commitment table
    - key: Rollup address * Commitment hash = H(data excluding committer account id)
        - Because the commitment key does not include the account id, we can reject duplicate commitments before storing them.
    - value Commitment
        - committer account id
        - ancestor commitment hash
        - (effect list * after root) list
            - each entry is one batch
- Candidates table
    - key: Rollup address * Rollup level (that the commitment applies to)
    - value:
        - (Commitment hash) list
        - Tezos level for finalization
- Inbox
    - key: Rollup address * Rollup level
    - value:
        - (rollup-operation list) list
- Ticket ledger
    - key: Ticket hash (= H (ticketer, content, type))
    - value : ticketer, content, type, amount

Note:
- Nodes must store the rollup operation batches so that we can replay them in the event of a rejection.  Once a commitment to a block is final, we no longer need to retain these.
- If amount = 0, then an entry can be removed from the ticket values table
## L1 operations:
(including gas and fees)

[Chiachi: I added some details [here](https://hackmd.io/XfjDXcL-SFSAAQprpFZ54w?both) but I havn't finished it yet.]

- Create rollup: creates a rollup identified by a hash of the operation
    - This burns 100 tez, which is somewhat arbitrary, but which should be sufficient to reduce unnecessary rollup creation
- Append: append a L2 operation to a rollup
    - No gas cost beyond the storage
- Deposit: transfer tickets to a rollup
    - ?? gas cost ??
- Commitment: commit to a rollup block
    - Contents:
        - rollup id
        - rollup level
        - committer account id
        - ancestor commitment hash
        - (effect list * after root) list
  - Requires a deposit of 10,000 tz
  - Probably no need for gas cost given the deposit requirement
- Rejection:
    - Key: 
        commitment hash * batch index * H(after_root, effects)
        (earliest batch index is checked first; after a successful rejection, subsequent rejections of the same commitment hash get no reward)
    - Value:
        - rejector account id
        - commitment hash
        - batch index
        - after root
        - effect list
    - Requires a deposit
    - Gets a reward on success
     
## L2 storage (per rollup):

- Part of the shared hash (sent to the L1 in commitments)
    - Counter (anti-replay) table, per-account
        - key: account
        - value: Z
    - Ticket table (per-account)
        - key: account * ticket_hash
        - value: Z

- Maintained by rollup node only
    - Rollup block table
        - key: rollup block hash (?)
        - value: We need a notion of rollup blocks
            - L2 operation hashes
            - L2 operation receipts (`Applied`, `Rejected`)
    

## L2 operations:

- operations (signed by an account, and comes with a counter):
    - Transfer (ticket from the signer to an account)
        - account id to
        - ticket hash
        - amount
    - (TODO in MR 4) Burn (part of withdraw)
- “trades”: a list of operations to be executed atomically (maybe be a list of 1 element).  It is  signed by the origin account of each individual operation
- batch: a list of “trades”, with an aggregated signature for each of the trade


Proposed approach to carbonate:

- For the BLS, fixed cost * number of signature to check
    - If failure, then the all batch is a no-op, and operations can be resubmitted in a smaller batch
- For IO, fixed cost * (number of bytes of the key + number of expected bytes of the value, since (if?) of values are of fixed size)
    - The `Counter` table is not carbonated
    - If failure, the counters are incremented and therefore the operations cannot be resubmitted

Pros:
- Easy to provide a upper-bound
- We can implement a `simulate` RPC in the rollup node to mimic how it is done in L1
