libra区块链技术白皮书-中文部分翻译版

模块这个概念其实很类似以太坊存在账户里的evmCode。在以太坊的智能合约是包含代码和数据的，在libra里，模块包含代码，资源包含数据值。从面相对象的角度看，以太坊类似一个账户对应一个单一对象。而libra，模块是创建资源的方法，一个模块可应用于多个不同账户创建任意数量的资源。（注解：相当于libra抽象出模块来让智能合约的代码更加重用而已，它的粒度更细致）

Move虚拟机

Move虚拟机为move字节码实现了一个验证器和解释器。字节码以基于堆栈的虚拟机为目标，具有本地过程运算堆栈和寄存器。通过goto和标签实现非结构化的控制流。

开发人员使用move中间代码来编写事务脚本或者模块，然后编译成move字节码。编译的过程会转换结构化的控制流（例如条件和循环）为非结构化的控制流，会转换复杂的表达式为少量的字节码指令。Move虚拟机执行一个事务，首先会检验事务，检验通过后就运行字节码。

Move VM支持少量类型和值：布尔值，无符号64位整数，256位地址，固定大小字节数组，结构（包括资源）和引用。结构字段不能是引用类型，这会阻止在分类帐状态中存储引用。

Move虚拟机没有堆，本地数据是分配在栈上，在分配过程返回时释放数据。所有的持久化数据必须存储在分类账本里。

（堆和栈的区别：

栈区（stack）：由编译器自动分配释放，存放函数的参数值，局部变量的值等。其
操作方式类似于数据结构中的栈。

堆区（heap）：一般由程序员分配释放，若程序员不释放，程序结束时可能由OS回收。类似c语言的malloc。

3.经过认证的数据结构和存储

3.2分类账本历史：

Libra使用单个默克尔树为分类账本历史提供经过身份验证的数据结构。事务信息记录的分类账本历史记录，包含以下部分：签名事务，执行事务后的状态验证器，由签名事务生成的事件验证器。

和比特币最大的区别就是：所有的交易构成一个大的默克尔树。不像比特币，只是区块里包含的所有交易构成一颗默克尔树。这样验证时，需要获取之前的区块hash数据才能完整验证是否真实有效。

计算一下是否可能先：

假设一个区块5000条交易，现在比特币的区块数为583390.那么总交易数约为30亿条。

按照olog（n）那么大约需要查找32次（31.4）左右，也就是如果要产生新的所有交易的总默克尔根，只需要传输另外32个hash值，利用这些hash值再和新的交易的hash值进行计算，就能算出新的默克尔树的根。

（注解：貌似这样才更符合逻辑，为什么比特币不这样做呢？之前我一开始接触比特币时，其实也是以为所有交易构成一个颗默克尔树，没想到只是区块里包含的所有交易构成一颗默克尔树。）

修剪存储。

分类帐历史Merkle累加器的根哈希是系统完整状态的验证器。它在系统的每个现有版本，每个发送的事务以及生成的每个事件中提交给状态。虽然第4.3节中描述的状态存储允许有效存储多个版本的分类帐状态，但验证器可能希望减少过去版本消耗的空间。验证器可以自由修剪旧状态，因为它们不是处理新事务所必需的。 Merkle树累加器支持修剪历史数据，只需要O （log n ）存储来追加新记录。

3.3分类账本状态：

对原文这段话的解释：

（大多数区块链，从比特币[ 24 ]开始，维护由共识协议商定的每个交易块的链表，其中包含一个包含单个祖先的散列的块。这种结构导致客户效率低下。例如，信任某个块 B 并且想要验证祖先块 B ' 中的信息的客户端需要获取并处理所有中间祖先。

Libra协议使用单个Merkle树为分类帐历史提供经过身份验证的数据结构。

(解释：比特币的链上的每个区块是否一定有效当前是无法确定的，因为这永远是个概率问题，但对于bft类的算法，每个区块经过法定数量节点签名后就一定是有效可以确定的了。)

）

每个状态（对应就是版本）理论上都有一颗全局的默克尔树。

每个状态/版本都存储全局的默克尔树，这样数据量会非常大，因此每个状态里存储的是一个经过优化的稀疏的默克尔树。其实就是从一个状态s1到s2，s2比s1新增或改变的地址账户，只需要能给出必要的默克尔节点，能得到新的总的根默克尔树hash即可。

如上图，对于一个新状态，新增了A和B和C三个节点，那么对于之前整个默克尔树，只需保留能计算出根hash的节点即可。这时就从第一个图，优化成第二个图。

