Long Term R&D: Integration with the Ethereum Network

Roadmap
61

@Roman, @dfisher, @lastmjs, all: Thanks a lot for your thoughts, and taking the time to write them down! Apologies for my late response, I am still recovering from a virus infection.

@Roman: My interpretation of your thoughts, at a high level, is that we should do the Ethereum integration diligently, do things properly, and not unnecessarily rush the integration. In other words, repeat the good things of the BTC integration. That’s the high-level semantics I get out of your arguments, abstracting from the concrete ckETH discussion. Please correct me if this interpretation is wrong. I could not agree more to this interpretation actually!

Now let’s discuss the proposal of Phase 1 and Phase 2 of the Ethereum integration. Phase 1 is thought of as an instrument to quickly make a first implementation of the API available to everyone in the community who wants to use it. The integration builds on HTTPS outcalls to one or more Ethereum cloud services like Infura, or QuickNode, thus has clearly a weaker trust model as Phase 2, but still is a solid implementation of an integration — just not trustless. For Phase 1, much of what is needed is there already in the form of the ic-web3 library by Rocklabs, which is already open source. The idea for Phase 1 now is to issue a grant to Rocklabs to retrofit the library to offer the same API, or one the is very close to the one for the Phase-2 integration. People will be able to build already on the API of Phase 1 early on. From this perspective, Phase 1 is analogous to the developer preview of the Bitcoin integration which was launched early on with the API close to the final one so that people could already build on it. The Bitcoin developer preview, however, did not do a real integration yet, so was less powerful than a Phase 1 of the Ethereum integration, which gives people more options on what they can do with it.

Your forum post was focussing on ckETH as application case for Ethereum integration. In my opinion, ckETH is only one use case, granted, a very important one, but there are many more: ckUSDC, ckUSDT, NFTs etc. One of your main assertions is that we should not launch ckETH before Phase 2 is complete. Thus, we should not transition ckETH from a weaker trust model of the integration (Phase 1) to a stronger one (Phase 2), but only launch with the strong one when Phase 2 is available. This definitely has some very valid points, e.g., avoid the reduced trustworthiness of the ckETH state acquired through Phase 1 integration vs Phase 2. From this perspective, your argument makes a lot of sense and ckETH’s strategy needs further discussion.

Continuing the ckETH discussion, a ckETH implementation will not be ready tomorrow: Someone needs to build an ERC-20-based minter, ideally customizable to any ERC-20 token, the code needs to go through a thorough security review, needs to run in beta phase on an Ethereum testnet for a while, and only thereafter can be launched for Ethereum Mainnet. Also, the question is whether DFINITY should build the ckETH minter canister, as it did for ckBTC, or the community should do it? That’s also something that is not yet clear, at least to me. Thus, for me, the ckETH question is not even the most important and most pressing one, it is one use case of many and its own timing dictates in many ways when it can be launched in production. Now to the concrete question: If ready, should it launch before Phase 2 is ready? I don’t know, this is actually a really tough question. Having a clean trust model without a migration to Phase 2 vs. a shorter time to market and our DEXs being able to use it earlier. An alternative is to have a preliminary chain-key Ethereum implementation that can bridge the gap towards the final launch. We had this for Bitcoin also in the form of icBTC by ICLighthouse.

My thinking goes into a direction that a community-launched chain-keyed Eth, lets call it icETH for now, based on Phase 1 might be a great idea. That is, Phase 1 is built and launched quickly so that everyone can start integrating their dapps with Ethereum. The API will stay (almost) the same for the Phase 2 launch. Then a first iteration of chain-key Ethereum in the form of icETH can be started with as well. And dapps can start integrating with icETH already. All of this helps reduce the time to market for the Phase 2 and Phase-2-based ckETH without severe drawbacks. The decisions are left to the individual community members on whether to adopt an early version of chain-key Ethereum as soon as possible and build upon it or whether to wait for the Phase 2 and a final ckETH to be ready. In any case, Phase 1 is an accelerator that does not cost us much, but helps a lot in getting the final API out so that our community can start building upon it. So it’s in many ways the most decentralized approach where everyone can do what they deem best for their projects. No one imposes anything on anyone. All we do now is to work with the community to enable this flexibility and shortening of the time to market.

@Roman, @dfisher, @lastmjs, all, I would really appreciate your feedback on this line of thinking.

