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

智能合约的独有之处在于，它们所代表的价值往往必要反映在它们所保持的状态中。随着区块链的持续发展，代表所有权的机制也在大大发展。比特币是由“并未用于的交易输入（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-resourcesMove 的关键特征是需要定义自定义资源类型（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 accountcentralKittyLedger.transfer(myKittyId, receiverAccountId)}在Resource模型中，Kitty本身被回应为一个Resource对象，被必要存储在享有它的帐户中。

就像在现实世界中一样，通过占据来回应所有权。你需要通过中央分类帐来查阅自己否享有某物,你可以把它不存在自己的帐户中，也可以不遗。如果你享有它,你就可以对其展开移往或掌控；如果你没享有它,则无法捕捉或转变它。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)留意:为了将重点放到分类账和必要所有权模型之间的差异上，上面的两个例子都忽视了访问控制、定义每个变量、以及动态代码涉及的其他因素。

简而言之，将某个东西标记为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的技术细节。

学术研究：~balzers/publications/digital_contracts_as_session_types.pdfResource Types的强劲功能令其我们愤慨，它是Flow的智能合约编程语言Cadence的定义功能之一。Resources关卡了比EVM或WASM更加非常丰富的可人组性选项，是数字资产的极致自由选择(特别是在是NFT!)可人组性：https://hackernoon.com/software-composability-in-crypto-a705700c3816Cadence具备舒适度的、符合人体工程学的语法，更容易读者。

它通过一个强劲的静态类型系统来仅次于程度地增加运营时错误，网卓新闻网，并且容许所有方法、模块和事务包括前置和后置条件，以强制执行预期的不道德。我们指出，这不会使语言显得更加更容易自学和审查，最后，不会比现有的所有自由选择都更为高效。

本文来源：kaiyun体育(中国)官方网站-www.esunon.com