压力测试数据已证明CTOR的必要性

Posted 2021-05-02 哈希值

为了能够证明目前BCH扩容所要面对的瓶颈是块传播，而且CTOR是提高块传播速度的必要条件，Jonathan Toomim对BCH压力测试的数据进行了分析。以下就是他的分析：

在压力测试期间，区块通过非中国主网以大约300-1000 kB / s的速度进行数据传播。这非常慢，而且如果区块经常都是大于8MB的，还会引起孤块率的问题。除非我们能够改进块传播的算法。

简介

在2018年9月1日，比特币现金进行了压力测试，用户故意在BCH网络上发送大量的小额交易，以便我们能够更好的了解系统如何处理负载。

不过，除非收集数据，否则压力测试又有什么用呢？在测试前不久，我要求人们配置他们的节点来记录额外的数据并安装NTP以获得更精确的时间戳。测试结束后，我请求不关心隐私的用户将他们的debug.log文件发送给我，以便我可以分析数据以获得块传播信息。这几乎是最后一刻，但即便如此，我还是从12个节点获得了数据。

块传播速度对于追踪和最小化非常重要，因为如果块传播延迟时间太长，它们可能会危及比特币的安全性。造成这一问题的主要原因是孤块率不平等的影响。比特币的工作证明系统旨在确保矿工执行的每个哈希都具有相同的预期收入，无论矿工是小还是大。这通常是正确的，但是当块传播延迟变得太高时，这将会被破坏。任何理性的矿工或矿池都不会故意孤立自己的区块，他们总是以零延迟收到他们自己的区块。

因此，一个具有35％算力的矿池与算力只有5%的矿池相比，对其区块的支持将会增加30%，而且孤块率也会降低30%。在孤块率高的情况下，大型矿池的收益要高于小型矿池，这将鼓励所有矿工加入大型矿池。最终，这可能导致网络由一个或两个超级矿池组成，这些超级矿池有足够的算力轻松地执行51%攻击。即使这些矿池是非常真诚的，但这仍会危及比特币的安全。因为这意味着黑客或该矿池中心怀不满的员工可能会损害整个系统的安全性。

为了避免矿池过于中心化，我建议使用35%算力的矿池与算力5%矿池相比的优势的1%作为目标。这1%的数字包含了矿池间费用的典型变化；比这更小的差异不太可能造成问题。当孤块率约为3.3%时，会出现1%的优势。而这一切将出现在块传播延迟平均为20秒时。我认为，块传播延迟时间大大超过这个时间- 比如40秒- 将导致不安全的挖矿激励措施，这可能导致失控的矿池的中心化。

考虑到这一点，我搜集了压力测试中的数据并做了分析。

方法

我分析了这个数据集，查看每个区块第一次到达的时间以及被每个节点验证的时间，以便了解不同大小的块通过网络传播的速度。具体来说，我计算了网络中的节点首次接收到该区块块到每个节点都接受到该区块所花费的时间。

数据集有几个局限性。首先，我们只有12个节点，我们的节点都不是大型矿工，因此我们观察到的传播延迟缺少传播过程的前几跳，并且传播延迟总数可能低估了大约2倍。我没有用这个因素来调整数据，所以读者应该记住，全网络延迟可能是这里报告的数字的两倍左右，速度是这里的1/2。其次，除了一个节点外，所有节点都是非挖矿节点，并且不一定是性能优化的节点。第三，我们的大多数节点没有提前成功配置NTP，导致他们记录的时间戳与真实时间相比具有偏移量。第四，我们的数据集中没有一个节点位于中国，因此此数据集中没有关于中国防火墙如何影响性能的信息。

虽然挖矿节点的普遍缺乏乍一看似乎是一个致命的缺陷，但挖矿节点和非挖矿节点运行的软件是相同的，如果性能限制是受算法和代码的影响而不是硬件，他们的性能将表现出相似性。正如我们稍后将看到的，情况确实是这样，我们的性能主要受代码而非硬件的限制，除了异常缓慢的硬件。