I agree to that in that we should repeat everything that was good from the Bitcoin integration, not unnecessarily rush, and do things properly. But not be slower than we could be while doing things properly. Also let’s improve it where possible. E.g., offer people a means to start coding their dapp integrations as soon as we can with a close-to-final interface and also giving people a choice whether to run something in beta or production before Phase 2 is ready. I think there is no drawback of running any dapp, also ckETH, in beta with Phase 1. Also note that Phase 1 is not some insecure mess, but uses well-vetted cloud service providers as integration points to Ethereum. This will give us a lot of advancement in terms of time to market. For this reason, I don’t see a dilemma to start with Phase 1 — it’s a powerful accelerator for the community to build dapps using Ethereum. The question whether to launch the “official” ckETH with Phase 1 is a specific one that needs lots of thought. But considering that building ckETH also takes time, this might not even be a relevant question as ckETH needs time to be built, time to be reviewed, and time to be run in beta with an Ethereum testnet — it might not be ready that long before Phase 2 is ready. Considering this, I would see doing Phase 1 as outlined to be only an advantage to the community.

So, yes, DFINITY needs to take its time to build Phase 2 and ckETH, but we should support the community to start building their dapps as soon as possible. Whether individual dapps are launched in production with Phase 1 or only Phase 2 is up to the discretion of each project — we definitely don’t want to impose anything on anyone here.

@dfisher, I hope this has been answered with the above response. Just note that Phase 2 has started in parallel to the Phase-1 efforts. Phase 2 is not delayed or otherwise impaired by Phase-1 efforts — on the contrary, it benefits from the thinking w.r.t. the concrete API we want to offer.

@jordan, I fully agree that this is technically possible without doubt. @Roman’s main concern is that Phase 1 and Phase 2 have different trust models and switching the main ckETH implementation from one to the other is, at least theoretically, not very clean. It’s definitely something that deserves further discussion. We are currently pursuing Phase 1 and Phase 2 in parallel, according to the approach outlined above.

And, yes, ckETH should definitely be an ICRC1!

I think you have got the general idea correct here.

@lastmjs: For context, you are referring to queries to the Ethereum interface here. In theory, this is possible as an IC node could just query its collocated Ethereum node in Phase 2. However, XNet queries are not available yet, so there are things that would need to be built to have this. And, you are right, query support for Ethereum would be really great, but there are currently still some blockers for it.

@ all: I hope that my argument for doing a Phase 1 now can appeal to everyone, as its adoption is left to the community in a completely decentralized way. We only help the community getting Phase 1 built. This does not dilute our efforts for Phase 2 and it helps a lot in sharpening the final API for Phase 2 as we need to think about it very concretely. Also having dapps build on Phase 1 will help detect any issues, e.g., with the API, early on and reduce delays and time to market for Phase 2.

Looking forward to hearing your opinions!

7 Likes
62

Indeed, we are targeting a pruned full node comprising a consensus and execution client as of now to be collocated to each IC replica on one subnet. An archival node would not be of much additional value for most of the user cases we see currently and would consume an excessive amount or resources of the IC machines.

Exactly, the idea is to use HTTP outcalls to localhost, which would then be directed to the respective collocated Ethereum full node that sits on the same physical machine as the IC replica.

The blockchain world is indeed increasingly becoming a X-chain world! There are dozens of chains, and a handful of chains you mention that are most interesting. Now the first question is: Can we do a native integration with all of them within a year’s time frame? Probably not. The second question is: Which of the EVM chains is the most important one? This is easily answered with “the Ethereum blockchain.” For this reason we are currently designing the Phase 2 for a native performant Ethereum integration, not requiring API keys to be managed securely. Our current design with having a subnet with collocated Ethereum full nodes that are accessed using HTTP outcalls to localhost. This is a trustless integration and does not need any additional trust assumptions besides the ones of the IC and Ethereum.

Ethereum, as a base chain to all the Layer-2 chains, secures all assets used in Ethereum and its Layer 2s. This means that an Ethereum integration allows for tapping into the liquidity of all those chains either directly or indirectly. Thus, my argument is that a native Ethreum integration is the best step we can do as a next step and provides tremendous value to the IC.

