APP
Resources为区块链上的所有权编程
2020-03-16 17516 0

智能合约是一个独特的软件,专门用于管理有价值的数字资产的所有权。尽管现有的编程环境可以用来跟踪资产的所有权,但它们通常用于反映所有权而不是直接定义所有权的场景。智能合约的独特之处在于,它们所代表的价值往往直接体现在它们所维护的状态中。



随着区块链的发展,代表所有权的机制也在发展。比特币是使用由“未使用的交易输出”或UTXOs定义的所有权模型构建的。



虽然UTXO模型非常高效,但它非常复杂,可能会产生一些不寻常的边缘情况,因此Ethereum采用了一种更简单的分类模型。



当Libra区块链宣布时,围绕该项目的主要兴趣在于Facebook建立的区块链的政治含义,但我们这些深入研究技术细节的人发现了一些非常有趣的新想法。



尤其是,Libra团队为他们的MoveVM定义了一个新的编程模型,该模型是围绕着一个新的所有权模型(受Linear Types:Resources启发)定义的。



Resources是在编程语言中直接表示资产所有权的一种新方法。工程师经常用“所有权”这个词来比喻跟踪哪个代码负责管理某种数据结构或系统Resources。



这种比喻在编程环境中最常见,在这种环境中,内存管理并没有完全从程序员那里抽象出来,说代码“拥有”一个对象,意思是说代码必须管理和释放分配给该对象的内存。



Resources扩展了这个想法,因此我们可以利用以前编程语言中的一些管理隐喻“所有权”的机制,并使用它来管理本地数字资产的真正所有权。



Move的关键特性是定义自定义Resources类型的能力。Resources类型用于编码具有丰富可编程性的安全数字资产。



Move系统为Resources提供了特殊的安全保障。不能重复、重用或丢弃Move Resources。Resources类型只能由定义该类型的模块创建或销毁。这些保证由Move虚拟机静态强制实施【...】



Libra货币是作为一种Resources类型来实现的,并且在语言中没有特殊的地位,每一个Move Resources都享有相同的保护。



最后两点非常重要:



1.Resources对象的特殊状态必须由运行时(“Move虚拟机”)强制实施;如果它们只是一个编译器抽象,恶意代码就很容易破坏值保证。



2.然而!如果您正确地执行了这些规则,您就可以允许网络最重要的资产——本机代币——安全地存储在由用户提交的代码控制的数据结构中。多强大!



那么Resources到底是什么呢?



最简单的方法是使用非可替换代币(NFT)的示例来思考,比如加密猫。每个加密模块都是不可分割的、不可复制的,并且可以有一个直接所有者,直接与Resources编程结构匹配。



在像以太坊这样的分类账模型中,所有的加密猫都存储在一个智能契约中,形成一个巨大的列表。



每只猫的所有权是通过将每个所有者的账户ID存储在一个中央分类账中来跟踪的,改变猫的所有权的唯一方法是联系该中央分类账,并要求它更新与该猫相关联的账户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)
}

在Resources模型中,猫本身被表示为一个Resources对象,它直接存储在拥有它的帐户中。就像在物质世界里,所有权是以占有为代表的。

你不需要查看中央分类账来查看你是否拥有某样东西,你可以把它存在你的账户里,也可以不存在。如果你有它,你可以转移它或以其他方式控制它,如果你没有,就没有办法捕捉或改变它。

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)
}

注意:为了保持对分类账和直接所有权模型之间差异的关注,上面的两个例子忽略了访问控制、定义每个变量以及活代码需要考虑的其他因素等问题。

简而言之,将某个东西标记为“Resources”告诉编程环境,这个数据结构代表某种有形的价值,与该数据结构交互的所有代码都需要遵循一系列特殊的规则,这些规则将维护该数据结构的价值。

那么,这些规则是什么呢?

1.每个Resources在任何给定的时间都恰好存在于一个地方。无论是通过编程错误或恶意代码,Resources不能被复制或意外删除。
2.Resources的所有权是由其存储位置来定义的。 在确定所有权时,不需要查阅中央分类账。
3.对Resources上方法的访问仅限于所有者。 例如,只有加密猫的主人可以启动育种操作,从而导致新猫的诞生。

为什么Resources很重要?

