如何用Move編程語言來管理本地數(shù)字資產(chǎn)的真正所有權

智能合約是一類專用于管理有價值數(shù)字資產(chǎn)所有權的獨特軟件。盡管現(xiàn)有的編程環(huán)境可以用來跟蹤資產(chǎn)的所有權，但是它們通常被用來反映所有權，而非直接定義所有權。智能合約的獨特之處在于，它們所代表的價值往往直接體現(xiàn)在它們所維持的狀態(tài)中。

隨著區(qū)塊鏈的持續(xù)發(fā)展，代表所有權的機制也在不斷發(fā)展。比特幣是由“未使用的交易輸出（unspent transaction outputs）”或UTXO所定義的所有權模型構建的。

雖然UTXO模型非常高效，但它也非常復雜，并且可能會產(chǎn)生一些異常的邊緣情況，因此Ethereum采用了一種更直接的Ledger模型。

當Libra區(qū)塊鏈發(fā)布時，圍繞該項目的主要關注點在于Facebook建立的區(qū)塊鏈的政治含義，但我們這群深入研究技術細節(jié)的人卻從中發(fā)現(xiàn)了一些很有意思的新想法。

尤其是，Libra團隊以一個新的所有權模型為基礎，為他們的Move VM定義了新的編程模型。該所有權模型的靈感來源就是線性類型（Linear Types）：資源（Resources）。

“Resources”是一種在編程語言中直接表示資產(chǎn)所有權的新方法。工程師們常常使用“所有權（ownership）”這個術語來比喻：跟蹤某代碼以管理某種數(shù)據(jù)結構或系統(tǒng)資源。

這種情況在編程環(huán)境中最為常見，在此環(huán)境中，內(nèi)存管理并沒有完全從程序員那里抽象獨立出來，如果說代碼中寫了一個對象，那么就意味著該代碼必須管理并釋放分配給該對象的內(nèi)存。

Resources將這一概念進行了擴展，我們可以利用一些機制來管理以前編程語言中的“所有權”，并用它來管理本地數(shù)字資產(chǎn)的真正所有權。

源引于Move簡介：

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

Move 的關鍵特征是能夠定義自定義資源類型（resource types）。資源類型可用于對具有豐富可編程性的安全數(shù)字資產(chǎn)進行加密。

Move 類型系統(tǒng)為資源提供了特殊的安全保障。Move資源不能被復制、重復使用或丟棄。資源類型只能由定義該類型的模塊創(chuàng)建或銷毀。這些保障是由Move虛擬機靜態(tài)執(zhí)行的。

Libra貨幣是作為一種資源類型實現(xiàn)的，在語言中并沒有特殊的地位，每個Move資源都享有同樣的保護。

最后這兩點非常重要：

1. Resource 對象的特殊狀態(tài)必須由運行時（“Move虛擬機”）強制執(zhí)行；如果其只是編譯器抽象，那么惡意代碼很輕松即可打破屏障。

2.然而！如果你能夠正確地執(zhí)行這些規(guī)則，則可以讓網(wǎng)絡中最重要的資產(chǎn)——本機代幣——安全地存儲在由用戶提交的代碼控制的數(shù)據(jù)結構中。厲害了！

1. 到底什么是Resource？

我們可以通過一個不可替代代幣（NFT）的示例（例如CryptoKitty）來理解Resource。每個CryptoKitty都是不可分割、不可復制的，并且有一個直接所有者，這與Resource編程結構是相吻合的。

在像Ethereum這樣的Ledger模型中，所有的CryptoKitTIes都以巨型列表的形式被存儲在一個智能合約中。

通過在中央分類賬中存儲每個所有者的帳戶ID來跟蹤每個Kitty的所有權，更改Kitty所有權的唯一方法是聯(lián)系該中央分類賬并要求其更新與該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對象，被直接存儲在擁有它的帳戶中。就像在現(xiàn)實世界中一樣，通過占有來表示所有權。

你無需通過中央分類帳來查看自己是否擁有某物，你可以把它存在自己的帳戶中，也可以不存。如果你擁有它，你就可以對其進行轉移或控制；如果你沒有擁有它，則無法捕獲或改變它。

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就是在告訴編程環(huán)境：這個數(shù)據(jù)結構代表了某種有形的價值，與該數(shù)據(jù)結構進行交互的所有代碼都需要遵循一系列特殊的規(guī)則，以維護該數(shù)據(jù)結構的價值。

那么，這些規(guī)則都有什么呢？

1.每個Resource 在某一時刻只能存在于一個地方。Resources不能通過編程錯誤或惡意代碼進行復制或意外刪除。

2.Resource 的所有權由其存儲位置決定。在確定所有權時，無需查閱中央分類賬。

3.只有所有者可以對Resource上的方法進行訪問。例如，只有CryptoKitty的所有者才可以產(chǎn)生新Kitty。

2. 為什么Resource非常重要？

