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 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 Proposals
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:
Get ETH and ERC-20 token balances
Get ownership of ERC-721 and ERC-1185 tokens
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 https://dfinity.org/grants mentioning RFP-5. There you'll also find more details about the DFINITY Developer Grants program.
If you have questions, please post to the following thread on the Developer Forum or the grants channel in the Developer Discord.
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 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 Proposals
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:
Considerations
eth_call, you need a number of calls (eth_getCode,eth_createAccessList, and multipleeth_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 likeeth_getReceiptProofandeth_getCallProofsto 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.
If you have questions, please post to the following thread on the Developer Forum or the grants channel in the Developer Discord.
Resources
Related to the Internet Computer
Related to Ethereum light clients