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.
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.
The main use cases that came up so far revolve around token ownership, balances, and gas price estimation:
- Get ETH and ERC-20 token balances
- Get ownership of ERC-721 and ERC-1185 tokens
- Estimate the current gas price for transaction automation
- 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_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_getCallProofsto streamline this. Ideally, you would support driving these changes.
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.
- Internet Computer Overview: What is the Internet Computer?
- How the Internet Computer works
- Chain-key Signing/Threshold ECDSA
- HTTPS Outcalls
- Internet Computer Interface Specification
- Forum Thread related to Ethereum integration
- Rust Implementation: Helios / Blog Post / Telegram Channel
- Light Clients after the Merge Presentation (DevCon6)
- Annotated Spec on Light Client Protocol
- OpenAPI spec of ETH beacon node
- Light-clients channel in ETH R&D Discord
- Ethereum beacon chain light client specification for IBC