# ETH Light client on IC

## Motivation

Ethereum Bridges like [Terabethia](https://terabethia.xyz/) or [Omnic](https://rocklabs.io/#) need EVM state or event information in their canisters. HTTPS Outcalls allow to fetch this information from JSON RPC providers like Alchemy or Infura. However, these API providers are single point of failures and can lie to canisters on the IC. An Etherum light client on the IC could be used to verify merkle proofs for state or log information retrieved from these RPC endpoints.

## Overview

A Light client keeps track of block headers as well as the current sync committee to allow verification of arbitray EVM state or inclusion of events via merkle proofs. The sync committee is a group of 512 validators that get randomly assigned every approx. 27 hours that sign block headers via aggregatable BLS signatures. Hence, a light client needs to do the following:

- Keep track of the current sync committee and their 512 public keys. At least this needs to be done against multiple RPC API providers using incentivized relayers. If we trust a single API provider we haven't gained anything.
- Keep track of block headers (optional?). Maybe this is even not required, as we could fetch the block header only if a merkle proof requested by a client canister

## How can some state be verified?

### Canister implementation

#### Interface to other canisters

##### verify_proof(merkle_proof): Bool

Accepts a merkle proof pointing to a block header, verifies the proof by
- Calculating the hashes
- Fetching the block header incl. a signature of the sync committee
- Verifying the aggregates BLS signature

### State

- The light client canister would store a configurable history of sync committees to allow the verification of merkle proofs up to a specific point in the past
- Furthermore, the canister should keep a configurable cache of block headers

## Existing implementions

- [Polkadot Bridge implementing a Light client in Rust](https://github.com/Snowfork/snowbridge)
- [Light client implementation in TypeScript](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client)
- [Lighthouse Consensus client in Rust](https://github.com/sigp/lighthouse)
- [Python implementation](https://github.com/EchoAlice/python-light-client/tree/light-client)
- [Rust Implementation: Helios](https://github.com/a16z/helios) / [Blog Post](https://a16zcrypto.com/building-helios-ethereum-light-client/)
- [Kevlar](https://github.com/lightclients/kevlar)
- Does also support Optimistic sync based on the construction of [Proofs of Proof-of-Stacke with Sublinear Construction](https://arxiv.org/abs/2209.08673)

## Discussion Channels

- [Light-clients channel in ETH R&D Discord](https://discord.com/channels/595666850260713488/595701319793377299)

## Resources

- [Light Clients after the Merge Presentation (DevCon6)](https://m.youtube.com/watch?v=ZHNrAXf3RDE)
- [Annotated Spec on Light Client Protocol](https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md#introduction)
- [OpenAPI spec of ETH beacon node](https://ethereum.github.io/beacon-APIs/#/Beacon)
- [Ethereum beacon chain light client specification for IBC](https://research.polytope.technology/ics-15:-ethereum-beacon-chain-light-client-specification-for-ibc)