以太坊DEX合的调用流程

研究报告节选:

与其出现的背景相匹配，Move 是面向资源(resources)的编程语言，资源在 Move 的世界里是“第一等公民”（first-class resource），其关键特性是自定义资源类型：resources永远不能被复制或隐式丢弃，只能在程序存储位置之间移动。它可以像传统的类型一样，可以存储在数据结构中，也可以作为参数传递。简单的说，他就是传统编程语言中一个不可随意销毁的新数据类型。对比 Solidity 定义的资产，如以太坊上的某种 Token 账户，资产只是一个数值，两个账户之间发生转账后，账户资产数值相应的发生变化，不同账户资产的区别就是数值余额，并无本质区别（也就是说资产是同质的）。同时需要注意，例如以太坊上 ERC20 代币 TokenA，其是一个独立的合约账户，这个合约为用户（账户地址）分配一个数值，代表用户拥有的 Token A 的数量。从这一点可以看出，Solidity 并不是面向资源的，用户的账户拥有某个 Token 资产，只是该 Token 合约分配给用户的一个数值。 而 Move 创建的 Token 账户资产是独一无二的资源类型，比如账户 A 中的资产是保存在A 账户中的，虽然也是数值，但不能复制、丢弃或重用，可以被安全地存储和转移，用并不完全准确的比喻，可以认为 A 账户中的资产与其他账户资产在某种意义上是不完全同质的。同时，账户资产只能由定义该资源的模块进行创建和销毁，这使得同质化的数值类型的资产可能产生的重入、类似双花或者账户余额出现不平衡的状况得以避免。在这一点上，Move 账户资产有些类似比特币的 UTXO 机制，Token 不再是简单的同质化数值，而是可区分的。为了可以实现更灵活的业务，Move 另外定义了 4 种权限属性：可复制(copy)、可丢弃(drop)、可存储(store)、可检索(key)。这 4 种属性可以任意组合，来定义资源的属性，方便用户灵活操作。如 drop+store+key 的组合，定义的资源是不可以复制的，可以避免复制引发的代币增发以及双花的问题，这一点类似 NFT 以及比特币的UTXO 机制。 可以这样理解，以太坊（Solidity）的资产是由相应的合约控制，如果把 Token A 合约比喻为保险箱，保险箱会给所有用户分配一个数值余额，来表达用户所有拥有的 Token A资产数量，但资产本身还是放在 Token A 合约的保险箱内。而 Move 用户账户本身就是一个单独的大保险箱，由用户自己控制，所有的 Token 资产都放在这个保险箱内。且这些 Token 并不是以数字的形式存在，而是不可复制的、权限受用户控制的资源（类型）。 Move 语言中的资源定义与权限是分离的，资源的权限属于用户。Solidity 中账户资源权限归属于合约，比如以太坊上某个 erc20 Token 属于相应的合约，如用户在 DEX 如Uniswap 合约进行 Token A（权限属于 Token A 的合约）兑换为 Tokend B（权限属于Token B 的合约）交易时，无法在 Uniswap 合约里直接提取自己的 A 资产换为 B 资产——因为 Uniswap 里资产的权限属于其合约。实际的流程至少三步交易操作：i）首先对Uniswap 合约进行授权（approve），授权 Uniswap 合约代用户提取 A 合约的资产；ii）进入 Uniswap 合约进行兑换，提取 A 后将 B 存入账户；iii）取消授权（revoke）。但用户一般不会在完成兑换后立刻取消授权（为后续可能还会进行兑换行为节省 gas 费用），一旦 Uniswap 合约受到攻击或者出现漏洞，就为用的 A Token 账户带来风险。需要注意的是，授权/取消授权都需要在以太坊上执行合约操作，从而产生 gas 费。从这里我们可以清晰看到，Token A、Token B、Uniswap 里的 LP 资产权限分属于各自的合约，用户无法通过一个账户在三个合约之间自由切换。而 Move 的资产大账户则不需要跨合约授权，权限是属于用户的，用户直接在 DEX 里提取 A、兑换为 B 存储到账户里，这个过程可以在一个交易操作里完成，无需授权/取消授权操作，一定程度上提高了安全性。