Move: A Language With Programmable Resources:区块链如何管理数字资产

区块链如何管理数字资产

区块链之抽象

区块链是一个复制的状态机。系统中的复制器称为验证器。系统用户将交易事务发送给验证器。每个验证器都了解如何执行交易，内部状态机就会把当前状态转换为新的状态。

交易详情都是共享的，验证器根据共识协议（Consensus protocol）来执行交易，这些验证码会集体决定状态如何以及维护和复制状态。如果

• 验证器从相同的初始状态开始，并且
• 验证器同意下一笔交易应该是怎样，以及
• 执行交易会产生最终确定的状态转换，那么验证器也就会同意下一个状态如何。

如果当前状态达成一致就如此反复地让不同的验证器执行交易。请注意，共识协议和状态转换组件对彼此的实现细节不敏感。只要共识协议确保交易之间的总顺序不会错且状态转换方案是最终的，那么组件之间就可以协调地进行交互。

在一个开放系统中编码数字资产

像 Move 这样的区块链编程语言，其本质就是状态的转换和状态的表述。为了支持大量的金融基础设施，Libra 区块链必须支持在给定的时间点对数字资产的所有者进行编码。此外，状态的转换应该包含资产转移。

区块链编程语言设计还必须考虑的一个因素。与其他公共区块链一样，Libra 区块链是一个开放系统。任何人都可以查看当前的区块链状态或将交易提交给验证器（即状态转换）。传统上，用于管理数字资产（例如银行软件）的软件在封闭系统中运行控制。而在公共区块链中，所有参与者都处于平等地位。参与者可以提出他喜欢的任何状态转换，但系统不应允许所有状态转换。例如，Alice 可以自由地提出转移 Bob 所拥有的资产的状态转换。状态转换函数必须能够识别此状态转换无效并拒绝它。

选择在开放软件系统中编码数字资产所有权，并允许状态的转换，——这非常有挑战性。特别是，现实中有两种资产的属性在数字世界中难以编码的：

• 稀缺性。系统中的资产的供应应要控制。禁止复制现有的资产，创建新资产应当是特权的操作。
• 访问控制。系统中的参与者应使用访问控制策略保护其资产。

现在我们举个例子，假设我们的数字货币是叫做“空气币”。区块链系统 G 是一个类似 Map 结构的键值存储。key 是用户身份，也就是用户加密后的公钥，映射到该用户所持有的空气币数量。首先提出第一个方案，根据该方案的规则有一个交易脚本，运行该脚本返回一个结果，该结果会影响到全局状态。我们用一个表达式 G [?]：=? 来表示在全局区块链更新存储在密钥 ? 处的空气币数量 n。

提出该方案目的是为了 Alice 将空气币发送给 Bob，貌似简单但是有两个大问题未说的——我们下面会讲。另外，当前不是要解决安全问题，例如重播攻击，虽然这些问题很重要，但与稀缺性和访问控制的讨论无关。

稀缺性问题

要进行更新交易，那很简单，对 K 用户设置一下 n 数量就好了：

上面左边是脚本的方式，需要 K 和 n 两个参数；右边是执行的规则，对 Map[K] 设置保存 n 的意思，——两者都是表示 Alice 转给 Bob 空气币。它有几个严重的问题。首先，这个提方案未考虑空气币的稀缺性。爱丽丝可以凭空给自己发送交易⟨Alice，100⟩，随便多少都可以——那果然是“空气币”。因此，爱丽丝发给鲍勃的空气币实际上毫无价值，因为鲍勃同样可以很容易地为自己创造这些币。

稀缺性是现实世界实物资产的重要属性，像黄金那样的稀有金属固然稀缺，数字资产物理上却没有那样的稀缺性。所谓数字资产，简单编下码就可以修改，例如 G [Alice]→10，或者拷贝一下，例如 G [Alice]→100。那样肯定乱套，于是我们必须在编码中强制约束，引入稀缺性的约束。

为此，我们考虑第二个有关稀缺性的方案：

在此方案下，交易脚本指定发件人 Alice 的公钥 ?? 和收件人 Bob 的公钥 ??。现在运算规则在执行任何更新之前先检查是否有足够 n 数量的空气币 ，如果成功，评估规则从存储在发送者密钥下的空气币中减去 n，并将 n 添加到接收者密钥下。在此方案下，爱丽丝再也无法凭空创造出空气币- 她只能从她的账户中扣除给的 Bob 空气币，所谓稀缺性的约束正是如此。

访问控制

虽然第二个方案解决了稀缺问题，但它仍然存在问题：Bob 可以执行属于 Alice 的交易！例如运算规则不会阻止 Bob 发送交易 ⟨Alice，100，Bob⟩。我们可以基于数字签名的访问控制机制（Access control）解决这个问题。

此方案要求 Alice 对交易脚本用私钥进行签名。我们使用公钥 K 和私钥一起对消息 m 进行签名，写作 ? ? (m)。评估规则使用 verify_sig() 函数验证 Alice 的公钥 ? 是否合法签名。如果签名没通过则不执行更新。新规则通过数字签名的不可伪造性来防止 Alice 从除她自己以外的任何帐户中扣除空气币，从而解决了之前方案存在的问题。

另外，请注意第一个方案实际上不需要评估规则——它是直接更新键值存储。但随着我们不断改进，出现了一些判断才能继续操作。

译自《Move: A Language With Programmable Resources》第二节