译者 | 火火酱 责编 | Carol
出品 | 区块链大本营（blockchain_camp）
智能合约是一类专用于管理有代价数字资产所有权的独特软件。只管现有的编程环境可以用来跟踪资产的所有权，但是它们常日被用来反响所有权，而非直接定义所有权。智能合约的独特之处在于，它们所代表的代价每每直接表示在它们所坚持的状态中。
随着区块链的持续发展，代表所有权的机制也在不断发展。比特币是由“未利用的交易输出（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.然而！
如果你能够精确地实行这些规则，则可以让网络中最主要的资产——本机代币——安全地存储在由用户提交的代码掌握的数据构造中。厉害了！
到底什么是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。
为什么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具有舒适的、符合人体工程学的语法，易于阅读。它通过一个强大的静态类型系统来最大程度地减少运行时缺点，并且许可所有方法、接口和事务包含前置和后置条件，以逼迫实行预期的行为。我们认为，这会使措辞变得更易于学习和审核，终极，会比现有的所有选择都更加高效。
本文为 CSDN 翻译，转载请注明来源出处。
原文：https://hackernoon.com/resources-programming-ownership-on-the-blockchain-lzb832d1
