Internet Computer <> Ethereum Integration Explained

The greatest possible force multiplier.

Background

The history of the Internet Computer is inextricably linked with the early years of the Ethereum project. Before talking more about how the networks will be integrated, and what this is going to unlock, I will provide some color and context to the background, as much of this has become lost in time — it was not that long ago really, but blockchain changes every day, and things move so far, it seems like a lifetime.

When I first started working full time in blockchain in 2013, my primary personal interest was devising faster consensus mechanisms that would work with Proof-of-Stake architectures. In the summer of 2014, I started work on a concept called Pebble, whose old unfinished paper can be found here (you probably shouldn’t bother reading unless you are interested in blockchain history). That project didn’t happen in large part because of learnings I gained on the Ethereum scene. At some point, I absorbed the concept of a “World Computer” and it became my Holy Grail — this was what I thought the future Internet should be.

I also had another epiphany: I saw that smart contracts were, in fact, a completely new, and profoundly superior form of software. Upon analysis, I saw that if their limitations could be removed, then surely nearly everything would eventually be rebuilt on blockchain, since they run on open public networks, which is better than running on private infrastructure, they are tamperproof (no need for firewalls!), unstoppable, can plug in to each other within a single universe, such that each contract can simultaneously be part of multiple systems at once, providing for service composability that will create extraordinary network effects, and can run autonomously, inheriting the properties of blockchain, so that they can process value in the form of tokens, and much more.

Scrolling forward to 2015, I had abandoned my previous line of work, which revolved around repurposing more traditional consensus technologies, after I saw something called “Threshold Relay” was possible (now part of Internet Computer Consensus). I saw a way that cryptography could be applied within a decentralized network to produce an unstoppable stream of random numbers, with complete security, that could be used to drive an efficient blockchain protocol. I saw the potential to drive blockchain protocols that scaled validation and thus capacity. Soon, I was talking about the DFINITY project, so named from a shortening of “decentralized infinity”. My focus became finding ways to create a World Computer blockchain that could run nearly all systems and services entirely on-chain using smart contracts.

Initially, my hope was that my research would be used within the Ethereum project. My work had no financial purpose, and was driven by a longstanding passion for distributed computing, which had morphed into an obsession with blockchain, such that I could not imagine anything else I would rather be working on. I became a fixture on the early Ethereum circuit, talking about new ways cryptography and distributed computing protocols could be applied within a next generation blockchain. At that time, people were interested in the ideas presented, but in truth they were too complex, and sounded too out there and futuristic, and certainly difficult to attain in any reasonable timeframe. My thanks go out to early Ethereum folks such as Vitalik and Joe Lubin for entertaining my ideas in many early discussions.

