An open, modular stack for EVM-based applications using Celestia, Evmos, and Cosmos

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.

20 Likes

I’m glad to see settlement rollups!

Reposting from the other thread: I’d like to see the Evmos settlement rollup be validity proven, enabling something like the Mina <> Ethereum bridge. (The delays with fraud proofs makes this harder to accomplish.) That said, I think it’s pragmatic to just post proofs to Ethereum directly, commit data to Celestia, and skip the Evmos settlement rollup entirely. A settlement layer is only as good as its liquidity, security, and network effects, and for rollups at scale the costs are so negligible (a 1,000 TPS ZKR only spends $0.00003 per transaction in gas fees to Ethereum) that the optimizations are much lower priority. Of course, Ethereum has its optimizations in the roadmap too - statelessness, separation of DA with data sharding & DAS will address most of the above concerns, but they will take time. Settlement rollups still make sense for ORs, low value, low activity rollups, and the hope is over the years/decades they can build network effects and liquidity to attract higher value rollups as well.

I’d also argue having a programmable settlement layer is valuable, as it enables exciting usecases like dAMM and DeFi Pooling. So, IMO, restricting functionality is not an ideal solution.

Related, essentially StarkNet L2 becomes a settlement layer for rollups further up the ladder! Fractal Scaling: From L2 to L3. It’s layers all the way down | by StarkWare | StarkWare | Dec, 2021 | Medium

5 Likes

I don’t think the L1 settlement rollup being restricted should prevent any use cases, for the same reason that StarkNet can have L3 rollup.

You can deploy an unrestricted L2 settlement rollup on the restricted L1 settlement rollup, which can be used for dAMM and DeFi Pooling by L3 rollups. This is particularly relevant to the “monorollup” I proposed in the post above.

Given a restricted L1 rollup that lets you deploy an unrestricted L2 rollup on it, it should be the same functionality as having an unrestricted L1 rollup.

2 Likes

Interesting that you mention this could be used for Mina <> Ethereum bridge. I wonder how you would compare this to nil foundations zk circuit based bridge - https://minaprotocol.com/announcements/ethereum-foundation-and-mina-foundation-award-a-1-2m-contract-to-nilfoundation-to-implement-minas-privacy-preserving-zk-snarks-on-ethereum. This bridge is currently uni-directional mina → eth. However, I would suppose a similar construct of verifying EVM blocks inside of a zk circuit could be used for the eth → mina bridge. These bridge would be trustless. Quite interested to hear your thoughts on this as I’m currently exploring the development of a mina based ZK rollup application that uses celestia for DA.

3 Likes