Search

Search for projects by name

Celestia logoCelestia

  • Type
    Public blockchain
  • Total value secured
    $1.05 B
  • Economic security
    $4.08 B

  • Duration of storage
    30 days
  • Used by
  • Select a bridge
    No bridge
    $1.05 B
    Blobstream
    $0.00


    Risk summary
    Celestia

    Celestia is a modular data availability network that allows L2s to post arbitrary data as blobs.

    Risk analysis
    Economic security
    Staked assets

    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.

    Fraud detection
    DAS

    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.

    Technology

    Architecture

    Celestia 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.

    Blobs 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. Blobs matrix 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. Matrix proofs 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 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.

    DAS

    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.

    1. Celestia Specifications
    2. Celestia Core - CometBFT
    3. Celestia Node - Data Retrieval
    4. Bad Encoding Fraud Proofs
    5. Fraud and Data Availability Proofs paper
    No bridge

    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.

    Risk analysis

    There is no committee attesting to the availability of data.

    Without the bridge, users cannot react in time to malicious actions by the sequencer.

    The relayer does not contribute to the DA bridge liveness since data availability attestations are not integrated in the scaling solution’s proof system.

    Technology

    No DA bridge is selected. Without a DA bridge, Ethereum has no proof of data availability for this project.