Long Term R&D: Integration with the Ethereum Network

Roadmap
1

1. Summary

This is a motion proposal for the long-term R&D of the DFINITY Foundation, as part of the follow up to this post: Motion Proposals on Long Term R&D Plans (Please read this post for context).

Chain Key cryptography facilitates consensus among IC nodes. Through an extension of the Chain Key cryptography, the IC will be able to directly interact with the Ethereum network. Smart contracts on the IC will be able to submit transactions on Ethereum. Additional work areas include supporting the Ethereum Virtual Machine (EVM) on the Internet Computer, and more.

2. Discussion lead

Dieter Sommer

3. How this R&D proposals are different to previous types

Previous motion proposals have revolved around specific features and tended to have clear, finite goals that are delivered and completed. They tended to be measured in days, weeks, or months.

These motion proposals are different and are defining the long-term plan that the foundation will use, e.g., for hiring and organizational build-out. They have the following traits and patterns:

  1. Their scope is years, not weeks or months as in previous NNS motions
  2. They have a broad direction but are active areas of R&D so they do not have an obvious line of execution.
  3. They involve deep research in cryptography, networking, distributed systems, language, virtual machines, operating systems.
  4. They are meant to match the strengths of where the DFINITY foundation’s expertise is best suited.
  5. Work on these proposals will not start immediately.
  6. There will be many follow-up discussions and proposals on each topic when work is underway and smaller milestones and tasks get defined.

An example may be the R&D for “Scalability” where there will be a team investigating and improving the scalability of the IC at various stages. Different bottlenecks will surface and different goals will be met.

3. How this R&D proposal is similar to what we have seen

We want to double down on the behaviors we think have worked well. These include:

  1. Publicly identifying owners of subject areas to engage and discuss their thinking with the community
  2. Providing periodic updates to the community as things evolve, milestones reached, proposals are needed, etc…
  3. Presenting more and more R&D thinking early and openly.

This has worked well for the last 6 months so we want to repeat this pattern.

4. Next Steps

Developer forum intro posted
1-pager from the discussion lead posted
NNS Motion proposal submitted

9 Likes
2

5. What we are asking the community

  • Ask questions
  • Read 1-pager
  • Give feedback
  • Vote on the motion proposal

Frankly, we do not expect many nitty-gritty details because these are meant to address projects that go on for long time horizons.

The DFINITY foundation’s only goal is to improve the adoption of the IC so we want to sanity-check the projects we see necessary for growing the IC by having you (the ICP community) tell us what you all think of these active R&D threads we have.

6. What this means for the existing Roadmap or Projects

In terms of the current roadmap and proposals executed, those are still being worked on and have priority.

An intellectually honest way to look at this long-term R&D project is to see them as the upstream or “primordial soup” from which more baked projects emerge from. With this lens, these proposals are akin to asking, “what kind of specialties or strengths do we want to make sure DFINITY foundation has built up?”

Most (if not all) projects that the DFINITY foundation has executed or is executing are borne from long-running R&D threads. Even when community feedback tells the foundation, “we need X” or “Y does not work”, it is typically the team with the most relevant R&D area that picks up the short-term feature or project.

1 Like
3

Please note:

Some folks gave asked if they should vote to “reject” any of the Long Term R&D projects as a way to signal prioritization. The answer is simple: “No, please, ACCEPT” :wink:

These long-term R&D projects are the DFINITY’s foundation’s thesis at R&D threads it should have across years (3 years is the number we sometimes use internally). We are asking the community to ACCEPT (pending 1-pager and more community feedback of course). Prioritization can come at a separate step.

2 Likes
4

Very important so thanks for creating this.

I’ve read in Terabethia’s Medium article that the IC <> ETH integration will allow IC canisters to hold ETH assets on ETH but “won’t actually enable Ethereum assets to exist on the IC”. Hopefully the one-pager clears up any confusion about what this integration will actually do.

In general, I’d love to get some high-level thinking on how this integration will fit into the burgeoning L2 rollup ecosystem. How do you hope ETH developers view the IC? As another rollup? If so, along the lines of an optimistic rollup, a zero-knowledge rollup, or something completely different? How do you envision the IC to co-exist with these other rollups and/or ultimately win over the ETH market?

These long-term R&D projects are the DFINITY’s foundation’s thesis at R&D threads it should have across years (3 years is the number we sometimes use internally).

I hope this won’t take 3 years… that’s a lifetime in web3 land haha

