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.
Funds can be lost if
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.
The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. Participation in the committee is permissionless, based only on stake requirements and an honest majority of validators processing the new operator’s request to join the active set.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
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 Blobstream bridge serves as a ZK light client, enabling the bridging of data availability commitments between Celestia and Ethereum.
The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. Participation in the committee is permissionless, based only on stake requirements and an honest majority of validators processing the new operator’s request to join the active set.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
Architecture
The Blobstream bridge is a data availability bridge that facilitates data availability commitments to be bridged between Celestia and Ethereum.
The Blobstream bridge is composed of three main components: the Blobstream contract, the Succinct Gateway contracts, and the Verifier contracts.
By default, Blobstream operates asynchronously, handling requests in a fulfillment-based manner. First, zero-knowledge proofs of Celestia block ranges are requested for proving. Requests can be submitted either off-chain through the Succinct API, or onchain through the requestCall() method of the Succinct Gateway smart contract.
Alternatively, it is possible to run an SP1 Blobstream operator with local proving, allowing for self-generating the proofs.
Once a proving request is received, the off-chain prover generates the proof and relays it to Blobstream contract. The Blobstream contract verifies the proof with the corresponding verifier contract and, if successful, stores the data commitment in storage.
Verifying a header range includes verifying tendermint consensus (header signatures are 2/3 of stake) and verifying the data commitment root.
By default, Blobstream on Ethereum is updated by the Succinct operator at a regular cadence of 4 hour.
For Blobstream on Arbitrum, the update interval is 1 hour, and for Blobstream on Base, the update interval is 1 hour.
Funds can be lost if the DA bridge accepts an incorrect or malicious data commitment provided by 2/3 of Celestia validators.
Funds can be frozen if excluding L2-specific DA fallback - the permissioned relayers are unable to submit DA commitments to the Blobstream contract.
The system consists of the following permissions on Ethereum:
- A Gnosis Safe with 4 / 6 threshold.
- Can change the configuration of Blobstream - can freeze the bridge contract and update the list of authorized relayers.
- Can upgrade the implementation of Blobstream.
Those are the participants of the BlobstreamMultisig.
Those are the participants of the SuccinctGatewaySP1Multisig.
- A Gnosis Safe with 3 / 4 threshold.
- Can change the configuration of SuccinctGateway - can renounce and transfer ownership, add and remove default prover, set fee vault, and recover stuck ETH.
Those are the participants of the SuccinctGatewayMultisig.
Can change the configuration of SuccinctGatewaySP1 - can verify proofs for the header range [latestBlock, targetBlock] proof.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
The system consists of the following permissions on Arbitrum One:
- A Gnosis Safe with 4 / 6 threshold.
- Can change the configuration of Blobstream - can freeze the bridge contract and update the list of authorized relayers.
- Can upgrade the implementation of Blobstream.
Those are the participants of the BlobstreamMultisig.
Those are the participants of the SuccinctGatewaySP1Multisig.
Can change the configuration of SuccinctGatewaySP1 - can verify proofs for the header range [latestBlock, targetBlock] proof.
- A Gnosis Safe with 3 / 4 threshold.
- Can change the configuration of SuccinctGateway - can renounce and transfer ownership, add and remove default prover, set fee vault, and recover stuck ETH.
Those are the participants of the SuccinctGatewayMultisig.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
The system consists of the following permissions on Base:
- A Gnosis Safe with 4 / 6 threshold.
- Can change the configuration of Blobstream - can freeze the bridge contract and update the list of authorized relayers.
- Can upgrade the implementation of Blobstream.
Those are the participants of the BlobstreamMultisig.
Those are the participants of the SuccinctGatewaySP1Multisig.
Can change the configuration of SuccinctGatewaySP1 - can verify proofs for the header range [latestBlock, targetBlock] proof.
- A Gnosis Safe with 3 / 4 threshold.
- Can change the configuration of SuccinctGateway - can renounce and transfer ownership, add and remove default prover, set fee vault, and recover stuck ETH.
Those are the participants of the SuccinctGatewayMultisig.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
Can change the configuration of Blobstream - it is a ‘Relayer’ and can call commitHeaderRange() to commit block ranges. Since adding and removing Relayers emits no events, there can be more relayers than are presented here.
The system consists of the following smart contracts on Ethereum:
Users could interact with this contract to request proofs onchain, emitting a RequestCall event for off-chain provers to consume. Now deprecated, SP1 is used instead.
The Blobstream DA bridge. This contract is used to bridge data commitments between Celestia and the destination chain. It specifies relayers that commit block ranges, but due to the lack of emitted events, there may be more relayers than are presented here.
Upgrade delay: No delay
The system consists of the following smart contracts on Arbitrum One:
Users could interact with this contract to request proofs onchain, emitting a RequestCall event for off-chain provers to consume. Now deprecated, SP1 is used instead.
The Blobstream DA bridge. This contract is used to bridge data commitments between Celestia and the destination chain. It specifies relayers that commit block ranges, but due to the lack of emitted events, there may be more relayers than are presented here.
Upgrade delay: No delay
The system consists of the following smart contracts on Base:
Users could interact with this contract to request proofs onchain, emitting a RequestCall event for off-chain provers to consume. Now deprecated, SP1 is used instead.
The Blobstream DA bridge. This contract is used to bridge data commitments between Celestia and the destination chain. It specifies relayers that commit block ranges, but due to the lack of emitted events, there may be more relayers than are presented here.
Upgrade delay: No delay
The current deployment carries some associated risks:
Funds can be lost if the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades.
Funds can be frozen if the bridge contract is frozen by the Guardian (BlobstreamMultisig).
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).