TL;DR
We found some challenges porting high-value applications built in Solidity to PolkaVM. Therefore we are considering deploying an EVM stack on Polkadot Hub as soon as possible after launching the preview version of our Ethereum-compatible PolkaVM stack on Hub, so that we (Parity, W3F, and BD partners) can ramp up traction (i.e. liquidity, users, and developers) as fast as possible. Then we will return Parity’s focus to delivering the feature-complete, highly performant PolkaVM stack, and to encourage the innovation that will be possible only on Polkadot with the increased traction that should already be achieved by then.
Background/Context
Now that the first part of our Ethereum-compatible PolkaVM release is available for testing and we have initial feedback, we have reached a decision point in the roadmap. Currently between Parity and the W3F we are discussing how best to balance:
- innovating: bringing greater compute to Solidity smart contracts using PolkaVM, vs.
- increasing traction (i.e. TVL, etc.): easily porting across high value Eth dApps, especially in the DeFi market segment.
Issues
In building the Ethereum compatibility layer on PolkaVM (part 1 of preview version released on Kusama last week) we have learned with the help of the Polkadot BD ecosystem about the types of issues that complicate porting dApps from EVM:
- Incompatibilities between EVM and PolkaVM.
- Differences in gas estimation, and decimals between DOT and ETH.
- Bytecode size differences.
For the first, especially the Solidity and YUL translation incompatibilities, we think we can progressively simplify the porting of apps, including using tooling, e.g. Hardhat and Foundry. We have designs to address the second point.
However, the third requires more consideration. While we have mitigations in the pipeline (i.e. a new memory allocator and other low hanging fruit) to allow executing larger bytecode contracts, we think that significantly decreasing the resulting bytecode size will require a longer term investment in improving the compiler.
This means that especially these resulting larger bytecode sizes of smart contracts (8x to 10x larger on average) is a short to medium term risk to port Eth dApps, because some contracts are too large to deploy. I.e. our current approach poses a time-to-market risk in porting Eth dApps.
As stated at the start, we are trying to strike a balance between innovation (developing new technology) and increasing traction. And, if you are pushing innovation, as we are with PolkaVM, there is always learning involved, and, based on what we’ve learned, we think we need to adapt our plan.
Path under consideration
We are deliberating how we can decrease the time-to-market for easily porting Eth dApps. Our current thinking is:
- Completing the preview version of PolkaVM (ERC20, basic XCM precompile, gas mapping, corrections for the decimal differences between DOT and ETH, memory allocator and other optimizations to allow larger contracts)
a. on Kusama Hub at least, and
b. on Polkadot Hub, but only if we can find a valuable use case. - Switching focus to bring out a 100% EVM compatible solution for Polkadot Hub ASAP (to unblock easily porting Eth dApps),
- Then refocusing on the PolkaVM stack, especially
a. implementing the JIT (which should unlock more compute that EVM), and
b. improving the Solidity compiler (to result in smaller bytecode sizes).
For #1, we can still launch ERC20 and the basic XCM precompile in late September, and we think we can follow with the rest (new memory allocator and other optimizations) in late October or early September.
An example of a valuable use case (#1.b) would be enabling our parachains to trade their tokens more widely. Which would only be valuable if we can do so fast, else, it is more valuable to focus on #2 rather then #1b. We are considering this cautious approach, because while Kusama is more adventurous (“expect chaos”), we only deploy what is rock solid and reliable on Polkadot.
For both #1 and #2 we need solutions for at least (a) gas estimation, and (b) corrections for the decimal differences between DOT and ETH (designs are near to being finalized). Furthermore, we are actively looking at how to deploy a 100% EVM compatible solution on Polkadot Hub as soon as possible, and we will share a timeline as soon as we have one.
Devs can choose between EVM and PolkaVM
As part of the above approach, dApp developers will be able to choose whether they want their Polkadot Hub Solidity contract to run on EVM or PolkaVM. Thus developers of existing Eth dApps can choose EVM initially to make the porting trivially easy, but as we progressively hide incompatibilities with tooling and unlock more compute via PolkaVM, those developers can choose to retarget PolkaVM to make it cheaper for their users and save on infrastructure (e.g. to compute heavy loads, such as zk proofs, onchain instead of offchain).
Users, developers, and liquidity ASAP
This approach means we can start accruing users, developers and liquidity on Polkadot Hub as soon as possible, so that when the feature-complete, highly performant PolkaVM version is completed, we already have the traction (i.e. users, developers, and liquidity) to encourage the innovation that will be possible only on Polkadot.
Next steps
As we clarify our thinking over the next week(s), we will get back to you as soon as we have a new agreed-upon direction.