We are excited to introduce the Astria development cluster, which contains the entire set of components needed to launch a rollup on the shared sequencer network. By choosing to deploy on Astria, rollups gain access to decentralized, and thus censorship resistant, fast block confirmations, and because using Astria is permissionless, deploying a rollup becomes as easy as deploying a smart contract.

Components of the Development Cluster

The development cluster’s reference architecture consists of a local Astria shared sequencer network, a local Celestia network, a Geth rollup with a faucet and block explorer, and the associated services needed to connect these components.

Additional Geth rollups can be deployed to the Astria network with a single command.

The responsibilities of each component are as follows:

• Astria Sequencer — Block producing node which provides commitments on block ordering.

• Data Availability Layer (Celestia) — DA Layer providing finality.

• Rollup (Geth) — Rollup node which performs executions and stores state.

• Composer — Write path middleware which converts rollup transactions into sequencer transactions.

• Conductor — Read path middleware which filters sequencer “meta blocks” for a single rollup’s namespace.

• Relayer — Broadcasts blocks from the sequencer to rollup nodes and posts blocks to the DA Layer.
  
  

The modular components of this stack can be swapped out as needed by the rollup. To join the Astria shared sequencer network, the rollup must be able to write transactions to the Composer and read blocks from the Conductor, which specifies that the blocks produced by the shared sequencer are the canonical blocks "driving" the rollup.

How Astria’s Shared Sequencer Works

To understand the role of each component in the development cluster, let's briefly examine the flow for a single rollup which uses Astria.

Write Path: Transaction Submission

1. Users connect to the Geth rollup using standard Ethereum tooling such as Metamask or Foundry and sign and submit transactions which land in the rollup’s mempool.

2. The Composer retrieves pending transactions from the rollup’s mempool in the order in which they were received (ie. first come, first serve), wraps them in an Astria transaction, and submits them to Astria’s CometBFT mempool. In the current architecture, an instance of the Composer is run alongside each individual rollup.

Our hope is that the Composer serves as a starting point for searchers and block builders interested in collecting end user order flow for one or more rollups and submitting it to the shared sequencer as bundles or blocks.

3. The Astria Shared Sequencer Network creates a single “meta block” consisting of transactions submitted to its mempool by one or more rollups.

The development cluster relies on a single Astria sequencer node. In a live network, a decentralized set of nodes would use CometBFT to reach consensus. Note that Astria is a lazy sequencer, it provides a guarantee on the ordering of transactions in a block, but it doesn’t execute the state transition function (STF) of any given rollup.

4. The ordered blocks from the sequencer are retrieved by the Relayer, which sends them to both the Conductor and the data availability layer, Celestia.

In the default development cluster configuration, Astria’s block time is ~1-second, while Celestia’s is ~11-seconds. At each Astria block time, blocks are sent to the Conductor and added to a queue of pending blocks waiting to be written to Celestia. At each Celestia block time these pending blocks are aggregated into a single batch which is submitted as one transaction to Celestia.

A batch of sequencer blocks are included as a transactions in a Celestia block, at this point we consider the ordering of transactions to be finalized.

Read Path: Block Retrieval and Execution

5. Each rollup runs its own instance of the Conductor. The Conductor receives individual blocks with Astria sequencer soft commitments at ~1-second Astria block times, and batches of blocks with firm commitments from Celestia at ~11-second Celestia block times. The Conductor filters these blocks, or batches of blocks, to contain only the data for its particular rollup’s namespace. Filtered blocks are passed to the rollup to be executed, resulting in an updated rollup state and state root.

When the Conductor receives a batch of blocks from Celestia that it has previously seen from Astria, it informs the rollup that these blocks are finalized.

Getting Started With Astria’s Development Cluster

To try out the development cluster, visit the GitHub repository for a step-by-step guide on deploying a Geth rollup on a local Astria shared sequencer network.

You can also watch the video walkthrough below.

Be sure to follow Astria for upcoming releases and updates!