区块链时代的拜占庭容错：Tendermint (八)

本文主要是介绍区块链时代的拜占庭容错：Tendermint (八)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

原文题目：《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》

原文作者：Ethan Buchman

本文为节选

性能和容错

Tendermint被设计为拜占庭容错的状态机复制算法。只要不超过总量的三分之一的验证人是拜占庭节点，就能保证网络的安全性，并且只要网络消息最终得到传递，即使对于gossiping提议的网络同步性假设很弱，它也能保持运行。在发生此类故障时，Tendermint共识的落实不会影响安全性，它会对性能产生最小的影响，并且可以快速恢复。可以通过几种关键的方式来评估Tendermint算法的性能。最明显的衡量指标是块提交时间，它是衡量最终延迟的指标，也是衡量交易吞吐量的网络容量指标。我们在网络上收集每个分布在地球上的验证人节点的测量值，其中验证人的数量范围是2的倍数，从2到64。

概览

可以使用https://github.com/tendermint/network_testing 上的代码库重现本章中的实验。所有实验都在t2.medium或c3.8xlarge的Amazon EC2实例上运行的docker容器中进行。 t2.medium有2个CPU和4GB RAM，c3.8xlarge有32个CPU和60GB RAM。实例分布在七个数据中心，跨越五大洲。负责生成交易的第二个docker容器在每个实例上运行。交易大小为250字节（包括一些32或64字节的哈希和签名的合理大小），并且构造为可调试的方式，也便于快速生成指令，并且也包含了一些随机性。因此，前导字节是表示该实例的交易编号和验证人索引的Big-Endian编码整数，从操作系统中随机抽取尾随的16字节，并且中间字节仅为零。

网络监控工具用于维护每个验证人节点的Tendermint RPC服务器的活跃websocket连接，并在第一次收到新的已提交块时使用其本地时间作为该块的正式提交时间。首先在没有监控的情况下运行实验，方法是复制验证人节点中的所有数据进行分析，并使用提交块的2/3验证人节点的本地时间作为提交时间。使用监控要快得多，适合在线监视，只要只有块头信息（而不是整个块）通过websocket传递，就不会影响到结果。

使用docker-machine工具可以轻松管理远程计算机上的Docker容器，并且网络测试存储库提供了一些工具，这些工具利用Go语言的并发功能在多个远程计算机上同时对docker容器执行操作。

每个验证人节点直接相互连接，以避免网络拓扑的混淆影响。

对于涉及崩溃故障或拜占庭行为的实验，故障节点的数量取决于Nfault = ⌊(N − 1)/3⌋，其中N是验证人节点的总数。

吞吐量和延迟

本节描述了测量Tendermint在非对抗条件下（编者注：作者意指不考虑拜占庭节点等容错的情况）的原始性能的实验，其中所有节点都在线并同步，并且没有为异步做出调整。也就是说，使用了极高的TimeoutPropose（10秒）参数，并且所有其他超时参数都设置为1毫秒。此外，所有mempool活动都被禁用（没有交易的gossiping亦或在提交完成后的复检），进程内的nil应用程序为了绕过TMSP。

实验基于验证人集合运行，集合大小从2增加到64，块大小从128到32768加倍。每个验证人节点都预先加载了交易。每个实验运行16个区块。

从图1中可以看出，Tendermint每秒可以轻松处理数千个交易，大约有一秒的出块延迟，尽管每秒大约有一万个交易处理容量限制。 16384个交易的块大小约为4 MB，并且网络带宽分析显示每个连接容易达到20MB / s以上，但是对日志的分析表明，在达到高的区块高度时，验证人节点可能花费超过两秒的时间来等待块部件。此外，如图2所示，单个数据中心的实验表明，可以实现更高的吞吐量，而在更好的机器上进行的实验表现出更一致的性能，从而减轻了容量限制，如图3所示。我们将此容量限制的进一步调研留待未来的工作。

图1：延迟-吞吐量权衡。较大的块会导致交易吞吐量逐渐减少，最终容量约为10,000 txs / s

图2：单个节点的情况。当消息不需要通过网络时，Tendermint每秒可以进行数万次交易。

图3：大型机。使用32个vCPU和60GB RAM，交易吞吐量随块大小线性增加，从而减轻了较小机器上的容量限制。

在后续的实验中将注入各种形式的故障并呈现延迟统计。对于不同的TimeoutPropose值，以及块大小为2048个交易，每个实验运行的验证人集合大小从4增加到32。

死机故障

为了评估遭受节点崩溃故障的网络的性能，每隔三秒就会随机选择，停止并在三秒钟后重新启动Nfault个验证者。

表1中的结果表明，此崩溃故障情形下的性能下降了约50％，而较大的TimeoutPropose值有助于减轻延迟。虽然平均延迟增加到大约两秒，但中位数接近一秒，并且延迟可能高达十甚至二十秒，虽然极端情况可高达七十秒。而将TimeoutPropose修改为略微的不确定性可以缓解这种极端延迟的可能性。

表1：崩溃 - 故障延迟统计信息。每三秒钟，一次随机选择的Nfault个验证者崩溃，并在三秒钟后重新启动。此崩溃重启过程持续了200个块。对于TimeoutPropose参数的不同值，每个表都报告出块延迟的最小值，最大值，平均值，中位值和第95百分位数(95th percentile)。

随机网络延迟

另一种形式的故障，可能归因于拜占庭行为或网络异步，是为每次读取和写入网络连接注入随机延迟。在这个实验中，在每次网络连接的每次读写之前，验证者的Nfault都会休眠X毫秒，其中X统一绘制在（0,3000）上。从表2中可以看出，延迟与崩溃失败情况类似，但增加TimeoutPropose会产生相反的效果。由于并非所有验证人节点都有错误，因此TimeoutPropose的小值允许快速跳过错误的验证人节点。如果所有验证人节点都受到网络延迟的影响，则预期较大的Timeout-Propose值将减少延迟，因为不会有无错误的验证人节点跳过，并且将提供更多时间来接收延迟的消息。

表2：随机延迟延迟统计。 Nfault个验证者设置为在每次读取和写入之前注入随机延迟，其中延迟时间在（0,3000）毫秒上均匀选择。

拜占庭式的失败

通过对状态机的以下修改，可以注入更明确的拜占庭故障：

相互矛盾的提案：在提出建议时，拜占庭验证员会分别签署两个相互冲突的提案并进行广播，同时进行投票前和预先提交，以分离其连接对等体的一半。
没有nil票：拜占庭验证者从不签署一次空的投票（nil-vote）。
签署每个提案：拜占庭验证者提交投票前和投票一看到它就会预先提交它看到的每个提案。

总之，这些行为明显违反了双重签名和锁定规则。但请注意，这种行为主要是由于冲突提案的广播，以及最终提交其中一个提案。更复杂的拜占庭策略则有待后续的工作。

虽说注入了拜占庭故障会导致许多系统完全立即失效，但Tendermint保持了可观的延迟，如表3所示。由于这些故障与异步处理几乎没有关系，因此TimeoutPropose没有真正可辨别的效果。性能也随着更大的验证者集合而下降，这可能是处理拜占庭投票的一个想当然结果。

结论

作者和Jae Kwon编写的Tendermint的实现很容易在全球分布的机器上实现每秒数千个交易，最多64个节点，延迟大多在一到两秒范围内。这也使它与其他解决方案竞争激烈，尤其是区块链的当前状态，例如比特币，支持每秒约7笔交易。此外，我们的软件实现体现出即使面对崩溃故障、消息延迟和故意的拜占庭故障等都是健壮的，在每个方案中也能够保持每秒超过一千个交易。