電子發(fā)燒友App
智能合約是一類專用于管理有價值數(shù)字資產(chǎn)所有權(quán)的獨特軟件。盡管現(xiàn)有的編程環(huán)境可以用來跟蹤資產(chǎn)的所有權(quán)，但是它們通常被用來反映所有權(quán)，而非直接定義所有權(quán)。智能合約的獨特之處在于，它們所代表的價值往往直接體現(xiàn)在它們所維持的狀態(tài)中。
隨著區(qū)塊鏈的持續(xù)發(fā)展，代表所有權(quán)的機制也在不斷發(fā)展。比特幣是由“未使用的交易輸出（unspent transaction outputs）”或UTXO所定義的所有權(quán)模型構(gòu)建的。
雖然UTXO模型非常高效，但它也非常復雜，并且可能會產(chǎn)生一些異常的邊緣情況，因此Ethereum采用了一種更直接的Ledger模型。
當Libra區(qū)塊鏈發(fā)布時，圍繞該項目的主要關(guān)注點在于Facebook建立的區(qū)塊鏈的政治含義，但我們這群深入研究技術(shù)細節(jié)的人卻從中發(fā)現(xiàn)了一些很有意思的新想法。
尤其是，Libra團隊以一個新的所有權(quán)模型為基礎(chǔ)，為他們的Move VM定義了新的編程模型。該所有權(quán)模型的靈感來源就是線性類型（Linear Types）：資源（Resources）。
“Resources”是一種在編程語言中直接表示資產(chǎn)所有權(quán)的新方法。工程師們常常使用“所有權(quán)（ownership）”這個術(shù)語來比喻：跟蹤某代碼以管理某種數(shù)據(jù)結(jié)構(gòu)或系統(tǒng)資源。
這種情況在編程環(huán)境中最為常見，在此環(huán)境中，內(nèi)存管理并沒有完全從程序員那里抽象獨立出來，如果說代碼中寫了一個對象，那么就意味著該代碼必須管理并釋放分配給該對象的內(nèi)存。
Resources將這一概念進行了擴展，我們可以利用一些機制來管理以前編程語言中的“所有權(quán)”，并用它來管理本地數(shù)字資產(chǎn)的真正所有權(quán)。
源引于Move簡介：
https://developers.libra.org/docs/move-overview#move-has-first-class-resources
Move 的關(guān)鍵特征是能夠定義自定義資源類型（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)絡(luò)中最重要的資產(chǎn)——本機代幣——安全地存儲在由用戶提交的代碼控制的數(shù)據(jù)結(jié)構(gòu)中。厲害了！
1. 到底什么是Resource？
我們可以通過一個不可替代代幣（NFT）的示例（例如CryptoKitty）來理解Resource。每個CryptoKitty都是不可分割、不可復制的，并且有一個直接所有者，這與Resource編程結(jié)構(gòu)是相吻合的。
在像Ethereum這樣的Ledger模型中，所有的CryptoKitties都以巨型列表的形式被存儲在一個智能合約中。
通過在中央分類賬中存儲每個所有者的帳戶ID來跟蹤每個Kitty的所有權(quán)，更改Kitty所有權(quán)的唯一方法是聯(lián)系該中央分類賬并要求其更新與該Kitty相關(guān)的帳戶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)實世界中一樣，通過占有來表示所有權(quán)。
你無需通過中央分類帳來查看自己是否擁有某物，你可以把它存在自己的帳戶中，也可以不存。如果你擁有它，你就可以對其進行轉(zhuǎ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）
注意：為了將重點放在分類賬和直接所有權(quán)模型之間的差異上，上面的兩個例子都忽略了訪問控制、定義每個變量、以及實時代碼相關(guān)的其他因素。
簡而言之，將某個東西標記為Resource就是在告訴編程環(huán)境：這個數(shù)據(jù)結(jié)構(gòu)代表了某種有形的價值，與該數(shù)據(jù)結(jié)構(gòu)進行交互的所有代碼都需要遵循一系列特殊的規(guī)則，以維護該數(shù)據(jù)結(jié)構(gòu)的價值。
那么，這些規(guī)則都有什么呢？
1.每個Resource 在某一時刻只能存在于一個地方。Resources不能通過編程錯誤或惡意代碼進行復制或意外刪除。
2.Resource 的所有權(quán)由其存儲位置決定。在確定所有權(quán)時，無需查閱中央分類賬。
3.只有所有者可以對Resource上的方法進行訪問。例如，只有CryptoKitty的所有者才可以產(chǎn)生新Kitty。
2. 為什么Resource非常重要？
就像簡介中提到的，智能合約特別適合管理貴重資產(chǎn)的所有權(quán)，但是大多數(shù)編程語言（甚至是專門為智能合約而設(shè)計的編程語言）都沒有任何用于管理所有權(quán)的本機抽象（native abstractions）。在協(xié)議級中包含這樣的抽象顯然意義重大。
但是，使用Resources還有一些其他值得一提的好處：
· 狀態(tài)租金（State Rent）
可擴展的智能合約平臺需要通過某種方式來收取狀態(tài)租金（state rent），以便為存儲在區(qū)塊鏈上的數(shù)據(jù)支付費用或?qū)⑵鋸墓ぷ骷袆h除。
在分類賬模型下，很難知道該由誰來支付這些租金。例如，CryptoKitties合約代表了數(shù)以萬計的用戶，有近200萬Kitties和超過111MB的鏈上數(shù)據(jù)。Ethereum無法公正地向所有這些Kitty所有者收取租金。
通過使用Resource Types的直接所有權(quán)模型，可以將每個Kitty都（與該用戶的其他資產(chǎn)一起）存儲在其所有者的賬戶中。支付存儲付費的責任十分明確。此外，個人用戶（在其客戶端軟件的幫助下）可以歸檔未使用的資產(chǎn)，以降低成本并減少網(wǎng)絡(luò)負載。
· 靈活所有權(quán)（Flexible Ownership）
將分類賬模型用于所有權(quán)會限制可用的所有者關(guān)系種類。例如，ERC-721為NFT定義了一個所有權(quán)模型，該模型假定只有Ethereum地址才能擁有NFT。然而，在某些用例中，資產(chǎn)本身擁有其他資產(chǎn)（比如CryptoKitty擁有一副漂亮的墨鏡）的想法非常有意思，這就需要創(chuàng)建新的規(guī)范（ERC-998）。
不可否認，ERC-998非常強大，但它也比ERC-721要復雜得多。要想正確地執(zhí)行該規(guī)范是非常困難的，而且實際上，要將其有效地應(yīng)用于現(xiàn)有的ERC-721資產(chǎn)是不可能實現(xiàn)的。
直接所有權(quá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)的強大機制，能夠讓遵循最小特權(quán)原則（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
去年，在對更好的智能合約語言進行了學術(shù)研究后，F(xiàn)low開發(fā)團隊調(diào)查了區(qū)塊鏈環(huán)境下Linear Types的使用。幾乎在同一時間，Libra的團隊發(fā)布了其最初公告，其中包括MoveVM的技術(shù)細節(jié)。
學術(shù)研究：
http://www.cs.cmu.edu/~balzers/publications/digital_contracts_as_session_types.pdf
Resource Types的強大功能令我們震驚，它是Flow的智能合約編程語言Cadence的定義功能之一。Resources解鎖了比EVM或WASM更豐富的可組合性選項，是數(shù)字資產(chǎn)的完美選擇（尤其是NFT！）
可組合性：
https://hackernoon.com/software-composability-in-crypto-a705700c3816
Cadence具有舒適的、符合人體工程學的語法，易于閱讀。它通過一個強大的靜態(tài)類型系統(tǒng)來最大程度地減少運行時錯誤，并且允許所有方法、接口和事務(wù)包含前置和后置條件，以強制執(zhí)行預(yù)期的行為。我們認為，這會使語言變得更易于學習和審核，最終，會比現(xiàn)有的所有選擇都更加高效。
責任編輯；zl
工商網(wǎng)監(jiān)
評論