作者 | Dieter Shirley
譯者 | 火火醬 責編 | 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 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 // Moves the Kitty into the receiver's account
let receiver = getAccount(receiverAccountId)
receiver.kittyCollection.deposit(kitty: 注意：為了將重點放在分類賬和直接所有權模型之間的差異上，上面的兩個例子都忽略了訪問控制、定義每個變量、以及實時代碼相關的其他因素。
簡而言之，將某個東西標記為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
閱讀更多 CSDN 的文章
