i think the answer is straightforward:
pivot to executing 100% EVM compatibility. this is what the market has told us in testing.
pool of Solidity developers is high enough to warrant this strategy.
the fact that devs can port from EVM to PVM makes it all the better. cos it means we do not really lose anything on the technical side.
so i do think pivoting to 100% EVM compatibility is what we should do. but then, it may be easier for others to decide if there is some timeline information.
“100%” EVM compatibility as a matter of urgency is the right choice.
I was, and am, excited about PVM and EVM-on-PVM but we can’t just wait around for somebody’s pet project to mature to a state where it’s just about useable (with some workarounds and caveats) for devs outside of the Polkadot ecosystem. EVM on Polkadot is strategic and we need to start prioritising strategic technical developments over conceptual future tech.
I’d second @gbaci’s point about Moonbeam.
I understand that an EVM chain is a different thing from native contracts (that are, or are accessible through, EVM contracts) on Polkadot Hub. But there are many architectural decisions that could have been made differently to tighter couple with this existing EVM ecosystem with users and deployed contracts and 5 years worth of learnings.
It was a rookie mistake to underestimate the PVM/ EVM language incompatibilities and they are, apparently, still being underestimated (The docs section on EXTCODECOPY, for example, is inaccurate - and reads as if it’s deliberately trying to downplay the significance of the incompatibility).
It appears that the current version of revive is fine for a Solidity developer wanting to write contracts from scratch and willing to account for the differences in writing for a different underlying machine, therefore fine if we want (@olanod ?) to build a new ecosystem from the ground up, borrowing heavily where we can, innovating where we have an opportunity.
While this would be exciting, the reason for EVM support is compatibility, and easy porting of projects and users from Ethereum-land, not building a copy from the ground up.
I would therefore suggest (as well as taking the path @Jan-Jan outlines, perhaps with even heavier emphasis on getting 100% EVM compatibility shipped), that this time round we think about the architecture where PVM and EVM will connect, in advance. Ethereum’s EVM, for better or for worse (well, OK, for worse) has evolved dozens of weird hacky workarounds for basic necessities and it will not be acceptable in a release version of EVM-on-PVM for, for example, codesize, delegatecall or extcodecopy to produce unexpected results. Due to the EVM’s limitations, all protocols on Ethereum depend on predictable results from ‘this one weird trick’ for their security.
Remember the 120k ETH wormhole hack? Turned out Solana left a verify_signatures, function for devs to use that didn’t actually verify signatures. We all laughed. Solana morons. Would have been hacked way earlier if anyone was paying attention to their protocol. And, akchually, it was the wormhole devs’ fault, because they should have read the docs and realised that version of the function was deprecated.
It is not exaggerating when I say - this is what we open the door to if we do shit like zero out primitives that solidity devs assume they can rely on for security, or don’t implement the callee gas limit.
We have to be ready for an EVM-on-PVM to fully mimic the EVM, including all the weird bits. And for this we need to design the interface between EVM and PVM from early on to be able to allow mimicking these features of the EVM (which are usually on the VM level, not the language level). Relying on modified tooling to paper over the cracks is insufficient. Putting a shim in hardhat will let devs compile and deploy without rewriting. It won’t leave security assumptions intact.
The fact that this seems to be the current working assumption going forward suggests that, at the very least, this project needs more eyes on it.
Please find our update on this topic here.