4 Likes
5

Dear Internet Computer Community!

I am Dieter Sommer, member of the DFINITY research team. I am responsible for this motion proposal and I am looking forward to having exciting discussions and working with you on this topic!

3 Likes
6

1. Objective

This motion proposal is about the efforts of integrating the Internet Computer (IC) with Ethereum, which comprises the following items:

  • Ethereum blockchain integration: Integrating the Internet Computer blockchain with the Ethereum blockchain in a trustless manner, i.e., without using any trusted intermediaries such as bridges. This will enable smart contracts on the Internet Computer to call smart contracts on Ethereum and vice versa.

  • EVM support on the IC: Providing an Ethereum execution environment (EVM) on the Internet Computer to run Solidity-/EVM-based smart contracts on the IC.

This proposal, being one of the R&D roadmap proposals, is different to our usual motion proposals for individual features that have been launched so far because it covers a multi-year strategic roadmap of R&D activities in a specific domain and likely results in multiple features on which we will have separate motion proposals. The proposal expresses the current thinking and intends to trigger a discussion process with the community to refine it towards the work on the individual features of the proposal.
The integration with the Ethereum blockchain and the EVM support on the IC must be aligned with each other in order to reap the most benefits from this strategic line of work.

2. Background

Smart contracts on blockchains like the Internet Computer or Ethereum can call other smart contracts on the same blockchain they are running on, but not on different blockchains. A blockchain is a walled garden in some way that is per se not openly connected with other systems and specifically other blockchains. The reasons behind this are technical and based on how blockchains work: It is not straightforward to deliver calls from a blockchain to another target blockchain and the results back in a trustless manner. Particularly, signing transactions for other blockchains is difficult given the trust model that any single node can be compromised and thus cannot hold private key material required to sign a transaction for the other blockchain it wants to interact with.
Regarding the other problem domain, most of today’s smart contracts are written in Solidity as they have originally targeted Ethereum and the language and surrounding ecosystem are well known by the community. However, Ethereum has become prohibitively expensive for running smart contracts at scale (especially ones with lots of data) due to its lack of scalability and massively increased demand in recent years. Thus, authors of smart contracts are looking for alternative blockchains with lower transaction, storage, and compute costs and possible other advantages like fast transaction finality and high throughput. It is crucial that Solidity-based smart contracts be portable with little effort and without major changes, because those contracts often have been running successfully and have been thoroughly audited and every change may introduce exploitable bugs and should therefore be avoided.

3. Why this is important

The interoperability between different blockchains is of increasing importance: As there is an increasing number of blockchains, the world’s smart contracts are distributed across those blockchains: So far, Ethereum has been the chain with most of the contracts running, but increasingly they have been moving to Layer-2 chains or other Layer-1 chains for lower operational cost. Now that contracts are spread over a diverse landscape of chains, the capability to make inter-blockchain calls and receive back the responses is becoming increasingly important for the world’s future open blockchain ecosystem. A particularly important aspect of integration between different blockchains is the transfer of value between the chains. This is also getting increasingly important now that liquidity is spread over a growing number of blockchains: Ideally, people can hold liquidity on a particular chain and easily transfer it to another chain and utilize it there to earn interest on the tokens. Take as an example Ether, Ethereum’s native currency, and the plurality of other ERC-20 tokens on Ethereum, e.g., those that are wrapped tokens of other cryptocurrencies that have been bridged to Ethereum. All those can be made available on the IC in a trustless manner with the integration between the IC and Ethereum. That is, token holders on Ethereum or on other chains that are bridged to Ethereum could benefit by using their tokens in a wrapped form on the IC and the IC would benefit in terms of a massive potential of liquidity influx from other blockchains. This would leverage the properties of the IC of being massively scalable, having very fast finality, and offering extremely cheap computation compared to other blockchains.
EVM support on the IC is the other aspect of the Ethereum integration that can provide substantial value to both the community and the IC. The IC, once offering an EVM integration, will be the best-suited platform for running Solidity-/EVM-based smart contracts due to its very low cycles cost, fast finality, and unbounded scalability. This will allow smart contract authors to bring their contracts over to the IC and benefit from all those properties the IC offers. This can be done without major modifications to the contracts, i.e., without the risk of introducing bugs or invalidating the audits that have been done.

4. Topics under this project

