LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts

The five-minute read

One action, walked through

1. A block producer orders transactions, which may be opaque blobs belonging to different applications.
2. The block is erasure-coded so that missing pieces can be detected and reconstructed.
3. Light clients sample random shares and check Merkle proofs against the header.
4. An application node downloads the blobs in its namespace and executes its own rules.
5. If a producer hid part of the block, sampling fails with high probability and honest clients refuse the header.

The argument, unpacked

What has to be true

• Enough light clients sample that withholding is likely to be noticed, or the security argument is about a different threat.
• Erasure coding matches the commitment in the header. A bad code with a good-looking Merkle root is the attack.
• Application nodes can fetch their namespace before they are asked to act on a state.
• Users agree on the execution rules off-chain. The base chain will not patch a disagreement about the meaning of the bytes.

What happened after the paper

Celestia is the network built from this line: a data-availability layer with namespaced blobs and sampling. Rollups that post there are applications in the paper's sense. The 2019 paper is the lazy-ledger argument. Blob markets and live parameters are the network's.

What to check before you use the idea

• Does this chain execute the contract, or only order the data?
• How many shares does a light client sample, and what failure probability does that imply?
• Who executes, and how does an invalid execution get rejected?
• Can an application download only its own namespace?

Terms

Data availability

The property that a block's bytes were actually published, not merely promised by a header.

Sampling

A light client fetching a few random pieces to gain confidence the whole block was published.

Lazy execution

Leaving contract rules to clients instead of running them inside the consensus chain.

Namespace

A partition of the blob log so one application can find its data without reading every other application's.

The problem the paper names

A chain that both orders data and executes every transaction forces every node to do both. The paper splits them. Consensus guarantees that a block's data was published. Interpreting that data is an application's job.

What the design proposes

• Block data is erasure-coded so a client can sample pieces and gain confidence the whole block was available.
• Namespacing lets an application fetch its own data without taking the entire chain's execution.
• Fraud or validity proofs, if used, are checked by the application client, not by the lazy base layer.

How the mechanism is specified

• Data availability sampling is the replacement for 'every full node downloaded everything'.
• The base layer does not know whether an application transition was valid. That is the point, and the risk.
• Celestia's later implementation choices are not all fixed by the 2019 paper.

What this page does not treat as proven

• Sampling confidence is probabilistic and depends on the code, the sample count and the adversary.
• A lazy base layer will not save an application that loses its own execution rules.
• The paper is not a product comparison against other data-availability layers.

Why a venture studio still reads it

This is the paper we use when a team conflates 'settlement', 'execution' and 'publication'. LazyLedger says publication can be its own ledger. The venture then has to say who executes.