这样要计算的hash次数还是很多的，这时把每个新增的节点不断往上计算，直到和其他新增的节点相遇或者到根hash的子节点为止。这时就从第二个图优化成第三个图。

经过这两部优化，存储的空间变少了，计算hash的次数也会变少。它和以太坊的mpt树类似，但提供更优的性能。

Libra还考虑了AVL树（平衡二叉树），它比稀疏默克尔树提供更优的最坏情况证明长度。但稀疏默克尔树方法允许实现者进行优化，例如跨服务器分片存储和并行化根哈希计算。

（疑问：从s1到s2，经过了优化和裁剪，那从s2到s3要如何处理？）

3.4.账户

Libra为了减少账户浪费，计划提出使用账户需要缴纳租金，如果到期没有缴纳新租金，虚拟机拒绝访问该账户，从而引发错误。（和比特币和以太坊都不同的地方）

Libra的账户存储资源和模块的集合。这样能为编程提供更好的抽象。以太坊的智能合约存储是直接存储在256位的存储器映射，这种方法可以有效的处理大型账户。

3.5事件

T(i): 表示事务i

E（i）:表示在T（i）执行过程中产生的事件列表。

每一个事件可以表示为（j，（A，p，c））∈ E（i），其中j表示事件的执行顺序，A表示accessPath，事件的结构化接入路径，p表示payload，表示数据的负载，c表示couter value。这里的c其实实现了一种统计指标，代表的是对于接入路径为A的事件，总共产生了多少次。这个数字会存储在账本状态里，并且如果一个交易包含了接入路径为A的事件，那么执行完该交易后，该数字会加1.

事件的机制和体系类似以太坊的事件机制，客户端可以订购指定的事件，通过不同的接入路径A。通过周期性的向验证节点查询接入路径A的总计算值C，如果查询到的C值大约本地的值，证明本地的数据已经过期，需要更新。通过这种方法，客户端可以通过订阅一个监测指定地址的收入交易的事件，来获得该地址的最新的收入交易数据。

解释：图1里的最底层的叶子节点代表的是一个key value的map，key是版本号，value就是TransactionInfo的结构化集合。

TransactionInfo会包含三部分内容：

第一个是经过法定人数签名的事务

第二个是到达这个版本时的账本状态，这个账本状态也是一个默克尔树，为了节省空间，使用优化过的稀疏默克尔树，这个优化过的稀疏默克尔树的叶子节点，也是一个key/value的map，key为用户的256账户地址的hash值，value就是账户包含的内容，可以包含资源和模块。

第三个是事件树，也是一个默克尔树，最底层的叶子节点代表的是从上一个状态到当前状态执行的事件（就是执行事务期间产生的事件集合），事件元组必须包含三部分的数据内容，包括事件集合的访问路径（事件执行的顺序），每个事件的具体内容，事件的总个数。

总结：图1版本默克尔树的子节点存储的是版本对应的事务集合信息，图6账本状态默克尔树的叶子节点存储的是到达i版本时的所有的账户信息，图5事件默克尔树的叶子节点存储的是从上个版本到这个版本执行的所有的事件信息。

版本==》事务集合

=〉当前版本的账户信息集合

=》从上一版本状态到达当前版本状态需要执行的事件信息

=〉经过签名的事务集合

从另一个角度去理解，其实这里的版本间接等同于比特币和以太坊的区块的概念。

以太坊的一个区块包括三种树，交易树，收据树，状态树（根hash）。

Libra共识协议能够使一组验证节点产生一个单一数据库的逻辑外观。共识协议会在验证节点间复制提交的事务，对于当前数据库执行潜在的事务，然后同意一系列承诺，包含事务的顺序和事务的执行结果。从而让所有的验证节点都能维护一个相同的指定版本的数据库，这个数据库遵循状态机复制范例。Libra区块链使用变体的HotStuff共识协议，称之为libraBFT共识协议。在部分同步模型中，包括传统的DLS和PBFT，或者较新的casper（以太坊新的共识协议）和Tendermint协议，libraBFT都能提供安全性和可用性。这部分章节将会概述libraBFT的关键决策。而LibraBFT的完整报告涵盖了详细的分析细节，包括安全性和可用性的证明。（就是那篇State machine replication in the Libra Blockchain的文章）

（注意：casper和tendermint协议都是类pos共识协议。Tendermint 是一个改进版本的的DLS 协议。）