Ethereum blockchain integration
The basic idea of the integration with the Ethereum blockchain is to perform a trustless integration between the IC and Ethereum blockchains analogous to the Bitcoin integration with the Internet Computer. This integration enables smart contracts on Ethereum to call smart contracts on the Internet Computer and receive the call result as a response and vice versa. This integration will comprise a fully functional cross-chain integration between the Internet Computer and Ethereum, allowing smart contracts on one blockchain to call smart contracts on the respective other chain and thereby create substantial innovation potential. Particularly, Ether will be transferable to smart contracts on the IC and be wrappable for DeFi applications. The same will be true for any ERC-20 token due to the generality of the approach. The integration will leverage threshold cryptography to achieve our trust properties.

EVM support on the IC
The Ethereum Virtual Machine (EVM) is the first VM, in addition to our default Wasm execution environment, that we want to deploy on the IC and an important part of this motion proposal.
EVM support will make it possible to deploy EVM-based smart contracts on the Internet Computer. Having EVM support brings about multiple benefits for the community, such as low cycle costs for running smart contracts, low finalization latency, and network effects of being able to deploy readily-available, time-tested, audited Solidity-based smart contracts, avoiding the liquidity bootstrapping process.
The main technical challenge in this area will be addressing the impedance mismatch between the asynchronous architecture of the Internet Computer and the synchronous EVM.

5. Key milestones

As this is a multi-year R&D motion proposal, it is at the current time not possible to give detailed milestones. We expect that each of the features resulting from this R&D motion proposal will have similar milestones reflecting our engineering process: System design, MVP implementation, extensions to the MVP. The detailed milestones will be defined once the individual features will be worked on.

6. Discussion leads

Dieter Sommer (@dieter.sommer) is driving the proposal, and will be joined by Thomas Locher (@THLO) and Timo Hanke (@timo) for the forum discussions.

7. Why the DFINITY Foundation should make this a long-running R&D project

The functionalities we target with this motion proposal are not straightforward to implement and will likely be developed and rolled out in a staged fashion, starting with an MVP and adding additional functionality in multiple rounds later. We intend to roll out an MVP that provides value as quickly as possible so that our community can benefit from this. We think this is absolutely crucial due to the fast moving domain, particularly in the area of EVM-compatible blockchains. Advanced functionality will be added later on and provide additional value. This approach fits well into a multi-year R&D proposal: It will require original research to tackle the hard problems that are open in terms of their solution,whereas work on problems that merely require significant engineering efforts can be tackled sooner. We also intend to work tightly with our community w.r.t. the features associated with this motion proposal.

8. Skills and Expertise necessary to accomplish this

What we intend to provide as outcome of this motion proposal requires people with a plurality of different advanced skills:

  • System design
  • System-level and software engineering
  • Algorithms, complexity theory
  • Probability theory
  • Cryptography
  • Deep understanding of the IC and Ethereum
  • Deep understanding of Internet Computer consensus
  • API design

The following teams have been identifier of being involved:

  • Research
  • Networking
  • Consensus
  • Message Routing
  • Execution
  • NNS
  • Security
  • SDK

9. Open Research questions

We have already identified some of the research questions, the list will likely grow further during the work on the features:

  • Trustless blockchain integration between the IC and Ethereum
  • Consensus protocol extensions for the trustless integration
  • Threshold cryptography
  • Security modeling of the system
  • Proving security of the system
  • Questions related to the advanced system design
  • Testing and providing a testing infrastructure for the users of the feature
  • Addressing the impedance mismatch between the asynchronous IC and synchronous EVM

10. Examples where community can integrate into project

  • Review proposals
  • Provide feedback on the dev forum
  • Submit NNS proposals
  • Review technical designs
  • Contribute to technical designs
  • Review code
  • Contribute code
  • Participate in workshops on the initiative or its features
  • Help us prioritize for the best benefit of the community

We intend to work closely with the community, particularly on some parts of the source code.

11. What we are asking the community

  • Review comments, ask questions, give feedback
  • Vote accept or reject on NNS Motion
7 Likes
7

Is the integration with the current Ethereum 1.0 chain the priority or integration with Ethereum 2.0?
Maybe there should be two teams for each version. Since Eth2 is still in development there can be more cooperation with the Eth2 and influence to go to a certain direction, it has a political touch. Eth1 is more a classic integration effort without moving parts and requires only technical skills.

1 Like
8

Proposal is live! Internet Computer Network Status

9

