LibraryScaling2019Design paperCorpus record
LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts
Celestia. Mustafa Al-Bassam.
Al-Bassam's LazyLedger paper, the research origin of Celestia. The base layer orders and makes data available. It does not execute application transitions. Clients check availability with sampling, and applications execute on their own.
LazyLedger, the paper behind Celestia's idea, has a chain that orders and publishes data, and leaves execution to clients. The chain does not run your contract. It makes the bytes available.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 8
Code
Source, repository, and what is actually hosted
- arXiv:1905.09274https://arxiv.org/pdf/1905.09274
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
Execution is the expensive habit
A chain that runs every contract is limited by its slowest honest executor. This paper stops doing that. It offers an ordered log of data.
Claim 02 · Paper model
Availability has to be checkable by a light client
A header that says 'the data is there' is not enough. The paper uses data-availability sampling so a small client can become confident the block was published.
Claim 03 · Paper model
Applications interpret the bytes
Two clients who downloaded the same data and applied the same rules reach the same state. The chain will not referee their contract logic. Fraud proofs or other client-side checks are how invalid transitions get rejected.
Claim 04 · Paper model
Namespaces keep one log useful to many apps
Later designs partition the blob space so a rollup downloads its own data. The paper's core is the shared ordered bulletin board.
Claim 05 · Paper model
This is not a smart-contract platform in the Ethereum sense
There is no global virtual machine in the base layer of this design. Citing it as one misunderstands the laziness. The laziness is the feature.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 Execution is the expensive habit
Observation
What the study says
A chain that runs every contract is limited by its slowest honest executor. This paper stops doing that. It offers an ordered log of data.
Model
What has to hold
Users agree on the execution rules off-chain. The base chain will not patch a disagreement about the meaning of the bytes.
Falsifier
What would retire it
Does this chain execute the contract, or only order the data?
02 Availability has to be checkable by a light client
Observation
What the study says
A header that says 'the data is there' is not enough. The paper uses data-availability sampling so a small client can become confident the block was published.
Model
What has to hold
Enough light clients sample that withholding is likely to be noticed, or the security argument is about a different threat.
Falsifier
What would retire it
How many shares does a light client sample, and what failure probability does that imply?
03 Applications interpret the bytes
Observation
What the study says
Two clients who downloaded the same data and applied the same rules reach the same state. The chain will not referee their contract logic. Fraud proofs or other client-side checks are how invalid transitions get rejected.
Model
What has to hold
Users agree on the execution rules off-chain. The base chain will not patch a disagreement about the meaning of the bytes.
Falsifier
What would retire it
Does this chain execute the contract, or only order the data?
04 Namespaces keep one log useful to many apps
Observation
What the study says
Later designs partition the blob space so a rollup downloads its own data. The paper's core is the shared ordered bulletin board.
Model
What has to hold
Users agree on the execution rules off-chain. The base chain will not patch a disagreement about the meaning of the bytes.
Falsifier
What would retire it
Can an application download only its own namespace?
05 This is not a smart-contract platform in the Ethereum sense
Observation
What the study says
There is no global virtual machine in the base layer of this design. Citing it as one misunderstands the laziness. The laziness is the feature.
Model
What has to hold
Enough light clients sample that withholding is likely to be noticed, or the security argument is about a different threat.
Falsifier
What would retire it
Does this chain execute the contract, or only order the data?
03 Sequence
One action, as an operating tape
- 01A block producer orders transactions, which may be opaque blobs belonging to different applications.
- 02The block is erasure-coded so that missing pieces can be detected and reconstructed.
- 03Light clients sample random shares and check Merkle proofs against the header.
- 04An application node downloads the blobs in its namespace and executes its own rules.
- 05If a producer hid part of the block, sampling fails with high probability and honest clients refuse the header.
04 Load-bearing
The argument, and where a pitch drops it
Ordering without execution is a real service
The cut
Rollups still need someone to order their data and keep it public. Doing that, and only that, is a coherent product. The paper's discipline is refusing to add a global execution environment that would recreate the bottleneck it removed.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The paper is not a product comparison against other data-availability layers.
Sampling is a probability, not a download
The cut
A light client that samples a handful of shares has a stated chance of noticing a withheld block. Parameters decide that chance. A client that samples nothing, and trusts the header, is not using the paper.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The paper is not a product comparison against other data-availability layers.
Fraud proofs still need someone full
The cut
If the application relies on fraud proofs, at least one honest full node for that application must see the data and raise the alarm. Sampling shows the data was published. It does not execute the contract for you.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Sampling confidence is probabilistic and depends on the code, the sample count and the adversary.
05 Register
What has to be true
Network · Not re-measured
Enough light clients sample that withholding is likely to be noticed, or the security argument is about a different threat.
Model · Not re-measured
Erasure coding matches the commitment in the header. A bad code with a good-looking Merkle root is the attack.
Model · Not re-measured
Application nodes can fetch their namespace before they are asked to act on a state.
Model · Not re-measured
Users agree on the execution rules off-chain. The base chain will not patch a disagreement about the meaning of the bytes.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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 the desk 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
Protocols
Papers
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.