Skip to main content
Operators commit only block headers to L1. They publish each full block to a data availability (DA) layer for at least the maturity period. Confirmed blocks then pass to archive nodes. DA is critical to security. A watcher can only challenge a block it can read. An operator that withholds a block’s data could merge an invalid block once the maturity period ends.

​
Requirements

A DA backing must provide all of the following for every committed block:
  1. Availability through maturity. The full block is retrievable from the moment its header is committed until the block is merged.
  2. Open retrieval. Anyone can retrieve it without permission and without paying the operator.
  3. Content addressing. The block is retrievable by its header hash, so the content can be checked against what is on L1.
  4. Timestamping. The backing attests when the block first became retrievable.
  5. Reconstructibility. The data is enough to rebuild the four tries of the block body and the transaction contents that fraud proofs work on.
Requirements 1 to 3 make fraud detectable. Requirement 4 makes withholding attributable. Requirement 5 makes every violation provable.

​
How a watcher retrieves a block

1

Read the state queue

Take a node’s header hash and header from L1.
2

Retrieve the block

Fetch it by header hash from the DA backing. Check that the retrieved header hashes to that value and matches the header on L1.
3

Rebuild the tries

Parse the body’s four sorted sets and rebuild the four Merkle Patricia Tries.
4

Compare roots

Check each rebuilt root against the corresponding root in the header.
5

Replay the block

Start from the previous block’s UTXO set, apply withdrawals, transactions and deposits in order, and evaluate the ledger rules.
A watcher that finds a violation submits the matching fraud proof within the block’s maturity period.

​
Serialization

A block is serialized as its header followed by its body. Each of the body’s four sets is written as key-value pairs sorted by key. The sort order is part of the format: it makes the serialized set canonical, so every honest party derives the same trie. The codec’s schema is cddl-files/codec.cddl in the monorepo, and its reference implementation is the midgard-ts package.

​
Root verification

If a header’s root doesn’t match the published data, that mismatch can be proven on L1. The procedure streams over a set’s key-value pairs in ascending key order, building the trie along the path of the latest key and finalizing each subtrie as soon as the ordering guarantees it is complete. Its working state is bounded by the depth of the trie, not the size of the set. On L1 it runs as a computation thread, each transaction processing a bounded chunk. It runs only when a watcher challenges a block, so honest blocks never pay for it.

​
Storage backings

The protocol fixes the interface, not the substrate. Three kinds of backing fit it:

​
Archive nodes

Archive nodes store the data of confirmed blocks. This is simpler than DA for unconfirmed blocks: the confirmed state’s chained header hash pins the whole history, so an archive either matches it or doesn’t. Every operator keeps the latest confirmed UTXO set, because it needs that set to build valid blocks. That set, plus the block data in the DA layer, is the minimum needed to keep producing blocks. The rollup’s security doesn’t depend on older history.