Celestia: Modular Data Availability for OP Stack

Celestia: Data Availability for OP Stack

Original article by Javed Khan, Celestia blog, translated by GWEI Research (DeFi Road)

Introduction

Since its release last year, OP Stack has gained tremendous attraction among developers. It has been accepted by new developers and modular infrastructure providers such as Caldera and Conduit, enabling developers to quickly launch their own rollups.

As announced last year, modularity is a fundamental aspect of OP Stack’s vision:

• Encrypted wallet developer Demox Labs secures $4.5 million in funding led by HackVC
• Circle will launch native USDC on Arbitrum on June 8th.
• Unprecedented demand for AI computing power, what is the role of Web3?

Optimism’s rapid-approaching Bedrock upgrade will modularize OP Stack’s execution layer and proof systems, enabling compatibility with future fraud and validity proofs.

Inspired by this, Celestia Labs has been focused on further advancing OP Stack’s modularity. Therefore, today, we are pleased to announce the beta release of the modular data availability (DA) interface of OP Stack, which is the first OP Stack Mod that OP Labs is focused on developer feedback. This interface allows developers to define the DA layer and inherit security from any blockchain they like, whether it’s Ethereum, Celestia, or Bitcoin.

Developers can start experimenting with using Celestia for DA and “settling” on the Ethereum version of OP Stack today. Caldera will soon release the Taro testnet, which allows developers and users to use Modular DA to trial the first public testnet of OP Stack.

The data availability layer is the foundation of the rollup architecture, ensuring the availability of data required for independent validation of rollup chains. Below we will explore the basics of data availability in OP Stack, and how we modularize it by defining a well-designed DA interface to publish and retrieve data from L1.

Data Availability in OP Stack: Today

How does OP Stack handle data availability today? For our purposes, we delve into two fundamental components, the Rollup Node and the Batcher, as described below.

Rollup Node

The Rollup Node is the component responsible for deriving the correct L2 chain from the L1 block (and its associated receipts). The rollup node retrieves the L1 block, filters out data transactions (usually in the form of transaction calldata ), and derives the correct L2 chain from that data.

Batcher – Batch Submitter

The batch submitter, also known as the batcher, is the entity that submits L2 sequencer data to L1 for validators to use. Both the rollup node and the batcher work in a loop, allowing the new L2 block data submitted by the batcher to be retrieved by the rollup node from L1 and used to derive the next L2 block.

Each transaction submitted by a batch program contains calldata, which is L2 sequencer data broken down into bytes called frames, the lowest abstraction level of data in Optimism.

Modular DA Interface for OP Stack

When creating a modular DA interface for the OP Stack our goal was simple: to enable aggregation developers to designate any blockchain as their data availability layer, whether it be Ethereum, Celestia, or Bitcoin. Without such an interface, each integration of a new DA layer could potentially require developers to implement and maintain a separate branch of the OP Stack.

The OP Stack already includes abstracts for specifying the L1Chain and L2Chain in the codebase, allowing us to model a new blockchain-agnostic interface for the data availability chain, which we call DAChain.

With the interface defined below, developers can implement DAChain to read and write data to any underlying blockchain or even centralized backends such as S3.

[object Object],[object Object],[object Object],...[object Object]

Writing Phase

The following outlines the integration with the batch processing program in the Celestia implementation of the interface:

SimpleTxManager.send is the function responsible for creating and sending actual transactions, which is modified to call WriteFrame to write the frame to Celestia and return a reference. The reference is then submitted as calldata to the batch processing inbox address, replacing the usual frame data.

[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Reading Phase

The following outlines the Celestia implementation of the interface integrated with the rollup node:

DataFromEVMTransactions is the function responsible for returning frame data from a list of transactions. It is modified to use the frame reference retrieved from the calldata in the batch processing inbox to actually retrieve the frame and append it to the returned data.

[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Note that the call to NamesBlockingcedData returns a byte slice array of all blobs submitted at the given BlockHeight, so we only return the TxIndex that we are interested in.

Integrate Celestia as DA Layer

Shows a chart of the OP stack architecture compared to Celestia+OP stack integration.

By making some small modifications to the Rollup node and batcher, we can enable OP Stack to use Celestia for DA.

This means that all the data required to derive L2 chains can be provided as local blob data on Celestia rather than being published to Ethereum, although a small fixed-size frame reference is still published to Ethereum as batcher calldata. The frame reference is used to look up the corresponding frame on Celestia using a celestia-node light node.

How does it work?

Write Phase

As mentioned above, the batcher submits L2 sequencer data as bytes called frames to a batcher inbox contract address on Ethereum L1.

We retain the batcher and calldata transaction to ensure frame ordering, but we replace the frame in calldata with a fixed-size frame reference. What is a frame reference? It is a reference to a Celestia data transaction that has successfully included the frame data as part of Celestia.

We do this by embedding a celestia-node light node in the batcher service. Whenever there is a new batch waiting to be submitted, we first submit a data transaction to Celestia using the light node, and then submit only the frame reference in the batcher calldata.

Read Phase

In the read phase, we do the opposite, i.e., we use the frame reference in the batcher transaction calldata to resolve it and retrieve the corresponding actual frame data from Celestia. Again, we embed a celestia-node light node in the rollup node to query its transaction.

When deriving L2 chains, the rollup node now transparently reads data from the light node and is able to continue building new blocks. The light node downloads only the data submitted by the rollup, rather than downloading the entire chain as in Ethereum.

Future

Fraud proof is a key part of the Optimism after Bedrock roadmap, and we hope to explore upgrading our OP Stack x Celestia integration to use fraud proofs on Ethereum mainnet.

To do this, we can leverage the Quantum Gravity Bridge (QGB), which will relay cross-chain DA proofs to Ethereum to enable on-chain verification that aggregated data is available on Celestia so that the aggregated data can be used in fraud proofs. This will allow OP Stack Rollup to directly leverage the DA assurance provided by Celestia.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!