我通过从该节点的时间戳减去每个节点的中值延迟来更正时间戳偏移。例如，如果一个节点报告在我们的网络中的第一个节点之后五秒钟接收到其50％的块，我的分析假设这是由时钟不准确引起的，并且将从该节点的所有时间戳减去5秒。

数据集存在一些问题。其中一个节点似乎有网络问题，并且经常报告“PROCESSMESSAGE：INVALID MESSAGESTART”错误，而且性能不一致，因此我从分析中排除了其数据。排除了另外两个节点是因为时间戳问题不容易纠正。

Gregory Maxwell观察到Bitcoin ABC和SV有一些从比特币核心继承的代码，人为限制它们每秒只传播7-14个交易。这个bug很容易修复，但这意味着我们数据集中唯一的大块是在前一个块之后延迟很长时间才诞生的区块。因此，我们非常大的区块（> 15 MB）的样本量非常小。

结果

完整数据可在以下链接中查看。每个中间列对应于一个节点，并显示该节点接收每个块之前的延迟（以秒为单位）。

https://docs.google.com/spreadsheets/d/1DJZX2gG6I4sE4FLRcuwR1A-R96lXwLjUDl7rUZVHmS8/edit?usp=sharing

如果您更喜欢纯文本（制表符分隔值）版本，可以在此处找到：

http://toom.im/files/stressdata.txt

完整的数据集可以在这里下载：

http://toom.im/files/stresstest.zip

块验证比块传播快得多。所有节点在大约1秒内验证了大多数区块，并且即使在我们的数据集中最慢的节点上验证时间也没有超过4.2秒。我们数据集中最快的节点能够在1964 毫秒内验证一个21.4 MB的块。

由此看出，块验证似乎不是一个重要的瓶颈，因此我没有对该主题做进一步的分析。作为一个大概的数据，块验证似乎占总块传播时间的5％到10％。

几个块花了超过100秒才到达所有节点。这些异常延迟在较大的块中更常见，例如00000000000000000069c3ad902b27621493eea7c3504d9a7a279b04c9dad565（15.2 MB）。

对于所有大小的区块在未压缩的情况下，整个网络中的块平均传播速度小于1.1 MB / s。较大的块通常可以更有效地利用可用带宽，除了样本量较小的最大层（> 16 MB）。由于Compact Block（ABC，SV和XT）和Xthin（BU和XT）的压缩比接近25，这意味着传播期间的平均有效网络带宽要低25倍，即使是最佳块也要低于44 kB / s。（注意：这个44 kB / s代表沿一条传播路径的网络带宽;由于每个节点将同时并行上传到多个对等端，其网络管道的峰值利用率将高于此。）这些数字比在Gigablock Testnet计划中看到的1.6 MB/s和62 kB/s低了41%。这种差异可能是因为我们测量的节点功能较弱且连接不如GTI中的节点。差异也可能是因为主网节点比GTI节点具有更多的对等节点，因此它们的可用带宽更加分散。

运行ABC + SV（致密区块）的五个节点和运行BU的三个节点（Xthin和一个不可靠的alpha版Graphene）之间的传播性能大致相似。两个比特币XT（致密区块+ Xthin）节点的传播性能要差2.5倍。但是，不要在此基础上就严厉的批评XT，因为这不太可能是XT真实性能的指标。其中一个XT节点在一个只有1个虚拟CPU的虚拟机中运行（在我们的数据集中是最慢的），而另一个XT节点的带宽限制在5 Mbps-25 Mbps 之间（在我们的数据集中是最慢的）。

