Emily Pillmore, an engineer at Kadena, just published this article about the differences between EVM/Solidity and Kadena’s VM/its interpreted smart contract language, Pact, which makes some very different design decisions than ours. I’ll leave deeper technical analysis to the experts and folks such as @gregc/@gcolvin who know far more about VM design than I, but a few high-level thoughts:
Many of the issues highlighted in the article are in the process of being fixed. E.g., to a large extent, I believe “dispatch” and lack of native-multisig support are addressed by CREATE2 and account abstraction, and the lack of a trusted “standard library” and ability to inline libraries will be addressed by Ewasm.
Kadena has taken a fundamentally different design direction with Pact than we have with EVM/Solidity, exemplified by the question of Turing-completeness. The Ethereum ethos seems to be, “we make everything possible, so the onus is on the smart contract developer to write safe code,” whereas the ethos with Pact seems to be, “we make the most dangerous things impossible in the first place.” This inspired my Disney World vs. Burning Man analogy. Obviously, there is no single right or wrong choice here: a different set of considerations has led to a different set of design decisions. I think we’d both gain a lot by having more dialog on this topic!
Among Ewasm, shards, and sidechains, I wonder if it wouldn’t be possible to have different state execution environments in “greater Ethereum” that allow developers to opt into one or the other mindset, for different applications with different sets of security considerations.