Thanks to Matthew Di Ferrante for the original idea, and John Adler and Federico Kunze Küllmer for comments on this post.
In this post, we will discuss what an optimal settlement layer for EVM rollups can look like, and how it can be built using Celestia, Evmos, and Cosmos as a part of a modular stack for EVM-based applications.
What do we mean by settlement layer? A settlement layer for rollups is a chain that rollups have a trust-minimized two-way bridge with, using a dispute resolution contract on the settlement layer. This allows tokens to be transferred between rollups and the settlement layer, or between rollups through the settlement layer, in a trust-minimized way.
Currently, rollups use the Ethereum main chain for settlement. However, the Ethereum chain is not an ideal settlement layer for rollups, because it is shared with non-rollup applications that use the chain directly for smart contract transactions. The Ethereum chain is therefore unspecialized and has reduced scale compared to a specialized settlement layer.
As explained in Matt’s post, an ideal specialized settlement layer for rollups would be restricted such that it would only allow for (a) rollup smart contracts, and (b) simple transfers between rollups, and would therefore forbid (or make it prohibitively expensive) for non-rollup applications to use the settlement layer.
This is in contrast to the geth team’s view, where their goal is that the Ethereum chain is for both non-rollup and rollup-based applications:
Specifically, we fear that EIP-4488 will, due to the 2-dimensional nature of the scheme, favor rollup transactions so much that it won’t be possible for non-rollups to use the blockchain. The EIP should present significantly more evidence that this will not be the case.
Architecture
We propose deploying an Evmos-based chain (a Cosmos SDK chain with the EVM built in) that is implemented as a Celestia rollup, by using Optimint instead of Tendermint. Optimint is a drop-in replacement for Tendermint BFT, that enables developers to deploy new chains that use an existing consensus and data availability layer such as Celestia, therefore making the new chain a rollup.
We call this the “settlement rollup”. As the settlement rollup is a restricted EVM environment, we envision that the state would be fraud provable with single-round fraud proofs.
Rollups can then be deployed on top of the Evmos settlement rollup, as a recursive rollup (a rollup within a rollup). Each rollup would have an enshrined two-way trust-minimized bridge with the settlement rollup, similar to Ethereum rollups. The goal is that it would be possible to re-deploy the same rollup contracts and software that exist on Ethereum today, so minimal work would be needed to port the rollups. This means that the rollups use calldata on the settlement rollup, and the settlement rollup batches the data using Optimint and posts it to Celestia.
The settlement rollup would need a censorship-resistant block production leader selection mechanism, as there is no “upper” execution environment to build an escape hatch to. This is currently being actively researched by several Ethereum rollup teams that seek to decentralize block production. This is necessary primarily for DoS resistance to prevent anyone from creating blocks that fraud proofs will need to be distributed for, at no cost.
Monorollup
One of the rollups that use this settlement layer could be a general-purpose EVM “monorollup” similar to Arbitrum One, that enables users to deploy any Ethereum smart contract. This will allow developers to enter the ecosystem with little friction, but giving them a Polygon-like developer experience where they can redeploy existing contracts with ease. They can then shard (i.e. redeploy) their contract onto their own application-specific rollups with a trust-minimized bridge, if the monorollup gets congested.
Intercluster bridging
If a rollup within the Celestia/Evmos/Cosmos stack wants to communicate with another non-rollup chain (such as in the IBC network), or a rollup that uses a different settlement layer (i.e. intercluster communication), a committee-based bridge would be needed, as a trust-minimized bridge wouldn’t be possible. However, the settlement rollup would ideally not have a validator set or committee. To solve this, we propose a decoupling of the committee-based bridge operator and block producer of the settlement rollup.
A third party chain would operate a committee-based bridge. If the EVM of settlement rollup may be too restricted for bridge contracts that e.g. verify a large committee multisig or threshold sig, the bridge could be with a rollup on the settlement rollup - rather than the settlement rollup itself.
This can be achieved in one of two ways, or both:
- A Cosmos zone acts as a “intercluster rollup hub”, in which the validators of the zone operate the bridge by following the state of the settlement rollup, and allowing assets on the settlement rollup to be transferred to the zone via a multisig or threshold sig contract on the settlement rollup, possibly using gravity bridge. The Evmos main chain could fit this role. (See diagram above.)
- Rely on an existing “interchain communication as a service”, such as Axelar or Polymer, to do the above.
Bonus: depending on the fraud proving mechanism of the settlement rollup, it may also be possible to allow a settlement rollup to Ethereum bridge contract on Ethereum to verify settlement rollup fraud proofs, for additional security, though it wouldn’t be as trust-minimized as an Ethereum rollup as the data availability of the settlement rollup is off-chain to Ethereum.