Blobstream
Blobstream allows Ethereum developers to build high-throughput L2s using Celestia, the first DA layer with Data Availability Sampling.
This page and following tutorials will go over Blobstream and how validators on Celestia can run it.
If you're looking to learn more, you can view the orchestrator-relayer repository, and read more about Blobstream.
Overview
Blobstream, consists of two components: an orchestrator and a relayer.
In the following diagram, we show how a layer 2 would post data to Celestia and then verify that it was published in the target EVM chain.
In fact, data will first be attested to by the Celestia validator set, i.e. signing commitments committing to the data. Then, these signatures will be relayed to the target EVM chain (in this case, Ethereum). Finally, the layer 2, or any party, will be able to verify that the data was published to Celestia directly on the EVM chain on the Blobstream smart contract. You can reference the Blobstream smart contract.
The specification of Blobstream Valsets, which track the Celestia validator set changes, can be found in ADR 002.
Blobstream data commitments, which represent commitments over sets of blocks defined by a data commitment window, are discussed more in-depth in ADR 003.
The orchestrator is part of the validator setup and works as follows:
- Celestia App: creates an attestation on the state machine level that needs to be signed
- The orchestrator: queries the attestation, signs it, then submits the signature to the Blobstream P2P network
The diagram below goes over this process.
The relayer submits the attestations' signatures from the Blobstream P2P network to the target EVM chain.
NOTE: If the contract is still not deployed, then it needs to be deployed before its used by the relayer. Check the deployment documentation for more details.
The diagram below goes over this process.
You can learn more about the mechanics behind the relayer in ADR 004.
Blobstream and data availability committees (DACs)
Decentralization and security
Blobstream is built on Celestia, which uses a CometBFT-based proof-of-stake system. An incorrect data availability attestation in this system will ultimately be penalized (currently not implemented), ensuring validators act in good faith. Thus, Blobstream shares the same security assumptions as Celestia. In contrast, data availability committees (DACs), are typically centralized or semi-centralized, relying on a specific set of entities or individuals to vouch for data availability.
Mechanism of verification
Blobstream uses data availability attestations, which are Merkle roots of the batched L2 data, to confirm that the necessary data is present on Celestia. The L2 contract on Ethereum can check directly with Blobstream if the data is published on Celestia. Similarly, a DAC would rely on attestations or confirmations from its permissioned members.
Flexibility and scalability
Blobstream is designed to offer high-throughput data availability for Ethereum L2s, aiming to strike a balance between scalability and security. It operates independently of Ethereum's gas costs, as Celestia's resource pricing is more byte-focused rather than computation-centric. On the other hand, the scalability and flexibility of a DAC would depend on its specific design and implementation.
In summary, both Blobstream and DACs aim to ensure offchain data availability, but Blobstream offers a more decentralized, secure, and scalable solution compared to the potential centralized nature of DACs.
Setting up Blobstream
The following sections in this category presume you have the following setup:
- A celestia-app validator node running