Completed: RFP-5: Canister-based Ethereum Light Client

Developers Bounties
1

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 accessing 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 validity 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 signatures, 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 assessing 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 the 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 to 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 prohibitively expensive 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 Developer Grants Program | DFINITY mentioning RFP-5. There you’ll also find more details about the DFINITY Developer Grants program.

Resources

Related to the Internet Computer

Related to Ethereum light clients

14 Likes
2

Actually we are working on it

6 Likes
3

I thought the IC BTC light client was in a regular canister now?

1 Like
4

I saw this and was about to ask the same thing.

5

There are two parts:

  1. The Bitcoin Adapter
  2. The Bitcoin Canister

The Bitcoin Adapter takes care of networking with the Bitcoin P2P network and does also the block validation (AFAIK). This part is implemented on the replica level.

6 Likes
6

Wouldn’t it be easier to just go ahead and expose the interface for accessing and verifying state variables in any contract? I don’t think there is much difference in validating (balance|address) on an ERC20 contract and symbol. This would give us access to verify all variables on the chain and not just standardized contracts(helper functions for those would be welcome though!).

1 Like
7

Yes, but as written in the considerations a general translation of eth_call might be costly if we rely on HTTPS outcalls and the currently available RPC endpoints.

My intention in stating the main use cases was that a potential implementation needs to ensure that at least these use cases are viable.

4 Likes
8

Wood integration using light client give the integration more Throughput?

9

Hi Dom, it would be nice to get recognition for suggesting this idea. As it stands, the InfinitySwap team applied for a grant for this and suggested the idea of using Helios, and we are yet to hear back from the Foundation.

10

Hey Max - I’m not aware of any grant application regarding this topic yet.

11

Not sure. In comparison to what?

12

I have forwarded the email we sent to Jan, outlining the proposal a few months ago. Alex also followed up with a grant application. We went as far as to have a locally running instance, but without support from the Foundation we had to hold back.

4 Likes
13

We are all in the same page, let’s collaborate

5 Likes
14

All of you are asking the right questions and seem to have the intricate knowledge to keep the train on the tracks. I hope all of you collaborate, I feel more secure with my investments into ICP knowing how proactive the community can be, though the Dfinity heads need to act faster to keep the right talent aboard with grants, not being too carefree with grants to opportunistic partners without doing proper due diligence.

1 Like
15

Any updates on this post?

16

Any updates on this ?

17

Very much needed good plan, is there any progress?

18

Eiger has finished the PoC of porting Helios to a canister smart contract on the IC. Read more here

5 Likes