Facebook Libra 性能初探

sp42 2019-08-25

服务器 性能 带宽 facebook 磁盘 存储

译自:官方文档翻译 《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节),但是查询过去交易事件时这些数据就必要了。由于验证器签名了历史数据的绑定确认,因此客户端可以自由使用访问该数据,而无需其他信任信息。这类的读取流量我们希望可以通过并行轻松扩展。

登录 后评论
下一篇
云攻略小攻
2212人浏览
2019-10-21
相关推荐
Flashcache初探
613人浏览
2013-10-16 10:20:42
著名网站系统架构设计
469人浏览
2009-02-04 10:19:00
【转载】知乎技术方案初探
2707人浏览
2016-05-11 13:18:57
Android开发技术周报 Issue#9
1279人浏览
2017-03-17 21:08:02
Thrift简析
575人浏览
2018-03-08 11:27:00
Thrift简析
688人浏览
2018-04-23 08:36:47
Thrift简析
450人浏览
2018-03-08 11:27:00
Facebook Canopy 初探
236人浏览
2019-08-03 19:05:33
0
0
0
253