The point is, you can say the same thing about Ethereum. At the time Ethereum was created, EVM was indeed also the best practical choice. It is probably still the best practical choice, compared with WASM (which we know its downsides now, and consider the issue of technical superiority vs ecosystem development), RISC-V (which is better than WASM, but hasn’t yet been developed), and all others.
In Polkadot, we often talk about EVM in the context of WASM vs EVM. Then we discuss why we made the right choice because WASM is the future. However:
- EVM is still a perfectly valid choice for a smart contract VM. It’s reasonably performant as long as you optimize the engine. And practically we learned that the bottleneck is rather storage, than CPU.
- Certain choices we thought that was wrong in EVM, are actually rather trade-offs. For example, if we’d need to deal with primarily 256-bit integers, then EVM’s choice is rather okay, and it makes the contract size shorter. In Wasm, those primitive operations are usually compiled inline, which affects the contract size (1 byte vs 4 byte, for every integer operation).
- We thought that WASM being able to compile and applying a lot of optimizations is a significant advantage. It turned out only to be a marginal advantage because we are limited by compilation time, and can probably only do one-pass.
Besides all the above, and again, while I agree Wasm is marginally better than EVM, we might also be arguing the wrong thing there. No one interacts with EVM directly, only the programming languages. It’s rather a hidden implementation detail that contract developer usually does not see. The engine just has to be there, doing its own things. And this considered, we should probably instead compare Solidity vs Rust, as those are the actual things to write smart contracts. In this sense, Solidity/EVM is actually better than ink/Rust/Wasm at this moment:
- The language was specifically designed with smart contracts in mind. Rust unfortunately isn’t, so we need to ask all dapp developers to be mindful of
no_std, and not use certain APIs. This is always a confusion point. - Solidity has been polished for a really long time. This is especially the case for its documentation and educational materials.
- There’s a mature industry and open source toolchain for security audit in Solidity. This part they are way superior than us.
If we compare the practical points, and compare the entire smart contract development toolchain, instead of just the VM, then the competition quickly reverse. Of course, all of those can be fixed in Polkadot – there’s no technical difficulty. However, so can Ethereum. Since Ethereum 2.0, their architectural separation of the consensus engine and the execution engine makes development a whole a lot easier. They are also ahead of us in terms of dealing with merkle tries and storages. We’ll one day figure out that we don’t need to store all intermediate trie nodes on disk, because hashing is cheap, just like they have already done. Ethereum also made the conscious decision not to go full into on-chain governance – while they don’t have anything better yet, their hesitation does have a point – they pointed out several years ago about the worry of non-representativeness, game theoritical attacks, etc, which we’re experiencing in OpenGov at this moment.
The point is, we should probably stop assuming that our architectural choice is the best. In certain parts, our architecture turned out to be only marginally better (Wasm). In certain parts, we are rather worse (Solidity/EVM ecosystem, merkle trie). It’s important that we don’t continue with those ideology-like battle (“Wasm is certainly better than EVM!”) and keep an open mind of everything that’s being developed elsewhere.