We would like to open this thread to publish our regular updates regarding Compatibility Hub for Polkadot.
Definition
Compatibility Hub is a series of Polkadot system parachains and JAM services that provide full compatibility for smart contract execution of other blockchains, such as Ethereum, Solana, Cardano, etc. For example, the Ethereum sub-project of Compatibility Hub provides full Ethereum-compatibility on Polkadot.
Background
For background of the project, please check the following threads:
We refer to the project as “Compatibility Hub for Polkadot”. We mainly chose between two names – “Polkadot Compatibility Hub” and “Compatibility Hub for Polkadot”. We decided on “Compatibility Hub for Polkadot”, for the following reasons:
It allows for shorter name when referred to inside the Polkadot ecosystem – simply as “Compatibility Hub”.
We can later add prefixes to differentiate “Ethereum Compatibility Hub for Polkadot”, “Solana Compatibility Hub for Polkadot”, etc.
Plan
For Ethereum sub-project, the Compatibility Hub consists of two stages:
First, we develop a proof-of-concept that is capable of importing the entire Ethereum blockchain, and we’ll demonstrate it on a Polkadot testnet. For this stage, we do not yet provide Ethereum RPCs, and it’ll be purely about runtime execution importing.
Second stage, after the on-chain part works correctly, we then adding back Ethereum RPCs.
In the next few months we’ll be talking with parachain teams as well as JAM teams to make sure our plan is a coherent design that will both work on Polkadot and the JAM upgrade.
We’ll be working extensively with existing parachain teams to ensure that whatever we do, it’ll be collaborating with the ecosystem, and not end up with a “Polkadot Hub vs. Moonbeam” situation.
Notes on Revive
We have reviewed the revised Revive design (this time with EVM interpreter), and we still believe it’s bad (some parts even worse) both security-wise and ecosystem-wise. There are still a few hard decisions (but really important ones) requiring pivoting that they have not yet dared to make. It’s however not our job to keep providing reviews for it. For those concerns, we have already shared them privately with relevant ecosystem shareholders.
Because our current goal for the stage is really clear (“importing the entire Ethereum blockchain into Substrate”), we can do test-driven development from the very beginning. The first step is to extract Ethereum block and state data offline, in the format of block + witness.
At this moment the plan is to do simple block batches and store on disk in plain JSON. This is because during the actual importing in testnet, this part won’t be subject to any performance bottleneck. In Ethereum, average witness data size is around 600-2200 kB, and code accessed is 200-700 kB. In RelayCore we don’t use the actual Ethereum witness, but the Substrate PoV. Still, the size will be roughly similar. In the end, we can only fit around 2-3 Ethereum blocks in one Polkadot parachain block. This means the reading of the block batches will not need to be fast.
This work will also be useful for CoreEVM on JAM.
Literal change transactions
We’re finalizing the design of what we call “literal change transactions” (LCTs).
Compatibility Hub utilizes a stateless client in a Substrate runtime / JAM service for actual consensus execution. It then feeds the executed result into a modified Reth client (that doesn’t participate in consensus), to give us the best possible compatibility.
On the Substrate / JAM side, we want to make sure we can customize the execution behavior freely. This comes the design of LCTs. LCTs will be an additional Ethereum transaction type, unsigned, which simply contains a batch of state changes. On Substrate/JAM side, the runtime is responsible for generating LCTs. This is verified by consensus. On Reth side, because it does not actually participate in consensus, LCTs are simply imported as is. This allows implementation of custom gas metering rules, precompiles, XCMs, etc, yet requiring minimum changes on the Ethereum side and maintaining maximum compatibility.
At this moment we’re still mainly working on the design. Part of the reasons is that we get other commitments, and part of the reasons is that we think it’s important to get it right before making a choice on the architecture.
In the past month, we have been researching several other already-established EVM/Ethereum-compatible chains (there are a lot of them, and one even already had RISC-V deployed). There is one important trend we are noticing – many of the chains started to reconsider the customization they made on top of EVM, and instead moving more and more back to “vanilla EVM”. This happens, even with teams with sufficient manpower.
We think there are several important reasons for this:
The Ethereum network is now being developed at increased pace. AllCoreDevs of course still suffer from the old problems, but gradually a process is developed, which means now each upgrade contains more and more changes. This makes it increasingly difficult for “non-vanilla EVM” to keep up, regardless of manpower (no one has more manpower than the Ethereum community). Even if we can now keep up, the “prospect” of whether this is always possible in the future is questionable. The Ethereum project is gradually becoming like the browser project (of their maintenance burdens).
Many of the customizations turned out to be unnecessary. There’s no reason to develop customized, complicated precompiles. Most of the features can be easily implemented in vanilla EVM, even with better security (because all the quirks of Solidity is already well understood, but not custom Rust code). Unless for those specific computationally intensive algorithms (for which the Ethereum community is also implementing new precompiles each year), performance is usually not the main concern. There’s also now the general purpose execution layer requests, which can be adopted, instead of precompiles, for async “system” calls. Many times they’re better suited for the situation because it’s specifically designed for it. Of course, those things are only available in the past years or so.
We’re therefore adopting our designs with those new insights. In particular, an “unmodified” Ethereum execution layer is likely our aim. This is a completely different path than Revive / Polkadot Hub – which is more similar to a complete customized re-implementation (than what is advertised of using REVM), because it re-implements all opcodes, gas metering, and even use its own custom call frame. We therefore will try to make our solutions generic so that it will be useful for other ecosystems.
This seems super interesting. I really don’t like the name though, compatibility is fine, but it’s still a bit ambigious while not adding much punch to it.
Probably will be laughed off, but reading through this I came up with: Entanglment Hub, EthEntangled Hub.
Otherwise, Mirror Hub: EthMirror Hub, etc.
Not super serious post, but I feel compatibility is too soft for this exciting project.