Solidity smart contracts: Striking a balance between innovating and traction

Ecosystem
1

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:

  1. innovating: bringing greater compute to Solidity smart contracts using PolkaVM, vs.
  2. 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:

  1. Incompatibilities between EVM and PolkaVM.
  2. Differences in gas estimation, and decimals between DOT and ETH.
  3. 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:

  1. 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.
  2. Switching focus to bring out a 100% EVM compatible solution for Polkadot Hub ASAP (to unblock easily porting Eth dApps),
  3. 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.

12 Likes
2

Thanks for the transparency, looking forward to hearing what the next steps are as and when confirmed :slight_smile:

3

Is interoperability currently a consideration for this approach?
More concretely, can a Solidity contract that “chooses/targets PolkaVM” interact with another Solidity contract that “chooses/targets EVM”?

5 Likes
4

Is there a clear plan on how this porting process (EVM => PVM) will look like, and are there any limitations to this? For example, will it be possible to easily port state, balances, etc. along with the actual re-deployment of the smart contract code?

Beacuse if we don’t have a clear plan on that, we risk further fragmenting the landscape.

5

I’m happy that Parity has finally come to its senses. A lot of opportunity costs and damages to the ecosystem have already done (especially as previously OpenGov was voting against all other alternative solutions because of revive “the only Ethereum-compatibility solution moving on”).

It’s important that we don’t make another bad choice again for political plays.

3 Likes
6

I’d like to hear the pitch that convinces me that allowing the deployment of this “high value apps”(in other ecosystems) is going to translate in a guaranteed inflow of users in Polkadot. Otherwise it’s just making everything more complex, confusing and creating division with two silos. It’s very important that @davidsemakula’s question gets answered or I’ll just read the whole thing as we are deprecating revive before launch because it doesn’t work as expected. With frontier around I don’t see a reason for people to deploy solidity stuff in revive, it’s not like it’s going to be any better.
Since the high value protocols won’t care about Kusama, I’ll just pass on this opportunity and nay the relevant ref when it comes :wink:

2 Likes
7

It is also important to note that in some cases the PolkaVM bytecode size can even overshoot to 80x the size of its equivalent EVM bytecode. This could make the solution impractical if future improvements to the compiler cannot decrease the final bytecode significantly.

8

100% yes. PVM and EVM contracts will be able to call each other.

3 Likes
9

I’d like to point out that the resolc compiler is currently in an MVP state. So far we had the chance to implement only the most basic size optimizations yet. For example 64bit RISC-V support and some basic function outlineing were quick to implement and together more than halved down the baseline contract size.

Moving forward, for resolc we will:

  • Analyze contracts exhibiting especially bad code size expansion factors and fix the root causes. Actually it looks like most contracts exhibit less than 10x size overhead (for example pure OpenZeppelin and LayerZero contracts). As far as I can tell, 40x - 80x are not common cases. Thus I’m confident that we can fix this.
  • Start to implement custom optimizations in resolcs YUL pipeline. Possibly implementing our own YUL dialect or augment it with PVM verbatim instructions. By looking at the YUL code solc produces and what resolc translates it to, without looking for too long, we can see a lot of unrealized optimization potential. Quantifying this is hard but I definitively expect to shrink the baseline code sizes significantly again.
  • Replace solc as our Solidity language implementation with a custom frontend (similar to what Solang did) in the long run. Also add am MLIR layer to the compilation pipeline. This opens up whole areas of further optimizations.

However this requires time. By deploying an EVM interpreter we can buy this time.

I’d like to thank you and everyone else trying out our new stack and reports any problems pre-launch!

2 Likes
10

What is the plan for the decimal difference? Masquerade as 18 decimals in the EVM?

Also curious why these issues weren’t surfaced much earlier on in this campaign. We could have deployed revm last year and had a working product already.