Try   HackMD

RFP-5 Canister-based Ethereum Light Client

Overview

The work on the Bitcoin integration already does some heavy lifting for integrating other chains with the Internet Computer. Most notably, chain-key signing allows canisters on the Internet Computer to sign transactions targeting platforms that support ECDSA, and HTTPS outcalls allow to submit them without incentivizing 3rd party relayers. However, the approach to access Bitcoin state relies on a custom implementation in the Internet Computer replica software, and is as such not a scalable approach for the integration of other chains.

One general pattern to allow accessing the state of other chains is to maintain a list of RPC provider services for a given chain and use HTTPS outcalls to interact with a random sample. Depending on the selection of the services and the size of the sample, there can be a high assurance of the valididty of the data if all services in the sample agree.

However, with the recent development of the proof-of-stake beacon chain and the merge, there has been significant progress in the development of Ethereum light clients which allows an integration without having to trust the RPC providers. These light clients enable the verification of state and inclusion of events through the use of merkle proofs and the reliance on sync committees - a slowly changing (approx. 25h), random sample of 512 validators - to obtain block headers with BLS signatues, rather than requiring the validation of the entire blockchain.

Areas for RFPs

We'd like to encourage individuals and teams to explore the integration of Ethereum light clients as canisters on the Internet Computer to allow other canisters secure access to data from the Ethereum blockchain. The nascent Helios client, which is implemented in Rust, could provide a good starting point.

As a first step, we are looking for a design document and a proof-of-concept implementation that allows to assess the viability and allows further input from DFINITY and the community.

Main use cases

The main use cases that came up so far revolve around token ownership, balances and gas price estimation:

  1. Get ETH and ERC-20 token balances
  2. Get ownership of ERC-721 and ERC-1185 tokens
  3. Estimate current gas price for transaction automation

Considerations

  • There is room for exploration to either use HTTPS outcalls to do RPC calls to execution and beacon nodes or provide economic incentives (and slashing) to 3rd parties to provide the necessary information
  • Since this space is nascent, there's also the chance suggest new APIs to beacon and execution nodes that make it friendlier/cheaper for canister-based clients. Currently in order to do the equivalence of an eth_call, you need a number of calls (eth_getCode, eth_createAccessList, and multiple eth_getProof) and a local EVM simulation. These are a lot of HTTPS outcalls, which might be prohibivly exensive on the IC for certain use cases. However, there is a chance on integrating new JSON RPC methods to the execution API like eth_getReceiptProof and eth_getCallProofs to streamline this. Ideally, you would support driving these changes.

How to apply?

Please submit your application at https://dfinity.org/grants mentioning RFP-5. There you'll also find more details about the DFINITY Developer Grants program.

Resources