Explore different Cosmos-native execution environments

[liamsi]

Motivation

We want optimistic rollups to be able to connect each other without requiring any governance. The caveat is that they need to dynamically be able to validate state transition fraud proofs of other chains (as they connect to them).

Options

The most interesting options are:

• CosmWasm (IBC-enabled smart-contracts): https://docs.cosmwasm.com/0.13/architecture/multichain.html and
• Agoric's stack (VM + dIBC): vision: https://medium.com/agoric/the-road-to-dynamic-ibc-4a43bc964bca, docs: https://agoric.com/documentation/platform/ , and "networking": https://github.com/Agoric/agoric-sdk/blob/master/packages/SwingSet/docs/networking.md

BTW by "Cosmos-native" I mean execution environments that are either built as a Cosmos-SDK module or more directly interact with tendermint via ABCI.

[evan-forbes]

I've been digging into cosmwasm, and while state transition logic for a rollup could definitely be written using cosmwasm smart contracts, it's important to note that, imho, it is extremely unlikely that we will be able to write the logic once in a cosmos-sdk based chain/rollup and then compile that logic to cosmwasm. The main reasons being

1. Go wasm support is limited

• per wiki, we can compile normal Go code to wasm, but AFAICT that wasm is only meant to be used inside javascript. For example, we can't compile Go code to be used with wasmer, which is what would be needed to go from Go code to cosmwasm.
• there's a really cool experiment getting cosmwasm smart contracts written in tiny-go, which it looks like might end up getting support after the 1.0 release of cosmwasm. Support for tiny-go is really cool, but making a tiny-go version of the sdk is... not an option.

2. The sdk was not designed around compiling down to wasm

• The state transition logic is wrapped in modules, keepers, antehandlers, etc. isolating this logic to be compiled to wasm is definitely doable, but not entirely straightforward

Off the top of my head, solutions include

1. Write some tooling to help devs go from cosmos-sdk logic <-> cosmwasm smart contract logic reliably
2. make a wasmd like wrapper that only runs the rollup logic written in cosmwasm contracts

[zmanian]

This kind of "hot load a wasm state machine to verify "a fraud proof was a target use case of Substrate/Polkadot but afaik none of this system for susbtrate has been implemented yet.

It's plausible that some kind of other virtualization framework other than Wasm would work but we also need have hooks into cosmos binaries process a single step state transition.

[liamsi]

It was essentially decided to focus on EVM-based exec envs. Arbitrum seems particularly interesting as it comes with a fraud proof mechanism (IVGs more precisely). That decision has not really be documented anywhere yet (cc @mattdf @adlerjohn @musalbas).

I'll keep this issue open to be revisted post-mainnnet.

[Manav-Aggarwal]

All Cosmos-native execution environments are supported in pessimistic mode. Closing this issue since Cosmos SDK is exploring the direction of going to ZK directly.