Sundial L2: an optimistic rollup for UTXO ledgers

The Sundial L2 is an optimistic rollup for UTXO-based networks, built on the Midgard design and settling to Cardano. It processes blocks of transactions off-chain and commits only fixed-size block headers to a set of L1 smart contracts. A block header has 10 fields and hashes to 28 bytes, however many transactions the block holds. That size difference between a block and its header is how the rollup multiplies the L1’s throughput.

​

How it works

1. Operators take turns, on a schedule enforced by an L1 contract, to receive L2 transactions, assemble blocks, publish them and commit their headers. Anyone can become an operator by posting the required bond and waiting the registration period.
2. The state queue is an L1 linked list of committed headers. A header is appended by the operator whose shift it is, and merged into the confirmed state after its maturity period.
3. Watchers read each committed block from the data availability layer and check it against the ledger rules. Anyone can be a watcher.
4. A fraud proof, verified on L1, removes an invalid block from the queue, slashes the operator’s bond and pays the watcher a share of it.
5. Settlement turns merged blocks into L1 UTXOs that let users absorb deposits into a reserve and pay out withdrawals from it.

​

The security argument

An optimistic rollup offers security similar to processing the transactions on L1, provided four conditions hold:

• the operator bond is large enough to discourage fraud;
• the watcher reward is large enough to keep watchers vigilant;
• the maturity period is long enough for watchers to detect and prove fraud;
• the data availability layer is open to everyone throughout the maturity period.

When the last three make detection near-certain, the bond is a strong deterrent. A disqualified block never enters the confirmed state, so fraud earns nothing to set against the forfeited bond.

​

Why UTXO helps

Sundial’s ledger is a UTXO ledger with deterministic transactions. A fraud proof isolates the one transaction that broke a rule. Violations that involve a second transaction, or the previous UTXO set, need Merkle proofs for those pieces alone. No fraud proof reads the rest of the block or any other block. This keeps fraud proofs small and cheap to verify on L1, which makes it practical for more people to police the rollup. On account-based chains, a much larger part of the global state has to be inspected.

​

Censorship resistance

Fraud proofs protect the validity of blocks. They don’t stop an operator from ignoring you. Two further mechanisms do:

• Inclusion times. Deposits, withdrawal orders and transaction orders are created on L1 and carry an inclusion time. A block whose time interval contains that inclusion time must include the event, or the block is invalid. See Deposits, withdrawals and transaction orders.
• The escape hatch. If operators stop committing blocks altogether, the bond requirement for new operators drops for a limited period so that honest actors can restart production. See Consensus.

​

Headline figures

​

Three layers, one protocol

The protocol exists at three levels of detail, all in the monorepo:

• A formal specification in Lean 4 that models the protocol’s state machines and proves properties of them (technical-spec/).
• A validator implementation of the L1 contracts in Aiken for Plutus V3 (onchain/aiken/).
• A node implementation of the off-chain half: sequencing, the rule engine, block production, commitment, merge and the API (midgard-node, midgard-sdk, midgard-ts).

​

Read next