Afaik solidity and EVM could never be “safe” per se. We have two primary concerns here:
- Can someone port Solidity code to run on Polkadot?
There is a long history of porting C code between architectures, so the concerns here look more like the blockchain specific tooling. As an example, if the user does not supply enough gas then does the RPC node catch this and report it in a similar enough way to how the EVM ecosystem handles this? Afaik yes
- W3F and treasury must give grants for Solidity development work. Are those teams going to get pissed off at Polkadot and switch to ETH or similar?
Again, the issue looks like the blockchain specific tooloing. As another example, there exists EVM in the browser tooling, probably not 100% EVM compatible either, but does revive match this browser tooling? If we hit difficulties matching the browser tooling with revive, then should we pay someone to improve revive compatiblity for the browser tooling?
Also we really want people to add their own rust for improved functionality over native EVM. In theory, grants could prioritize people doing some rust, in part making this list longer, but also just linking rust into their combiled solidity.
As a specific example, you cannot efficently implement a drand timelock bridge in solidity using EVM precompiles, but you can do one in polkadot, and it’d be efficent if we deploy the ECC hostcalls (onegoing goals). See
Anyways..
We should catalog and prioritize the specific incompatiblities that look problematic, not just in revive but in all the tooling.
We could also quietly identify incompatiblities that exist between other parties EVMs and provide compiler flags in revive for improved compatiblity with those, which then maybe presents revive as a possibly better option for wider “EVM compatiblity” than EVM itself.