在压力测试期间，一个区块成为孤块。在UTC时间下午6:53左右，ViaBTC在高度为546012处打包了一个6029 kB区块，哈希值是000000000000000000e28e540ea0819e83377f201802fd38fde4e7a2f4bda192。该区块在网络中传播缓慢。不到60秒，BTC.TOP在高度为546012处下挖出了一个51KB的竞争区块，哈希值是0000000000000000002d5be4e56f448a247088ee91e31f788d9a6ad5411f71b6。这创造了一个孤块比赛。BTC.TOP的区块传播的速度大于ViaBTC区块，并且是第一个到达我们网络中所有节点的区块。然而，ViaBTC有足够的哈希值和运气，可以在5分钟后在546013高度上挖出第二个区块，结束孤块竞赛，这对ViaBTC有利。即使孤块比赛是由于ViaBTC打包一个大块传播速度小于BTC.TOP引起的，BTC.TOP的区块是第一个到达所有其他节点的区块，但ViaBTC能够通过哈希值的强大力量赢得比赛。如果频繁发生，这可能导致哈希值集中的情况。

Mark Lundeberg观察到，在这种情况下，理性的自私矿工会从他们的BTC池中借用算力来挖BCH，直到孤块比赛得到解决。这似乎是一种自私的采矿技术，以前没有公布过，而且会提高所有自私的采矿变种的效率。我们无法知道ViaBTC是否真的这么做了，但是他们肯定有足够的算力可以这样做。

结论

我们的块传播协议还需要完善。如果大块的块传播速度为1023 kB / s，那么我们推荐的20秒限制将使得区块最大为19.5MB。因为我们只测量传播过程的一个子集，所以真正的块传播速度更低。如果速度慢2倍，那么内存块始终大于10 MB将导致孤块率超过3.3%，并产生不受欢迎的矿池的中心化激励。不幸的是，128 MB的块在这个时间点是完全不合理的。它们可能需要大约250秒的时间进行传播，这将导致像CoinGeek这样的大型矿池的孤块率约为34%，整体收入优势为7% - 10%。

幸运的是，我们可以做很多升级，这些升级能够有助于块传播。

没有CTOR的石墨烯似乎能够实现100倍的压缩，这比我们目前使用Compact Blocks和Xthin的效果好大约4倍。没有CTOR的石墨烯需要将86％的数据用于交易排序信息，如果我们支持CTOR，石墨烯将能够获得~700倍压缩，比我们现有的要好28倍。然而，目前的石墨烯原型是不可靠的，并且不能成功地传输所有区块。石墨烯是否可以制造得足够可靠以使非常大的区块也是可行的仍有待观察。

另一种可以提供帮助的技术是Xthinner。Xthinner使用CTOR能够进行约120倍压缩，在没有CTOR的情况下能够进行约56倍压缩。虽然效率不如石墨烯，但Xthiner更简单，更可靠，并且可以作为石墨烯传输失败时的后备选项。

除了提供更好的压缩的技术之外，我们还可以利用更多的可用带宽。我们现在每个TCP连接只获得大约44 kB / s，即使在具有100 Mbps连接的机器上也是如此。虽然这对非网络工程师来说可能听起来很奇怪，但这种带宽利用率很低是TCP的拥塞控制算法会造成高延迟，高带宽连接以及大量数据包丢失的影响是众所周知的。我们可以通过切换到基于UDP的协议来避免这个问题，最好是使用前向纠错。Matt Corallo的比特币FIBER就是这样一种协议。尽管FIBER依赖于受信任的中继服务器集中式网络，但它确实表现良好。UDP + FEC也可以应用于Xthinner或Graphene以提高其有效性。很久以后，当我们处理多GB块时，我们可能会开始使网络管道饱和，我们可能需要添加多播UDP，切换到Blocktorrent等协议，或者只需支付更大的网络管道费用。

所有这一切都清楚地表明：目前BCH扩容将会遇到的瓶颈主要是块传播，而不是块验证。我们的社区最近花了很多时间讨论了CTOR对块验证的影响，而且这个时间已经被大量浪费了。在未来的某个时间，块验证速度可能很重要，但是现在和不久的将来，主要的瓶颈是AcceptToMemoryPool性能和块传播。而且CTOR是提高块传播速度Xthinner或石墨烯技术的有利的助手。在CTOR存在的前提下，BCH的块传播速度将会得到很大的提高。

数据分析链接：

https://medium.com/@j_73307/block-propagation-data-from-bitcoin-cashs-stress-test-5b1d7d39a234

相关文章：