即使存在拜占庭故障，也必须在验证者之间达成关于数据库状态的一致共识。拜占庭故障模型允许一些验证节点在没有约束的情况下任意偏离协议，除了计算限制（因此不能破坏加密假设）。拜占庭故障是最坏情况的错误，其中验证者串通并且做出恶意行为来试图破坏系统。共识协议容忍由恶意行为或验证节点被黑客入侵而引起的拜占庭故障，也可以减轻由硬件和软件而产生的故障。

LibraBFT假设一组3f+1的投票，来自于一组包含可能是诚实的或拜占庭节点的集合。当最多有f投票是由拜占庭问题节点控制时，LibraBFT可以保持安全，防止双重花费和分叉等攻击。只要存在全局稳定时间（GST），并且诚实验证器之间的所有消息都会在最大网络延迟δ内传递给其他诚实的验证器，LibraBFT就仍然可用，客户端允许提交交易给验证节点。除了传统的保证之外，LibraBFT在验证器节点崩溃和重启时，甚至所有验证节点都同时重启时，都可以保证安全。

4.1libraBFT的概述

验证节点接受来自客户端的事务，然后通过共享内存池协议把事务共享给其他验证节点。然后libraBFT协议将会执行一系列的轮次过程。在每一轮中，获得领导者角色的验证节点将会在已有的、通过验证的、包含过去全部交易历史的区块链后，提出一个包含交易集合的新区块去扩展原有区块链。接受到提议区块的验证节点，将会检查他们的投票规则去决定是否投票验证这个区块。这些简单的规则能确保libraBFT的安全性和他们的实现是可以清晰的区分并且是可审计的。如果一个验证节点想投票给这个区块，它将会模拟执行这些个区块的交易事务，这个过程不会对账本数据产生真实的额外影响。执行完区块中的事务，将产生的新的状态数据库，然后会对这个数据库进行验证计算。验证节点然后发送一个对区块和数据库的验证器签名的投票给领导者节点。领导者节点收集这些投票去形成仲裁证书，对于这个区块如果收集到>=2f+1张投票，则广播法定人数证书给所有的验证节点。

当连续3链提交规则符合时，一个区块才会被提交。具体规则就是：一个区块在k轮被提交需要符合以下两个条件：条件1，收集到法定人数证书，条件2，在k+1轮和k+2轮都收集到经过确认的两个区块和法定人数证书。这种提交规则最终会允许诚实节点提交区块。LibraBFT保证所有的诚实节点都会最终提交区块（以及链接该区块的一系列区块）。一旦一系列的区块已经被提交，执行这些事务而产生的状态将会被持久化，并且形成一个副本数据库。

（注解：这里和pbft最大的区别是，pbft是三阶段提交，确保一个区块一定是有效验证的。二libraBFT引入了类似比特币的确认规则，当在当前确认的区块的基础上又产生了两个或者以上的确认区块时，那么这时之前n-2的区块才会真正被提交。

难道libraBFT有类似以太坊叔块的概念？）

4.2 HotStuff共识的优势

我们根据性能，可靠性，安全性，稳健实施的简易性以及验证器的操作开销等方面评估了几种基于BFT的协议。我们的目标是选择一个最初支持至少100个验证节点的协议，并且能够随着时间的推移而发展到支持500-1,000个验证节点。选择HotStuff协议作为LibraBFT的基础有三个原因：（1）经过安全论证的简单性和模块性; （2）能够轻松地将共识与执行结合起来; （3）在早期实验中表现良好。

HotStuff协议分为安全模块（投票和提交规则）和可用模块（心跳）。这种分离解耦提供了独立或者并行开发和实验的能力。因为简单投票和提交规则，协议安全是很容易实现和检验的。把执行组件集成到共识里是很简单的，这样会避免产生基于领导者协议而产生非确定性执行问题。最后，我门在早期的原型中通过独立测量，确认了HotStuff协议的高吞吐和低延迟特性。我们不考虑pow协议，因为其低性能和高能源消耗。

QC即quorum certificates

4.3 HotStuff的扩展和修改

为了更好的支持libra的生态系统目标，我们在许多方面扩展和调整了HotStuff协议和它的实现。重要的是，我们重新制定了安全条件并且提供安全性，可用性和积极响应的额外检验。我们还实现了很多其他特性。

首先，我们令协议更加抵抗非确定性错误，主要通过让验证节点共同签署区块的结果状态而不仅仅是事务序列。（解释：如果不签名区块的结果状态，可能会发生事务内容和序列都一样，但执行的结果不一样的非确定性问题。）这也允许客户端使用QC（法定选举人证书）来验证数据库中的读取。

