e0309385

As an ex-Move engineer, the Move-VM ecosystem frustrated me after two years of building and I decided to leave. Here's why: 1. Move is not a single smart contract language, but a family of languages and VM designs originated from Diem but diverged significantly as companies like @Aptos @SuiNetwork @movementlabsxyz build their own versions 2. That means the friction that developers meet transitioning from one Move chain to another is incredibly high. Each chain is a siloed ecosystem with its unique VM and toolkits. In the early days of EVM L2s, we already saw examples that 1% disparity of VM can lead to bad experiences and even security breaches. The disparity between Move chains are so large (and continue to grow as protocols release new features!) that they are almost different languages. No efforts have been made to reduce the disparity 3. Move projects typically market Move as an ultra-secure language. However, since Move is not a single language, what should really be discussed is the security of Aptos-Move / Sui-Move / xyz-Move. A language is secure only if the protocol implementation is secure. For example, @zellic_io once found a bug in Sui Move that could cause billions at risk zellic.io/blog/the-billion-d… 4. Interestingly, the above-mentioned bug also existed in Aptos but Aptos Labs declined the bug bounty to Zellic, citing the context that the vulnerability was discovered in Sui. 5. A smart contract is never secure if the privileged admin keys are leaked. Contrary to Solidity contracts where people would typically question the necessity of making a contract upgradeable, Move contracts are admin-upgradeable by default. 6. Although there is an option to make contracts immutable, it is required that an immutable contract cannot depend on a mutable one. For example, if you want to call an external oracle which is upgradeable, your own contract must be upgradeable as well. 7. I also want to mention other points like (1) Permission of wallet signer is too large. Any wallet can be drained by signing 1 txn (2) Lack of smart contract verification on block explorers (3) Lack of high-quality production-ready code examples for new devs to onboard (4) High costs of auditing especially when formal verification is involved