handle_new_minor_block_header_list_command中启动synchronizer造成的拒收区块问题

[BubbLess]

在shard.py中，注意到handle_new_minor_block_header_list_command函数下会触发synchronizer

        Logger.info(
            "[{}] received new tip with height {}".format(
                m_header.branch.to_str(), m_header.height
            )
        )
        self.shard.synchronizer.add_task(m_header, self)

而synchronizer启动后节点将拒收新的区块

    async def handle_new_block(self, block):

        if self.synchronizer.running:
            # TODO optional: queue the block if it came from broadcast to so that once sync is over,
            # catch up immediately
            return

逻辑上讲handle_new_minor_block_header_list_command应该是在进行最长链切换时的同步时调用的，那么我们可以伪造大量这样的请求，使得目标节点一直处于同步阶段，拒绝处理网络发送过来的新区块，从而对目标节点进行隔离。 另外因为synchronizer中同步时需要从对方下载该区块，如下

            block_header_list = await asyncio.wait_for(
                self.__download_block_headers(block_hash), TIMEOUT
            )

此处TIMEOUT为10秒，相当于我们一次请求可以阻塞目标节点10秒，这样我们持续阻塞该节点的难度将进一步降低，危害还是比较大的。

[qcdll]

If I recall correctly, timing out when downloading block header or block will cause the peer sending new_minor_block_header_list_command to be disconnected from current cluster, preventing it from performing the same attack

[BubbLess]

在timeout之后确实是会断开连接，不过似乎并没有对这类恶意节点建立黑名单，那么就可以继续发送同样的请求重新建立连接，使用多个peer应该就可以对目标节点进行无缝切换的攻击了。

[qizhou]

我的理解是核心还是黑名单的问题，对吧？

[qcdll]

should be resolved by #199

[ninjaahhh]

another aspect to alleviate the problem is to do a PoW validation before adding the synchronization task. however considering the hashpower of a shard is relatively low, such validation won't stop malicious nodes keeping sending valid blocks to hang the synchronizer.