There’s another project that allows to login on the IC with an Ethereum wallet. Thanks to @domwoe for pointing this out!
2 Likes
Thanks for mentioning our project, and we shall find a better approach of interacting with other blockchain on IC.
1 Like
That sounds great, cannot await to see this demo!
It’s really cool to see interoperability things being worked on by the community!
2 Likes
How is this going now? Anybody can share us with some new information?
There’s been silence here on this topic for quite some time as we have been focussing on getting the integration with Bitcoin out of the door. We have started discussions on how an Ethereum integration should look like. We have two important building blocks already that can help facilitate an Ethereum integration:
- Threshold ECDSA: required for any reasonable form of secure Ethereum integration
- HTTPS outcalls: may be a building block for Ethereum integration, depending on the architecture.
For now, you can definitely use the threshold-ECDSA and HTTPS outcalls features to roll your own Ethereum integration based on Ethereum cloud nodes.
Discussion on Ethereum integration is to start here soon!
17 Likes
Any update for this one?
- Addressing the impedance mismatch between the asynchronous IC and synchronous EVM
3 Likes
Dear colleagues!
Following up on our discussions of last week’s ICP.Lab in Zurich, which some of you have attended, let me summarize the outcome of the sessions related to Ethereum integration.
We decided to go for a 2-Phase approach, to have tangible results within weeks, not months.
- Phase 1: Short-term integration based on HTTPS outcalls to Ethereum cloud nodes
- Low-effort for implementation
- Available within a few weeks
- Compromise w.r.t. trust model due to using cloud-based nodes
- Limited throughput
- Phase 2: Full Ethereum integration in the protocol stack
- Substantial effort due to integration with the IC protocol stack
- Will take 4+ months to design and implement
- Strong trust model due to not adding extra assumptions besides the IC and Ethereum trust assumptions
- Good throughput
Both Phases will build on the already-available chain-key ECDSA signatures, based on threshold ECDSA.
We have created a Discord channel for the discussions: Discord
Anyone interested in the subject is invited to join the discussion!
Let me tag the attendees from the ICP.Lab meeting whose user ids I could find:
@brutoshi, @simpson, @cryptoschindler, @Maxfinity, Michael, Bruce, Punk, Olliver, Paul, @zire, @lomesh, @benji, @domwoe, @TimHermann, @Manu
Discussions can be had here on the forum or in the Discord channel. The forum lends itself better for longer (technical) posts with dense content, Discord for the more interactive discussions.
Further details and materials from the ICP.Lab will be posted shortly.
18 Likes
These discussions may, among others, also be interesting for @lastmjs, @skilesare, @diegop, @Zane, @jzxchiang, @timo.
5 Likes
Here are the slides with some ideas regarding Phase 1:
Next steps:
- Refine and agree upon the design for Phase 1
- Put together the available code mentioned at the ICP.Lab
- Decide who will help in building this
11 Likes
Amazing! Glad to see Dfinity has made it a high priority.
For the ckEth tokens, do we need to wait for the full integration or can that be done with the intermediary solution?
4 Likes
The basic ideas here are fantastic. I especially like that there’s no immediate rush to deploy the integration canister or ck canisters under the NNS. Publishing the code and letting the community decide what to do with these is great.
7 Likes
As part of the Developer Grants program, we’ll provide a USD 5k bounty (paid in ICP) for the implementation of Phase 1.
7 Likes
Hi everyone, we are Rocklabs and have been exploring this direction for a while now, would love to provide some input here:
Project Omnic basically implemented Phase 1, which enables message passing between EVM chains and the Internet Computer, the pic below shows how it works:
There are 3 major components:
- On each EVM chain, there is a gateway contract, responsible for receiving crosschain message requests from application contracts, message hashes are inserted into a Merkle tree. On the other hand, gateway contract is responsible for receiving crosschain messages from other chains, and notify application contracts on the local chain about the message. Gateway contracts are controlled by the Omnic Proxy Canister on the IC via threshold ECDSA, only Proxy Canister can instruct gateway contracts to process crosschain messages.
- Offchain relayer fetches crosschain messages from EVM chains, and generate a Merkle proof for each message, then submit the message with merkle proof to the Omnic Proxy Canister. The relayer is completely permissionless, which means everyone can run a relayer, this is because the Proxy canister will verify every message so we don’t have to trust the realyer.
- Omnic Proxy Canister is the core, responsible for verifying and handling crosschain messages, the proxy canister controls several gateway canisters on the IC, each EVM chain has a dedicated gateway canister responsible for periodically fetching crosschain message merkle tree root via canister HTTP outcalls, the merkle root is then used for crosschain message verification.
If a crosschain message & proof submitted by the relayer passed the verification, then proxy canister will route the message to the destination chain, if the destination is IC, it’ll call the application canister to notify the message, if the destination is another EVM chain, it’ll send a tx to the destination chain, instruct the gateway contract on the destination chain to notify the application contract about the message.
Trust issue: the root of trust in this system is the validity of the merkle tree root hash in the gateway canister, to prevent single point of failure, gateway canister will choose several RPC providers from a RPC pool, then fetch the root hash from these multiple different RPC providers and compare the result to ensure the validity of the root hash.
Why not directly fetch crosschain messages via canister HTTP outcall: in the above design, we use an offchain relayer to submit crosschain messages and proofs, then verify messages in canister, the main reason is cycle cost issue, fetching crosschain messages via HTTP outcall can be expensive, especially if you want to eliminate the single point failure issue you have to fetch a crosschain message from multiple RPC providers, the cycle cost can be expensive.
The implementation repo is here: GitHub - rocklabs-io/omnic: Omnic protocol repo, and we’ve already built a token bridge on top of Omnic, users will be able to bridge token from EVM chains to the IC.
Internal test version of the token bridge: https://test.omnic.network, explorer: https://scan.omnic.network, currently supporting Ethereum Goerli Testnet and Polygon Mumbai Test. We’ll announce the official public testnet soon, the data in the internal test version will be cleared by then.
Note: Omnic is for crosschain message passing, if you only want to query data from or send transactions to EVM chains, we have a library called ic-web3: GitHub - rocklabs-io/ic-web3: Ethereum RPC client for canisters on the IC
We welcome comments and suggestions from the community! We’d love to provide help on the Ethereum Integration direction!
17 Likes
In my opinion this can already be done with the intermediate solution. The idea would be that in few weeks, when the Phase-1 solution is there, one can start building ckETH and launch it. Both should be acceptable with the Phase-1 solution.
@ccyanxyz: Thanks for providing all this information on Omnic and related work! 
Everyone: Would (parts of) this solution be something to use instead of implementing Phase 1 as planned? Need to look into this in some more detail.
2 Likes
Omnic is more for the needs of generalized crosschain dApp, ckETH can be one application built upon it, in fact, the Omnic token bridge already did this.
3 Likes
Yea it seems like Omnic solution already handles phase 1.
3 Likes
Dear @dieter.sommer,
Sorry about my question if it is dumb, but see this as a non dev question :
Since the ckBTC functionality is described as « built upon the native Bitcoin integration », if a CkETH is launched before the native Ethereum integration, will we keep it even once the Ethereum integration achieved ? Or will we « update » this CkETH by eliminating the need for intermediaries as a CkETH issued and redeemed through canister smart contracts built upon the native Ethereum integration itself ?
I guess the answer is here :
But preferred to ask ! Because we had chain-key ECDSA signatures before the bitcoin native integration too and yet did not launch CkBTC before the native Bitcoin integration.
3 Likes
tECDSA and bitcoin integration are 2 different things. Bitcoin integration uses the tECDSA feature.
ETH integration will happen in 2 forms, an HTTPS one, and a native one. Apps are free to choose whichever that suits their needs. We will aim for a maximally compatible interface between the 2 implementations.
4 Likes
Thanks a lot for your answer @benji 
I got that. And as I read it, the tECDSA is a building block of the native BTC integration and will be one of the native ETH integration.
But my misunderstanding was : as the ckBTC functionality is described as built upon the Bitcoin integration, I was thinking that the ckETH functionality would be built upon the Ethereum integration. So if we launch CkETH before such a native integration, I was thinking that it would not obey to the same logic as CkBTC did (wait for the native integration of X to base upon it CkX) and by consequence would not be to ETH what CkBTC is to BTC.
Hi ccyanxyz, do you have any plans to continue Omnic? I think we could be very interested to work with you and use your solution.
5 Likes