A Frontier developer's perspective on Moonbeam's strategic direction

I’m doing some research and benchmark on Polkadot Hub vs EVM parachains. My current conclusion is that Polkadot Hub will actually run slower than Moonbeam, even assuming Polkadot Hub does all the optimizations to its theoretical limit.

This may be counterintuitive, but the main reason is contract size explosion. We know, as a matter of fact, that PolkaVM contracts are around 10x the size of equivalent EVM contracts (sometimes even up to 80x for compute heavy contracts). Even if the optimization is done to the roof, the theoretical limit is 4x. Smart contract parachains are usually limited by its PoV size, but not by execution time. The contract size explosion of PolkaVM will mean that much less of them can fit in a single PoV, and thus much less throughput.

I think PolkaVM is probably good for deploying a blockchain runtime as it’s fast. On the other hand, for smart contracts, especially on Polkadot where we need PoV, the impact of contract size should not be underestimated, which PolkaVM does much worse than many other VM formats. Therefore while we already have basic optional PolkaVM support in Frontier and I’ll soon write some guides on how to use it, I would really advise caution adding PolkaVM, cause premature deployment of PolkaVM may make your network run slower!

There’s probably no silver bullet. At least PolkaVM is not. If one wants something that recompiles fast, then it’ll inevitably have storage size penalty. If a VM is compressed well, then it’ll inevitably be slower compared with the former.

The trick is to know what is actually the bottleneck. From Ethereum benchmarks we know ~80% is storage IO, and only ~20% is VM performance. Therefore the better choice here seems to be pretty clear.

1 Like