Informal Systems has begun work to build the Interchain Scheduler, in collaboration with a wide group of partners, including Sam Hart, Iqlusion, Skip, Mekatek, Fairblocks, Strangelove, and others. A preliminary specification will be done in January 2023 and shared with the Cosmos community. This post will give readers a look at the design challenges we are tackling and how we are approaching them.
The Scheduler is a system with two main goals:
To facilitate synchronization of transactions across Cosmos chains. Ideally, we will be able to achieve cross-chain multipart transactions that are synchronous (each part of the transaction happens at the same time), and atomic (the transaction fails or succeeds as one piece).
To enable capture of Maximal Extractable Value (MEV) revenue by participating blockchains. Currently, MEV services operate by making payments directly to validators. With the Scheduler, they will reserve block space on participating blockchains at an auction. The payment for this block space will flow through to the blockchain’s protocol, e.g. the stakers, the LPs, the community pool, etc.
To enable these goals, the Scheduler has two main parts:
An auction that enables bidding on future block space on participating blockchains. Most likely this will take the form of time slot reservations across several chains, for example the right to propose blocks across several DEX blockchains at a given common time slot, the set of chains and slot length being governed by the scheduler. To avoid censorship and centralization concerns, participating blockchains will not auction all of their blockspace, but allow some blockspace to be filled “normally”. This auction will be run on chain secured by the Cosmos Hub using Interchain Security. A block allocation design allowing participating chains to honor the terms of the auction. This extension must enable the auction winner to get their chosen transactions into the blocks in question, without introducing any performance, censorship, security concerns, or a single point of failure into the participating blockchains.
Below, we explore how we are approaching the design of the Interchain Scheduler, bearing in mind the different properties of the system.
Note: We assume all actors are RATIONAL. They are incentivized by maximizing their economic and social status, i.e., increasing profits and improving reputation.
Delegate tokens to validators (they have stake in the game).
Receive block rewards.
Operate validator nodes (w/ sentries and so on).
Form the active validator set.
Vote on proposed blocks; this entails validating the blocks, but it’s not enforceable (rational behavior).
MAY reject valid blocks.
Receive block rewards.
MAY operate validator nodes.
Propose blocks.The creation of blocks doesn’t have to follow specific rules; proposers can propose whatever they want.
[Tendermint] Require ⅔+ of voting power to get proposed blocks committed.
[Tendermint] Have limited time to get blocks committed.
[Tendermint] Are chosen from the active validator set based on a (deterministic) round-robin approach.
MAY receive extra block rewards.
Are not required to operate validator nodes.
Create profitable candidate blocks (MEV).
Their rewards are out of the scope of this specification.
Search for interesting transactions and create bundles that optimize MEV.
Generate transactions.
The Interchain Scheduler is focusing on the interaction between builders and both proposers and validators. The other interactions, including those between searchers and builders, are out of the scope of this specification.
In a nutshell, builders want to be able to execute their blocks (or contiguous set of transactions, not necessarily an entire block) on particular blockchains at particular times. For now, we assume that the builders execute entire blocks.
The Interchain Scheduler should enable builders to execute a set of blocks on a set of chains at specific times.
System properties are an important tool in protocol design. By deciding what we are working towards, and defining it in rigorous terms, we can evaluate possible designs quickly.
Liveness: No actor (with under ⅓+ voting power) should be able to stop the progress of a participating blockchain.
Censorship resistance: No actor (with under ⅓+ voting power) should be able to stop the auction winner from having their valid blocks published or bids from being submitted to the blockchain in question.
Bundle unstealabilty: Let t1 be the time an auction winner propagates its transactions to proposers and t2 be the time these transactions are being decided. Then, it must not be possible for any actor, except for the auction winner, to use any of these transactions before t2.
Latency: The builder should be able to decide which transactions to include in an auctioned block after the previous block is published.
Value capture: The auction must be able to capture most of the MEV value of the auctioned block. By “most” here we mean that the MEV market should push the limit of the captured MEV value to maximum. The auction market must be competitive!
Cartel-creation resistance: The protocol must not incentivize / must punish the creation of cartels among the active validator set.
Quasi-synchronous atomic cross-chain execution (QSACCE): It must be possible to execute atomic transactions across multiple chains at approximately the same time.
Monopoly protection: It must not be possible for a single actor to acquire all the auctioned block space.
In general, the resulting system should be a more attractive alternative to the current state of the art, i.e., off-chain MEV relays.
The auction facilitates MEV revenue capture for participating blockchains. By requiring builders to compete in the auction, the auction shares MEV with the blockchain (at least for the portion of blocks that are auctioned).
The auction facilitates cross-chain synchronization by allowing block space to be reserved simultaneously across several blockchains. The builder reserving this block space can then create synchronous and atomic cross-chain transactions.
The auction is mostly concerned with these system properties:
Value capture
Quasi-synchronous atomic cross-chain execution
Monopoly protection
We are considering a number of different questions to accomplish these goals:
How rigid or flexible should the slots of blockspace be? For example, we could allow auctions to be created for slots across any number of the participating chains, for any length of time. We could also require that all slots be 15 seconds long, and be across all participating chains. The benefit of the former is flexibility- builders can bid on whatever they want. The benefit of the latter is simplicity, it seems like a very hard problem to manage auctions for slots of many different shapes and durations that cannot overlap. However, the simple design probably also misses out on value capture for the auction, and thus the participating chains.
Based on auction theory and using our expertise in that field, we are researching to find a suitable auction design/mechanism that meets the above properties. Another important property is blockchain compatibility. The auction needs to run on a blockchain, and blockchains introduce mechanism design constraints. For example, it is challenging to identify unique participants, and true randomness is hard to come by.
How can the auction be synergistic with other parts of the design? For example, there may be some issues in the block allocation design where a block’s proposer is incentivized to “steal” the MEV in a builder’s block. Maybe the auction can do something to balance incentives there.
On each participating blockchain, the block allocation design must allow the winner of the auction to control the ordering and inclusion of transactions in the block space it has won.
The block allocation design is mostly concerned these system properties:
Liveness
Censorship resistance
Quasi-synchronous atomic cross-chain execution
Cartel-creation resistance
Bundle unstealability
Latency
Latency is very important. MEV services currently allow searchers to submit bundles at the very last millisecond, reflecting their latest understanding of the state of the blockchain. We cannot create a system that is slower than what already exists.
Liveness and bundle unstealability have been tricky to balance. Liveness requires the system to get the information that is intended for the next block (e.g. transaction bundles). Exposing that information can also allow someone to steal it.
Cartel-creation resistance: The ⅓+ assumption is necessary to satisfy some of the properties above (liveness and censorship resistance) – ⅓+ of validators would need to collude to violate these properties. However, if there is enough of an economic reward to violating one of these properties, it may incentivize creation of a ⅓+ cartel.
The biggest potential of MEV in Cosmos is in operations which are executed almost simultaneously on several chains. A good example of this would be an arbitrage which takes place across 3 different DEXes. Quasi-synchronous atomic cross-chain execution is a property which addresses this use case.
Do you have expertise in MEV, in the Cosmos space, Ethereum, or beyond? Do you run a searcher, or a builder? Are you active in the community of a chain that might benefit from participating in the Interchain Scheduler? We think that the Scheduler will benefit all players in the ecosystem, and we want to talk to you about how your role can fit into and evolve in a post-Scheduler world. Reach out to us at thyborg@informal.systems!