其次，我们设计了明确的心跳超时时间，验证节点只需依靠法定人数节点来进入下一轮，而不需要同步时钟。

第三，我们设计了一个不可预测的领导者选举机制，新一轮的领导者由最新提交的块的提议者使用可验证的随机函数来确定的。这种机制限制了攻击者可以针对领导者发起有效的拒绝服务攻击。（注解：这种就相当于之前清利写的raft+随机函数选领导者的专利）

第四，我们使用聚合签名[ 38 ]来保护签署QC的验证节点身份。这使我们能够为有助于QC的验证者提供激励（见9.3节）。它也不需要复杂的密钥设置门槛。

注意：验证者节点只会投票提议者提议的正在增加的轮次（等于或高于现在的轮次），并且只会投票那些连接到之前有效区块的提议区块。

4.4验证节点管理

Libra协议使用move模块来管理验证者节点集合。这样使得在共识系统和加密经济系统之间创建了清晰的分离。在9.2章节我们讨论了这个合同（验证者节点管理）在libra区块链的实现。通过这种方式来抽象验证者节点管理，是一个体现灵活性保证的例子。

验证者节点集合每次改变都会定义一个新的时期（类似raft的term的概念）。如果一个事务会引起验证者节点管理模块改变验证者节点结合，那么这个事务将会成为当前时期最后一个提交的的事务，任何来自当前时代的后续事务（无论是当前区块还是后续区块），将会被忽略。一旦这条事务被提交，那么新的验证者节点集合就能启动下一个时代的共识协议。

在一个时代里，客户端无需同步每一个法定选举人证书。既然一个QC包含了对所有之前状态的约束承诺，因此客户端只需要同步在当前时代最新的有效的QC即可。如果一个QC是当前时代最后一个QC，客户端可以查看新的验证者节点集合，更新它的时代，同步新的时代里最新的QC。如果一个验证者节点选择修剪历史数据（就像4.2描述的那样），它需要保留至少足够多的数据给客户端，让客户端能验证验证者节点集合的更改。

验证者节点管理合约必须提供一组满足共识协议安全需求的验证者节点集合。不能多于f个投票权利是控制在拜占庭验证节点上的。投票权必须在纪元期间以及纪元之后的一段时间内保持诚实，以便允许客户同步到新配置。离线时间超过此期限的客户端需要使用某些外部事实源来重新同步，以获取他们信任的检查点（checkpoint）（例如，从其用于接收更新软件的源）。此外，验证者节点集合不能频繁更换，因为经常轮换世代会破坏系统的性能或导致客户端下载过多的时期QC。我们计划研究最佳的时代的长度，但预计它不到一天。

5.网络

与其他分布式系统一样，Libra协议需要一个网络层来实现其成员之间的通信。验证节点之间的共识和共享的mempool协议都需要通过互联网进行通信，分别如第5 节和第7 节所述。

网络层设计为通用的，并从 libp2p [ 40 ]项目中汲取灵感。它目前提供两个主要接口：（1）远程过程调用（RPC）和（2）DirectSend，它实现向单个接收器发送“即发即弃”消息。

内部验证节点网络实现了一个p2p系统，节点的地址使用 Multiaddr 方案，可靠传输使用TCP协议，用于认证和完全端到端加密使用noise协议，在单个连接上复用子流使用yamux，以及用于节点发现使用推送式的gossip协议。每个新子流都会分配一个发送方和接收方都支持的协议。每个RPC和DirectSend类型对应于一个这样的协议。

网络系统使用与共识系统相同的验证节点集管理合约。该合同包含每个验证者的网络公钥和共识公钥。验证节点通过监测此智能合约中的更改，来检测验证节点集合的变更。要加入内部验证器网络，验证器必须使用合同定义的最新验证器节点集合的网络公钥进行验证。引导验证节点需要一个种子节点列表，加入的这些种子节点会首先被验证为内部验证节点网络的合格会员，然后与新节点共享它们的状态。

Libra协议中的每个验证节点都维护系统的完整成员资格视图，并直接连接到需要与之通信的任何验证节点。一个无法直接连接的验证节点，则假定为属于拜占庭故障节点。通过定期心跳检测来获取验证节点的健康信息，这些信息并不在验证节点之间共享; 相反，每个验证节点直接监视其连接的节点列表的活跃度。我们希望这种方法在需要部分成员资格视图，复杂的故障检测器或通信中继之前，可以扩展到几百个验证节点（这句话的意思其实就是：我们希望这种方法能够扩展到几百个验证节点，并且不需要部分成员资格视图，复杂的故障检测器或通信中继。）

