Our 2023 Atomic IBC paper makes a business case for why atomic (aka synchronous) composability is the ultimate moat for a blockchain platform, then presents a concept for extending the current asynchronous IBC protocol to support a synchronous mode when possible.

We left the implementation and platform for this open, but suggest an initial direction: Megablocks.

The Megablocks concept is the idea of taking many separate Cosmos state machines and having them share blocks on one CometBFT consensus process. Each “megablock” would contain a block for every participating state machine. This provides atomic inclusion, and provides the basis to build the deeper integrations between state machines called for by Atomic IBC.

Megablocks Prototype

As part of our work towards Atomic IBC, we built a prototype of Megablocks, starting from something called the “ABCI multiplexer shim”. ABCI is a protocol used to communicate between the CometBFT consensus process and the Cosmos state machine using it.

Our ABCI multiplexer enables multiple state machines to use one consensus process. On each validator’s infrastructure, the “megablock” is split up into separate transactions and passed to several state machines for parallel execution. When this is finished, the resulting root hashes are combined, and Comet reaches consensus on this result.

This architecture provides several things:

• Each state machine has the same level of security as the underlying Comet process
• Scaling is horizontal- in principle many state machines can be added and run in parallel
• Atomic IBC can be built on top of this architecture, by feeding transactions within an atomic bundle into the relevant state machines synchronously (more on this in the paper)

Here’s a screencast demonstrating the Megablocks proof of concept in action, running two state machines on one CometBFT instance:

https://drive.google.com/file/d/1rSo9NeqNgBmkbSLJlMtUF_xUAvGN87Am/view?usp=sharing

Thanks to Bernd Müller for the implementation and video demo! Here is a link to the repo.

Megablocks limitations and rollup architecture

Some of the biggest questions around Megablocks are about how one of these Cosmos state machines differs from a full Cosmos chain (running standalone or with ICS).

Benefits (vs full Cosmos chain):

• Atomic inclusion is enabled easily by Megablocks, with full Atomic IBC possible with more work
• Inherit full security of the validator set without the scaling burden of running full separate Comet networks
• Loading new state machines into the same Megablocks instance can potentially be standardized to be lighter weight for validators than installing a whole new Cosmos chain

Limitations:

• State machines in Megablocks do not easily have access to ABCI++
• State machines in Megablocks cannot run custom off-chain code (oracles etc)
• State machines in Megablocks cannot easily have custom block times
• State machines in Megablocks cannot have custom block size
• State machines in Megablocks may interfere with each other if they have apphash errors or timeouts

In general, the limitations of Megablocks are the same as apply to rollups.

This has led to a question- if we are going to accept these limitations anyway, why not move to a full rollup architecture and benefit from provable state transitions and a modular architecture? In fact, Megablocks is very similar to a shared sequencer. Let’s look at some of the benefits of moving Atomic IBC to a rollup architecture.

Benefits of rollup architecture (vs Megablocks)