Coming back to an integration with the other EVM chains (and possibly other chains in the future): I’d love to have such integrations available, but this will take time. There are different ways on how such integrations can be done, some examples of approaches being presented next:

  • Native as for Bitcoin
    • Running a full node of the target chain on chain
    • Strongest trust model
    • Hard for chains that have more state than the Bitcoin network
  • Native as for Ethereum
    • Runs collocated full nodes of the target chain in one subnet
    • Strongest trust model (essentially like running a full node on chain)
    • Requires lots of resources
  • Using on-chain or collocated light clients (particularly the collocated option is interesting as it could reuse a lot of what is done now for Ethereum)
    • Light-client trust model, weaker than a native integration, but still good
    • Requires few resources to run
    • Implementation effort differs a lot based on concrete architecture
  • Using HTTPS outcalls to cloud nodes
    • Weaker trust model: Trusting a quorum of cloud nodes
    • Easiest to realize,; would benefit from additional protection of the API keys
    • Good approach for larger number of integrations with different, but not for the key integrations with the major chains

The Phase 2 of the Ethereum integration does not need API keys, but other integrations built on HTTPS outcalls do. And for those we should definitely think about an approach to allow different API keys to be used for different nodes as you suggest. This would also immediately allow for observing if a node leaks and misuses an API key. That’s a discussion that should be have when considering integrations with further blockchains using the HTTPS outcalls feature following the Ethereum integration. We should, however, not think about this for Phase 1 of the Ethereum integration as this is a stop-gap solution towards Phase 2 that is obsoleted once Phase 2 launches.

Opinions?

5 Likes
63

Seems very reasonable to me.

2 Likes
64

Trying to integrate every blockchain (with a native integration at least) could get out of hand very quickly and become a large time-drainer, I think this would be a big mistake.

But perhaps tEDdsa combined with a phase 1 template would allow many integrations to flourish, while only the most important chains get native integrations (like Bitcoin and Ethereum). Objective criteria could be applied to determine which native integrations deserve to be created.

I fear this could easily run away and become something that wastes a lot of time while other important protocol tasks remain undone. Demergent Labs has a list of tasks we need from the protocol just as a few examples.

3 Likes
65

@lastmjs, I fully agree with you that only the most important integrations should be done natively, i.e., Bitcoin and Ethereum for now. The Phase-1 implementation can indeed help integrate any chain the API of which is available through one, ideally multiple, cloud API providers. Anyone can then use t-ECDSA and the Phase 1 integration to roll their own integration with any blockchain. I think this is a very realistic way forward for integrations with many more chains quickly.

One can think about few other important chains to receive thought about a native-style integration into the system, but it should be few of them, and only once Ethereum has bee integrated. Anyway, Ethereum captures probably most of the value by far already and is by a huge margin the most important chain to integrate with.

2 Likes
66

I think that it is important to integrate all EVM chains, including Ethereum. Ethereum may have the lion’s share of TVL, but for DeFI activity and trading this is not the case. Anyway, the API key attack needs to be addressed for both bridging and oracles, so it would be good if the Foundation could put resources on this, otherwise as soon as the Foundation gets any serious kind of TVL a bad actor will hack it.

67

Currently the only other chain I think is important enough for a native integration is Cosmos.

2 Likes
68

Here is a document summarizing the efforts planned for Phase 1: Ethereum Integration — Phase 1 - Google Docs

Have a nice weekend!

3 Likes
69

Quick question, does phase 1 allow for connecting with multiple Ethereum cloud providers? I think this would be very helpful for the security of phase 1.

For example, we could allow the service performing the http outcalls to Ethereum cloud providers to accept any number of cloud providers URLs and API keys, and allow setting a threshold on how many responses need to come back and agree.

So perhaps you use 5 Ethereum cloud providers and expect at least 3 to always agree perfectly. This could be important for overcoming network failures as well, making the phase 1 fault tolerant.

The phase 1 design might already have this, but here’s the idea explained: https://twitter.com/lastmjs/status/1556058841208455168

And here’s the code using an old version of Azle with generators: ic_chainlink_data_feeds/latest_answers.ts at main · demergent-labs/ic_chainlink_data_feeds · GitHub

In Rust I assume it’s easy to fire off multiple asynchronous requests and wait on all of them, the example above waited for each in sequence because of the limitations of generators.

2 Likes
70

Good question, currently it is something we consider optional, but it’s definitely an important feature for security reasons.