注意：yamux为golang的多路复用库。

6.Libra Core实现

（如何结合libra 协议的组件来处理事务）

为了验证libra协议，我们已经构建了一个开源的原型实现—libra core。这个实现是用rust语言编写的。我们选择rust因为它专注安全编码实践，支持系统编程和高性能。我们将系统的内部组件拆分为grpc服务。模块化会带来更好的安全性，例如，共识安全组件能运行在一个独立的进程，甚至运行在不同的机器上。

Libra Blockchain的安全性取决于验证节点，Move程序和Move VM的正确实现。解决Libra Core中的这些问题正在进行中。它涉及有助于验证节点在共识期间签署交易块的部分代码和应用措施来增加对这些组件正确性的保证（例如，广泛的测试，正式规范和形式验证）。高质量的代码开发还涉及确保代码依赖的安全性（例如，代码审查过程，源代码控制，开源库依赖，构建系统和发布管理）

6.1写请求生命周明

图6展示了libra core中对分布式数据库执行写入操作的事务生命周期。本节将会深入看一下一个事务是怎么流转验证节点里的内部组件的。

一个请求开始于一个客户端想提交一个事务到数据库。我们假设客户端有一个外带机制能找到验证节点的地址去提交教育（这个外带机制的最终版本还没涉及）

（1）准入控制（admission control）

在接收到一个事务时，验证节点里的准入控制组件将会执行初始的句法检查（箭头第1步），然后丢弃那些不符合条件的、将永远不会执行的事务。越早做这些检查就能避免话费不必要的资源在这些交易处理上。准入控制组件可能会访问Vm组件（箭头第2步），而Vm组件会使用存储组件来执行检查，例如确保账户有足够的余额去支付执行事务所需要的gas。准入控制组件的设计使验证节点可以运行组件的多个实例。此设计允许验证节点扩展传入事务的处理并减轻拒绝服务攻击。

(2)内存池（mempool）

通过准入控制组件检查的事务将会被发送到验证节点的内存池，内存池会在内存缓冲区中保存这些等待被执行的事务（箭头第3步）。内存池kennel会保存来自同一个地址的多个事务。因为内存池一次处理多个事务，它能执行以下检查：验证来自同一个地址的一系列操作是否都能支付执行这些操作所需要的总gas，而这种验证准入组件就无法做到。使用共享内存池协议（箭头第4步），验证节点和其他验证节点共享它自己内存池里的事务，把其他验证节点发来的事务放入自己的内存池。

(3)共识（consensus）

验证节点通过从他们的内存池选出一系列的事务来创建新区块。当一个节点扮演的是共识协议里的领导者，它会从它的内存池形成一个交易块（箭头第5步）。验证界限会把这个交易区块作为提议区块发送给其他验证节点（箭头第6步）。共识组件主要负责在所有验证节点之间协调达成以下共识：包括这些交易区块的顺序和这些交易区块执行的结果。共识组件主要使用libraBFT协议来实现以上功能的。

(4)事务执行（transaction execution）

作为达成共识的一部分内容，包含交易的区块将会被发送到执行组件（箭头第7步），执行组件主要管理在vm中的事务执行（箭头第8步）。在事务真正达成共识之前，将会被模拟执行。这种早期的模拟执行是安全，因为交易是确定的并且不会产生额外的影响。在执行完区块的交易后，执行组件见会构建这些插入的事务的账本历史。而账本历史的验证器将会返回到共识组件（箭头第9步）

领导者验证节点然后尝试通过形成法定人证书来对这些事务达成共识，收集到的法定人证书至少需要有2f+1个验证节点的签名投票。

(5)提交区块（committind a block）

一旦共识算法达成共识，任何诚实的验证节点就能确定所有其他的诚实验证节点将会最终提交一个一致的账本历史。验证节点将会从执行组件的缓存中读取区块执行的结果，然后更新它的本地数据库存储（箭头第10步）。

6.2读请求生命周期

客户端也可能向验证节点提交读请求去查询在去中心化数据库里的账户的内容。读请求不会改变状态，因此能在本地处理，并且不需要通过共识过程。