就像簡介中提到的，智能合約特別適合管理貴重資產(chǎn)的所有權，但是大多數(shù)編程語言（甚至是專門為智能合約而設計的編程語言）都沒有任何用于管理所有權的本機抽象（native abstractions）。在協(xié)議級中包含這樣的抽象顯然意義重大。

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

· 狀態(tài)租金（State Rent）

可擴展的智能合約平臺需要通過某種方式來收取狀態(tài)租金（state rent），以便為存儲在區(qū)塊鏈上的數(shù)據(jù)支付費用或將其從工作集中刪除。

在分類賬模型下，很難知道該由誰來支付這些租金。例如，CryptoKitties合約代表了數(shù)以萬計的用戶，有近200萬Kitties和超過111MB的鏈上數(shù)據(jù)。Ethereum無法公正地向所有這些Kitty所有者收取租金。

通過使用Resource Types的直接所有權模型，可以將每個Kitty都（與該用戶的其他資產(chǎn)一起）存儲在其所有者的賬戶中。支付存儲付費的責任十分明確。此外，個人用戶（在其客戶端軟件的幫助下）可以歸檔未使用的資產(chǎn)，以降低成本并減少網(wǎng)絡負載。

· 靈活所有權（Flexible Ownership）

將分類賬模型用于所有權會限制可用的所有者關系種類。例如，ERC-721為NFT定義了一個所有權模型，該模型假定只有Ethereum地址才能擁有NFT。然而，在某些用例中，資產(chǎn)本身擁有其他資產(chǎn)（比如CryptoKitty擁有一副漂亮的墨鏡）的想法非常有意思，這就需要創(chuàng)建新的規(guī)范（ERC-998）。

不可否認，ERC-998非常強大，但它也比ERC-721要復雜得多。要想正確地執(zhí)行該規(guī)范是非常困難的，而且實際上，要將其有效地應用于現(xiàn)有的ERC-721資產(chǎn)是不可能實現(xiàn)的。

直接所有權模型能夠讓任何使用Resource Types進行建模的資產(chǎn)安全地存儲在系統(tǒng)中的任何位置，包括其他資產(chǎn)“內(nèi)部”（如果適用的話）。

所有的安全性和價值保障都可以由運行時系統(tǒng)進行維護。在為開發(fā)人員提供靈活性的同時，又不會帶來不必要的復雜性。

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

Resource Types為實現(xiàn)基于能力的安全性模型中的“功能（Capabilities）”概念提供了所需的一切保障。Capabilities是定義安全系統(tǒng)的強大機制，能夠讓遵循最小特權原則（Principle of Least Privilege）（安全系統(tǒng)中常見的最佳實踐）變得更加容易。

通常認為，基于能力的安全性模型在提供了更強靈活性的同時，也更容易進行推理（這增強了安全性）。

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

Ethereum歷史上最著名的智能合約bug是由可重入性問題引起的，Solidity開發(fā)人員需要不斷提高警惕，防止引入易受可重入性攻擊的邏輯流。

Ethereum歷史上最著名的智能合約bug：

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

幸運的是，定義在Resource對象上的方法不會成為任何可重入性bug的受害者。

這似乎是一個十分大膽的主張！然而，它僅僅是自然地遵循了Resources的定義方式：每個Resources都有一個單獨的所有者，并且只有其所有者可以調(diào)用Resources上的方法。如果一個Resources方法在“堆棧上”，那么我們就知道該對象的單個所有者引用已在使用中。我們從該方法內(nèi)部調(diào)用的任何代碼都不可能（盡管是間接地）獲得對該對象的第二個引用以進行可重入方法調(diào)用。

當然，直接使用全局共享狀態(tài)（繞過Resource對象的使用）仍然可能創(chuàng)建易受可重入性bug影響的代碼。

這就是慣用的Cadence style對所有共享狀態(tài)使用Resources的原因，精通Resources的智能合約作者無需再擔憂可重入性錯誤問題！

Flow的編程語言Cadence使用Resources

去年，在對更好的智能合約語言進行了學術研究后，F(xiàn)low開發(fā)團隊調(diào)查了區(qū)塊鏈環(huán)境下Linear Types的使用。幾乎在同一時間，Libra的團隊發(fā)布了其最初公告，其中包括MoveVM的技術細節(jié)。

學術研究：

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

Resource Types的強大功能令我們震驚，它是Flow的智能合約編程語言Cadence的定義功能之一。Resources解鎖了比EVM或WASM更豐富的可組合性選項，是數(shù)字資產(chǎn)的完美選擇（尤其是NFT?。?/p>

可組合性：

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

Cadence具有舒適的、符合人體工程學的語法，易于閱讀。它通過一個強大的靜態(tài)類型系統(tǒng)來最大程度地減少運行時錯誤，并且允許所有方法、接口和事務包含前置和后置條件，以強制執(zhí)行預期的行為。我們認為，這會使語言變得更易于學習和審核，最終，會比現(xiàn)有的所有選擇都更加高效。