Compatibility Hub for Polkadot

Tech Talk
1

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:

Contact

If you have questions regarding this project or would like to discuss collaboration, you can:

3 Likes
2

Update 2025-07-20

Naming

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.

1 Like
3

Update 2025-07-25

Offline witness data

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.