Former Move language engineer @artoriatech posted a message announcing his departure from the Move ecosystem, expressing his pessimism about the Move ecosystem.
As a former Move engineer, I became frustrated with the Move-VM ecosystem after two years of building it, and I decided to leave. Here are the reasons:
1. Move is not a single smart contract language, but a family of languages and VM designs derived from Diem, but with significant differentiation as companies like @Aptos @SuiNetwork @movementlabsxyz build their own versions.
2. This means that the friction for developers transitioning from one Move chain to another is very high. Each chain is an isolated ecosystem with a unique virtual machine and toolkit. In the early days of EVM L2, we have seen examples where a 1% difference in VM can lead to a bad experience or even security vulnerabilities. The differences between Move chains are so large (and continue to grow as each protocol releases new features!) that they have almost become different languages, and no measures have been taken to close this gap.
3. Move language projects often market Move as a super-safe 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 only safe if the protocol implementation is safe. For example, @zellic_io once found that a bug in Sui Move could put billions of dollars at risk https://zellic.io/blog/the-billion-dollar-move-bug/
4. Interestingly, the above vulnerability also exists in Aptos, but Aptos Labs refused to offer a bug bounty to Zellic on the grounds that the vulnerability was found in Sui.
5. Smart contracts are never secure if privileged administrative keys are leaked. In contrast to Solidity contracts, where people often question the necessity of contract upgradeability, Move contracts are manageable and upgradeable by default.
6. Although you can choose to make a contract immutable, this requires that an immutable contract cannot depend on an immutable contract. For example, if you want to call an upgradeable external oracle, your own contract must also be upgradeable.
7. I would also like to mention a few other points, such as:
(1) Wallet signers have too much power. Any wallet can drain all funds by signing one transaction.
(2) Lack of smart contract verification on block browsers
(3) Lack of high-quality production-ready code examples for new developers to use
(4) Auditing is expensive, especially when formal verification is involved
