译自：官方文档翻译 《Libra 技术白皮书》。 本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 *许可协议进行许可。

Libra 中文网同步翻译 http://www.libra-cn.top/document/info/?id=18

Libra 协议的使命在于至此全球的金融基础设施。性能是满足这种需求不可或缺的一部分。我们讨论区块链性能的三个组成部分：

吞吐量：区块链每秒可以处理的交易数。
延迟：客户向区块链提交交易到另一方看到交易已提交的时间。
容量：区块链存储大量账户的能力。

当前 Libra 还是一个原型的阶段，我们没有具体的性能测评报告，我们预料 Libra 初次启动能每秒支持一千支付的交易，十秒内交易可以从提交到确认。随着时间的推移，我们希望能够提高系统的吞吐量以满足网络的需求。我们预测许多交易发生在链下（off-chain，译注：指不存储于区块链上的数据，较不重要的交易活动可以在链下（在单独的私有通道中）处理，并在稍后的时间最终在链上解决），例如保管钱包（Custodial wallet）或使用支付通道。因此，我们相信对于初级阶段的生态来说，每秒支持一千笔交易可以满足。Libra 协议通过以下几个手段来达到这目标。

协议之设计。 Libra 协议的许多元素依据性能来衡量选择。例如 LibraBFT 算法在三个网络通讯回合之内便可达成共识协议，而且不需要获取任何实时延迟才能提交或投票区块。这相当于唯一的延迟就只剩下是验证器之间的网络延迟了。
协议设计中，我们还考虑具有并行化和分片的优化。计算验证的稀疏默克尔树就是使用了数据库切片的方法，把数据库划分到不同的机器执行（增加了容量），并行执行更新（增加了吞吐量）。交易初始化验证，其中签名验证部分是很很耗资源的，这部分也可以并行化。

验证器部分。 像多数服务那样，Libra 区块链的性能表现很大程度来源于底层验证器的影响。在去中心化和性能之间怎么取舍呢？假如说资源越多越好，那么验证器也执行不过来那么多；然而验证器太少资源跑起来的性能却是不能恭维的；

我们倾向于在这些方法中折中，设定一个目标就是，让普通常见的商用设备、多数人可以负担的硬件即可跑起来，但是现实是残酷的，为满足性能要求之目标，我们还是把要求提升到服务器级别的机器，和较理想的连接网速。那样子的话系统几乎可以达到每秒一千笔交易的速度。

带宽：假设每笔交易需要 5KB 带宽——包括了内存池接收交易的、重新广播的、在领导者那儿接收区块的和复制到客户端的几个步骤——总的下来验证器约需要 40Mbps 的公网带宽，那么便可达到每秒一千笔交易的速度。满足这个条件应该很多环境都可以。
CPU：支付交易中验证签名，往往占用大量的计算成本。该协议的设计中，我们特意考虑了该问题，解决之道是并行验证。一般商用 CPU 可以支持超过每秒一千笔交易的签名方案生成。
磁盘：主流服务器厂商都能提供 16TB 固态硬盘存储的空间。由于当前状态是验证器需要用来处理交易的唯一信息，每个账户约占 4 KB（包括所有形式的开销），那么我们估计 16TB 可以存储验证者 40 亿个账户。磁盘存储下一步的发展就是将验证器扩展到多个分片，还有引入报酬上的激励，使得最终目的是普通便宜机器都可以跑起来。

单个服务器可可能不足以处理历史数据。验证者可以随意丢弃处理新交易所不需要的历史数据（参见第4.2节），但是查询过去交易事件时这些数据就必要了。由于验证器签名了历史数据的绑定确认，因此客户端可以*使用访问该数据，而无需其他信任信息。这类的读取流量我们希望可以通过并行轻松扩展。