Thank you for your further thoughts about this, need to look into the links you have sent.

Yes, this should be easy, so not increasing the latency when querying >1 providers.

2 Likes
71

Dear Dieter,

It is my turn to beg pardon for the delay of response.

Thank you very much for your answer and for your rigor, the same one and only one we find among researchers. This is exactly why I invested in ICP : for the Dfinity’s team’s scientificity. So thanks again.

Your interpretation is right yes !

In my opinion, probably idiosyncratic : yes Dfinity should. In the future, Dfinity could let developers build such minters for other blockchains, but not for the CkETH. This is too decisive to summon the decentralization argument or ideal, all the more given the context (we are still early in the ICP blockchain and in a bear market, so the decentralization has not to be thought yet as it will have to be thought eventually). The decentralization is not a target per se : it has to be reached when it is the best for the ecosystem, but the best for the ecosystem is not everytime the decentralization, all the more now.

Can’t agree more !

It is only my opinion of course, but for me : if ready, it should not launch before Phase 2 is ready ; as I defended the necessity to reach the simplest model, without having to pace up and down from a first CkETH to a second one, taking the risk of some confusion and some bad influence of the CkETH 1.0 on the CkETH 2.0 ; “bad influence” meaning a sort of difficulty or reluctance to migrate because we would have developed a lot around the 1.0 and would want to save the ecosystem which would have developed within the timeline between CkETH1.0 and CkETH 2.0. To say it differently, I am afraid that we are currently underestimating how much we will tie our hands to CkETH1.0 and the fact that we won’t be able to get rid of it when we will want.

Still, if it has to be launched, that we can’t wait, I could not agree more with each one of your lines below :

If we truly can’t wait, such a distinction between icETH (or iETH like ICLighthouse’s iBTC) and CkETH would be necessary and the best way to give the opportunity to flexibly play already with ETH, but not confusing people with a CkETH which could be perceived at least inconsistent or at worse “messy”.

Even if I think that the best is the simplest and that the simplest is not the quickest and that on the contrary the quickest is often what brings a lot of complexifications, I trust you and feel reassured about launching a phase 1 as you presented it above even if I’d prefer a start with the phase 2.

3 Likes
72

@Roman
Excellent, it seems the two of us have some roughly similar view here, with some differences, but not material ones.

Regarding ckETH, it is probably the best approach that DFINITY builds this. Also with the latest developments in the ckBTC domain that we will need to perform some form of checks on the incoming tokens to ensure they are not from illicit origin, which is currently being solved for the ckBTC canister. The same approach can be taken then for ckETH.

Also, there is only the need for a single ERC-20 minter, which can handle any ERC-20 token. It should be parameterizable for any token so that deploying a new ckABC token just requires deployment of the parameterized minter and a corresponding ledger. This way, it will be streamlined to roll out further ERC-20 chain-key tokens in the future.

And if a ckETH is launched before Phase 2 is ready, it would need to remain the same ckETH with Phase 2 in the view of its users, just with a change of trust model, which users don’t need to care about. Security has increased. Yes, this is not as clean as one starting with Phase 2, but might make sense in case there is not too much liquidity in it yet during Phase 1, so effectively the initial liquidity in it is based on a different trust model. There are people who want to move forward with this approach. This is surely still an important discussion to be had in more depth and I hope you will participate in it.

I think there are parties interested in building some other chain-key ETH with Phase 1, so this is likely to happen.

2 Likes
73

do you mean we will have both icrc-1 chain key token and erc-20 chain-key token?

74

The chain key tokens on the IC have the ICRC-1 interface and they bring ERC-20 tokens into the IC ecosystem. The ledger being used likely also supports ICRC-2, which brings ERC-20’s approve / transfer_from semantics to the IC. There will not be an ERC-20 interface offered on the IC as the IC uses ICRC-1 as token standard. Does this answer your question?

1 Like
75

This sounds just perfect dear @dieter.sommer ! Thank you for your answer.

76

Phase 1 update

Meanwhile, our community has been working on Phase 1 of the Ethereum integration. First results are now available to the public and can help people build their projects that integrate with the Ethereum network.

JSON RPC API canister via HTTPS outcalls to API providers

