Many new protocols that use the same basic techniques pioneered by Interchain Security are emerging. Some of these are Mesh Security, Eigenlayer, and Polygon 2.0. In all of these protocols, stake from one blockchain system can be used to secure another. Right now, they are different protocols, but over the long term, interoperability requires nothing more than a little bit of shim code.
The future will be a fluid market of commoditized proof of stake security. What token you choose to stake will have no bearing on which applications you can choose to secure, and what chain/rollup/DA/etc they run on. A market where products are undifferentiated is known as a commoditized market. It is generally considered to be difficult for producers to profit in such a market. The market for shared security seems to be going in this direction.
Conversely, a differentiated product is one that can only be obtained from one source. Even if there are other products of its type that it competes with, it has a unique offering that cannot be obtained elsewhere. There is a good reason for consumers to switch to such a product, and if they are switching away from it, they will have to give something up. The shared security market does not have differentiation, since the thing being bought and sold is a number representing assets at stake, which can come from many different sources.
In addition to operating in a commoditized market, shared security platforms do not have a strong network effect. A network effect is when the more use a product gets, the more useful it becomes. Many inventions, such as railroads, the telegraph, the power grid, the internet, and social media, all harness strong network effects. Shared security providers do not have such a network effect, since securing a larger number of applications does not, by itself, make the security more effective.
While commoditized markets are not good for producers, they are good for consumers. Commoditization means quick, scaleable, and inexpensive access to a resource. In the proof of stake security market, this means that any application will be able to get access to exactly as much security as it needs from the security mesh, at a competitive price.
The platforms which will succeed in this security mesh will not rely solely on providing security, but will instead have the following characteristics:
Differentiation: Applications joining these platforms will be getting something which they can’t get anywhere else. Applications leaving these platforms will have to sacrifice functionality or resources to do so.
Network effect: The more applications join such a platform, the greater the benefits from using the platform.
Table of Contents
Atomic composability: A differentiated offering
Atomically composable platforms allow the applications using them to communicate with each other instantly. Transactions between applications on an atomically composable platform can be programmed synchronously, and they don’t have to worry about the state of any of the applications on the platform changing during the time that the transaction is in progress.
Some examples of atomic composability platforms are monolithic smart contract platforms like Ethereum and Solana, shared sequencers like Astria and Espresso, and the subject of this paper, Atomic IBC. Some examples of platforms that do not provide atomic composability are rollups using independent sequencers, Cosmos chains communicating using regular IBC, and shared security platforms such as ICS, mesh security, or Eigenlayer.
Atomic composability platforms are differentiated because they offer the ability to interoperate tightly with a certain set of applications, something that is impossible to get even when switching to another atomic composability platform (they will have a different set of applications). In contrast to selling security, this differentiation means that a platform can build up a lead with a unique offering, without constantly having its market share eroded by competitors who can offer the same amount of security for less.
As well as being differentiated, atomic composability platforms have strong network effects. The more high quality applications are on an atomic composability platform, the more sense it makes for new applications to join. This dynamic is known as a network effect, and is key to building a durable advantage. Simply providing security does not have such a network effect.
Monolithic smart contract platforms are one of the most common forms of atomically composable platforms. For example, on Ethereum, function calls between contracts happen atomically, and no other state on Ethereum changes while a series of function calls between contracts is in progress. A downside of most monolithic smart contract platforms (but not all, see Solana) is that they tend not to be very scalable. They process transactions sequentially, one at a time, which can be a huge bottleneck during times of high demand. Another downside is that they generally only work with one programming model, and smart contracts don’t offer full flexibility.
Atomic IBC: Atomic composability with multichain scalability
Atomic IBC is an evolution of Replicated Security which allows consumer chains (or “atomic zones”) to compose atomically with one another, while still being able to scale infinitely using parallelism. This is accomplished with a protocol called Atomic IBC. Consumer chains can connect to other consumer chains and external chains using normal IBC. This is asynchronous and non-atomic. But for transactions which must compose atomically between consumer chains, atomic IBC can be used.
An atomic IBC bundle consists of several transactions happening across multiple zones, with communication coordinated by the IBC protocol. Atomic IBC transactions are fully atomic. If one piece of an atomic IBC transaction fails, the whole transaction is rolled back, across all zones. Atomic IBC transactions also preserve isolation- no other state on any zone will change during the atomic IBC transaction, except for state changed by the atomic IBC transaction itself.
Atomic IBC is optional- users decide at runtime whether they want a given transaction to be atomic or not. This will be useful for many things such as arbitrage and flash loans, and works right away with existing applications that support IBC. Atomic IBC combines the scalability of a multichain system with on-demand atomic composability, giving users the best of both worlds.
It’s likely that Atomic IBC will be finished before the inevitable cross-chain shared security marketplace as envisioned above has fully emerged from separate efforts such as Mesh Security and Eigenlayer. During this time, consumer chains will be secured by the substantial security of the Cosmos Hub.
As the shared security marketplace becomes more interlinked, the Cosmos Hub will be able to begin consuming security. It will have access to the security of assets staked across many proof of stake chains, which is currently in the hundreds of billions of dollars. The Hub, of course, will be able to sell security from its staked Atoms as well.
At this point, any blockchain application will have access to the same potential PoS security as any other application. In this world, the market value of a blockchain’s own staking token will not be as important, and there will be a distinct competitive advantage for applications that are able to interoperate atomically with other high quality applications.
Atomic IBC use cases
Atomic IBC has the potential to greatly improve the user experience and developer experience on interchain transactions in the AEZ. Atomic IBC should be able to reduce the running time of complicated interchain workflows from minutes to seconds, and reduce the amount of code needed to handle them by up to 90%.
However, regular IBC will always be critical for bridging between ICS and standalone chains, and between ecosystems. Atomic IBC just makes it so that interactions between chains in the AEZ are faster, smoother, and much easier to build.
Let’s look at an example.
Timewave stATOM-ATOM LP automation
A common application type on atomic composability platforms is the orchestration contract. This type of application composes several other DeFi applications to automate an outcome for end users. A good example is Yearn on Ethereum. This application automates complicated DeFi market making positions to generate a return for users, without those users having to do the operations themselves.
This is also possible asynchronously over IBC, but it can be complicated. Every step of the process which involves an IBC connection can potentially fail or time out, and due to the time that the sequence of steps takes, state on the chain might have changed. Timewave is a project building this type of DeFi automation platform in Cosmos. Let’s look at one of their products, which takes ATOM as an input, liquid stakes it to get stATOM, and then enters an stATOM-ATOM LP position on Astroport.
Steps:
Create interchain account on Hub
Send Atom to interchain account
Create interchain account on Stride
Send half of the Atom to Stride interchain account and convert to stATOM
Send stATOM to Timewave contract
Send remaining Atom to Timewave contract
Timewave contract enters LP position stATOM-ATOM, sending LP tokens to user
This is a relatively straightforward sequence of steps, but dealing with the asynchronous nature of IBC makes it more complicated than it appears here. 5 IBC packets are sent in this sequence and each one introduces some latency and a potential timeout. Every time that there is a timeout or other type of failure, the system needs to be able to recover and do the right sequence of steps to get back to a good state, otherwise the user will be left halfway through the process not knowing where their coins are.
With Atomic IBC, this can be much simpler. It’s still the same sequence of steps as above, but without any code to deal with timeouts or failures. Either the whole sequence completes successfully, or nothing happens. It’s estimated that the amount of code in this contract could be reduced by 90% with Atomic IBC. Also, due to the latency introduced by the IBC packets, this contract currently takes 2-3 minutes to complete. With Atomic IBC, this time goes down to 1 block, or around 6 seconds.
This is a big developer experience improvement, and developer experience often has a big effect on user experience. While in theory it is possible for developers to deal with all failure modes and edge cases in an asynchronous application, in practice they miss some, and some number of users will be left needing to clean up a half-completed operation. Each IBC packet send incurs at least a block’s worth of latency, and often more. With Atomic IBC, the entire operation either succeeds or fails, and it happens in one block.
Technical implementation
Replicated Security currently allows consumer chains to share the Cosmos Hub’s security by sharing the Hub’s validator set. This overlap in the validator set is what makes Atomic IBC possible. There are several ways to take advantage of this overlap. Note: Not all Replicated Security consumer chains will need to use Atomic IBC.
Megablocks
Megablocks has participating consumer chains share a mempool and blocks, while maintaining separate state machines. Consumer chains participating in Atomic IBC basically run on one chain. Even though the blocks are shared, transactions of each consumer chain are run in parallel in their own lanes unless they are part of an atomic IBC bundle. This model is comparable to a DA layer plus shared sequencer in one platform.
This enables IBC to be used in an atomic, isolated, and effectively synchronous mode. This enables deterministic arbitrage, flash loans, rebalancing, and other interactions which are normally only possible across applications on a single chain.
While transactions of each chain run in parallel for scalability, users can choose that any transaction or bundle of transactions be executed sequentially using Atomic IBC.
Transactions in an Atomic IBC bundle are executed sequentially, at the beginning of each block, even if the bundle includes transactions on many different consumer chains.
IBC messages in an atomic bundle are “relayed” instantly between chains without the need to generate and verify a light client proof (taking advantage of the fact that the consumer chains share a validator set).
Messages can be sent back and forth between consumer chains multiple times in an atomic bundle.
During the time that the atomic bundle is being executed no other state changes on any of the involved chains.
Given a particular state at the start of the atomic bundle’s execution, the outcome across all involved chains is deterministic.
If any transaction in the atomic bundle fails, the whole bundle is rolled back.
Once all atomic bundles have been executed, the rest of the blocks of each consumer chain are executed in parallel.
Other technical attributes
Reduction of Replicated Security costs
Atomic IBC uses a single Comet process for all participating consumer chains, while sharding most execution. This is analogous to DA layers like Ethereum or Celestia, which use a single consensus process to store data for a large number of rollups. When comparing this model to Replicated Security, ongoing per-chain costs are greatly reduced, since adding a consumer chain does not require running another Comet node. Costs for running consumer chains with Atomic IBC scale smoothly with their transaction volume and storage use.
Single MEV marketplace
Atomic IBC functions by processing blocks from all participating consumer chains and atomic bundles in one cadence, and each block has one proposer. This provides a simple and powerful interface for services selling prioritized access to block space, aka MEV. A proposer can sell priority access to blocks across all participating consumer chains, and atomic bundles across the tops of the blocks at once. And since proposers are chosen by amount of staked ATOM, MEV value ultimately accrues back to ATOM.
Atomic IBC compared to shared sequencers and cross chain MEV platforms
Atomic IBC has goals similar to shared sequencers and cross chain MEV platforms such as SUAVE. All of these platforms aim to facilitate atomic composability between separate state machines. Most shared sequencers and cross chain MEV platforms offer the following atomicity guarantees:
Atomic inclusion: Given two transactions, if one gets into a block on one chain, the other will get into a block at the same time on another chain. This is pretty limited, but things like arbitrage and other types of MEV can be built with it. More sophisticated things like flash loans can get quite complicated. While atomic inclusion can be a great starting point to build valuable MEV-harvesting features, it is far from full atomic composability and doesn’t do a lot for user or developer experience. Atomic IBC, meanwhile, provides full atomic composability. These are the same properties offered by monolithic smart contract platforms, but Atomic IBC does it with more scalability and customizability than most smart contract platforms do. This does not mean that shared sequencers and MEV platforms are a bad idea, it’s simply that they make different tradeoffs. In addition to atomic inclusion, here are the guarantees offered by Atomic IBC:
Isolation: No state anywhere in the system will change from the beginning of an atomic bundle to the end, other than changes made by transactions in the bundle. This means that, for example, an arbitrage bundle could make several interchain queries for prices at the beginning of the bundle, and have those prices remain completely accurate over the course of the bundle’s execution. In the Timewave example above, this property allows the contract to know exactly how much ATOM to convert to stATOM to get a 50-50 LP position.
Atomic execution: If one transaction in an atomic bundle returns an error, every transaction executed as part of the bundle will be rolled back. Any errors in the bundle make it so that it is as if the bundle never happened. In the Timewave example above, this property means that there doesn’t need to be any error recovery code, greatly reducing the amount of code required.
Multi step and cyclical sequences: The atomic inclusion property offered by shared sequencers and MEV platforms can guarantee at most that a send on one chain and corresponding receive on another chain are both processed. An atomic bundle can contain longer sequences of transactions across multiple chains, and even allow chains to send transactions back and forth (cyclically) between them. In the Timewave example above, this property makes it possible to easily program as many steps as are needed to complete the goal.
Dynamic transaction generation: Atomic IBC allows new transactions to be generated during the execution of a bundle, without the programmer needing to supply every transaction which will be in a bundle.
These are the same properties provided by monolithic smart contract platforms (for example, calls between contracts on Ethereum). This means that programming skills honed on smart contract platforms can easily be applied in the AEZ. Regular IBC as it exists today will always be very useful for communication between different ecosystems, and between the AEZ and chains outside of it, but Atomic IBC will provide a faster, simpler, and easier form of composability between chains in the AEZ.