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.

16 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”?

6 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.

1 Like
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.

6 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:

3 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.

5 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.

1 Like
11

Just had a thought how we can potentially even go below EVM bytecode sizes with PVM contracts and resolc. For example an ERC20 which compiles to 4kb EVM code size (currently 18kb PVM) could be around just 2kb of data. I’ll try to make a working PoC.

1 Like
12

BD teams like https://www.velocitylabs.org/ or https://magentalabs.io/ are actively talking to various projects that ultimately have the customer base or promising projects to bring more liquidity and users into our ecosystem. Most of the time, the projects share a list of dependencies or partners they are used to working with, e.g., Etherscan, Wormhole, Safe Smart Contracts, Oracles like RedStone or Chainlink, Compliance Solutions like Elliptic/Chainalysis/Merkle Science, etc. If these partners are unavailable in a specific ecosystem, they often don’t even consider deploying or integrating into this particular ecosystem, simply because various other ecosystems have existing integrations by these “high-value apps”/projects and developing new custom solutions and integration with other partners would mean an additional security risk and addtional overhead/costs.

For me personally, this shows the importance of network effects in this space and, sadly, also again that many end users don’t care much about decentralization.

3 Likes
13

In my opinion it would be better to just postpone the deployment until the targeted Ethereum-compatible PolkaVM stack on Hub is fully ready and more performant than other EVM platforms. If it turns out theoretically and practically impossible, then it might be preferable to just shelve the project, but I’m confident that the team will find a way to make this work. A stopgap solution sounds like a retreat, and would cause further issues of segmentation and later, migration. I also find it unfair to the parachain(s) who have been offering the solution for years.

2 Likes
14

I understand, if there’s a real promise of said protocols deploying and bringing their users to Polkadot I see why the interest and that could make sense for Polkadot.

From the perspective of a Kusama builder however, I’m betting more on innovation, bring new users because we build great things of value that are not possible elsewhere, I don’t think Kusama has the rush to desperately re-deploy existing protocols with the naive hope users will come, so I hope Parity doesn’t try to push Frontier to Kusama where Revive is already live, I doubt Velocity or Magenta are pushing to bring the same protocols and users to Kusama, so Frontier there would become just bloat or a source of divide and confusion.

I’m biased as personally I have no interest in Solidity contracts(only ink! ;)), I arrived to this ecosystem because of Rust and the potential to do things other existing ecosystems couldn’t, so my suggestion, what if Kusama keeps revive to keep pushing for innovation as it’s meant to do, and Polkadot gets frontier(on top of revive?) to attract the high profile projects that will save us?(:thinking:)
Ink! has already spent a considerable effort porting to revive compromising in the process to fit the EVM model, it would be likely and ironic if solidity devs end up deploying only to Frontier leaving Revive only for ink!, so let’s better not mix the two, Solidity devs can still innovate in Kusama with revive :wink:

15

Just to see if i understand everything. You are thinking about working on actually implementing EVM in the hub on top of also PVM and have them be able to talk to each other, and later on have PVM 100% compatible and ditch the addon ?

If yes my question is : Why bother spending extra resources on something that will get ditched in the long run when we can already have EVM contracts with Moonbeam ?

Are we not FOMOing here ? Or maybe i am missing some key technical details/knowledge

3 Likes
16

there is no value to an ‘almost compatible’ EVM. the ‘almost’ condition completely undercuts the whole point of the strategy. it is a bit disheartening that it seems this is still not obvious to the main players.

i really wish we would prioritize market-focus over technical-focus. cos, to me, there is no question or confusion. if Path 1 obviously does not lead to our original goal, then the right thing to do is to scrap it or pause it. barrelling down to complete it just because is not ideal.

we are lagging in the market. thus, EVM compatibility was intended to help fix that. so if we cannot get 100% EVM compatibility (which is what has been marketed since), then we should pivot ASAP.

also, why did it take us almost a year to figure out something that it seems would have been obvious from just looking at the situation structurally? why did we ever assume that ‘almost compatible’ was going to cut it? why did we not just learn a great deal from Moonbeam and their work on Frontier?

it is astonishing to me that we would spend a year on an already-solved problem only to come back and say “actually, we couldn’t solve it”.

a few dissident voices had expressed disagreement on the path taken but they weren’t listened to constructively. instead, FUD accusation was thrown around. why do this? i’ve noticed it lately with some people who work at Parity. our ecosystem offers expertise and diversity that Parity can tap into but it seems that the way Parity sees itself in relation to the rest of the ecosystem undercuts its ability to make use of this advantage we have.

maybe i should be more thankful that we have now seen the error of the original path, and that is valid. but to me, it just doesn’t make sense that it took so long to see this, especially because some of it had been pointed out previously. question is: why was it so hard for Parity to listen to the dissident voices?

added: like @kukabi and @Krayt78 have suggested, we should just make use of what we have that works. Moonbeam is fully EVM compatible. what exactly is wrong with using them as the EVM hub on Polkadot and letting PolkaVM be whatever it needs to be? i mean the question genuinely. what exactly is wrong with making Moonbeam the EVM center of Polkadot?

if we did this before, we would have already driven more traction. much like we were able to accelerate Hydration’s growth with the GIGAHydration proposal, we would have increased activity on Moonbeam by a great deal while also speeding up our work on PolkaVM.

we need to start treating our parachains as literal extensions of Polkadot: which is what was sold in Polkadot v1.

3 Likes
17

this is a valid consideration.

my argument against it was originally that Moonbeam is not Polkadot and the brand associations matter.

but now, i realize that if Parity + the community had decided to make what we already had with Moonbeam work, we could have used our immense technical expertise to solve the problems that presented. our BD efforts would have been spent bringing projects to Moonbeam. but because we see Moonbeam as a separate project (rather than as part of Polkadot), we didn’t think this way. and i see this problem happening again and again.

to avoid this ecosystem blindness, the Treasury should start DCAing into its top parachains (‘top’ referring to those who have executed on product/protocol and gotten meaningful traction). because if the Treasury held a decent amount of GLMR, then the Polkadot community wouldn’t feel like it was competing against Moonbeam. i mean, part of the reason Hydration’s GIGAHydration incentive proposal almost didn’t pass was cos some people were of the sentiment that ‘why should we help Hydration grow when we get nothing for it?’

such thinking only exposes a serious lack of understanding of what an ecosystem really is.

1 Like
18

We have opened the discussion on Frontier’s roadmap for 2025 and 2026, and we would love to hear your inputs: Discussions on the Frontier roadmap for 2025 and 2026 · polkadot-evm/frontier · Discussion #1711 · GitHub

19

Thank you for the transparency! I’m afraid that if developers could freely choose between EVM and PVM, the reality would be that no one would choose PVM.

20

I think you are mixing two discussions here. We definitely need smart contracts on Polkadot Hub.
They are needed to natively integrate with pallet-staking, nomination-pools, governance etc after the Asset Hub Migration (Project Plaza) is done. The advantage is that the contracts can call into these pallets synchronously - something that is not possible if the contracts are on another chain (at least until JAM lands). This need is independent of Moonbeam.

The other discussion is about whether we need 100% EVM compatible contracts or not.

5 Likes