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:
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 Developer Grants Program | DFINITY mentioning RFP-5. There you’ll also find more details about the DFINITY Developer Grants program.
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.
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!).
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.
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.
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.
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.
The Omnity team has revived plans to implement an Ethereum light client on the Internet Computer and has completed the first vision of the ethereum-lightclient-canister. This canister, adapted from the Helios project, currently provides functionality to verify the available of transactions on Ethereum, with plans to expand data verification capabilities as needed.
Project repository: GitHub - octopus-network/ethereum-lightclient-canister
Additionally, the light client has been deployed to the Internet Computer, canister id is 2jzxy-6qaaa-aaaai-atfya-cai, and a command-line tool named ethereum-lightclient-tester is provided to demonstrate its features.
Project repository: GitHub - octopus-network/ethereum-lightclient-tester
Usage instructions can be found in the project’s README documentation.
Why did we develop the ethereum-lightclient-canister?
As our team specializes in cross-chain technologies, the light client enhances the security of cross-chain interactions between Ethereum and other chains on Omnity. We investigated the existing ethereum-canister project(GitHub - eigerco/ethereum-canister), but found it has been unmaintained for a long time, and its interfaces are incompatible with newer versions of the Ethereum RPC protocol. Adapting it would require significant development efforts, so we built a new preview version currently undergoing testing. We welcome interested developers to try it out, review the code, and share your feedback or suggestions.
