Nodes that run the LazyLedger protocol have a number of parameters that can be tweaked with regards to which parts of the data is downloaded, validated, and/or stored. All nodes process the header and lastCommit fields of each block, but can handle the availableDataHeader and availableData fields differently.
We define security assumptions as assumptions under which a given node is guaranteed accountable consensus safety (i.e. that finalized blocks will remain in the prefix of all future sequences of blocks accepted by the node, unless a supermajority (> 2/3) of validator voting power performs an attributable—and thus penalizable—malicious action) and state safety (i.e. that an invalid state transition will not be included in the chain accepted by the node).
Nodes that only process compact block headers will download and validate the block header without downloading or validating the availableDataHeader block field that is committed to in the block header. These nodes cannot perform Data Availability Sampling on block bodies.
Secure under an honest supermajority of validator voting power and a weak subjectivity assumption.
Nodes that process extended block headers will download and validate both the compact block header and the
availabledataheader block field. These nodes can perform Data Availability Sampling on block bodies, and their security assumptions depend on how block bodies are handled.
Block bodies (the availableData block field) can be downloaded and optionally stored and/or served. Storing and serving block body data has no effect on node security assumptions.
Nodes that only process compact block headers have no need for block bodies and simply do not process block bodies.
Secure under an honest supermajority majority of validator voting power and a weak subjectivity assumption.
These nodes perform Data Availability Sampling on block bodies.
Secure under an honest minority of nodes and a weak subjectivity assumption.
These nodes fully download and validate the erasure coding of a random subset of block bodies (configurable locally). Since the erasure coding of each block is stateless, nodes that perform validation of partial bodies contribute to the overall security of the network by being able to produce fraud proofs of invalid erasure coding.
Secure under an honest minority of nodes and a weak subjectivity assumption.
These nodes fully download and validate the erasure coding of all block bodies.
If transactions are not processed, secure under an honest minority of nodes and a weak subjectivity assumption. If transactions are processed, secure under a weak subjectivity assumption.
These nodes process do not process requests with a reserved namespace ID and thus to not know the chain state without relying on a third party.
At most secure under an honest minority of nodes and a weak subjectivity assumption.
Nodes that wish to produce new blocks must know the chain state. Processing all block bodies is actually not needed to know the LazyLedger state, as transactions that pay for message inclusion commit to messages. These nodes process all requests with a reserved namespace ID from block bodies and perform Data Availability Sampling for the remaining (message) data.
At most secure under a weak subjectivity assumption.
For convenience, we will define several common parameter configurations:
- Full nodes provide the strongest security guarantees.
- Block headers: Extended Block Headers
- Block bodies: Full Bodies
- Storage: Not stored beyond a parameter
- Serving: Served to the network
- Transactions: Full Transactions
- Fraud proofs:
- State transition: produce, consume
- Erasure coding: produce, consume
- Partial nodes are capable of producing fraud proofs of invalid transactions and contribute to validating the erasure coding of random blocks.
- Block headers: Extended Block Headers
- Block bodies: Partial Bodies
- Storage: Not stored beyond a parameter
- Serving: Served to the network
- Transactions: Full Transactions
- Fraud proofs:
- State transition: produce, consume
- Erasure coding: produce (partial), consume
- Light nodes perform Data Availability Sampling (DAS) and are secure under an honest minority.
- Block headers: Extended Block Headers
- Block bodies: Sampled Bodies
- Storage: Not stored beyond a parameter
- Serving: Served to the network
- Transactions: No Transactions
- Fraud proofs:
- State transition: consume
- Erasure coding: consume
- Superlight nodes do not perform DAS and are secure under an honest majority.
- Block headers: Compact Block Headers
- Block bodies: No Bodies
- Storage: Not stored
- Serving: Not served to the network
- Transactions: No Transactions
- Fraud proofs:
- State transition: consume
- Erasure coding: consume
- Storage nodes provide the same security guarantees as full nodes.
- Block headers: Extended Block Headers
- Block bodies: Full Bodies
- Storage: Fully stored in erasure-coded form
- Serving: Served to the network
- Transactions: Full Transactions
- Fraud proofs:
- State transition: produce, consume
- Erasure coding: produce, consume
- Partial storage nodes provide the same security guarantees as partial nodes.
- Block headers: Extended Block Headers
- Block bodies: Full Bodies
- Storage: Partially stored in erasure-coded form
- Serving: Served to the network
- Transactions: Full Transactions
- Fraud proofs:
- State transition: produce, consume
- Erasure coding: produce (partial), consume