MOVE：一种将资源可编程化的语言

作者：Sam Blackshear, Evan Cheng, David L. Dill, Victor Gao, Ben Maurer, Todd Nowacki, Alistair Pott, Shaz Qadeer, Rain, Dario Russi, Stephane Sezer, Tim Zakian, Runtian Zhou*

译者注

本白皮书具有以下创新：

* 将数字资产(Digital Assets)归到资源(Resources)
* 不再提不可篡改，而是主要提资产的不可复制性

摘要

我们设计了Move，一种在Libra区块链上安全灵活的编程语言[1][2]。 Move是一种可执行的字节码语言，用于实现自定义交易事务(transaction)和智能合约(smart contract)。 Move的关键特性是能够用受线性逻辑启发的语义来自定义资源类型[3]：资源（译者注：在这里指的是资产）是永远不会被复制或莫名其妙灭失的，只能在程序（或数据）存储位置之间移动。这些安全保障在系统层面由Move的数据类型强制执行。尽管有这些特殊保护，但资源仍旧是在程序中的普通的数据 - 它们可以存储在数据结构中，或者作为参数传递给进程等等。一流的资源是一个非常通用的概念，程序员不仅可以用它来实现安全的数字资产，还可以编写正确的业务逻辑来描述资产并实施访问控制策略。Move的安全性和表现力使我们能够在Move中实现Libra协议的重要部分，包括Libra币，交易处理和验证器管理。

1. 介绍

互联网和移动网络的出现连接了全球数十亿人，提供了知识传播、免费通信和各种低成本、便捷的服务。这种连接还使更多人能够访问金融生态系统。然而，尽管取得了这些进展，但对于那些最需要金融服务的人来说，能获得金融服务仍然有限。

Bibra的使命是改变这种状况[1]。在本文中，我们提出了Move，一种用于在Libra协议中实现自定义事务逻辑和智能合约的新编程语言[2]。为了介绍Move，我们：

1.在第二节中，描述了在区块链上表示数字资产的挑战。

2.在第三节中，解释了我们的Move设计如何应对这些挑战。

3.在第四节中，给出了一个面向实例的全景模型，用来了解Move主要特性和编程模型。

4.在第五、六和附录A中，我们深入了解语言和虚拟机设计的技术细。

5.在第七节中，我们总结了在Move方面取得的进展，描述我们的语言演变计划，并概述我们支持Libra区块链上的第三方移动代码的路线图。

关于受众

本文面向两类不同的受众：

• 可能不熟悉区块链系统的编程语言研究人员。

我们鼓励这些读者完整仔细地阅读本文，但友情提示，对那些并不太熟悉区块链的读者，有时候我们在提及区块链概念时，并没有提供足够的参考来做专业解释。

尽管在研究本文前，通过阅读些有关的参考资料可能会有帮助，但并没有绝对的必要。

• 区块链开发人员，他们可能并不熟悉编程语言，但有兴趣了解Move语言。

我们鼓励这些读者从第3节开始。我们提醒大家，第5节，第6节和附录A中会包含一些大家并不太熟悉的编程语言术语和规范。

2.在区块链上如何管理数字资产

我们将首先简要地解释一个抽象级别的区块链，以帮助读者理解“区块链编程语言”（如Move）所扮演的角色。

本讨论有意省略了区块链技术的许多重要细节，以便专注于从语言角度来看相关的特征。

2.1 关于区块链的概述

区块链是一个可被复制的状态机[4][5]。这个可被复制的机制称为验证人(Validators)。系统的用户将事务发送给验证人，每个验证人都了解如何执行事务，并将其内部状态机从当前状态转换为新状态。

验证人基于一个共同遵循的共识协议，以及他们对交易执行的共同理解，来维护状态更新。即：

如果：

• 验证人从相同的初始状态开始，并且

• 验证人就下一个交易应该是什么达成一致，并且

• 执行交易会产生确定性的状态转换，

那么：

验证人就会就下一个状态是什么达成一致。反复以上流程，验证人就能在与当前状态保持一致的情况下进行交易事物的处理。

请注意，共识协议和状态转换组件对彼此的实现细节不敏感。只要共识协议确保各事务之间的先后顺序，并且状态转换方案是确定性的，则各组件之间就能协调地交互。

2.2 在一个开放的系统中对数字资产进行编码

像Move这样的区块链编程语言的作用是决定如何交易以及状态转换。为了支持丰富的金融基础业务，Libra区块链的状态必须能够在给定的时间点对数字资产的所有者进行编码确权。此外，Move还应该允许资产的转移（译者注：或者称为转让与交易）。

还有一个在区块链编程语言设计时必须要考虑的因素，就是与其他公共区块链一样，Libra区块链是一个开放系统。任何人都可以查看当前的区块链状态或将事务提交给验证人（即，状态转换）。而传统上，用于管理数字资产（例如，银行软件）的软件则运行在具有特殊功能，且受到特殊监管的封闭系统中。

在公共区块链中，所有参与者都处于平等地位。参与者可向系统提交她喜欢的任何状态转换申请，但系统并不应允许所有状态转换操作。

例如，Alice可以自由地提交希望转移Bob的资产的状态转换事情。状态转换函数必须能够识别此状态转换无效并予以拒绝。

