如何用Move编程语言来管理本地数字资产的真正所有权

智能合约是一类专用于管理有价值数字资产所有权的独特软件。尽管现有的编程环境可以用来跟踪资产的所有权，但是它们通常被用来反映所有权，而非直接定义所有权。智能合约的独特之处在于，它们所代表的价值往往直接体现在它们所维持的状态中。

随着区块链的持续发展，代表所有权的机制也在不断发展。比特币是由“未使用的交易输出（unspent transaction outputs）”或UTXO所定义的所有权模型构建的。

虽然UTXO模型非常高效，但它也非常复杂，并且可能会产生一些异常的边缘情况，因此Ethereum采用了一种更直接的Ledger模型。

当Libra区块链发布时，围绕该项目的主要关注点在于Facebook建立的区块链的政治含义，但我们这群深入研究技术细节的人却从中发现了一些很有意思的新想法。

尤其是，Libra团队以一个新的所有权模型为基础，为他们的Move VM定义了新的编程模型。该所有权模型的灵感来源就是线性类型（Linear Types）：资源（Resources）。

“Resources”是一种在编程语言中直接表示资产所有权的新方法。工程师们常常使用“所有权（ownership）”这个术语来比喻：跟踪某代码以管理某种数据结构或系统资源。

这种情况在编程环境中最为常见，在此环境中，内存管理并没有完全从程序员那里抽象独立出来，如果说代码中写了一个对象，那么就意味着该代码必须管理并释放分配给该对象的内存。

Resources将这一概念进行了扩展，我们可以利用一些机制来管理以前编程语言中的“所有权”，并用它来管理本地数字资产的真正所有权。

源引于Move简介：

https://developers.libra.org/docs/move-overview#move-has-first-class-resources

Move 的关键特征是能够定义自定义资源类型（resource types）。资源类型可用于对具有丰富可编程性的安全数字资产进行加密。

Move 类型系统为资源提供了特殊的安全保障。Move资源不能被复制、重复使用或丢弃。资源类型只能由定义该类型的模块创建或销毁。这些保障是由Move虚拟机静态执行的。

Libra货币是作为一种资源类型实现的，在语言中并没有特殊的地位，每个Move资源都享有同样的保护。

最后这两点非常重要：

1. Resource 对象的特殊状态必须由运行时（“Move虚拟机”）强制执行；如果其只是编译器抽象，那么恶意代码很轻松即可打破屏障。

2.然而！如果你能够正确地执行这些规则，则可以让网络中最重要的资产——本机代币——安全地存储在由用户提交的代码控制的数据结构中。厉害了！

1. 到底什么是Resource？

我们可以通过一个不可替代代币（NFT）的示例（例如CryptoKitty）来理解Resource。每个CryptoKitty都是不可分割、不可复制的，并且有一个直接所有者，这与Resource编程结构是相吻合的。

在像Ethereum这样的Ledger模型中，所有的CryptoKitTIes都以巨型列表的形式被存储在一个智能合约中。

通过在中央分类账中存储每个所有者的帐户ID来跟踪每个Kitty的所有权，更改Kitty所有权的唯一方法是联系该中央分类账并要求其更新与该Kitty相关的帐户ID。

