Last week we opened the discussion on Polkadot forum about the idea of Polkadot Compatibility Hub. After talking with another team working on JAM, I realized that this new design actually has a lot more benefits than I thought about, especially regarding future upgradability and “100%” compatibility. I think this is also relevant to Moonbeam’s future roadmap, so I would like to open a discussion post here, and am looking for comments and feedback.
Design
Below we only use Ethereum as an example. But note that Compatibility Hub is designed to be generic that the same concept can be used for other chains – Cardano, Solana, etc.
The essence of the Compatibility Hub is basically a stateless client in runtime. It’s carefully crafted with the following requirements:
- State should stay available in Polkadot 1.0. This ensures that there’s no disadvantage in runtime when EVM contracts need to interact with other pallets or XCM. We don’t have such limitations in JAM, which we’ll also talk about below.
- There shouldn’t be extra storage requirements. This means that we don’t do Ethereum stateless proofs (but only Polkadot PoV) in Polkadot 1.0, and we switch to Ethereum stateless proofs in JAM.
- We should reuse things from Ethereum as much as possible, reducing development time and cost. This means that for things like transaction pools, RPCs, etc, we just directly run a (modified non-consensus) Reth/Geth client.
The Ethereum Executor
The Ethereum Executor handles all Ethereum transaction execution logic and validate Ethereum blocks. You can think of it as a Substrate runtime, but with much more limited API.
- Exported function:
validate(block) - Imported function:
get_state,set_state
The executor does not handle any merkle trie related thing, but simply pass them down to the host.
Polkadot 1.0
In Polkadot 1.0, we use the wrapper block strategy. Each Substrate block in the Compatibility Hub is required to have one unsigned extrinsic which is an Ethereum block. An Ethereum Executor is included in the Substrate runtime, and it’ll handle validating that Ethereum block. The resulted state, through the imported function get_state and set_state, is written to the Substrate state.
Note that in Polkadot 1.0 we don’t write or validate the “state root” of the Ethereum block. This is validated on the Substrate side anyway and the merkle trie format is different.
JAM
When upgrading to JAM, the entire Compatiblity Hub becomes a native JAM service. We reuse what we already have of the Ethereum Executor. This then becomes an actual stateless client with merkle proofs. The executor is then put into JAM’s refine and we just finished “CoreEVM”!
Ecosystem Tools
You may have noticed that in the above I did not talk about RPCs, transaction pools or other ecosystem tools. This is a main advantage of the design of Compatibility Hub – we create a non-consensus Geth/Reth node. Therefore we get all ecosystem tools we can imagine for “free” with 100% compatibility.
What we do is actually simple: the Geth/Reth node still function as normal, but with consensus and state root verification disabled. It then follows the Substrate node, and simply import that Ethereum block in the unsigned extrinsic.
A collator will also use a Geth/Reth node for authoring so we don’t need to rewrite a transaction pool or deal with any Ethereum specific problems. Note that for consensus reasons, the Geth/Reth node strictly only make “recommendations” and the actual authoring is only handled on the Substrate side. This means that in the worst case scenario if the Geth/Reth crashes or we have other consensus problems, a collator will simply put in an empty Ethereum block when authoring. There will be no chance of a “chain crash” due to problems on the Ethereum side.
In JAM, it’ll be even simpler, and we reenable state root verification.
Discussions
As I write more about the specification, I find the design attractive in several aspects. It’s future proof, it can easily work with native JAM (but not just a “Substrate-compatibility layer” of Polkadot 1.0). We get full compatibility, this time both state and ecosystem tooling.
Another main advantage is that this design is easily adopted to work on other blockchains. So we can have a Solana-compatibility layer or Cardano-compatibility layer if we want. It may also have special strategic values for Moonbeam since last roadmap discussion if it ever wants to expand operations to other ecosystems.