I have been in close discussion with the Moonbeam community recently regarding the whole issue. tldr, I believe we’ve been totally focusing on the wrong problem. EVM performance has not really been the bottleneck at all, but storage IO. Off-chain JIT/AOT is probably the only viable solution to speed up EVM (but due to Polkadot’s architectural limitations, off-chain JIT/AOT is not as easy to implement as it is on Ethereum mainnet). In any case, EVM interpreting is probably more than sufficient for the foreseeable future. For compute-heavy smart contracts, it’s perfectly viable to treat them as “precompiles” and we allow “pure PolkaVM contracts” to be deployed on-chain.
It’s therefore our belief that Frontier has made the correct decisions regarding Ethereum and EVM compatibility all along. Recently we started adding optional PolkaVM support to Frontier to implement the “pure PolkaVM precompile” idea.
I also invite you to read:
The optimization guide of Frontier, where we discuss in more detail the benchmarks on Ethereum mainnet and why storage IO (but not VM performance) is the bottleneck.
Pallet Revive clearly contains traces of code that is inspired by Frontier. Even the Revive compiler is not an original but a fork of zkSync’s era-compiler.
We’re just not as pity as you when it comes to code reuse. In fact, we welcome it. The Frontier code has been forked by many Polkadot parachains to adopt to their own needs. In open source, code reuse means power.
Frontier does not use CLA. This means that the code is owned by all developers who wrote it. This includes me, Moonbeam, Acala, many other parachains, and of course also Parity. We always write “Frontier developers” as the attribution.
We do also want to question your intention as why you bring up this instead of a technical argument. You have been making personal attacks, accusing those who disagree with you on the revive project of writing “GPT”. Many of your comments fall short of anything technical. Now Parity has admitted you’re wrong on the revive project, so I do hope you can apologize to those people, and also to the whole community – we basically lost a whole year due to this strategic mistake.
You can keep repeating yourself as much as you want. The fact that there is no such thing as 100% compatibility won’t go away. Frontier will always fall into your “almost compatibility”.
The hard problems we have to solve which frontier conveniently ignores are:
Gas model incompatibilities?
Currency denomination incompatibilities?
AccountId32 compatibility?
Storage deposit and ED incompatibilities
JIT compilation is hard (needs either to be done on-chain or proven correctness which is both, at the time of writing, infeasible for optimizing compilers)?
Can the chain run all possible EVM bytecode unchanged? Frontier can, Revive can’t. That’s what differentiate those two. Of course sometimes there are bugs, but we treat specification incompatibility as security issue and have actually already published several security advisories with fixes.
Some of those are solved problem in Frontier (like AccountId32). For others, the problem is rather you chose a bad strategy and were solving totally the wrong problem. The constraints you’ve chosen are rather unnecessary and impractical.
As an example, if you have actually benchmarked real-world Ethereum blocks, you would know that 80% is storage IO and only 20% is VM execution. With actual information but not “appeal to cool tech”, we would have known from the very beginning that the compiler project is probably unnecessary.
We could instead have further developed ink! or some other more important projects. But we spent more than a year to learn a hard and expensive lesson. Premature optimization is the root of all evil. Donlad Knuth has already told us this lesson in the 1970s.
By the way, the JIT compilation limitation is only a Polkadot architectural limitation. In Ethereum, JIT compiled EVM has already been developed (and tested against mainnet blocks) by the Reth team.
I am genuinely interested in how this was - or wasn’t - solved technically. Would appreciate your answer please (you are welcome to keep your political and philosophical insights for yourself).
Moonbeam developers will have the authority to answer this.
But from what I see, this seems to be a spamming + state bloat issue, which can be elegantly fixed by customization of gas metering (which we already have many in Frontier).
If you’re asking the throughput in this case, that’s rather a Polkadot problem and the limitation is PoV. The bottleneck is almost always storage IO, and seldom VM execution. If the PoV is used up, then of course users will feel things to be slow.
See, on a critical system chain like Asset Hub we definitively don’t want to introduce state bloat vulnerabilities. But we do want as high throughput and compatibility as possible. I don’t think it’s as simple as it may seem on a glance.