下面介绍读请求的生命周期过程：读请求首先会提交到验证节点的准入控制组件。准入控制组件会执行初步的检查，然后从存储中读取数据，把结果发送回给客户端。响应结果会带上包含根hash的法定人数证书。法定人数证书使客户端能够验证查询操作的响应结果。客户端使用与VM相同的技术来和逻辑数据模型来解释帐户的原始字节。例如，要读取地址为a的帐户的余额，客户端会解码嵌入帐户原始字节码内的LibraCoin.T资源。

7.性能

Libra协议的任务是建立全部货币基础设施。性能是其中一个必须要达到的要求。我们用以下三个指标来讨论区块链的性能：

1.吞吐量：每秒能处理的区块链事务数

2.延迟：客户端提交一个事务到区块链与另一方能看到事务已经成功提交之间的时间。

3.容量：区块链存储海量账户的能力

然而libra协议现在仍然处于一个原型阶段，因此我们没有报告具体的性能指标，但我们预料libra协议的初次启动能支持每秒1000次的事务，并且一个事务从客户端提交到真正提交写入到验证节点的时间在10秒之内。随着时间的推移，我们希望能增加系统的吞吐量从而满足网络的需求。我们预料许多支付交易将会发生在线下，例如，在监管钱包内或者使用支付渠道。因为，我们认为在区块链上支持每秒1000笔交易将会符合生态系统给的初始需求。Libra协议通过以下的设计来完成这些目标。

（1）协议设计。

Libra协议的许多元素是基于性能来进行选择的。例如，libraBFT算法在三轮网络通信里实现了共识，而不需要增加任何实时的延迟时间来给区块做提议或者投票。这样使得提交区块的延迟仅受限于验证节点间的网络延迟。

我们也在选协议元素的时候，想到了并行化和分片。计算验证时使用稀疏默克尔树这样的方法，使得能够在不同机器间分片数据库（因此能增加容量），也使得能够并行处理更新过程（因此能增加吞吐量）。事务的初始验证，会包含计算消耗很多计算资源的签名验证，这个过程也能实现并行化计算。

（2）验证节点选择。

与大多数服务一样，Libra 区块链的性能取决于运行它的底层验证节点的性能。这时一个去中心化和性能之间的权衡。如果需要资源十分好的验证节点，则限制了可以执行该角色的实体数量。但是，如果需要硬件性能较差的验证节点，它的存在则会限制整个系统的性能。（这里的资源包括机器硬件，网络环境等）

我们更倾向于在这些方法做一个平衡，选择那些大多数人都买的起的商用硬件作为目标节点。不管怎样，我们假设这些节点运行在服务器级别的硬件上，并且与数据中心有很好的连接。我们使用近似的分析来展示一个系统如果符合每秒1000笔交易的需求，会有怎样的配置。

带宽：如果我门假设每个事务在通信中需要5KB的数据量，包括了以下过程成本：通过内存池接收事务，重新广播事务，从领导者节点接收区块，然后复制到客户端。那么验证节点需要一个40Mbps的网络带宽来支持每秒1000笔交易的事务。接入这样的带宽是容易获得的。

Cpu：对于支付交易，签名验证是一个重要的计算成本。我们设计的协议已经能够允许并行的验证事务的签名。现代签名方案在商用CPU上支持每秒超过1,000次验证。

磁盘：具有16TB固态硬盘的服务器在大多数的服务器供应商都能获得。既然现在的状态只是验证节点需要处理事务的信息的一部分，我门估计如果账户存储大约需要4KB（包括所有形式的开销），那么16TB的固态硬盘将能存储4亿的账户。（我们预料无论磁盘存储，扩展验证节点成多个分片和经济激励的怎样发展，libra系统仍然能接入商用系统。注解：这句话实在不知道原文想表达什么。

We anticipate that developments in disk storage, scaling validators to multiple shards, and economic incentives will allow the system to remain accessible to commodity systems. ）

历史数据可能会增长到超过单个服务器能够处理的能力。验证节点可以自由的丢弃历史数据，然后，对于希望查询来自过去交易的事件的客户端来说，可能会感兴趣这些历史数据。既然验证节点已经对这些数据进行了约束承诺签名，客户端可以自由使用任何系统去访问这些数据，而无需只信任传输这些数据的验证节点。我们希望这种类型的读取方式能够很容易进行并行化扩展。

（注解：实际上就是像比特币或者以太坊，读取数据时，可以从多个其他节点同时读取，这就是所谓的并行化读取。P2p下载速度快的原理。）

8.通过move语言来实现低波动性和储备支持的libra生态系统

