Celestia
Funds can be lost if
- a dishonest supermajority of Celestia validators finalizes an unavailable block, and there aren't light nodes on the network verifying data availability, or they fail at social signaling unavailable data,
- a dishonest supermajority of Celestia validators finalizes an unavailable block, and the light nodes on the network cannot collectively reconstruct the block.
Celestia is a modular data availability network that allows L2s to post arbitrary data as blobs.
There are staked assets on the DA layer that can be slashed in case of a data withholding attack. A dishonest supermajority of validators must collude to finalize a block with missing or invalid data. The invalid block would be added to the chain but rejected by honest full nodes.
The DA layer uses data availability sampling (DAS) to protect against data withholding attacks. However, the block reconstruction protocol, which enables the minimum number of light nodes to collectively reconstruct the block, is still under development.
Architecture
Consensus
Celestia uses CometBTF, the canonical implementation of Tendermint consensus protocol. The consensus protocol is fork-free by construction under an honest majority of stake assumption. Celestia achieves finality at each block, with an average time between blocks of 12 seconds.
Blobs
In Celestia, blobs are user-submitted data that do not modify the blockchain state.
Each blob has two components, one is a binary object of raw data bytes, and the other is the namespace of the specific application for which the blob data is intended for.
All data posted in a Celestia blob is divided into chunks of fixed size, called shares, and each blob is arranged in a k * k matrix of shares. Currently k = 64, for a total of 4096 shares.
Celestia shares’ rows and columns are erasure-coded into a 2k * 2k matrix and committed to in a Namespaced Merkle Trees (NMTs), a version of a standard Merkle tree using a namespaced hash function.
In NMTs, every node in the tree includes the range of namespaces of all its child nodes, allowing applications to request and retrieve data for a specific namespace sub-tree while maintaining all functionalities (e.g., inclusion and range proofs) of a standard Merkle tree.
Ultimately, a single data root (availableDataRoot) of the Merkle tree is computed with the row and column roots as leaves. This data root is included in the block header as the root of commitments to erasure-coded data so that individual shares in the matrix can be proven to belong to a single data root.
Data Availability Sampling (DAS)
To ensure data availability, Celestia light nodes perform sampling on the 2k x 2k data matrix. Each light node randomly selects a set of unique coordinates within the extended matrix and requests the corresponding data shares and Merkle proofs from full nodes. Currently, a Celestia light node must perform a minimum of 16 samples before declaring that a block is available. This sampling rate ensures that given the minimum number of unavailable shares, a light client will sample at least one unavailable share with a 99% probability. For more details on DAS probabilistic analysis, see the Fraud and Data Availability Proofs paper.
Erasure Coding Proof
Light nodes performing data availability sampling must have the guarantee that the sampled data is erasure coded correctly. In Celestia, light nodes can be notified of a maliciously encoded block through Bad Encoding Fraud Proofs (BEFPs). Full nodes receiving invalid erasure-coded data can generate a fraud-proof to be transmitted to all light and full nodes in the DA network. The proof is generated by full nodes reconstructing the original data from the block data, and verifying that the recomputed data root matches the data root of the block header. Upon receiving and verifying the BEFP, all Celestia nodes should halt providing services (e.g., submitTx).
L2s Data Availability
L2s can post data to Celestia by submitting blobs through a payForBlobs transaction. The transaction can include data as a single blob or multiple blobs, with the total maximum size determined by the maximum block size. The transaction fee is determined by the size of the data and the current gas price. Applications can then retrieve the data by querying the Celestia blockchain for the data root of the blob and the namespace of the application. The data can be reconstructed by querying the Celestia network for the shares of the data matrix and reconstructing the data using the erasure coding scheme.
Funds can be lost if a dishonest supermajority of Celestia validators finalizes an unavailable block, and there aren't light nodes on the network verifying data availability, or they fail at social signaling unavailable data.
Funds can be lost if a dishonest supermajority of Celestia validators finalizes an unavailable block, and the light nodes on the network cannot collectively reconstruct the block.
The risk profile in this page refers to L2s that do not integrate with a data availability bridge. Projects not integrating with a functional DA bridge rely only on the data availability attestation of the sequencer.
There is no committee attesting to the availability of data.
The relayer does not contribute to the DA bridge liveness since data availability attestations are not integrated in the scaling solution’s proof system.
No DA bridge is selected. Without a DA bridge, Ethereum has no proof of data availability for this project.