Rocklabs has been working on the following, which is now ready in a first version:

  • An extended ic-web3 library that offers an HTTPS outcalls transport for calls to Ethereum full nodes that offer the JSON RPC API.
    • The library offers the JSON RPC API now besides the web3 API.
    • The max_response_bytes for the HTTPS outcalls transport can now be set to a user-defined value so that the cost of the calls is dramatically lower as with the default value.
  • A canister building on the updated ic-web3 library is available as part of the examples section of the library codebase.
    • The canister offers an endpoint for the JSON RPC API and uses the ic-web3 library to invoke an Ethereum JSON RPC API provider via HTTPS outcalls.
    • Each call can define an RPC API provider URL including API key in the format used by API providers.
    • Each call can define its own max_response_bytes value for the HTTPS outcall that is made to be set to a user-defined value to reduce cycles cost.

Anyone can now deploy this canister that exposes a JSON RPC API and with this run their own Ethereum integration. What is needed in addition is an API key of one, or, preferably, several API providers. It is recommended to use multiple API providers for each state query that decisions are based on, such as minting chain-key tokens. There are also API providers that do not require API keys, e.g., The source code is available as open source in its GitHub repository.

The API envisioned for the Phase-2 Ethereum integration worked on by the DFINITY Foundation will offer a subset of the Ethereum JSON RPC API, however, there will be slight differences:

  • The HTTPS-outcalls-based Phase-1 solution offers users the option to set a maximum response. This is not required for Phase 2 as the Ethereum canister there is trusted and there is no attack vector of it consuming substantially more ingress bandwidth than is paid for.
  • There may be slight differences in the exact behaviour of the API due to the different ways of integration based on how the asynchronous nature of the interoperating blockchains is addressed.

Ethereum helper canister

Community member @stopak has built, as an ICDevs bounty by Austin, an Ethereum helper canister that provides essential Ethereum-related functionality to Motoko users because the Motoko ecosystem does not have those libraries as of yet. The canister is built in Rust and offers those essential Ethereum functionalities as services to its callers. Anyone doing their project in Motoko can spin up this canister on the same subnet their project canisters reside on and call its endpoints with low latency intra-subnet inter-canister calls. Some examples of functionality the canister offers are given next:

  • RLP encoding
  • Creating a transaction from its inputs
  • Parsing a transaction into its constituent fields
  • Verifying a Merkle proof
  • Keccak256 hashing
  • Signature validation
  • Derive an Ethereum address from a public key

The library is available as open source in its evm_utils_ic GitHub repository.

With this, the main building blocks are now available so that any Rust or Motoko project can start building their project using a Phase-1 Ethereum integration.

  • The project deploys their own canister based on the extended ic-web3 lib.
  • The project deploys the Ethereum helper canister for accessing relevant Ethereum calls.

Interested community teams, please have a look and let us know whether this is enough for the first steps to get started or whether things are missing.

8 Likes
77

Technical Working Group Meeting on Ethereum Integration

Let me suggest to start having a first Working Group call related to Ethereum integration to get more involvement of the community members. There has been good progress in Phase 1 and we need to see what is missing to get where we want to be. Further calls could be, following demand, either regular or scheduled on an as-needed basis whenever we have items to discuss.

As there are people interested in this subject from all major geographies, the time choice would be suggested as follows (summer time where available). The rationale behind this proposal is that we have many interested people from China and thus would put them into a more convenient time and have US and Europe early or late in the day.

  • West coast (PDT): 22:00
  • Europe (CEST): 7:00
  • China (CST): 13:00

UPDATE:
The first meeting is still in CET time in Europe:

  • West coast (PDT): 23:00
  • Europe (CEST): 7:00
  • China (CST): 14:00

The first meeting is scheduled for the upcoming Wednesday, March 22, at the above time slot.

Public WG calendar (Google Calendar)
Public WG calendar (browser link, (no google account required)

Please like this post if you plan to attend such WG meetings.

Let’s see what the level of interest in this is and proceed accordingly.

5 Likes
78

See here for a new forum topic on a Technical Working Group for Blockchain Integrations.

3 Likes
79

Hi @dieter.sommer the Google Calendar link isn’t working for me. It takes me to Google Calendar but not the event on Google Calendar.

80

I would be super excited to see a ckETH built on Phase 1 that happens faster, and then it can migrate to Phase 2 later. What kind of time frame would we be looking at for that?