Good question! According to current thinking, we will first tackle Ethereum 1 which will likely also solve a part of a future Ethereum 2 integration. Ethereum 2 will likely still take some time until it will arrive in production.
You are completely right that Ethereum 2 has still many moving parts. How much influence on it do you think we could have in the light of an integration?

10

With the upcoming BTC/ETH integration will it be possible to use IC as a L2? Will it be possible to do transactions using layer 2 solutions such as lightning network too or will it be limited to L1?

11

I’m wondering how easy it will be to integrate into existing platforms such as WordPress, Shopify? Will there be special plugins created for such platforms?

12

@marrymosss : Welcome to the forum and apologies for the (very) late response!

Platforms such as WordPress or Shopify are “traditional” HTTP(S)-based services. We are building a first version of the feature currently that will allow for an integration with HTTP(S)-based services: Enable canisters to make HTTP(S) requests

Have a look at this and participate in the discussions over there!

2 Likes
13

Yes it should be possible to use the IC as both a sidechain and a place for L2s to be implemented. For example, rollup sequencers and validators, lightning nodes, really any scaling solution that is not built on the base layer blockchain itself I imagine could eventually be implemented on the IC to support the other blockchain.

1 Like
14

Hi, I don’t know where to post this idea, but as it relates to ETH… here it is:

What if… what if we could create a sort of reverse ii token, ie publish an NFT (on any other chain, but obviously ETH first) containing a cryptographic hash of a GUEST Principle-ID that would provide access to Nuance, or any content for that matter, on the IC?

Might this reduce barriers to content hosted on the IC?

15

Hi Nick!

I don’t fully understand your idea, could you elaborate on it a bit more?

Thank you!

2 Likes
16

Disclaimer ( :slight_smile: ) I am non-technical!

What I am thinking… there is no doubt that ETH, Matic, SOL, Palm, etc have well established communities, most of which use Metamask and ERC20, etc tokens. These communities are clearly crypto-centric, but also chain-loyal.

Chain Loyalty in itself is a barrier to accessing other chains… my own experience is that I am 100% more likely to explore new chains that work with my existing Metamask than I am to spin up another wallet, e.g. Keplr, TronLink, Polkadot{js}, because asset management is so much easier if they are all under one login - I am a Grumpy Old Password Peep.

Let’s take the idea one step further… mint ii Profile Tokens on every MetaMask compatible chain, and use these tokens to log in to OpenChat, DSCVR, DISTRIKT, ICEVENT, NUANCE etc… these tokens will give MetaMask Peeps access to the IC stack (compute, storage, wallet, DeSo, DeFi, NFTs, etc.) WITHOUT asking them to sacrifice chain-loyalty.

The original idea was to have a general token, which the above IC Dapps could publish on these other chains in order to bring content to these other chains - again, without asking these other-chain-peeps to spin up a new wallet.

Reduce Barriers. Provide Access. Drive Adoption.

Edited grammar a bit.

Final Edit: as an example … here is my new ICNS landing page… every Crypto Peep would die for one of these IF they could get access VIA their chosen chain!

THIS IS A WONDERFUL THING!

1 Like
17

very cool idea, there was a similiar example called “the wall” where you could login via metamask.

3 Likes
18

Thanks for providing the link. That is a very cool proj of which I was unaware!

1 Like
19

Yes, indeed a really cool idea, along the lines of the “The Wall” project that @cryptoschindler mentions! Have discovered this myself only now because of asking around in the team regarding your idea (Many thanks to @alexa.smith for pointing this out to me!). Allowing people to login with MetaMask might get many folks try out the Internet Computer who would not do so otherwise, so might be a good catalyst for growing our customer base.

I discussed this already with the Internet Identity (II) team and we think that technically / architecturally that could be realized. However, II folks would prefer to have a mechanism in place to denote the authentication strength as it will be different when logging in with MetaMask when compared to the standard biometric login via WebAuthn as is default for Internet Identity currently. Then dApps could use this authentication strength to decide on the authorization granted at their discretion.

To preserve this idea, I just created a feature for authenticating with MetaMask to the Internet Computer in our internal backlog.

7 Likes
20

Here’s the original forum post and discussion related to “The Wall” mentioned above: The Wall – A crossover ETH/IC demo dApp – Next.js, Rust canisters

And here’s the link for those who haven’t yet read through the “The Wall” posts: https://rivyl-6aaaa-aaaaf-qaapq-cai.raw.ic0.app/

2 Likes