在开放的系统中对数字资产所有权进行编码确权和状态转换具有很强的挑战性。特别是，物理资产有以下两种属性难以在数字资产中进行编码确权：

• 稀缺性

即：① 在该系统中，资产的供应需要得到控制（译者注：即不能乱发数字资产）

② 严禁复制现有资产

③ 创建新资产时应该在一定的授权下操作（译者注：即发币需要得到授权）

• 访问控制

即系统中的参与者应该能够使用访问控制策略保护其资产。

直觉上，我们会看到在一系列关于状态转换的请求中是如何出现这些问题的。我们假设在区块链上来跟踪一个名为StrawCoin的数字资产。区块链状态G被构造为键值（key-value）的数据结构，G将用户身份（用加密公钥表示）映射到每一个用StrawCoin作为单位的自然数值（译者注：即每个公钥拥有多少个StrawCoin的数字资产）。请求由一个事务脚本组成，该脚本将使用给定的评估规则进行评估，从而生成应用于全局状态的更新。我们将用

G[𝐾]：= 𝑛

来表示在区块链全局中，键值为K的状态改变成为 𝑛

每个请求的目标是设计一个足够清晰的系统，允许Alice将StrawCoin发送给Bob，但又足以阻止用户任何违反稀缺性或访问控制的操作。这些请求并未尝试解决安全问题，例如重放攻击[6]，这些问题很重要，但这里与我们关于稀缺性和访问控制的讨论无关。

稀缺性

首先，来看最简单的状态转变请求，也就是在脚本中直接更新状态，如下图：

该请求可以表示Alice发送StrawCoin到Bob。

但它有几个严重的问题。

首先，这个请求没有强制对StrawCoin进行稀缺性审查。

通过发送交易⟨Alice，100⟩，爱丽丝可以“凭空”给自己尽可能多的StrawCoin。 因此，Alice发给Bob的StrawCoin实际上是毫无价值的，因为Bob也可以很容易地为自己创造这些币。

稀缺是宝贵的实物资产的重要属性。像黄金这样的稀有金属自然具有稀缺性特点，但数字资产并没有固有的物理稀缺性。

通过编码方式改变数字资产状态要比物理方式生成或者复制资产要简单的多，例如G[Alice]→10，与G[Alice]→100相差并不大。相反，重要的是在评估规则中加入强制性的稀缺性审查。

让我们继续考察第二种需要考虑稀缺性的请求：

Under this scheme, the transaction script specifies both the public key 𝐾𝑎 of the sender, Alice, and the public key 𝐾𝑏 of the recipient, Bob. The evaluation rule now checks that the number of StrawCoin stored under 𝐾𝑎 is at least 𝑛 before performing any update. If the check succeeds, the evaluation rule subtracts 𝑛 from the StrawCoin stored under the sender’s key and adds 𝑛1 to the StrawCoin stored under the recipient’s key. Under this scheme, executing a valid transaction script enforces scarcity by conserving the number of StrawCoin in the system. Alice can no longer create StrawCoin out of thin air — she can only give Bob StrawCoin debited from her account. Access control. Though the second proposal addresses the scarcity issue, it still has a problem: Bob can send transactions that spend StrawCoin belonging to Alice. For example, nothing in the evaluation rule will stop Bob from sending the transaction ⟨Alice, 100, Bob⟩. We can address this by adding an access control mechanism based on digital signatures:

在此方案下，事务脚本指定发件人Alice的公钥Ka和收件人Bob的公钥𝐾𝑏。现在，评估规则检查在执行任何更新之前存储在𝐾𝑎下的StrawCoin的数量是否至少为1/3。如果检查成功，评估规则从存储在发送者密钥下的StrawCoin中减去and，并将𝑛1添加到存储在接收者密钥下的StrawCoin中。在此方案下，执行有效的事务脚本通过保留系统中的StrawCoin数量来强制执行稀缺。爱丽丝再也无法凭空创造出StrawCoin - 她只能从她的账户中扣除Bob StrawCoin。 访问控制。虽然第二个提案解决了稀缺问题，但它仍然存在问题：Bob可以发送使用属于Alice的StrawCoin的交易。例如，评估规则中的任何内容都不会阻止Bob发送事务⟨Alice，100，Bob⟩。我们可以通过添加基于数字签名的访问控制机制来解决这个问题：

4. Move全貌

We introduce the basics of Move by walking through the transaction script and module involved in a simple peer-to-peer payment. The module is a simplified version of the actual Libra coin implementa- tion. The example transaction script demonstrates that a malicious or careless programmer outside the module cannot violate the key safety invariants of the module’s resources. The example module shows how to implement a resource that leverages strong data abstraction to establish and maintain these invariants. The code snippets in this section are written in a variant of the Move intermediate representation (IR). Move IR is high-level enough to write human-readable code, yet low-level enough to have a direct translation to Move bytecode. We present code in the IR because the stack-based Move bytecode would be more difficult to read, and we are currently designing a Move source language (see Section 7). We note that all of the safety guarantees provided by the Move type system are checked at the bytecode level before executing the code.

我们通过简单的点对点支付中涉及的事务脚本和模块介绍Move的基础知识。该模块实际上是Libra币的简化版本。