This page will cover the main components of Rollkit.
Rollup sequencer nodes collect transactions from users, aggregate them into blocks, and post the blocks onto a data availability (DA) layer (such as Celestia) to be ordered and finalized. Full nodes execute and verify rollup blocks, and in the case of an optimistic rollup, propagate fraud proofs when needed. Light clients will receive headers, verify proofs (fraud, zk, etc), and authenticate trust-minimized queries about the state.
Rollkit is a fully functional Application BlockChain Interface (ABCI) client software. It can be used as a CometBFT replacement for any ABCI application. Thanks to this compatibility, you can use tools like abci-cli to test and debug your rollup.
Would you like to change your Cosmos SDK application to a Rollkit rollup? No problem! You need to replace the Cosmos SDK Go dependency with a Rollkit-enabled version, which can be found at the
rollkit/cosmos-sdk repository follows the release branches of upstream Cosmos SDK, but with the bonus of using Rollkit instead of CometBFT as the ABCI client.
And don't forget to replace another dependency,
rollkit/cometbft, which has an enhanced ABCI interface that includes the methods needed for state fraud proofs.
Data availability (DA) can be accessed using generic interfaces. This design allows for seamless integration with any DA layer. New implementations can be plugged in programmatically, without a need to fork Rollkit.
DataAvailabilityLayerClient interface includes essential lifecycle methods (
Stop) as well as data availability methods (
BlockRetriever interface serves to enable syncing of full nodes from the data availability layer. It's important to keep in mind that there is no direct correlation between the DA layer block height and the rollup height. Each DA layer block may contain an arbitrary number of rollup blocks.
Celestia is an example of a data availability integration implemented for Rollkit. It's using the Celestia Node Gateway API via the
rollkit/celestia-openrpc package. To deploy a Rollkit rollup on Celestia you also have to run a Celestia light node.
Use of other data availability (DA) layers is also supported by Rollkit, and research integrations for Bitcoin, Mock, gRPC are works in progress.
The mempool is inspired by the CometBFT mempool. By default, transactions are handled in a First Come, First Served (FCFS) manner. Ordering of transactions can be implemented on the application level; currently this is possible by returning a priority on
CheckTx, and once we support ABCI++ it is also possible via
PrepareProposal and the application mempool.
The block manager contains routines
SyncLoop that communicate through Go channels. These Go routines are ran when a Rollkit node starts up (
OnStart). Only the sequencer nodes run
AggregationLoop which controls the frequency of block production for a rollup with a timer as per the
All nodes run
SyncLoop which looks for the following operations:
- Receive block headers: block headers are received through a channel
HeaderInChand Rollkit nodes attempt to verify the block with the corresponding block data.
- Receive block data: block bodies are received through a channel
blockInChand Rollkit nodes attempt to verify the block.
RetrieveLoopwith timer as per the
All nodes also run
RetrieveLoop which is responsible for interacting with the data availability layer. It checks the last updated
DAHeight to retrieve a block with timer
DABlockTime signaled by
SyncLoop. Note that the start height of the DA layer for the rollup,
DAStartHeight, is configurable in
- Information about the rollup node: information such as node's health, status, and network info.
- The rollup blockchain: getting information about the rollup blockchain such as blocks and block headers.
- The rollup transactions: getting transaction information and broadcasting raw transactions, with search capabilities.
- ABCI: rollup application information.
The following RPC protocols are currently supported:
- URI over HTTP
- JSON-RPC over HTTP
- JSON-RPC over WebSockets
Rollkit's P2P layer enables direct communication between rollup nodes. It's used to gossip transactions, headers of newly created blocks, and state fraud proofs. The P2P layer is implemented using libp2p.
Rollkit uses DHT-based active peer discovery. Starting a node connects to pre-configured bootstrap peers, and advertises its namespace ID in the DHT. This solution is flexible, because multiple rollup networks may reuse the same DHT/bootstrap nodes, but specific rollup network might decide to use dedicated nodes as well.
Rollkit node types
Rollkit nodes are implemented in the
Full nodes verify all blocks, and produce fraud proofs for optimistic rollups. Since they fully verify all rollup blocks, they don't rely on fraud or validity proofs for security.
Light node (work in progress)
Light nodes are light-weight rollup nodes that authenticate block headers, and can be secured by fraud proofs or validity proofs. They're recommended for average users on low-resource devices. Users running light nodes can make trust-minimized queries about the rollup's state. Currently, Rollkit light nodes are still under development.
Rollups can utilize sequencer nodes. Sequencers are block producers for rollups, responsible for aggregating transactions into blocks, and typically executing transactions to produce a state root, used by the rollup's light clients.
Rollkit plans to support multiple different pluggable sequencer schemes:
|Deploy in one-click||Faster soft-confirmations than L1||Control over rollup's transaction ordering||Atomic composability with other rollups||Censorship resistance||Implementation Status|
|Centralized sequencer||Requires spinning up a sequencer||Yes ✅||Yes ✅||No ❌||Eventual ⏳*||✅ Implemented!|
|Decentralized sequencer||Requires spinning up a sequencer set||Yes ✅||Yes ✅||No ❌||Real-time ⚡️||Planned|
|Shared decentralized sequencer||Yes ✅||Yes ✅||No ❌||Yes ✅||Real-time ⚡️||Planned|
|Pure fork-choice rule||Yes ✅||No ❌||Maybe 🟡||Maybe 🟡||Eventual ⏳||Planned|
"Pure fork-choice rule" refers to any rollup without privileged sequencers, e.g. nodes defer to the data availability layer for ordering and apply a "first-come-first-serve" fork-choice rule.
* implementation of this property is in progress.
State validity modes
Pessimistic (full nodes only)
A pessimistic rollup is a rollup that only supports full nodes that replay all the transactions in the rollup in order to check its validity. Rollkit supports pessimistic rollups by default.
Pessimistic rollups are similar to how Tether uses Bitcoin as a data availability layer via OmniLayer.
Optimistic (fraud proofs) (work in progress)
Rollkit's current design consists of a single sequencer that posts blocks to the DA layer, and multiple (optional) full nodes. Sequencers gossip block headers to full nodes and full nodes fetch posted blocks from the DA layer. Full nodes then execute transactions in these blocks to update their state, and gossip block headers over the P2P network to Rollkit light nodes.
Once state fraud proofs are enabled, when a block contains a fraudulent state transition, Rollkit full nodes can detect it by comparing intermediate state roots (ISRs) between transactions, and generate a state fraud proof that can be gossiped over the P2P network to Rollkit light nodes. These Rollkit light nodes can then use this state fraud proof to verify whether a fraudulent state transition occurred or not by themselves.
Overall, state fraud proofs will enable trust-minimization between full nodes and light nodes as long as there is at least one honest full node in the system that will generate state fraud proofs.
Note that Rollkit state fraud proofs are still a work in progress and will require new methods on top of ABCI, specifically,
You can find current detailed design and the remaining work needed to push state fraud proofs towards completion in this Architecture Decision Record (ADR).
Validity (ZK proofs)
Validity (ZK) rollups are planned, but not currently supported by Rollkit.