Libra区块链是一个独特的系统，平衡了传统金融网络的稳定性和加密经济系统的开发性。该协议规定了一个灵活的框架，该框架的关键系统组件是可以进行参数化配置的，例如本地货币，验证节点管理和事务验证。在本节中，我们将讨论Libra 区块链如何使用Move编程语言来自定义这些组件。我们的讨论侧重于协调网络参与者和验证节点激励的挑战，以及支持Libra生态系统的运营，治理和发展的挑战。

8.1 libra币

许多加密货币并不是基于真实世界的资产。因此，结果是这些加密货币大多数用来投资和投机的。投资者购买这些加密货币，通常基于以下的假设：即认为这些货币能持续升值，然后能以较高的价格卖掉它。对这些货币长期价值的信念波动，会导致价格相应波动，有时会产生大幅波动。

为了推动libra币被广泛采用，libra被设计成这样一种货币：任何用户都会知道libra今天的价值会接近明天和将来的价值（也就是波动性很小的稳定币）。储备是实现价值保护的关键机制。通过储备，每个libra币背后都有一套稳定和流动的资产作为支持。由于存在多个竞争性的流动性提供商，这些流动性提供商背后对接的是libra币的储备，因此用户可以相信他们持有的任何libra币都可以以高于或低于标的资产价值的窄幅差价来进行出售，然后获得法定货币。这从一开始就给出了硬币的内在价值，并有助于防止现有加密货币所经历的投机性波动。

储备资产是低波动性资产的集合，包括来自稳定和信誉良好的中央银行的现金和政府证券。由于libra的价值与一篮子法定货币有效挂钩，从任何特定货币的角度来看，libra的价值会有波动。储备的构成旨在减轻这些波动的可能性和严重性，特别是在负面方向（例如，甚至在经济危机中）。为此，该篮子的结构考虑了资本保护和流动性。

该保护区由libra协会管理，该协会已公布了保护区运作的详细报告。用户不直接与储备接口。相反，为了支持更高的效率，由授权经销商来进行在储备内或者外的法币和libra币的交易，这些授权经销商是唯一授权合法交易的实体。这些经销商整合到交易所和其他机构中，这些机构买卖加密货币，并为希望从现金转换为libra币并再次转换回来的用户提供流动性。

为了实现这个方案，libra币合约允许协会在需求增加时进行铸币，在需求缩减时销毁币。该协会没有制定货币政策。它只能根据授权经销商的要求铸造和销毁libra币。用户无需担心通货膨胀会引入系统或使货币贬值：因为对于要铸造的新libra币，储备中必须有相应的法币存款。

使用Move定制Libra币合同的能力允许定义这种方案，而无需对底层协议或实现它的软件进行任何修改。还可以创建其他功能，例如需要多重签名来铸币并创建有限数量的密钥以提高安全性。

8.2 验证节点管理和治理

共识算法依赖验证节点管理的move模块，通过这个管理模块去维持当前的验证节点集合和管理验证节点之间的投票分配。这个合约主要负责维护验证节点集合，在3f+1张总投票中最多只有f张投票是控制在拜占庭节点上。

最初，Libra区块链仅允许创始成员投票，这些创始会员实体满足下列条件：（1）符合一组预定义的创始成员资格标准（2）拥Libra投资代币。这些规则有助于确保具有安全和可用的验证节点集合的安全性要求。使用创始成员资格标准，可确保创始成员是具有良好声誉的组织，使他们不太可能恶意行事，并表明他们将尽力保护其验证节点免受外部攻击。 Libra投资代币表示对储备利息的回报预期，将进一步激励验证人保持系统运作。由于储备中的资产是低风险和低收益的，早期投资者的超额回报只有在网络成功并且储备大幅增长的情况下才能实现。

虽然这种评估验证者资格的方法是对传统许可区块链的改进，这通常形成一组封闭的业务关系，但我们希望使Libra区块链编程完全无需许可即可加入。为此，我们计划逐步过渡到POS系统，在该系统中，验证人被分配与他们持有的libra币数量成比例的投票权。这将生态系统的治理转变为用户治理，同时能防止女巫攻击（因为用户持有的是稀有资源，即libra币，实现女巫攻击将需要很大成本）。这种转变要求以下条件：

（1）生态系统足够大，可以防止不良行为者造成破坏; （2）对于不希望成为验证人的用户，存在竞争性和可靠的授权市场（即用户可以把投票权授权给其他用户）; （3）解决libra币中的技术和可用性挑战。

