Frontier roadmap for 2024 and onwards

[sorpaas]

Frontier will soon enter a new chapter! While the current "Parity Decentralization" effort does not affect Frontier, I have expressed my desire to Parity leadership to gradually move Frontier into an independent project in the next few years. This way, Frontier can have a much clearer incentive as it works directly for its users (EVM parachains), and over the long-term we can also possibly have more dev time.

A short survey has been sent out to several EVM parachain teams. I really appreciate everyone's feedback on this and thank you everyone who has responded so far! If you want to see the survey questions but haven't received anything, I'm sorry! -- please contact Wei (@wei:parity.io or @wei:pacna.org) and I'll send you a copy.

With a new chapter, we'll also need a new roadmap. Below are the current draft roadmap of Frontier for 2024 and onwards.

Maintenance

We'll continue on with the work on maintenance. This includes supporting new versions of Substrate, responsible disclosure procedure and publishing security advisories, refactoring and regular auditing. As the codebase becomes mature, we'll also be spending a little bit more time in responding in our issue tracker.

Profiling and benchmarking framework, EVM performance

We'll develop an easy-to-use executable in the EVM engine repo, for profiling and benchmarking of large contracts. We aim to understand any still-existing bottlenecks in the EVM engine, and further improve its performance.

Sandboxing

We'll develop a second sandboxed runner that users can optionally use for improved security. We utilize the WebAssembly-in-WebAssembly feature in Substrate. The EVM runner is first compiled to a WebAssembly binary, and then we execute that binary in runtime, instead of using the EVM runner directly. The benefit of this is that any bugs in the EVM engine (for example, uncaught
panics) won't affect the outer-layer chain. However, the performance will be inevitably slower.

Standalone RPC layer

We'll develop a second, less "intrusive" method to include Frontier into a Substrate project. Currently, one has to import the whole Frontier stack completely -- runtime changes and client changes. Having a standalone RPC layer means those two changes can be included independently. The runtime change of Frontier can be imported "clean". Then a separate, standalone RPC client will talk with the node using Substrate RPCs and maintain the mapping database.

EVM compilance and compilance testing

We aim to completely integrate the Ethereum testing framework into the EVM engine. Currently, we already integrated the majority portion of it. However, in real world testing, we still find issues with EVM compilance. We therefore aim to integrate it fully, to make it possible to have the option of full compilance, for those chains that really need it.

Integrated testing

We aim to reduce the amount of TypeScript testing code currently in the codebase. For maintainability, if we can find ways to write certain parts in Rust, then we'll move them to use Rust. We'll also add a few integrated testing cases using real-world contracts.

Pre-log wrapper block support

From our experiences talking with some teams willing to migrate their chains to Polkadot, we find that in certain cases, pre-log wrapper block is still beneficial. A pre-log wrapper block allows one to put a complete, ordinary Ethereum block into the pre-log, and Frontier will then finalize the state execution, just like in Ethereum. With proper engineering, this will even allow Frontier to pretend to be just an Ethereum node, joining an existing network.

The main use case of this is zero-downtime migration. For an Ethereum chain, one can continously feed existing block data into Frontier, one-by-one. The state on the Ethereum chain and on Frontier is the same (assuming full EVM compilance). A production network can thus switch RPC endpoints (except eth_submitTransaction and eth_submitRawTransaction) from the Ethereum chain to Frontier, without anyone noticing. After all RPC endpoint switches are finalized, the network is migrated, with zero downtime, pending a final runtime upgrade to allow extrinsic inputs on the Frontier side.

Migration toolchain

In regards to Ethereum blockchain migration to Polkadot, besides supporting migration through wrapper block, we'll also create better toolchains for other migration methods including state migrations, and transaction-level migrations. Currently those migrations are possible, but a large amount of efforts for customized migration code is needed. The goal is to eliminate the needed efforts as much as possible.

Solidity interface generation for FRAME pallets

If one properly writes the precompile interface for a FRAME pallet, then deep interactions, even faking a WebAssembly pallet as an EVM contract, is already possible. We first aim to properly document the procedure to do that. Secondly, we aim to create a Solidity interface generator given a compatible FRAME pallet, to make the interface even easier to use.

Documentation

We'll continue to work on improving Frontier documentations.

Releasing

With the releases of Substrate onto crates.io, we'll soon restart releasing Frontier on crates.io. We also try to figure out strategies to make upgrading dependencies as painless as possible.