井通与 libra的对比分析

2019年6月18日，Facebook 旗下 Libra 官网上线，并发布了白皮书。根据白皮书，Libra 将建立一套简单的、无国界的货币、服务于数十亿人的金融基础设施。Libra 一经推出就受到了广泛关注，引发了激烈讨论和各国监管层的担忧。也有意见认为Libra融合了区块链技术和比特币的优势，升级了技术和发行机制，实现了普惠金融。

2020年4月16日，Libra 协会发布了新版白皮书，增加了大量关于合规方面的设计。

本文无意去加入以上关于 Libra 的金融与政策层面话题讨论，而是拨云去雾，希望从技术角度去理解 Libra 所构建的区块链世界。全部资料来源于 Libra 项目白皮书，另外目前 Libra 还在开发过程中，讨论仅限于白皮书中已经披露的技术细节。

根据白皮书所述，Libra 区块链是一个基于 Libra 协议的加密认证的分布式数据库。我们简略探讨下 Libra 协议的核心概念，并将其与我们已经在应用的、纯自主的井通 Jingtum 区块链做一下简单对比。

交易和状态

Libra 协议的两个核心基本概念为交易和状态在任一时间点，区块链都有一个所谓的状态。状态(或成为分布式账本状态)表示区块链上数据此时的快照。交易的执行会改变区块链的状态。

图 1.1 展示了执行交易时，Libra 区块链的状态变化。例如，在状态"S(N-1)"时，Alice 的余额为 110 Libra 币，Bob的余额为 52 Libra 币。交易发生后，区块链生成一个新的状态。在状态"S(N)"的前提下，交易"T(N)"发生，则状态由"S(N-1)"变更为"S(N)"。Alice的余额减少 10 Libra 币，Bob的余额增加了 10 Libra 币新的状态"S(N)"展示了状态更新后的账户余额情况。在图 1.1 中:

● A and B 分别代表Alice和Bob在区块链上的账户。 ● S(N-1) 代表区块链中第(N-1)个状态。 ● T(N) 代表区块链中执行的第N个交易。

从图中的例子可以看出，T(N)代表的交易是：从A账户中转 10 Libra 币到B账户中。

● F 为一个确定性函数。在特定的初始状态执行特定的交易， F 函数总会返回相同的最终状态。如果当前区块链状态为S(N-1)，执行交易 T(N)，则返回的新状态恒为S(N)。 ● S(N) 代表区块链的第N个状态。S(N)为将函数F应用于S(N-1)和T(N)的结果。

此处，井通 Jingtum 的过程和 Libra 是一样的，但是在第四步中确保交易的最终状态略有不同。Libra 协议使用 Move 语言来实现函数 F 的确定性执行，可以理解为合约层；而 Jingtum 底层是通过 TX 层负责处理最基本的 transaction ，在此之上增加一个合约层，负责处理合约。我们将合约的要素(code，state, storage，transaction)分开，transaction 的执行下传到 Jingtum 的 TX 层，其他部分的执行在合约层实现。这样使得合约的执行与产生的交易分开，使得合约和交易从各自的特点来匹配相应的协议，以达到最高的效率和最大的安全。

交易

Libra 区块链客户端通过提交交易请求来更新分布式账本状态。区块链上一个签名交易包括：

● 发送方地址 — 交易发起者的账户地址。 ● 发送方公钥 — 用于签署交易的私钥所对应的公钥。 ● 程序 — 程序包括以下内容：

一个Move语言的字节码交易脚本； 可选的输入列表：在点对点交易中，输入包括接受者信息及金额； 可选的Move字节码模块部署列表；

● Gas价格 — 以 microlibra/gas 为单位—执行交易时，发送方愿意为一单位 Gas 所支付的价格。Gas 是用来支付在区块链上计算和存储费用。每一 Gas 单位是对计算量的抽象度量； ● Gas上限 — 交易允许消耗的 Gas 最大值； ● 序号 — 无符号整型，必须和发送者账户中的序列号相等； ● 有效期 — 交易的有效截止时间； ● 签名 — 发送者的数字签名。

交易脚本是任意包含对交易逻辑编码的程序，能够与 Libra 区块链中发布的数字资产进行交互。

注：其中程序就是上文中指的 F 函数。不同点已在上文指出

分布式账本状态

分布式账本状态，又称为 Libra 区块链全局状态，是区块链上所有账户状态的集合。想要执行交易，每个 Validator 必须获得区块链上分布式数据库的最新全局状态。

此处与井通 Jingtum 区块链一致。

版本化数据库

Libra 区块链上的所有数据都存储在一个单一版本化的分布式数据库上。版本号为无符号的64位整数，与系统内已经执行的交易数量相对应。

