本文摘要：智能合约是一个独有的软件，专门用作管理有价值的数字资产的所有权。

智能合约是一个独有的软件，专门用作管理有价值的数字资产的所有权。尽管现有的编程环境可以用来追踪资产的所有权，但它们一般来说用作体现所有权而不是必要定义所有权的场景。

智能合约的独有之处在于，它们所代表的价值往往必要反映在它们所确保的状态中。随着区块链的发展，代表所有权的机制也在发展。比特币是用于由“并未用于的交易输入”或UTXOs定义的所有权模型建构的。

虽然UTXO模型十分高效，但它非常复杂，可能会产生一些不奇怪的边缘情况，因此Ethereum使用了一种更加非常简单的分类模型。当Libra区块链宣告时，环绕该项目的主要兴趣在于Facebook创建的区块链的政治含义，但我们这些深入研究技术细节的人找到了一些十分有意思的新点子。特别是在是，Libra团队为他们的MoveVM定义了一个新的编程模型，该模型是环绕着一个新的所有权模型（不受Linear Types：Resources灵感）定义的。Resources是在编程语言中必要回应资产所有权的一种新方法。

工程师常常用“所有权”这个词来比喻追踪哪个代码负责管理某种数据结构或系统Resources。这种比喻在编程环境中最少见，在这种环境中，内存管理并没几乎从程序员那里抽象化出来，说道代码“享有”一个对象，意思是说道代码必需管理和获释分配给该对象的内存。Resources拓展了这个点子，因此我们可以利用以前编程语言中的一些管理隐喻“所有权”的机制，并用于它来管理本地数字资产的确实所有权。Move的关键特性是定义自定义Resources类型的能力。

Resources类型用作编码具备非常丰富可编程性的安全性数字资产。Move系统为Resources获取了类似的安全性确保。无法反复、器重或弃置Move Resources。

Resources类型不能由定义该类型的模块创立或封存。这些确保由Move虚拟机静态强迫实行【...】Libra货币是作为一种Resources类型来构建的，并且在语言中没类似的地位，每一个Move Resources都拥有完全相同的维护。最后两点十分最重要：1.Resources对象的类似状态必需由运营时（“Move虚拟机”）强迫实行；如果它们只是一个编译器抽象化，恶意代码就很更容易毁坏值确保。

2.然而！如果您正确地继续执行了这些规则，您就可以容许网络最重要的资产——本机代币——安全性地存储在由用户递交的代码掌控的数据结构中。多强劲！那么Resources究竟是什么呢？最简单的方法是用于非可替换代币（NFT）的示例来思维，比如加密猫。每个加密模块都是不可分割的、不能拷贝的，并且可以有一个必要所有者，必要与Resources编程结构给定。

在像以太坊这样的分类账模型中，所有的加密猫都存储在一个智能契约中，构成一个极大的列表。每只猫的所有权是通过将每个所有者的账户ID存储在一个中央分类账中来追踪的，转变猫的所有权的唯一方法是联系该中央分类账，并拒绝它改版与该猫相关联的账户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 accountcentralKittyLedger.transfer(myKittyId, receiverAccountId)}在Resources模型中，猫本身被回应为一个Resources对象，它必要存储在享有它的帐户中。就像在物质世界里，所有权是以占据为代表的。你不必须查阅中央分类账来查阅你否享有某样东西，你可以把它不存在你的账户里，也可以不不存在。

