Polkadot, Substrate and Ethereum
Ever since the release of the Polkadot paper three years ago, we knew that bridging with the Ethereum ecosystem to help extend capabilities on either side would be one of the key points of the network. This has not changed. Of course, “Ethereum” means many different things in various contexts largely dependent on intention and strictness. Few would argue that whatever the usage, Ethereum wouldn’t refer to at least the current “ETH mainnet”. However, some would assert that it would mean this to the exclusion of any other networks, even those “officially” sanctioned.
In other instances it includes officially sanctioned (as per the owner of the Ethereum trademark) follow-on projects/networks/forks, such as Shasper. Some would also include “non-canonical” forks such as the original “Classic” chain under the Ethereum banner, yet there are those who would oppose it.
Some such as the Ethereum Enterprise Alliance industry group, or as is typical in Ethereum-development groups, would consider “Ethereum” a much wider concept. This view would include any technology based on, or compatible with, the original execution engine of Ethereum — the EVM — and its associated developer tooling; Ethermint, Hyperledger Burrow, and various Parity-PoA networks, to name a few.
In any case, Parity is as committed as ever to supporting and bridging “Ethereum”, however it is intended, into Substrate and Polkadot. While we are creating Substrate and its associated smart-contract infrastructure to be the world’s most powerful and joyous framework for creating new blockchains and dApps, we absolutely understand that there are many who enjoy their home in Ethereum ecosystem, be it the mainnet or simply the wider development community. We are committed to doing our utmost to support these teams as they build and interconnect.
Our commitment takes three distinct projects, which I’d like to take some time to explain; a Polkadot/Ethereum public network bridge, a Substrate/Parity-Ethereum-PoA bridge and an Ethereum-compatible EVM smart-contract execution module in Substrate.
Polkadot/Ethereum Public bridge
The first is essentially the piece of software postulated in the original Polkadot paper, back in 2016. The idea is to have a smart contract on the Ethereum mainnet chain which stays synchronised to Polkadot’s Grandpa finality gadget, being a sort of “ultra-light-client” for Polkadot. This facilitates a very general level of interoperation, primarily for the native token of the Ethereum chain and pre-existing contracts that provide key pieces of functionality otherwise unavailable in Polkadot.
Technically speaking, this smart contract is able to analyse new blocks (specifically the ones that contain messages destined for Ethereum) and forward them on into the Ethereum chain. A Polkadot parachain would include an Ethereum “light-client”, able to check its PoW consensus system and interpret smart contract receipts and thus forward messages from Ethereum into the Polkadot network.
There are obstacles to this, primarily the prohibitive price of gas for non-native crypto on the Ethereum mainnet. Some early efforts are already underway on creating such a piece of infrastructure (like ChainX). However, to work properly and without an additional validator/staking economy, this will need additional support from Polkadot, specifically by having its validators be required to make finality proofs available in formats native to Ethereum. The Web3 Foundation is actively researching and specifying the design for this and grants are available to teams (including but not limited to Parity Technologies) who wish to pursue implementing the outcome.
Substrate/Parity-Ethereum-PoA bridge
For some projects however Polkadot/Ethereum interoperation is less important since they will be unable to deploy to the mainnet (due to scalability issues) anyway. Despite not deploying on the Ethereum (1.0) mainnet, these projects nonetheless prefer to remain strongly compatible with the Ethereum ecosystem for a multitude of factors including the active and vociferous community, developer tooling, support and documentation, along with the multitude of service providers available. At the end of the day, the network is in the coveted position where “nobody blames you for choosing to write your contract on Ethereum”, and this is something that we both respect and take pride in for our part of its creation.
In order to support this outlook we will introduce a Substrate to Parity-Ethereum-PoA bridge, very similar to our existing Parity Bridge that sits at the heart of the xDAI chain. In this case, rather than connecting an arbitrary Parity Ethereum chain to the Ethereum mainnet, it connects one to a Substrate module (and by extension to Polkadot). In this case, the Ethereum-PoA chain would still need to manage its own security (and in this way makes it a not-entirely-dissimilar value proposition to Cosmos’s Ethermint). The Ethereum-PoA chain would use the fast Aura consensus algorithm (or, a slower “instant-finality” PBFT-based consensus) and benefit from the tried-and-tested Parity Ethereum codebase which has years of optimisation and tuning together with various additional enterprise-level features including secret-store integration and contract state encryption.
The infrastructure needed is much simpler in this case: we introduce a special pre-compile contract into the Parity Ethereum codebase which is able to efficiently and statelessly validate a Grandpa finality proof (removing the issue of non-native crypto gas costs). With a bridge contract (to be adapted from Parity’s pre-existing PoA bridge system) and a block forwarder (same), the only additional component needed is a Substrate module which acts as an Ethereum/Aura-PoA light client and can comprehend and forward messages. Work on this project has begun and we expect a prototype by the end of the year.
This project will thus allow any secure private or PoA Ethereum chain built on Parity Ethereum to have full access to a sibling Substrate chain (as an eventual upgrade path) or to the Polkadot community (for using Polkadot’s resources and interoperation with other projects).
Substrate EVM
There are also those projects that love the idea of Substrate and all of the power and flexibility that it brings with it (like off-chain workers, the SRML, extensible transactions, Rust-based smart contracts, metaprotocol-governance, one-click upgrades and more), but yet who need an upgrade path for their existing Solidity codebase which in some cases is really quite substantial. Our own WebAssembly-based Substrate Contracts module and its various tooling including the Ink! Rust-based EDSL is something we embarked on and are committed to for numerous reasons: LLVM’s WebAssembly backend means that many common languages (C, C++, Rust, Go and others) can easily be targeted to Wasm. The multitude of tooling like interpreters and compilers, debuggers, byte code analysers and libraries mean that development is dramatically improved, and with Ink! we get the Rust Language’s testing, documentation and correctness features.
Furthermore, by ditching the five-year-old Ethereum execution model, we can both simplify and speed up the codebase (by getting rid of flawed or overly opinionated EVM opcodes) and introduce economic efficiencies (like separating code-upload to instance deployment and introducing deposit-based state rent) onto the execution environment.
That said, reality dictates that sometimes features, performance and clarity must take a back seat to compatibility. For this, we are introducing Substrate EVM. This is a Substrate SRML module that introduces an Ethereum-compatible execution environment “natively” into Substrate. Essentially, this allows your Substrate chain to host the vast majority of the Ethereum state transition function. Existing Solidity/EVM code can be deployed into this environment. Interoperation with the rest of Substrate (i.e. calling into other modules, transfer to and from other accounts and using interchain messaging features) happens through specially introduced “pre-compiled contract” APIs.
Think of it as a whole Ethereum blockchain inside of a single SRML module, ready to be integrated into the rest of your custom blockchain. A blockchain virtualisation layer, of a sort. Work has begun on this and we also expect an MVP to be ready over the coming weeks.
Furthermore…
We are also increasingly interested in supporting existing efforts into developing a WebAssembly backend for the Solidity compiler that is compatible with the Substrate-Contracts execution model. Properly implemented, this would allow existing Solidity smart-contracts (authored for deployment into an Ethereum chain) to be deployed directly into a Substrate-Contracts chain.
Indeed in this model, nothing stops the same Substrate chain from having both an EVM-Contracts module (for executing origin Solidity/EVM code) as well as a Substrate-Contracts module (for executing Solidity/Wasm or Ink! Wasm code). The two could interoperate between each other and even post messages over to a distinct Parity-Ethereum chain that is bridged in or, if deployed as a parachain, to the wider Polkadot community including the Ethereum mainnet!
Developing and hardening the final core components of Polkadot 1.0 is what we are presently focussed on primarily and as such we cannot always dedicate quite as much developer time to these projects as we would like. That said, Polkadot’s raison d‘etre is in bringing together dramatically different projects with diverse technical assumptions under one roof. The Ethereum community is the foremost developer community on the planet with the freest thinkers and the most meaningful developments — we’d be rather shortsighted to ignore that. Now that, after two long years of development, the core infrastructure of Polkadot and Substrate are maturing, we can really begin to think about building the peripheral parts and make the world of diverse, connected chains a reality.
For more information on Polkadot and Substrate, visit the Polkadot website or Substrate website. You can view the status of the Substrate SRML EVM module at its Github PR or follow the progress of the Ethereum-PoA/Substrate bridge as we build it at the Github repository.
