You really need to stop that passive aggressive FUD tone. We’re here working for the Polkadot community, not to fill your ego after we realized that revive doesn’t work.
You’ve been calling nearly all oppositions of the Revive project FUD. I’ve been calling out the incompatibility issues (and the relevant security issues) as well as the storage issue for a long time. Last week I also started some more serious research on the benchmarks and PolkaVM’s PoV issue.
I’m not sure if you referenced my work making your decision admitting that revive’s current strategy will not work, or if you reached your conclusions independently, but either way, if you have, for one moment, thought about the possibility that you might be wrong instead of dismissing everyone else as FUD, we would not have been in this bad situation. Please have some professionalism.
Then the benchmark is not done correctly or sufficiently. I know you have some benchmarks of toy programs, but those do not replace real-world testing. If revive is to address those storage problems you mentioned, then it’s making things worse, not better.
Regarding compilation time and execution time, the whole PVM strategy is not without flaws. I mentioned this in the discussion with the Moonbeam community:
In a recent discussion with the Nervos team and also checking how Paradigm’s revmc actually worked in production in Reth, I was introduced a new design pattern that may completely change our view on how we optimize on-chain smart contract bytecode. The current view from Polkadot is that there are huge restrictions for an on-chain JIT/AOT recompiler. It must be really fast, and it must avoid JIT bomb. This means we’re left with single-pass recompiler that cannot do much optimization. The bytecode then must be easy to recompile and map as close to native as possible. That’s why we spent so much efforts searching for the “perfect” instruction set. From EVM to Wasm to eBPF and finally to PolkaVM.
What if we’re wrong?
The Polkadot view assumes that the recompilation process always happens immediately before a contract is ran. Therefore that the benchmark of compile+runtime is the most important. This may not have to be the case, because the compilation only needs to happen once! Therefore one can imagine the following design:
- A main thread that handle normal block/transaction processing. It uses already compiled blob when available, or interpreter as fallback.
- An optimization thread in the background that gradually optimizes contracts in the state.
We can imagine that the optimization thread would first try a simple (inefficient) one-pass AOT, and when time permits, try an advanced LLVM AOT with aggressive optimization.
(…)
If this design is possible, unfortunately, it’ll also mean that what we’ve spent years on searching the “perfect” instruction set is in vain.
You have spent at least a full year on resolc, we haven’t fixed it, and have to call things off. It may be another year or two. Ethereum will not wait for us and there are a lot more teams trying better Ethereum-compatibility at different chains. If you have actually looked at their work, but not just develop in your own ivory tower, you would know how intense the competition is. We really have zero advantage regardless of PVM.
Paradigm’s revmc is mainly designed to be used off-chain. As an off-chain JIT/AOT we can remove the code size concern and thus it can work much better.
But in any case, as I mentioned millions of times already. VM execution is not the bottleneck at all. It’s storage IO. So at this stage, EVM interpreting is more than sufficient. We would have better throughput gain focusing on IO/storage problems first.