contract KittyLedger {

struct Kitty {

priv let kitTIes： {Int： Kitty}

fun transfer（kittyId： Int， newOwner： AccounTId） {

if （msg.sender == kitTIes［kittyId］.owner） {

kitties［kittyId］.owner = newOwner

}

}

}

transaction（signer： Account） {

// tells the central ledger to assign ownership of

// myKittyId to a different account

centralKittyLedger.transfer（myKittyId， receiverAccountId）

}

在Resource模型中，Kitty本身被表示为一个Resource对象，被直接存储在拥有它的帐户中。就像在现实世界中一样，通过占有来表示所有权。

你无需通过中央分类帐来查看自己是否拥有某物，你可以把它存在自己的帐户中，也可以不存。如果你拥有它，你就可以对其进行转移或控制；如果你没有拥有它，则无法捕获或改变它。

contract CryptoKitties {

// Accounts store a collection in their account storage

resource KittyCollection {

// Each collection has functions to

// move stored resources in and out

fun withdraw（kittyId： int）： CryptoKitty

fun deposit（kitty： CryptoKitty）

}

// The resource objects that can be stored in the collection

resource CryptoKitty {}

}

transaction（signer： Account） {

// Removes the Kitty from signer‘s collection， and stores it

// temporarily on the stack.

let theKitty 《- signer.kittyCollection.withdraw（kittyId： myKittyId）

// Moves the Kitty into the receiver’s account

let receiver = getAccount（receiverAccountId）

receiver.kittyCollection.deposit（kitty： 《-theKitty）

注意：为了将重点放在分类账和直接所有权模型之间的差异上，上面的两个例子都忽略了访问控制、定义每个变量、以及实时代码相关的其他因素。

简而言之，将某个东西标记为Resource就是在告诉编程环境：这个数据结构代表了某种有形的价值，与该数据结构进行交互的所有代码都需要遵循一系列特殊的规则，以维护该数据结构的价值。

那么，这些规则都有什么呢？

1.每个Resource 在某一时刻只能存在于一个地方。Resources不能通过编程错误或恶意代码进行复制或意外删除。

2.Resource 的所有权由其存储位置决定。在确定所有权时，无需查阅中央分类账。

3.只有所有者可以对Resource上的方法进行访问。例如，只有CryptoKitty的所有者才可以产生新Kitty。

2. 为什么Resource非常重要？

就像简介中提到的，智能合约特别适合管理贵重资产的所有权，但是大多数编程语言（甚至是专门为智能合约而设计的编程语言）都没有任何用于管理所有权的本机抽象（native abstractions）。在协议级中包含这样的抽象显然意义重大。

但是，使用Resources还有一些其他值得一提的好处：

· 状态租金（State Rent）

可扩展的智能合约平台需要通过某种方式来收取状态租金（state rent），以便为存储在区块链上的数据支付费用或将其从工作集中删除。

在分类账模型下，很难知道该由谁来支付这些租金。例如，CryptoKitties合约代表了数以万计的用户，有近200万Kitties和超过111MB的链上数据。Ethereum无法公正地向所有这些Kitty所有者收取租金。

通过使用Resource Types的直接所有权模型，可以将每个Kitty都（与该用户的其他资产一起）存储在其所有者的账户中。支付存储付费的责任十分明确。此外，个人用户（在其客户端软件的帮助下）可以归档未使用的资产，以降低成本并减少网络负载。

· 灵活所有权（Flexible Ownership）

将分类账模型用于所有权会限制可用的所有者关系种类。例如，ERC-721为NFT定义了一个所有权模型，该模型假定只有Ethereum地址才能拥有NFT。然而，在某些用例中，资产本身拥有其他资产（比如CryptoKitty拥有一副漂亮的墨镜）的想法非常有意思，这就需要创建新的规范（ERC-998）。

不可否认，ERC-998非常强大，但它也比ERC-721要复杂得多。要想正确地执行该规范是非常困难的，而且实际上，要将其有效地应用于现有的ERC-721资产是不可能实现的。

直接所有权模型能够让任何使用Resource Types进行建模的资产安全地存储在系统中的任何位置，包括其他资产“内部”（如果适用的话）。

所有的安全性和价值保障都可以由运行时系统进行维护。在为开发人员提供灵活性的同时，又不会带来不必要的复杂性。

· 基于能力的安全性（Capability-Based Security）

Resource Types为实现基于能力的安全性模型中的“功能（Capabilities）”概念提供了所需的一切保障。Capabilities是定义安全系统的强大机制，能够让遵循最小特权原则（Principle of Least Privilege）（安全系统中常见的最佳实践）变得更加容易。

通常认为，基于能力的安全性模型在提供了更强灵活性的同时，也更容易进行推理（这增强了安全性）。

· 消除可重入性Bugs（Eliminating Reentrancy Bugs）

Ethereum历史上最著名的智能合约bug是由可重入性问题引起的，Solidity开发人员需要不断提高警惕，防止引入易受可重入性攻击的逻辑流。

Ethereum历史上最著名的智能合约bug：

https://www.wired.com/2016/06/50-million-hack-just-showed-dao-human/

幸运的是，定义在Resource对象上的方法不会成为任何可重入性bug的受害者。

这似乎是一个十分大胆的主张！然而，它仅仅是自然地遵循了Resources的定义方式：每个Resources都有一个单独的所有者，并且只有其所有者可以调用Resources上的方法。如果一个Resources方法在“堆栈上”，那么我们就知道该对象的单个所有者引用已在使用中。我们从该方法内部调用的任何代码都不可能（尽管是间接地）获得对该对象的第二个引用以进行可重入方法调用。

当然，直接使用全局共享状态（绕过Resource对象的使用）仍然可能创建易受可重入性bug影响的代码。

这就是惯用的Cadence style对所有共享状态使用Resources的原因，精通Resources的智能合约作者无需再担忧可重入性错误问题！

Flow的编程语言Cadence使用Resources

去年，在对更好的智能合约语言进行了学术研究后，Flow开发团队调查了区块链环境下Linear Types的使用。几乎在同一时间，Libra的团队发布了其最初公告，其中包括MoveVM的技术细节。

学术研究：

http://www.cs.cmu.edu/~balzers/publications/digital_contracts_as_session_types.pdf

Resource Types的强大功能令我们震惊，它是Flow的智能合约编程语言Cadence的定义功能之一。Resources解锁了比EVM或WASM更丰富的可组合性选项，是数字资产的完美选择（尤其是NFT！）

可组合性：

https://hackernoon.com/software-composability-in-crypto-a705700c3816

Cadence具有舒适的、符合人体工程学的语法，易于阅读。它通过一个强大的静态类型系统来最大程度地减少运行时错误，并且允许所有方法、接口和事务包含前置和后置条件，以强制执行预期的行为。我们认为，这会使语言变得更易于学习和审核，最终，会比现有的所有选择都更加高效。