Sovereign Rollup Using Celestia and Dojo
Introduction
This documentation outlines the design and implementation of a sovereign rollup project built on Celestia and Starknet, specifically leveraging Dojo stack. The rollup aims to provide scalable and decentralized execution by using Celestia's modular data availability layer and Starknet's cryptographic proofs.
In this architecture, Katana (Dojo's starknet sequencer) is responsible for producing blocks. Saya (Dojo's proving service) then polls the Katana sequencer to retrieve these blocks. Saya generates cryptographic proofs using STARK (Starknet's proof system) to ensure the validity of these blocks and posts the proofs to Celestia.
Celestia acts as the storage layer for these proofs, with the data posted as blobs. These blobs contain headers that allow backward retrieval of proofs, as long as the commitment and height of the last proof are known. Importantly, the proof already includes the state update, which enables the reconstruction of Katana's state based on the latest posted proof.
It's worth noting that the project described in this overview is conceptually similar to an existing open-source framework for building sovereign rollup, Rollkit. Like Rollkit, our project aims to enable developers to deploy customizable sovereign rollups that leverage modular blockchain architecture. A key difference, however, is that our project is based on the infrastructures that we have built around the Dojo stack. While the specific technologies and implementation details may differ, the core concept of creating scalable, sovereign rollups using a modular approach is shared between these projects. Therefore, the scope of this project will be largely similar to that of the Rollkit project.
Technical Architecture
1. Katana - Block Producer (Starknet Sequencer)
Katana is the Starknet sequencer used in this project. It continuously generates blocks by sequencing transactions.
In addition to block production, Katana will support a sync mode, which allows it to reload the entire state from the latest proof posted on Celestia. When operating in this mode, Katana requires the Celestia height and commitment of the latest proof to begin syncing. The syncing process happens in reverse (backward), retrieving prior proofs and state updates from Celestia until the full state is reconstructed.
This enables Katana to resume or start fresh in a fully sovereign fashion, based on the latest verified proof stored on Celestia.
2. Saya - Prover and Proof Poster
Saya is the component that consumes blocks from Katana. Unlike a push model, where Katana would send blocks to Saya, here Saya actively polls Katana to retrieve the produced blocks. Once a block is retrieved, Saya computes a STARK proof of its validity and the state update associated with it. This proof is then posted to Celestia for storage.
Additionally, Saya is capable of applicative recursion, where it aggregates multiple block transitions into a single proof. By batching several blocks and their respective state updates, Saya can reduce the overhead of proof generation and storage. This recursive aggregation not only increases efficiency but also allows the system to handle larger volumes of transactions while maintaining the integrity of the rollup.
The aggregated proof is posted as a single entity on Celestia, where it represents the transition across multiple blocks, reducing costs and the number of proofs required while ensuring that the complete state update is verifiable.
3. Celestia - Data Availability and Proof Storage
Celestia provides the data availability layer for the rollup, storing the proofs generated by Saya. Each proof is posted in the form of a blob, which contains a header allowing backward retrieval of previous proofs if the commitment and height of the last proof are known. This design enables the reconstruction of Katana's state by following the chain of proofs stored on Celestia, ensuring the integrity of the rollup without reliance on a centralized coordinator.
The proof blobs posted to Celestia contain crucial metadata in their headers, allowing the rollup to maintain state continuity and ensure proof validity. The current header format includes the following fields:
**prev_state_root**: This is the state root of the previous state that was posted on Celestia. It represents the state of the rollup at the time of the last proof, ensuring continuity in the state transitions.**state_root**: This represents the state root of the current state, as reflected by the block(s) and state update(s) data present in the proof. It is the outcome of the state transition verified by the STARK proof.**prev_height**: The height in Celestia's blockchain where the previous proof blob was posted. This allows easy tracking and retrieval of the previous proof from Celestia's storage.**prev_commitment**: The Celestia commitment corresponding to the previous proof blob. The commitment is required along the height to retrieve a blob on Celestia.**proof**: The STARK proof itself, which contains a validated state transition. Within the proof, an output segment includes the specific state update(s) that has been proven, which can be used to verify the integrity of the rollup's and reconstruct the state.
Proof of Concept (alpha) Shortcuts
Given the alpha nature of the integration, certain aspects have been simplified for this initial phase:
Absence of Peer-to-Peer (P2P) Network
The alpha does not yet implement a peer-to-peer network to propagate new heads of the chain or block updates across nodes. As seen in the project's description, only the latest Celestia height and commitment are required to keep track of the chain progress, as the namespace is considered known. This would ideally be communicated using p2p networking.
String-Based Proof Format
The current proofs are represented in a string format for simplicity, and converted to bytes before being posted on Celestia. This format could be optimized in the future by converting the proofs into compressed Starknet finite field elements (felts) and then bytes, improving storage efficiency and reducing bandwidth usage.