In truth, people were probably right not to follow the path I proposed. Nothing I described could have been achieved quickly, as has been proven by the many years taken to bring the Internet Computer to fruition, which ultimately involved relentless work by a large and brilliant team, the creation of novel cryptographic techniques, and much more (high-level documentation is being progressively uploaded to https://dfinity.org/technicals/).

By 2016, it was obvious that the direction I would have to take to create the Internet Computer would be incompatible with the short-term trajectory of Ethereum, which committed to Proof-of-Work, while exploring an upgrade path using Proof-of-Stake, and that to progress the ideas DFINITY must become a standalone project.

Eventually the DFINITY Foundation was created in Switzerland, funds were raised, and the rest of the story is fairly well known, so I will not repeat it here. The network has taken a very long time to bring to fruition — years of work — and in practice would never have been possible without the kind of team we now have, which incorporates many brilliant engineers and researchers, working from research centers around the world, that perhaps incorporates more leading cryptographers than any operation in tech, inside blockchain or more broadly.

Our mission is to push towards a blockchain singularity, where the majority of the world’s systems and services are created using smart contracts, and run entirely on chain, a transformation that will also take years.

Before talking about how the Internet Computer and Ethereum can be integrated, accelerating that dream, I will restate what I have said many times, for the avoidance of doubt, to debunk misinformation on social media:

• The Internet Computer network we see emerging today would not exist without the inspiration that Ethereum provided, which introduced the concept of a “World Computer” and “smart contracts”, for which everyone involved with DFINITY is immensely grateful. We stand on the shoulders of giants, and are friends of Ethereum, and always have been.
• Ethereum and the Internet Computer are different beasts, which derives from their respective focuses. You cannot transform one into the other owing to technical considerations. They are different by design, but very complementary — not competitive. The Internet Computer is hosted by special node machines run by independent node providers in independent data centers around the world. By contrast, anyone can create a block-making Ethereum node using a graphics card and run it from home. You need both architectures in the world, for technical reasons I will not go into here, and they produce different and complementary properties.
• The Internet Computer is not, and was never intended to be, nor has ever been sold as, an “Ethereum Killer”, which is a frustrating misconception I battle against even today. Where examples of contrasting properties are provided, such as the relative costs of smart contract computation, the purpose is to illustrate the additive role the Internet Computer plays, not claim deficiency with Ethereum. The networks are stronger together.
• I remain a massive supporter of Ethereum, and maintain many friendships that were formed in the earliest days of the project. Enough said.

Nothing will bring me greater pleasure than to see the two networks integrated, in a manner that will add enormous value to both, and rejoin the starting point of DFINITY— and that is exactly what we are going to do.

The following is written in haste as people are clamoring for more information after my recent tweet, which has been widely read — it is an outline only, and more information will be provided soon.

Direct interoperability

Smart contracts on the Internet Computer (which are called “canisters” because they are a bundle of WebAssembly bytecode, and persistent memory their logic runs within as a software actor) are very different beasts. They run at web speed, can serve web experiences directly to end users providing end-to-end blockchain security, can be used to create scalable dapps, and can process and store data at relatively stable cost that is a tiny fraction of that on traditional blockchain. They can do things that aren’t possible on Ethereum today. For example, today a GB of smart contract data can cost you about $100,000,000 on Ethereum (see the latest cost here). On the Internet Computer, you can expect that to be below $5 per year paid in cycles. Connecting the two will provide these decentralized capabilities to smart contracts running on Ethereum.

To make all this possible, we need to enable Ethereum smart contracts to directly call into smart contracts on the Internet Computer, and to enable Internet Computer smart contracts (“canisters”) to directly call into smart contracts on Ethereum.

For example, you can imagine that a DeFi system running on Ethereum might use smart contracts on the Internet Computer to securely serve user experience to end users, rather than using an insecure website hosted on the Amazon Web Services cloud — which forces end-users to trust the website operator is honest, that AWS is honest, and that the account has not been hacked, such that they can never really be sure they are even interacting with smart contracts. This simple potential application of integration hints at the possibilities. The combination of the two networks will be incredibly powerful.

Websites served by smart contracts on the Internet Computer can also securely interact with smart contracts on the Internet Computer. If those smart contracts can directly interoperate with Ethereum smart contracts, then we can create secure decentralized loops, which are end-to-end blockchain. Security is not the only benefit: the entire system can be made autonomous, and placed under the control of governance tokens, such that operators of DeFi websites do not become legal “owners” of such open services.

Innumerable other possibilities will be provided by this kind of architecture. A DEX might be created using smart contracts on the Internet Computer, with an interface similar to that provided by Poloniex, say, with flows of value and assets then settled on Ethereum. Or, for example, Ethereum based dapps could use the Internet Computer to maintain and serve large data objects, up to and including even video files, within a secure blockchain trust zone, where data does not just reside, but can also be queried and manipulated by tamperproof, unstoppable and potentially autonomous smart contract logic.

Just imagine how much more powerful Ethereum smart contracts will become, which have already been applied to create the DeFi ecosystem, once they are enabled to maintain and process large amounts of data, quickly, and at low cost, on chain, and serve experiences directly to end users.

Integrating Ethereum and the Internet Computer will also provide a route for Ethereum dapps to solve their usability challenges through application of Internet Identity — which allows users to authenticate themselves to blockchain services on the Internet Computer using only their devices, such as Face ID on their phone, the fingerprint sensor on a laptop, and YubiKeys and Ledger devices, without need to hold tokens or manage a token wallet (the Internet Computer uses a “reverse gas” model in which smart contracts pay for their own computation). For example, end-users of Ethereum dapps might authenticate to services on a website using Internet Identity, without friction, while the underlying smart contracts on the Internet Computer securely and seamlessly manage creating the underlying Ethereum transactions, removing a key barrier to mass market adoption— more on how Chain Key cryptography makes this possible in a moment!

The Internet Computer will also benefit from this integration. For example, a key purpose of the network is to enable the reimagination of social media running from blockchain in open and tokenized form. This will often involve integration with DeFi, and this will be greatly boosted by direct interoperability with DeFi smart contracts on Ethereum.

So, there can be no doubt that integration of the networks will generate immense value, but how shall it be done?

Stage I

Enabling Internet Computer smart contracts to call into Ethereum smart contracts

The Internet Computer network has been created using something called “Chain Key” cryptography. Without getting into the gory details, this depends heavily on threshold cryptography, in which groups of node machines organized into subnet blockchains collaboratively manage a single “chain key”, which is typically only 48 bytes. Essentially, this is a public key for the chain, and corresponding signatures on your interactions with these chains tell you that (a) the interactions are valid, and (b) the chain is correct.

Complex assemblies of protocols manage these chain keys, which stay the same even when the nodes that make up the chains come and go. No corresponding “private key” exists. Instead, the nodes making up the chain maintain “private key shares” that can be used in some number equal to the “threshold” to generate signatures corresponding to the public chain key. The Internet Computer’s complex protocol architecture has been designed to make management of these keys Byzantine Fault Tolerant, and ensures that chain keys stay the same even when the nodes hosting the blockchain change.

We will now surface this functionality to smart contracts on the Internet Computer blockchain. While the Internet Computer relies heavily upon BLS threshold cryptography (named after Dan Boneh, Ben Lynn, who works at the DFINITY Foundation, and Hovav Shacham) we will introduce support for a threshold variant of ECDSA — the very cryptography scheme that secures Bitcoin and Ethereum balances and smart contracts. In essence, this will enable smart contracts on the Internet Computer to create Bitcoin and Ethereum transactions pertaining to public keys on those chains, without holding corresponding private keys (which will not even exist, and instead take the form of private key shares securely distributed across independent nodes).

To make this simple for developers to use, we will create a special “proxy” smart contract on the Internet Computer, which will make creating Bitcoin and Ethereum transactions as easy as calling a function! That means that smart contracts on the Internet Computer will be able to call the functions of smart contracts on Ethereum.

At this stage we should note that threshold ECDSA is not at all efficient, and would be completely unsuitable for general usage within the Internet Computer blockchain’s protocols. However, the Internet Computer blockchain runs efficiently, and the cost in cycles consumed involved with creating transactions on Bitcoin and Ethereum will still be relatively tiny compared to the transaction fees that must be paid on those networks. Thus, even though constructing the signatures on Ethereum transactions will be very computationally expensive, the cost shall not be a concern.

Now, we must consider how the results of calls from the Internet Computer to Ethereum will be returned, and how smart contracts on Ethereum will call into smart contracts on the Internet Computer.

Enabling Ethereum smart contracts to call into Internet Computer smart contracts, and Ethereum to return results

We cannot use fancy cryptography to solve this problem, but thankfully a sound Stage I solution can be provided relatively easily.

Given knowledge of the current hashrate of the Ethereum network, it can be seen what blocks are valid just by checking how embedded they are by “proofs of work”. That is, if community relays copy new Ethereum blocks into the proxy contract on the Internet Computer, that contract will be able to detect when a block has been finalized with sufficient probability by looking at how much work embeds it within the chain. Once the contract can see that a block has been finalized, it can scan the block for calls from Ethereum smart contracts to Internet Computer smart contracts, and the results of previous calls in the other direction. The proxy will then invoke smart contracts on the Internet Computer, and return values to smart contracts that previously called into Ethereum. Naturally, of course, smart contracts on Ethereum will also call in to smart contracts on the Internet Computer via another proxy contract on Ethereum. Simple!

What Stage I can and cannot do

This relatively simple architecture, which is enabled by Chain Key, is already very powerful. End users interacting with web experiences served by smart contracts on the Internet Computer can trigger calls to Ethereum, and the results can be returned to them. Moreover, smart contracts on Ethereum can make calls to smart contracts on the Internet Computer, which might perform computationally complex tasks for them, and maintain and process large volumes of data on their behalf. This is achieved without any need for a blockchain hub, oracle or other intermediary. All kinds of things will become possible.

However, there is one area that will need to be improved. Smart contracts on the Internet Computer will only be able to display to end users that data from Ethereum that Ethereum smart contracts have pushed to them through function calls invoked via the proxy. While this is workable, it remains the case that making any function call on Ethereum is very expensive — in the tens of dollars, while making a call on the Internet Computer costs only tiny fractions of a cent. This fails to grant Ethereum smart contracts the full benefits that can be provided by the efficiency of the Internet Computer in all cases. To address this last piece, we must progress to Stage II.

Stage II

To make the data and functionality of Ethereum smart contracts available to Internet Computer smart contracts at near zero cost, we must maintain a copy of Ethereum’s current state within the proxy contract(s). That is, the proxy contract must not only scan finalized Ethereum blocks for transaction data, but also use the blocks received to maintain and update a copy of Ethereum’s full state. Once this is done, Internet Computer smart contracts will be able to make calls to Ethereum smart contracts that do not modify their state (such as a call to an Ethereum smart contract getter that just returns some information, or performs some statistical analysis say) at near zero cost. In essence, it will be running an Ethereum node inside contract(s), in much the same way Infura nodes running on AWS maintain copies of Ethereum state today.

Stage II is a more complex undertaking, and will take substantially longer, not least because Internet Computer smart contracts (“canisters”) can currently only hold a maximum of 4GB of memory pages, and so the Ethereum state will have to be sharded across multiple contracts. Nonetheless, the advantages provided will be enormous, and so it should certainly be done if possible — some Ethereum devs have already been looking at implementing this, and made some headway in code.

A last note is that a messy shortcut is possible, which would involve enabling Internet Computer nodes to talk to Ethereum nodes, so that they can provide a low cost bridge for querying Ethereum state. The challenge here is that this would involve trusting whoever ran the Ethereum nodes that the network interoperated with, which provides far less security than when only smart contracts are involved. If someone can think of a way of improving the security, this might conceivably provide a Stage 1.5 solution however.

Summary

Many of us have already given our lives over to blockchain. But this endeavor is still young, and we cannot rest in our quest to make blockchain more powerful, and solve the challenges standing in the way of mass adoption. Blockchain is the new internet. We must enable all systems and services to be rebuilt and reimagined on blockchain. This will drive a wave of innovation, growth, opportunity, and social freedoms, and provide new ways of doing things, many of which are difficult to imagine even now, which will be comparable to, or even far exceed, those resulting from widespread adoption of the internet, a public network that unites us all. We must push past the challenges of usability and cost, and unleash network effects of the like rarely seen on a global scale. A great first step will be ensuring that the Internet Computer and Ethereum can function similarly to a single network, providing the benefits of their relative strengths within both networks — an integration that could prove transformative.