如果你有它，你可以移往它或以其他方式掌控它，如果你没，就没办法捕猎或转变它。contract CryptoKitties {// Accounts store a collection in their account storageresource KittyCollection {// Each collection has functions to// move stored resources in and outfun withdraw(kittyId: int): CryptoKittyfun deposit(kitty: CryptoKitty)}// The resource objects that can be stored in the collectionresource 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 accountlet receiver = getAccount(receiverAccountId)receiver.kittyCollection.deposit(kitty: -theKitty)}留意：为了维持对分类账和必要所有权模型之间差异的注目，上面的两个例子忽视了访问控制、定义每个变量以及活代码必须考虑到的其他因素等问题。简而言之，将某个东西标记为“Resources”告诉他编程环境，这个数据结构代表某种有形的价值，与该数据结构交互的所有代码都必须遵循一系列类似的规则，这些规则将确保该数据结构的价值。

那么，这些规则是什么呢？1.每个Resources在任何等价的时间都刚好不存在于一个地方。无论是通过编程错误或恶意代码，Resources无法被拷贝或车祸移除。2.Resources的所有权是由其存储方位来定义的。在确认所有权时，不必须查询中央分类账。

3.对Resources上方法的采访仅限于所有者。例如，只有加密猫的主人可以启动选育操作者，从而造成新的猫的问世。

为什么Resources很最重要？正如在章节中提及的，智能合约是唯一合适管理有价值资产所有权的，但大多数编程语言——甚至是那些专门为智能合约设计的编程语言——都没任何本地抽象化来管理所有权。在协议级别上包括这样的抽象化似乎是一个极大的胜利。

但是用于Resources还有其他一些次要的益处，每一个都是十分最重要的：州租金可拓展的智能合约平台必须某种方式来缴纳“州租金”，这样存储在区块链上的数据要么必须缴纳费用，要么从工作集中于移除。根据分类账模型，很难告诉谁应当缴纳这笔租金。例如，加密猫合约代表了数以万计的玩家，享有近200万只小猫和多达111Mb的链上数据。

以太坊没办法公平缴纳租金给所有这些猫主人。用于通过Resources类型的必要所有权模型，每只小猫将存储在其所有者的帐户内，以及该人的其他资产。

谁必须为存储缴纳费用的责任是具体的。更加最重要的是，个人用户（在他们的客户端软件的帮助下）可以副本并未用于的资产，以增加他们的成本和增加网络上的阻抗。

灵活性所有权用于分类账模型展开所有权容许了能用的所有者关系的种类。例如，ERC-721为NFTs定义了一个所有权模型，该模型假设只有以太坊地址才能享有NFT。

然而，在某些用例中，资产本身享有其他资产(比如加密猫享有一副可爱的太阳镜)的点子十分有意思，必须创立一个新的规范(ERC-998)。ERC-998是十分强劲的，但它也比ERC-721简单得多。正确地实行它是十分艰难的，并且追溯到性地将它的特性应用于到现有的ERC-721资产实质上是不有可能的。

必要所有权模型容许任何用于Resources类型建模的资产被安全性地存储在系统中的任何地方，还包括在必要的情况下“内部”其他资产。运营时系统可以确保所有的安全性和价值确保，同时为开发人员获释创造性的灵活性，网卓新闻网，而会带给不必要的复杂性。基于能力的安全性Resources类型获取了构建基于能力的安全性模型的“功能”概念所需的所有确保。

能力是定义安全性系统的一个强劲机制，并且可以使遵循大于特权原则(安全性系统中少见的最佳实践中)显得更容易得多。基于能力的安全性模型一般来说被指出更容易推理小说（这提升了安全性），同时容许更大的灵活性。

避免交接性缺失以太坊历史上最知名的智能合约漏洞源自可交接性问题，可信的开发人员必须大大提高警惕，避免引进易受可交接性反击的逻辑流。幸运地的是，在Resource对象上定义的方法无法沦为任何交接的受害者。

这或许是一个大胆的主张！然而，从如何定义Resource就可以很大自然地得出结论这样的结论：每个Resource都有一个分开的所有者，并且只有Resource的所有者可以调用它上的方法。如果Resources方法是“在堆栈上”，那么我们就告诉对该对象的单一所有权提到早已在用于了；对于我们从该方法内部调用的任何代码——无论多么间接地——都不有可能取得对该对象的第二个提到来展开可交接的方法调用。

当然，必要用于全局分享状态（跨过Resources对象的用于）依然可以创立易受轻进错误影响的代码。这就是为什么惯用的Cadence风格是为所有分享状态用于Resources的原因；亲吻Resources的智能契约作者很久不必考虑到可交接性漏洞了！Flow的编程语言Cadence用于Resources去年，Flow研发团队在对更加智能的契约语言展开学术研究后，调查了区块链环境下线性类型的用于。完全在刚好，Libra团队公布了他们的可行性声明，还包括MoveVM的技术细节。

我们对Resources类型的力量深感愤慨，它是Cadence的定义特性之一，Flow的智能合约编程语言。Resources关卡了比EVM或WASM更加非常丰富的可人组选项，并且非常适合数字资产（特别是在是NFTs！）Cadence有一个舒适度的，符合人体工程学的语法，使它很更容易读者。

它用于一个强劲的静态类型系统来最小化运营时错误，并容许所有的方法、模块和交易都包括实条件和后条件来强迫构建预期的不道德。我们指出，这将造成一种语言更容易自学，更容易审核，并最后比任何现有的替代方案更加有效率。

本文来源：Kaiyun·yunkai(中国)官方网站-www.93ly.com