What should be the (default) ABCI server ontop of optimint?

[liamsi]

Summary

The current direction we are taking is to use optimint as a drop-in replacement for tendermint to be used with the Cosmos-SDK (modules). @musalbas brought up that some (most?) of the existing SDK modules will not be too relevant for Rollups. e.g. Rollups could use a much simpler staking logic (for leader selection #18). That raises the question of what exactly ABCI server on top of optimint should be?

I've opened this discussion to discuss and understand requirements, edge-cases (e.g. upgradability), and trade-offs of different solutions.

Cosmos-SDK & Modules

Most developers in the Cosmos ecosystem use this approach. They choose from a set of modules from the Cosmos-SDK (written in go) that implement some components they usually want to use in their state machine or application anyways. These modules are parametrizable and some are extendable in the sense that app devs can add or modify the default behavior.

While the modules approach gives a great developer experience it makes connecting rollups via IBC require ways to execute each other's state machines - more complex & difficult if there is no VM.
@zmanian already brought this up in the original rollups@SDK issue here: celestiaorg/celestia-core#62 (comment)

The modules that are likely interesting and could be used without any modifications for Rollups are imo:

• auth
• bank

I also think that the following modules can be used without many changes:

• gov (IMO governance is interesting in a non-consensus setting as Rollups might want to vote on upgrades)
• upgrade
• evidence (but we'd need to plugin other evidence types)
• mint
• crisis

It might also be worth considering modified versions of the following modules:

• staking (ref: Define Leader Selection for Cosmos-SDK based Rollup chain #18)
• slashing

Alternatives to the SDK & modules

Alternatives could be:

• only define core components ("core auth stuff that involves crypto signing and curves" as @musalbas said) and more directly interact with optimint (the abci-client) via abci instead of providing larger parts of state-machines as modules
• define "modules" as in the Cosmos-SDK case but in another VM environment (e.g. wasm)

I've captured some of the ideas discussed on various below:

Fully define default state machine logic in wasm, e.g. via

• https://github.com/datachainlab/hypermint (brought up by @marbar3778)
• https://github.com/datachainlab/hmemu

Define core default components of the state machine (like bank, auth, staking etc) in CosmWasm (re #35):
copy&pasta from some convos that happened outside of github regarding the above:

remove the sdk and have cosmwasm interact with abci
But the important thing is to maintain IBC support

Regarding the required IBC compatibility, it is worth noting that "IBC compatibility" doesn't have much to do with abci, or, the Cosmos-SDK directly. The way IBC is defined is that any (fast finality) chain / state-machine can use IBC.

There is also this idea that only:

core auth stuff that involves crypto signing and curves, should be part of the [default environment]

as opposed to defining sub-portions of the state machine in modules (as the SDK currently does). This would be more like in ethereum where there are different opcodes for different functions instead of different Txs routed to different modules to be handled (as in the Cosmos-SDK).
I personally feel like (and agree with @marbar3778 on this) that we should provide all that default logic somehow (like in the SDK) because while it seems easy to define some portions of the state machine, it is not easy to implement these correctly. Other teams with a lot of resources e.g. failed to correctly implement staking and governance logic in a timely fashion correctly. So ideally, you don't have to define these yourself (but it should be possible if desired).

Further References

• Explore different Cosmos-native execution environments #35 (comment)
• https://docs.celo.org/celo-codebase/protocol/optics

[liamsi]

We should also explore if in the case of SDK-modules in go, we can't use the go plugin system to load the other machines' state-machine: https://golang.org/pkg/plugin/