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

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.