然而，从随机数计较 FID 的设计也有一个缺点：每当节点收到一个新的随机数 r 时，就要为所有已经收到的生意业务（按照上一期的假设，全节点会将已往 5 分钟内收到的 180 万条生意业务和方才收到的 FID 比拟）从头算一遍 FID，这会带来了极大的计较承担。
思量如下方案：在上面这个 3+1 消息团结的方案下，进攻者其实仍然可以反复雷同的进攻计策。之前的进攻计策中，进攻者为每一个静态的 FID 筹备一笔生意业务。在这一计策中，进攻者为每个桶预先筹备一些生意业务。当受害者的生意业务呈现后，进攻者在短时间内大量广播与受害者生意业务在同一个桶里的生意业务，就可以或许低落受害者生意业务被转发到其他节点的概率。纵然同一笔生意业务每次转发时回收一个完全随机的动态字节，可是这个动态字节只有 256 种大概的取值，所以一个桶中的生意业务越多，斗嘴概率也会越高。
这个设计的另一个长处是，即便节点 B 给节点 A 发送生意业务时产生了 FID 值斗嘴，导致某笔生意业务没有乐成发送给节点 A，另一个节点 C 发送这笔生意业务给 A 时，或许率将回收差异的随机数 r 计较 FID，相当于增加了一次把这笔生意业务发给 A 的时机。
一个节点将一笔生意业务转发给另一个节点时，为了节省带宽，可以发送这笔生意业务的 FID (Forwarding ID) 而不是直接发送完整的生意业务，由接管者按照 FID 判定是否需要向发送者请求完整的生意业务。我们的方针是将 FID 的长度低落到 4 个字节。
为了办理静态 FID 易被进攻阻塞的问题，我们将 FID 的取值由静态转酿成动态的。因为 FID 只是在节点与节点之间转发生意业务时的姑且取值，与共鸣逻辑无关也不需要被记录在上，所以 FID 值没有须要是一个稳定的数值。
回首
我们先往返首一下上一期讲到的生意业务转发中带宽优化的问题。
只要计较 FID 的进程足够随机（如利用伪随机函数），则 B 发送乐成和 C 发送乐成可看作是两个独立的事件。按照我们之前的计较，一笔生意业务因为 FID 值斗嘴而发送失败的概率是 0.04%，而节点 B 和 C 两次独立发送都失败的概率是 0.04% × 0.04%，失败率大大低落。
此刻我们有两种不甚满足的方案：
这条特另外法则触发时会让生意业务转发退化到没有利用 FID 优化的环境。可是因为正常环境下每个桶里期望只有 0.1 笔生意业务，险些不行能产生高出 10 笔生意业务落在同一个桶里的环境，所以这条特另外法则在系统没有遭到进攻时并不会被触发。而当系统真的遭到进攻的环境下，掩护系统的安详性和不变性才是最重要的，即便为此而低落系统的吞吐量也是可以接管的妥协。
这样，按照生意业务 ID 的前 3 字节，我们把所有的生意业务放在了 224 个“桶”里。每次一个节点收到其他节点发来的 FID 和 r 时，先按照 FID 的前 3 字节判定生意业务地址的桶，再将本身已经收到的，落在这个桶里生意业务按照 r 从头计较 FID 值并比对。
简朴地计较可以发明，对付 180 万条随机生成的生意业务，平均每个桶里只有 0.1 笔生意业务，纵然是含有生意业务最多的桶里也不会高出10 条。从头计较一个桶里生意业务的 FID 所需耗费的本钱远远低于从头计较所有生意业务的 FID。
上一期的最后部门还提到假如每笔生意业务的 FID 牢靠稳定，则进攻者可以用不高的本钱阻塞特定生意业务的广播。根基要领是进攻者先结构一个包围所有 232 个大概的 FID 的生意业务库，当受害者发出一笔生意业务时，进攻者从生意业务库里选择具有沟通 FID 的生意业务并抢先发送给其他节点，从而使其他节点都误觉得已经收到了受害者生意业务，而选择不吸收完整生意业务。
由于 r 的随机性，进攻者并不能估量一笔生意业务在每次转发时选择的 r 和由此算出的 FID 别离是几多，自然也就无法预先结构斗嘴的生意业务了。
为了应对上述进攻，我们引入了一个特另外法则：假如一个节点收到一个 FID 时，发明这个 FID 对应的桶里已经有不少于 10 条生意业务，就不再利用 FID 来判定，而是直接请求完整的 32 字节生意业务哈希值来比拟是否接管过这笔生意业务。这样，进攻者就不能再通过制造斗嘴的 FID 来阻塞生意业务广播了，因为斗嘴过多的时候反而无法起到阻塞的浸染。
每个节点在计较 FID 时，并不只仅由生意业务的 ID （生意业务的 32 字节哈希值）计较，而是选择一个随机数 r，通过 ID 和 r 配合计较出一个 4 字节的 FID，并将r 与 FID一同发送。这样，当随机数 r 改变时，生意业务的 FID 也会随之产生改变，收到 FID 和 r 的节点需要按照 r 从头计较已有生意业务的 FID 来完成比拟，并确定需要请求哪些 FID 对应的完整生意业务。因为一次转发的多笔生意业务可以共享同一个随机数 r， 所以这个随机数 r 险些不会在带宽上带来特另外承担。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
