"Is 'Not Authorizing' Really Safe: The Design Philosophy Behind Move"

Original author: @jolestar

Recently, there has been much debate about whether interacting with users and Move smart contracts without authorization (Approve) is safer or less safe. Here, I will attempt to explain the differences behind the two concepts and the philosophy behind the design of Move in a simple way.

First, let's understand how users interact with smart contracts. When we sign a transaction to call a smart contract on the blockchain, it is like entering the digital world of a smart contract from the physical world. In this digital world, we have an avatar, and what this avatar does is defined by the smart contract.

In EVM, each contract is like an independent small world. Once the avatar enters this world, it can only operate on the state (assets) of the user within the current contract world.

For example, if we enter the swap world and want to exchange our USDT for other assets, but USDT exists in the contract world that defines USDT, we cannot directly extract assets from the USDT contract in the swap world as our own identity. Therefore, the user must first go to the USDT contract world to execute an approve, informing the USDT contract that the swap can withdraw their assets on their behalf, and then enter the swap world to perform the operation.

After the operation is completed, the user goes back to the USDT side to revoke the authorization. However, both the approve and revoke operations require independent transactions, and users often do not revoke to save gas fees. As a result, if the swap contract has security issues, the user's assets may be stolen without their knowledge.

In contrast, in Move, all contracts operate within a larger digital world. The user's digital avatar can freely move between contracts and perform any operations, while the user's state (assets) exists in the user's own storage space.

Users enter from the swap entry, withdraw USDT from their balance, exchange it, and store it all in one atomic transaction. This model allows for more flexible combinations of contracts, enabling many combinations that are difficult to achieve on EVM. This is also the model that the account abstraction scheme on EVM aims to achieve. Of course, this also brings new security challenges.

So, can EVM directly add a feature that allows the user identity to be carried over during contract calls? Technically, this is feasible, but EVM supports dynamic calls, allowing calls to contracts at any address, making the risks of such operations difficult to measure. Additionally, EVM's state changes are not user-friendly for users and wallets, making it hard for wallets to alert users through state changes.

Move addresses this security challenge in two ways:

1. When pre-executing contracts, the state changes after contract execution are communicated to the user, allowing them to know which important assets were affected by the transaction and the results of the execution. This method has already been implemented in StarMask; see the link and attached image https://starcoin.medium.com/starmask-v4-6-

2. Some contracts may set conditions that prevent certain users from noticing state changes during pre-execution. @0xmetazen's analysis https://twitter.com/0xmetazen/status/1582581013972414465, but since Move does not have dynamic calls, the execution logic of a contract is determined at deployment. Static analysis of the bytecode can reveal the states of operations along all possible paths of the contract, which can be communicated to users in block explorers or wallets.

The two approaches of EVM and Move present different security risks. The risk of the Approve scheme is turning an immediate authorization into a long-term authorization. Its risks do not occur immediately, such as when a contract vulnerability goes undetected or a malicious contract uses a long con. Once it happens, users are often very passive, and many may forget which contracts they have authorized.

In contrast, Move's approach grants contracts greater freedom. When encountering a malicious contract, there is a higher risk, but this risk occurs immediately and can be detected through technical means. In the worst-case scenario, at least those who rush in first may fall into a trap, providing a warning for those who follow, and malicious contracts will be quickly exposed.

Finally, there is no silver bullet; it is impossible to solve all security issues just by using a certain technology. It requires collaboration among chains, tools, and users.

Security recommendations for Move users:

1. Choose wallets with more comprehensive state change notifications and try to understand the wallet's alerts.

2. Do not interact casually with DApps of unknown origin or that are not open source.

3. If you cannot do the above two points, you can wait for others to test the waters first.

The challenges and improvement plans for security in Move are not limited to these; I will elaborate on them in the security section of the "Why Move" series. Friends who are interested can follow along.