版本化数据库允许 Validator：

● 在最新的全局状态下进行交易； ● 响应客户端发送的对当前或历史全局状态的请求。

此处与井通Jingtum区块链一致。

账户

Libra 账户包括 Move 模块和 Move 资源。由账户地址标识。这也意味着每个账户的状态都包含代码和数据两方面。

● Move模块 包含代码(类型和过程声明)，但不包含数据。模块中的子程序对区块链全局状态的更新规则进行编码。 ● Move资源 包含数据不包含代码。每个资源的类型都应在区块链的分布式数据库中已发布模块里声明过。

账户可以包含任意数量的 Move 资源和 Move 模块。通俗点讲，Move 资源就是该账户运行的合约，Move 模块就是该账户的状态。而 Jingtum 区块链暂时没有 Move 资源这个概念，只有账户的状态。

账户地址

Libra 账户地址为一个256位的值。用户可以使用电子签名来声明地址。对于一个账户，其地址由用户的公钥通过密码学 Hash（或托管的客户端）生成，用户必须通过相应的私钥签名才能从此账户发起交易。

Libra 对用户的账户地址的数量不做限制。但申请新账户地址时，必须通过另一 Libra 币充足的账户支付申请费用。

此处，关于地址的规则，各种区块链都大同小异；对于每个Libra账户，都需要支付申请费用，井通 Jingtum 区块链同样也是需要对每个地址进行激活，才能使用。

证明

Libra 区块链上的所有数据都存储在一个单一版本化的分布式数据库上，存储被用来对交易区块和交易结果的持续确认。区块链是一个不断增长的 Merkle 交易树. 每次区块链上有新的交易执行，交易树都会增加一片“叶子”。

● 证明是验证 Libra 区块链中数据真实性的一种方式； ● 区块链上存储的每个操作都可以进行加密验证，结果性证明也可以证实没有数据缺损。例如，如果客户端发送了对最新的 n 笔交易的查询请求，证明可以验证查询响应中没有遗漏任何一笔交易记录。

在区块链中，客户端不需要信任接受数据的实体。客户端可以查询账户余额，以及特定交易的交易状态等。与其他 Merkle 树类似，分布式账本记录可以对特定的交易提供 O(log n)时间复杂度证明， n 为处理的交易总量。

Validator 节点 (validator)

Libra 区块链的客户端创建交易并提交到 Validator 节点。Validator 节点（和其他 Validator 节点共同）运行共识协议，执行交易，并将交易和执行结果存储在区块链中。Validator 节点判定哪些交易可以被添加到区块链上，以及以何种次序添加。

Validator 节点 包括以下逻辑组件：

准入控制 (AC)

● 准入控制是 Validator 节点的唯一外部接口。客户端向 Validator 节点发送的任何请求都将先转入AC； ● 准入控制通过对请求进行初始检查，来保护 Validator 节点的其他部件免受损坏或大量输入的影响。

目前井通 Jingtum 区块链的准入控制是人工审核，这方面有待优化。

内存池

● 内存池是一个缓存区，用于保存“等待”执行的交易。 ● 当一个内存池中添加了新交易时，这个内存池会和系统中其他 Validator 节点的内存池共享此交易。

井通 Jingtum 区块链同样也有内存池的概念，主要用于处理交易和快速查询。

共识

● 共识组件负责判断交易区块的顺序，并与区块链中其他的 Validator 节点在共识协议下共同决定执行结果。

Libra 共识和井通 Jingtum 共识同属 X-BFT 拜占庭容错共识，效率问题得等Libra 上线之后再验证了。

执行

● 执行组件利用虚拟机（VM）交易。 ● 执行组件的作用是协调一个区块中的交易的执行，并维护一个可用于协商投票的瞬时状态； ● 执行组件维护内存中执行结果，直至共识组件允许其被提交到分布式数据库。

Libra 的交易执行都放在了虚拟机中执行，即合约层；而井通 Jingtum 区块链进行了分层，最基本的交易下沉到了交易层，其余交易在合约层执行。

虚拟机 (VM)

● 准入控制和内存池借助虚拟机组件对交易进行校验。 ● 虚拟机用于运行交易中所包括的程序，并确定结果。

存储

● 存储被用来持久化保存已确认的交易区块和交易结果。

小结

从上文的探讨中我们可以发现，Libra 从基本的设计结构和流程上，应该是选择了一条积极稳妥的技术路线，立足于现有成熟技术进行部分创新，这也符合其超大规模应用的特点。通过与国内自主井通 Jingtum 区块链底层的简单比较，我们也有似曾相识燕归来之感。

也许对于超大规模应用，可选择的路线并不太多，殊途终会同归。