Besides what has already been said, there was indeed a related thought experiment in the past exploring the flexibility of Substrate framework. We know Ethereum block structures vs Polkadot/Substrate are vastly different. There are different encoding strategies, different block processing rules and different consensus. Still, would it be possible to write an Ethereum node using purely the Substrate framework? Once we have that, then upgrading Ethereum mainnet to Substrate would just be a simple hard fork away (which is no more complicated than just a Substrate runtime upgrade), and we have accomplished our goals.
We find this possible, using a design called wrapper block. What we're doing is basically to re-group an Ethereum data structure while maintaining the original sealing. In this particular case for Ethereum, all Ethereum transactions are mapped onto Substrate extrinsics. We map one or several additional inherent extrinsics for the uncle headers, receipts, coinbase, miner seals, as well as other information in the original block. The block processing strategy is then as follows:
- In runtime, we validate transactions using
pallet-evm
and pallet-ethereum
, and check information such as gas limits, receipts, uncles.
- In consensus, we re-build the original Ethereum block from the Substrate block (because information are one-to-one mapped), and using that Ethereum block to verify the miner seal.
The deployment then becomes unobtrusive. This new Substrate node will be built just as another Ethereum client. In the beginning, we run another Ethereum client alongside of this Substrate node so that we don't need to re-create the devp2p networking protocol. This Ethereum node is then responsible for feeding all the past block data into the Substrate node, which it will happily convert into the wrapper block discussed above (using the one-to-one mapping). The Substrate node will contain its own, newly developed genesis code, with all Substrate-specific modules disabled. This allows it to sync together with the mainnet, and even exposing Ethereum-specific RPCs. Once the time comes and the community reaches consensus, only a runtime upgrade is due to enable those Substrate-specific modules. This will cause the Substrate node to de-sync from Ethereum client in the activation block, and enable access to things like on-chain governance. The upgrade is then complete.
Due to obvious reasons, the full wrapper block strategy was never (not yet?) fully developed. This does not mean it's abandoned, but just there are currently not enough interest in it. In Frontier, you can find those "architectural holes" we left in the code (for example, pre-runtime transaction processing) allowing us to quickly extend it if one day we decide to support a full wrapper block design.