[EPIC] 08-wasm Ethereum Light Client

[gjermundgaraba]

Objective

This epic aims to get a working Ethereum Light Client that can be deployed to a chain running ibc-go, to enable IBC (Eureka) from Ethereum to Cosmos SDK-based chains.

Context

We need a production-ready and stable Ethereum light client that can be deployed to Cosmos SDK-based chains for the IBC Eureka launch. Up until now, we've relied on Union's light client, but as they are moving to a full self-built IBC implementation in CosmWasm (and there have been a lot of changes to that code), their code is likely not going to be compatible with 08-wasm.

To let us have an Ethereum Light Client we can depend upon for this launch, we have decided to fork/extract the code we need to develop and maintain an 08-wasm Ethereum Light Client ourselves.

Requirements and Acceptance Criteria

High level, we need a fully functional Ethereum light client that does all the things a light client needs to do, in order to have a fully functional IBC connection (given that a light client exists on the other side as well, of course).

The light client shall:

• Have 80-90% unit test coverage of core light client logic
  • Update client, verify membership (inclusion and non-inclusion), submit misbehavior, client recovery
• Have happy path e2e test coverage of all messages
• Have a CI pipeline for building and testing (unit and e2e)
• Replace the current wasm file we use in the e2e tests
• Integrate with the dependency structure in solidity-ibc-eureka to keep maintenance simple

Considerations

Priority considerations:

• Given that we have a working light client we use and test in the Solidity IBC Eureka repo, we should be able to copy and restructure that code without having to write much code ourselves. The branch that contains the current light client we use can be found here: https://github.com/gjermundgaraba/union/tree/gjermund/eth-light-client-for-eureka
  • One exception might be unit testing, if there are areas that are not well tested at the moment (or have broken tests because of our own modifications).
• Since the Union codebase already includes light clients for other EVM chains (and more), we should try to keep our abstractions and structure set up in such a way that this could be added in the future without too much refactoring.

Good if possible (and practical):

• There might be chains who would want to run this light client as a ZK light client. To enable that without too much problem, we should try to keep CosmWasm specific code separate from the core light client logic itself. We can discuss how to achieve this, but it should be possible to either create some light abstractions, or even just a simple layered approach where the CosmWasm contract only deals with CosmWasm specific handling of messages and storage, and the light client layer is unaware of any CosmWasm types.
• If we can find a way to get rid of the custom querier requirement that is currently present, it would be great!
• If we can find a good and reasonable way to remove the static compilation of network configurations, that would be a bonus as well
• Fully implement all the messages in the 08-wasm light client interface

Alternatives considered

This section is added mostly for general context and background.

We had 3 options for this light client (after using Union's directly was off the table):

• Build one in Go as a native light client module
  • Why not: It would require a lot of effort to write this from scratch, and given that less intense options are available, the cost/benefit ratio was not ideal.
• Fork and build a ZK light client that is wrapped with SP1 and only run proof verification in a native light client module
  • While this option was both viable and cost-effective, it would impose a dependency on SP1 and it would be more costly (in terms of infrastructure and prover network usage), as well as somewhat slower (because of the proving time).
• For and build an 08-wasm from the current working light client we have from Union (the option chosen)
  • This main drawback of this option is that it requires chains to have CosmWasm in some form. But it would still be more than possible for someone to write an ZK version of the light client (given that we can structure it well enough) by wrapping the relevant code in a ZKVM like SP1 or RISC0.

Open questions

• Do we need to have client upgrade (not sure of the current state in Union's code)?