With the aftermath of Revive, I’ve been in discussion with several community members on how we may get out of the current situation.
We’re in a rather awkward situation. Due to incompatibilities and other issues, if we want to follow through with the plan of “Ethereum-compatibility on Polkadot Hub”, then we’ll have to launch an EVM interpreter. Yet, Revive was originally designed with every bits against this. The interpreter addition will therefore have to be added as an afterthought of the original design. On top of this, Revive made several decisions (not sure if deliberately or not) incompatible with Frontier. This means almost nothing can be reused from the Frontier project (so none of the lessons Frontier learned over the past 5 years), and Revive team’s only choice would be to integrate the revm interpreter and do everything from scratch. Unless we rush it really hard (which is a really bad idea due to security bugs and hacks), the development, testing and audit will take at least 6 months. This means that the time-to-market has already effectively lost. And the result would not really be better than existing Polkadot parachains, or any other Ethereum L2s already on the market.
Therefore we probably have no choice but to pivot. If things have to take longer anyway, then we may better use the time to design something that is actually great and attractive, in hope of finding actual market fits.
Here I present you a (draft) idea of Compatibility Hub(s).
Compatibility Hub(s)
This comes from a rather old idea in Frontier when we were designing Wrapper Blocks. The goal is to have a generic setup that can process a “foreign” block format and process the state in Substrate. The original objective was actually about migrating a full Ethereum blockchain over to Substrate (yeah you heard it right!).
With the Wrapper Block strategy, we can simply take a full Reth client, stripping all consensus, networking and merkle trie storage, and just create a compatibility chain (with possible Substrate additions like XCM). And this will not be limited to just Ethereum, but can also apply to other smart contract platforms like Cardano and Solana.
This comes to the new Compatibility Hub(s) strategy:
- Polkadot Hub will purely focus on ink/Rust smart contracts. The time-to-market is already lost anyway and it’ll actually be much better if we don’t introduce Ethereum debts.
- We develop a generic Chain API (actually similar to Avalanche’s “VM” strategy). This generic Chain API is processed by a Substrate pallet using the Wrapper Block strategy.
- We’ll need to strip an Ethereum/Solana/Cardano node and fit it in our Chain API. We then compile that node into Wasm/PolkaVM runtime. This will still require some work but is already simpler than what we’re doing, and is repeatable for other blockchains.
- We’ll launch one or several Compatibility Hub(s) for Ethereum/Solana/Cardano.
Advantages of this:
- We’re not limited to just Ethereum compatibility. We can also have Cardano compatibility, Solana compatibility, etc.
- The knowledge of process is transferable, meaning, once we launched one Compatibility Hub, launching the next Compatibility Hub will become significantly easier. This includes any security lessons we learn along the way.
- In the long term we have less maintenance costs. At this moment we must still manually follow chain upgrades.
Notable Mentions
JoshOrndorff and Rodrigo_Quelhas had the idea of using Engine API. We actually cannot directly use Engine API (Ethereum post-merge really functions more like two blockchains combined, rather than a single blockchain). However, the direction is similar.