Libra生态系统治理的另一个独特方面是验证节点构成了一个真实世界的实体，即非营利性的Libra协会，由一个验证节点委员会管理。协会理事会的成员代表每个验证人。会员在议会中的投票权重与验证节点在共识协议中的投票权重相同。协会执行诸如管理储备，评估验证节点资格标准以及指导Libra协议的开源开发等任务。

Move语言使得可以将验证及诶单管理和治理的规则编码为模块。Libra投资代币可以使用Move资源实现。Move语言允许通过将投资代币或libra币的股份包裹成资源，来防止访问底层资产。股份资源可用于计算验证节点的投票权。合同可以配置更改生效的时间间隔，以减少验证节点集合的流失。

libra协会的运作也得到了Move的帮助。由于协会是保留的运营商，因此它可以创建Move模块，该模块将委托铸币和销毁币的权利给一个与授权经销商对接的运营部门。该运营部门还可以评估潜在的创始成员是否符合资格标准。move允许灵活的治理机制，例如允许理事会主张其权力并通过投票收回其授权。

协会已经发布了一份详细的文件，概述了其提议的结构。协会的所有治理都源于验证节点理事会 - 该理事会拥有对该协会提供任何授权的最终权利。因此，整个libra生态系统的治理，将会随着验证节点集合从最初的创始成员集合，转变为基于股权证明的集合。

8.3验证节点的安全和激励

在初始设置中，使用创始成员作为验证者，我们认为每个验证者的机构声誉和财务激励足以确保拜占庭验证者控制不超过f票。然而，在未来，代表基于libra币所有权的开放系统将需要完全不同的市场设计。对于一个基于持股和消费者对钱包和其他代表的信心的区块链系统，我们已经开始理解其治理和均衡结构。在此过程中，我们找到一种新的市场设计，这种设计会在libra方法和其他更成熟的方法（例如工作证明）之间做一个权衡。

但是，需要进行更多的研究，以确定如何最好地保持生态系统中的长期竞争，同时确保网络的安全性和效率。此外，由于基于股权的治理引入了影响力依赖，因此必须探索一种机制，这种机制能够保护较小的股份持有者和服务提供者。

Move允许灵活定义相关激励计划，如gas定价或股份。例如，可以通过move实现股份削减机制，这种机制会在一段时间内锁定股份，如果验证节点在安全方面违反libraBFT算法的规则，将会自动受到惩罚。

类似地，当验证节点在LibraBFT算法中投票时，这些投票可以记录在数据中。该记录允许Move模块基于参与算法来分配激励，从而激励验证节点在线可用（因为只有在线可用才能参与投票）。libra储备和gas支付产生的利息也可以用作激励措施的来源。两个来源都由Move模块管理，这增加了分配的灵活性。虽然需要更多的研究来设计一种支持Libra生态系统发展的方法，但Move的灵活性确保了这种需要的方法，可以在Libra协议几乎没有任何变化的情况下实现。

9.libra的下一步计划

我们已经发布了libra协议的提议，并且有一组验证节点提供一个分布式数据库来跟踪可编程的资源。我们已经讨论了libra协议的开源原型，并展示了为智能合约引入Move编程语言，是怎样使得协议能够实现Libra生态系统的独特设计。

文章里关于协议和实现的描述现在是处于原型阶段。我们希望从最近新成立的libra歇一会和广泛的社区手机反馈，将这些想法变成一个开放的金融基础设施。我们现在运行着一个测试网络来允许社区去试验这个系统。

我们正在努力初步启动这个系统，并将其保持在可管理的范围内，我们计划在第一个版本中进行一些简化。在该系统的早期阶段，使用外部认可的创始成员集合减少了对共识激励系统的要求，并能加快更新速度。我们预计仅将Move用于系统定义的模块，而不是让用户定义自己的模块，这允许Libra生态系统在Move语言完全形成之前能够启动起来。这也会允许当出现突破性变化时，不会影响使用move来定义核心系统行为的灵活性（注解：因为如果一开始就做的很全面，但是没有做的很细致，后来升级版本时可能出现很大的改动）。但是，我们打算在未来版本的Libra协议中提供对Move语言的开放访问。

最后，我们目前正在Libra协会的框架内开展这个新生态系统背后的技术基础设施。我们已经发布了一个工作路线图，它描述了我们为支持这次启动的具体计划。libra协会的首要目标之一是将Libra生态系统迁移到一个不用许可访问的系统（公链）。我们已经记录了进行此迁移所涉及的技术挑战。协会的开源社区提供了有关如何启动Libra testnet，尝试move语言以及为Libra生态系统做出贡献的相关信息。