正如在引言中提到的,智能合约是唯一适合管理有价值资产所有权的,但大多数编程语言——甚至是那些专门为智能合约设计的编程语言——都没有任何本地抽象来管理所有权。在协议级别上包含这样的抽象显然是一个巨大的胜利。

但是使用Resources还有其他一些次要的好处,每一个都是非常重要的:

州租金

可扩展的智能合约平台需要某种方式来收取“州租金”,这样存储在区块链上的数据要么需要支付费用,要么从工作集中删除。

根据分类账模型,很难知道谁应该支付这笔租金。例如,加密猫合约代表了数以万计的玩家,拥有近200万只小猫和超过111Mb的链上数据。以太坊没有办法公平收取租金给所有这些猫主人。

使用通过Resources类型的直接所有权模型,每只小猫将存储在其所有者的帐户内,以及该人的其他资产。谁需要为存储支付费用的责任是明确的。更重要的是,个人用户(在他们的客户端软件的协助下)可以存档未使用的资产,以减少他们的成本和减少网络上的负载。

灵活所有权

使用分类账模型进行所有权限制了可用的所有者关系的种类。例如,ERC-721为NFTs定义了一个所有权模型,该模型假定只有以太坊地址才能拥有NFT。然而,在某些用例中,资产本身拥有其他资产(比如加密猫拥有一副漂亮的太阳镜)的想法非常有趣,需要创建一个新的规范(ERC-998)。

ERC-998是非常强大的,但它也比ERC-721复杂得多。正确地实施它是非常困难的,并且追溯性地将它的特性应用到现有的ERC-721资产实际上是不可能的。

直接所有权模型允许任何使用Resources类型建模的资产被安全地存储在系统中的任何地方,包括在适当的情况下“内部”其他资产。

运行时系统可以维护所有的安全性和价值保证,同时为开发人员释放创造性的灵活性,而不会带来不必要的复杂性。

基于能力的安全性

Resources类型提供了实现基于能力的安全模型的“功能”概念所需的所有保证。能力是定义安全系统的一个强大机制,并且可以使遵循最小特权原则(安全系统中常见的最佳实践)变得容易得多。

基于能力的安全模型通常被认为更容易推理(这提高了安全性),同时允许更大的灵活性。

消除重入性缺陷

以太坊历史上最著名的智能合约漏洞源于可重入性问题,可靠的开发人员需要不断提高警惕,防止引入易受可重入性攻击的逻辑流。

幸运的是,在Resource对象上定义的方法不能成为任何重入的受害者。

这似乎是一个大胆的主张!然而,从如何定义Resource就可以很自然地得出这样的结论:每个Resource都有一个单独的所有者,并且只有Resource的所有者可以调用它上的方法。如果Resources方法是“在堆栈上”,那么我们就知道对该对象的单一所有权引用已经在使用了;对于我们从该方法内部调用的任何代码——无论多么间接地——都不可能获得对该对象的第二个引用来进行可重入的方法调用。

当然,直接使用全局共享状态(绕过Resources对象的使用)仍然可以创建易受重入错误影响的代码。

这就是为什么惯用的Cadence风格是为所有共享状态使用Resources的原因;拥抱Resources的智能契约作者再也不用考虑可重入性漏洞了!

Flow的编程语言Cadence使用Resources

去年,Flow开发团队在对更智能的契约语言进行学术研究后,调查了区块链环境下线性类型的使用。几乎在同一时间,Libra团队发布了他们的初步声明,包括MoveVM的技术细节。

我们对Resources类型的力量感到震惊,它是Cadence的定义特性之一,Flow的智能合约编程语言。Resources解锁了比EVM或WASM更丰富的可组合选项,并且非常适合数字资产(尤其是NFTs!)

Cadence有一个舒适的,符合人体工程学的语法,使它很容易阅读。它使用一个强大的静态类型系统来最小化运行时错误,并允许所有的方法、接口和交易都包含预条件和后条件来强制实现预期的行为。我们认为,这将导致一种语言更容易学习,更容易审计,并最终比任何现有的替代方案更有效率。

内容来源:区块网社区 作者:Dieter Shirley

版权声明:本文仅为传播消息之用,不代表币源社区立场,文章不构成投资建议。如需转载,请务必注明文章原作者以及来源,部分图片来源于网络,我们尊重版权,如有疑问敬请联系,我们将核实并删除。

我要评论
字数上限500
评论(0)