长话短说 在网络区块生成之间，矿工重新启动并快速重新连接到网络的情况下，存在潜在的DoS攻击风险，会暂停他们的挖矿操作。 解决此问题的方法包括： - 升级到Core-Geth 1.12.17版本。
- 解决方法：在重新启动之间留出足够的时间，足以使网络产生至少一个新区块，或者通常在15-30秒左右。区块生成的间隔遵循长尾分布。在过去的12小时中：
- 99%的区块在69秒内生成，
- 75%在19秒或更短时间内生成，
- 25%在4秒或更短时间内生成。
- 平均区块时间约为13秒。
摘要 2023年11月14日，用户@Ewemek报告了他们的挖矿工作提交意外间歇性暂停的问题。 对这个问题的调查导致我们发现了以前安全漏洞解决方案中未处理的边缘案例。 在2020年10月，Go-ethereum实施了一个安全补丁，防止对矿工进行可能的DoS攻击，攻击者可以向矿工提供虚假的TD，导致矿工的挖矿操作在尝试下载不存在的更好链时暂停。 然而，对问题586的理解表明，情况并非总是如此。如果在重新启动并重新连接到网络所需的时间内未产生新的区块，矿工可能在快速重新启动时拥有一个节点，该节点在启动时已经与规范网络同步，因此downloader不需要完成同步，以使本地节点处于网络的规范头。 以前的补丁未处理这种边缘情况，导致与以前相同的潜在DoS场景。 这是我的锅 问题586的报告与我正在开发的节点爬虫的开发时间重叠。 由此，我（愚蠢地）认为向网络宣传一个任意高的总难度是个好主意，试图在网络上交朋友。 这不是个好主意，主要是因为它根本没有达到目的，而且我成功地让一些矿工的挖矿设备暂停了几分钟。抱歉@Ewemek。 当我理解到相关性后，我立即修改了探险者的行为，以礼貌的方式进行操作，幸运的是，@Ewemek在那之前就聪明地找到了解决方法。 解决方案 我们的修补程序（现在只与ETC相关；ETH使用PoS且没有矿工）解决了此边缘情况，使用了额外的事件fetcher.ChainInsertEvent，矿工监听该事件，并在接收到该事件时禁用其自动暂停同步逻辑。 BlockFetcher系统会在接收到NewBlock (0x07)和NewBlockHashes (0x01)区块传播协议消息时发出此事件。
对于这些消息，BlockFetcher尝试将接收或获取的区块附加到本地链，该过程只有在该区块直接构建在本地链之上时才能成功，从而指示出网络规范同步的状态。 通过这种方式，矿工能够将fetcher的区块插入操作用作相对于她的同行完全同步的指标。 这种逻辑与用于事务池消息处理的现有逻辑相对应，后者也依赖于完整的链同步。 参考文献 | 
