Frontier's 2020: year in review

[sorpaas]

Frontier is the Ethereum-compatibility layer for Substrate.

This post serves as a year-in-review for the Frontier project. We briefly discuss Frontier's history, what it tried to accomplish, and what it can do now. We also aim at providing some thoughts on what we're planning to work on next.

2020 and before

Bring Ethereum to Substrate

Frontier project started as an internal project in November 2018. The goal, initially, was to "bring Ethereum 1.0 to Substrate". In other words, it tries to build a complete Ethereum client using the Substrate framework.

The first issue it tried address is multi-trie. Both Ethereum and the Substrate framework stores their on-chain data in a merkle trie structure. Substrate uses an updated merkle trie structure that is different from Ethereum, which makes them incompatible. Multi-trie support in Substrate would allow us to support both native Substrate merkle trie and Ethereum merkle trie.

The second issue it tried to address is to unify some code between Parity Ethereum (now called Open Ethereum) and Substrate. In 2018, Substrate was not yet released, and to allow the code to be developed fast, some base dependency code was copied or rewritten from Parity Ethereum, but served similar proposes (yet incompatible). The primary example was the differences between substrate-primitives and ethereum-types. Both provided basic integer types like H256 and U256. Another example was parity-common/trie and paritytech/trie. Both provided merkle trie structure implementations.

To address the multi-trie support issue, we developed the so-called "child-trie" implementation in Substrate. The assumption was to make the top-level merkle trie structure always fixed, and use native Substrate varient. Then, on top of this top-level trie, we add support for an unlimited number of child tries, which can use different trie variant (including the Ethereum variant), and have their correct trie root hash calculated. Using this method, we successfully calculated the Ethereum genesis block state root.

Over the years, "child-trie" was further developed and used in places like pallet-contracts for the contract storage support.

The other issue, code unification, basically involved many refactoring work. To unify substrate-primitives and ethereum-types, we created a library called primitive-types, and make both of substrate-primitives and ethereum-types dependent on it, so that things like H256 and U256 became sharable. The code of parity-common/trie and paritytech/trie was also gradually finished merging.

Pallet EVM

As an internal project, "bringing Ethereum 1.0 to Substrate" wasn't the mission nor a vision of Substrate until much later. So when Frontier finished addressing the two issues it stated, it became idle, until November 2019.

At that time, we have a much better understanding of what Substrate was capable of, so we decided to add EVM execution capability in Substrate. This resulted in "SRML EVM" (paritytech/substrate#3927) (now called Pallet EVM). This is a runtime module that can be included in any Substrate project. It embeds an EVM execution engine (called SputnikVM) into the runtime, and allows basically any existing EVM smart contracts to be executed, unmodified.

One of the goals for the EVM execution engine was modularity. An issue with EVM is that many of the opcodes are specific to Ethereum's execution environment. In other places, those opcodes may not have a suitable replacement definition. Modularity ensures that the EVM engine can easily redefine all of those non-essential environmental-specific opcodes, and it was one of the reasons why an EVM execution engine in Substrate was possible.

Reinitialization and implementation

In February 2020, with Pallet EVM in place, we decided to go further. As a result, the repo of Frontier was reinitialized and made public. Frontier formally became the Ethereum-compaibility layer for Substrate, with plans of components that it planned and has implemented as of today, pallet-evm, pallet-ethereum and rpc-ethereum (now called fc-rpc).

As the goal is for compatibility on the smart-contract level (instead of on the node level), we made our compatibility goals accordingly. Instead of node-level compatibility, we made web3 RPC compatibility our priority, as that is what most EVM applications directly depend on.

Later in the year, PureStake started to participate in Frontier to build their Moonbeam project. They helped enormously to bring forward many Frontier implementations.

Now

As of now, Frontier can already do a lot of things for you, if you need anything related to Ethereum-compatibility for Substrate.

EVM execution

By using the pallet-evm runtime module, you gain the ability to execute EVM smart contracts in any Substrate-based blockchain implementation. The runtime module is non-intrusive, meaning you can add or remove it at any time without worrying too much.

RPC compatibility

By using pallet-ethereum and fc-rpc, most of the dapps that are on Ethereum can be ported to Substrate, unmodified. Things like Truffle and Metamask will just work.

Importing Ethereum state in genesis

By taking advantage of GenesisConfig in pallet-evm, you can import the necessary Ethereum state into a Substrate blockchain.

Interoperability with the rest of Substrate

In pallet-evm, we provided a dispatch precompile that allows you to configure the runtime module so that EVM contracts can interact with Substrate dispatchables.

2021 and after

Stability, usability and documentation

With most of the basic functionalities done, one of the things Frontier will focus on in 2021 is stability, usability and documentation. We still have many bugs in the code. While adopting pallet-evm itself is simple enough, adopting the full Frontier suite including pallet-evm, pallet-ethereum and fc-rpc still requires many code on the client implementations. We have some documentations right now, but still not yet sufficient enough for new people to get started. Those are things we plan to address in 2021.

We never marked the codebase as stable, or made any release. Nonetheless, we know some blockchain projects started to use Frontier in a semi-production way. As a result, stability is also one of the focus. Many of the data structure and storage changes are indeed planned. However, when we do this, we aim at providing sufficient migration scripts for existing blockchains to update.

Wrapper block strategy

Wrapper block will make it possible for Substrate to host most of the other block-based blockchains out in the wild, even if they don't have Substrate in mind for their designs. For Frontier, the wrapper block strategy also brings many benefits compared with the existing partial-information strategy used in Frontier's consensus layer.

• On one hand, by making the wrapper block pre-runtime, we would be able to import an existing Ethereum-like blockchain to Substrate. This allows either a blockchain migration (from an Ethereum node to a Substrate node), or block pinning for bridges.
• On the other hand, by making the wrapper block post-runtime, it allows the Substrate runtime to process and generate an Ethereum block for subsequent processing by the RPC, for indexing and other purposes.

The goal for us is to implement the post-runtime wrapper block first, as a replacement for the existing consensus layer. We then add support for pre-runtime wrapper block to support other use cases.

Towards a full Ethereum node

One of the initial goals when the Frontier project was started in 2018 was to make it possible to become a full Ethereum node. With wrapper block in place, this goal becomes possible. It is one of the ultimate way for an Ethereum-like blockchain to update easily, and adopt new functionalities like forkless upgrade and on-chain governance. An Ethereum-like blockchain, if with a Substrate node in place, is only a simple hard-fork away from enjoying whatever new feature that is possible in Substrate, while persevering all existing data and all API compatibility.

Known projects using Frontier in 2020

• PureStake is using Frontier to build the Moonbeam, an Ethereum-compatible smart contract parachain on Polkadot.
• Acala network uses pallet-evm runtime module.
• Ellaism, an Ethereum-based blockchain, is considering building a full Ethereum node based on Frontier, as a migration path to Substrate.

[adoerr]

@sorpaas would you have a pointer with some additional information regarding the wrapper block strategy (issue # or something).

[JoshOrndorff]

https://corepaper.org/substrate/wrapper/

[lwb1234]

PureStake not include to substrate 3.0