This is indeed ambitious, because it’s a non-trivial X-chain smart contract on the IC and the Ethereum network and we need a very high assurance of correctness. Exploitable bugs in this system would be detrimental to the whole ecosystem. Also, it needs to be ensured that the system will be maintained in the long term, ideally by the same team that has implemented it originally.
Considering the criticality of this piece of software and longer-term maintenance, we found it to be the best way forward to have a team of the DFINITY Foundation implement this piece of software and take on the long-term maintenance. Ensuring that the same team can do the maintenance is important for such complex software and increases the chance of keeping it bug free. We thought that it would be rather challenging to have many (including external) contributors on the project in addition building bits and pieces of the system and getting the same high level of assurance. Also, a community team we have been discussing this with came up with similar estimations for the timeline towards having a production-grade system available.
Your LC proposal: It may be a good idea to try out the idea of the Ethereum in-canister LC for which you have finally submitted a proposal. Need to have a look at this proposal.
Here is an update on the Ethereum integration: We are currently focussing on building ckETH and ckERC-20 based on Phase 1 of the Ethereum integration, i.e., building on top of HTTP outcalls to Ethereum JSON RPC API providers. Phase 2 will start only later so we focus available resources now on the chain-key tokens.
It is estimated that this effort will be complete in Q4 this year.
Do you need an API key to get RPC-JSON from an RPC provider? If so, I am concerned that neither Phase 1 nor Phase 2 can be done without solving the problem of the node being able to see the key. it seems that you are considering using a SEV-SNP node, but there are still issues.
If Ethereum integration allows EVM on IC and EVM on Ethereum to call each other and interact with each other, does this interaction not include asynchronous processing and asym, which can do general operations? Is it only possible to do heavy processing among the processing that EVM can do?
Sorry for the late response, was on a long vacation.
Excellent questions!
The idea is to use API providers that do not require API keys as API keys both have the problem of getting exposed and introducing centralization as someone needs to register for the API keys. SEV/SNP could address the first issue to some extent, but the centralization one still remains and is harder to address.
Ethereum and IC contracts calling each other is only be part of the full integration (Phase 2) that is coming after the ckETH / ckERC-20 tokens. These calls, as you mention, will be asynchronous of course and you can do anything of interest, e.g., offloading heavy computation from Ethereum to the IC, as you suggest. But you can do anything you can think of, it just needs to fit the model of being asynchronous. In Ethereum, this can be modelled similarly to an oracle call: you place the request that gets executed asynchronously and some time later a response comes back asynchronously. Everything that you can model with this approach should work.
Not sure whether this answers your question as I am not fully clear to have interpreted it correctly. If not, please do not hesitate to come back for further clarification.
How are ICP tokens going to be called when transformed to erc 20?? Ck-XX as well?? For instance ck-Kineox??
That is kinda confusing cause you won’t know if you are on ICP or ETH chain depending on what token is native to what ecosystem. Product team should get involved on this…
This transformation is going to be part of release 1 with ckEth or release 2??
You can verify BLS signatures on Ethereum, so the short answer is “yes”.
However, verifying such signatures has a much higher gas cost than verifying ECDSA signatures. Depending on your use case, an approach to prevent the high gas cost could be to embed an ECDSA signature in the IC response (incurring a higher delay and cost on the IC side because an ECDSA signature must be obtained).
@JaMarco The general idea is that smart contracts on ETH themselves don’t need to verify the signatures, but they could just check that the msg.sender / tx.origin is a certain account controlled by a canister.
As @domwoe already mentioned, this is not necessary as the threshold ECDSA signature made by an IC smart contract is the technology foundation to realize the IC → Ethereum direction of the integration, i.e., information flowing from IC to Ethereum in a secure manner.
If there was no threshold ECDSA available, the other prominent option of integration would be to have an “IC light client” implemented on Ethereum in a smart contract. This would require that an Ethereum smart contract validate an IC BLS threshold signature of a subnet. This would not be possible (without zk technology) in a gas-efficient way as there is no BLS precompile available yet. Using zkSNARKS or the like, one could build a gas-efficient light client on Ethereum.
But, as we have t-ECDSA, we don’t need Ethereum to validate IC consensus and thus we don’t need Ethereum smart contracts to validate IC’s signatures.
I’m a bit lost and could use some simple clarifications.
Is the plan still to have a general-purpose Ethereum JSON-RPC canister? What is the status of that canister (phase 1 I believe is what we are calling it)? Where is the best place to go for updates on it?
I am specifically interested in the full protocol-level integration enabling smart contracts on the Internet Computer to call smart contracts on Ethereum (and vice versa). When can I expect this full integration to be available please?
