Replies: 1 comment 2 replies
-
|
@sorpaas would you have a pointer with some additional information regarding the wrapper block strategy (issue # or something). |
Beta Was this translation helpful? Give feedback.
2 replies
-
Beta Was this translation helpful? Give feedback.
-
|
PureStake not include to substrate 3.0 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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-primitivesandethereum-types. Both provided basic integer types likeH256andU256. Another example wasparity-common/trieandparitytech/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-contractsfor the contract storage support.The other issue, code unification, basically involved many refactoring work. To unify
substrate-primitivesandethereum-types, we created a library calledprimitive-types, and make both ofsubstrate-primitivesandethereum-typesdependent on it, so that things likeH256andU256became sharable. The code ofparity-common/trieandparitytech/triewas 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-ethereumandrpc-ethereum(now calledfc-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
web3RPC 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-evmruntime 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-ethereumandfc-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
GenesisConfiginpallet-evm, you can import the necessary Ethereum state into a Substrate blockchain.Interoperability with the rest of Substrate
In
pallet-evm, we provided adispatchprecompile 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-evmitself is simple enough, adopting the full Frontier suite includingpallet-evm,pallet-ethereumandfc-rpcstill 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.
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
pallet-evmruntime module.Beta Was this translation helpful? Give feedback.
All reactions