Owner: @jobjo

Implement the Rollup Management Protocol (RMP). This milestone is for providing one implementation of an RMP module sufficient to be used to demo SCORU. In this milestone we only focus on the L1/L2 communication part and not additional effects.

Design document

https://www.notion.so/trilitech/Rollup-Management-Protocol-0e06967921cb4c7e99b70b2b1e2aff89

Break-down

Required

• Effect type for inbox with type for message from L1 to L2 (including ticket deposits). (#2899 (closed))
• Effect type for outbox with type for message from L2 to L1 (including ticket withdrawals) (#2900 (closed)).

Additional

• Provide type validation #2915
• Effect for ticket-minting
• Effect for withdrawing to tz1s

Background

The communication layer between the L1 protocol and any L2 kernel must follow the specification of a Rollup Management Protocol. In particular to describe such actions as:

• A message from L1 to L2 (including ticket deposits).
• Messages from L2 to L1 (including ticket withdrawals).
• Minting ticket-tokens in L1 based on kernel authorization — for example to represent a minted L2 asset.
• Other effects authorized by the L2 kernel, such as a hardware/ISA upgrade.

This protocol is meant to be shared between kernels and PVMs.

To enable the L1/L2 communication we need at least specifications for deposit and withdraw operations.

In the L1 protocol we can represent a deposit — any message from L1 to L2 — as:

type deposit = {
  payload : Script_repr.lazy_expr;
  sender : Contract.t;
  source : Contract.t
}

For withdrawals we support grouping of multiple L2 to L1 messages in atomic batches:

type withdrawal = {
  parameter_ty : Script_repr.lazy_expr;
  parameter : Script_repr.lazy_expr;
  entrypoint : Entrypoint.t;
  destination: Contract.t
}

type atomic_withdrawal_batch = withdrawal list

In addition we need to expose functions for encoding and decoding values of these types. Any rollup needs to be able to emit and consume values of this type.