Shrec: Bandwidth-Efficient Transaction Relay in High-Throughput Blockchain Systems

概要

Bitcoin and Ethereum的成功吸引了人们去建立高吞吐量的区块链系统，高效的交易传输方法是区块链系统保持极高吞吐量的关键，而现有的解决方案存在不足，作者提出了Shrec，一种新颖的建立在混合交易哈希机制的高吞吐区块链系统的中继传输协议，具有极低的哈希冲突率、能够抵抗混合攻击、构建速度快。通过实验展示了Shrec能够很好地利用网络效率，对比绝大多数的设计，Shrec在适度的CPU开销下降低了带宽消耗至60%，并将系统吞吐量提升了90%。

背景

Bitcoin and Ethereum是基于Nakamoto Consensus的，每秒交易量在7～30笔，块的生成速率很低或者块的大小限制严格。为了克服基于该共识的区块链系统的瓶颈，近年来提出了许多共识协议，这些协议探索了组织块的替代结构、使用BFT容错来完全或部分替代中本聪共识、还有把区块链状态划分为多个分片，比如说CONFULX和OHIE能够处理超过5000 TPS 数量级的交易，却忽视了高吞吐量的P2P系统的关键要求——典型的比特币交易的平均大小约300字节，5000 TPS 的共识吞吐量至少需要10 Mbps 的网络带宽来进行交易传播，此时每个节点20 Mbps 的可用带宽配置下，其他协议消息几乎没有剩余空间（建立在公链的典型设置下）。

（介绍典型的交易生命周期）
交易在区块链网络里传播对于系统确认延迟的要求极高，为了让系统能够接受交易，需要通过网络向参与的节点进行广播，并等待其中一个节点生成一个有效块，生成该块的矿工将通过网络传播该块，其他节点根据共识协议接受该块，若这个块确实被接受了，那么对应的交易才会被确认——说明了交易到达的节点越多，才会越快被打包到确认的块中。

在P2P网络中最直接的传播方法是通过Flooding，即参与节点接受到的每个交易都被传输到该节点的所有邻居，因为每个节点都不知道它的邻居接收到了哪些消息，因此会导致每个节点接受交易出现冗余，从而导致网络利用率下降。

比特币通过Announcement（指发送交易哈希值的环节，对于交易哈希值的检测可以保证每个节点只需要接受一次完整的交易内容，避免重复传送完整交易带来的带宽浪费）来优化网络效率，其中的节点不是广播交易，而是只公布它知道的所有交易的摘要，尽管这个传播方法消除了冗余，但是却占据了30%～50%的网络流量。

flooding

比特币网络采用flooding传播的方式，第一次听到某交易，则加入到集合中等待上链并转发这个交易，后面收到就不再转发了，避免无限传播。一个节点在将收到的交易广播钱给它的对等节点注入一个随机延迟，有助于减少交易在in-flight状态中冲突的可能性。

Erlay

在flooding基础上用于降低带宽消耗的传输协议，结合了low fan-out 和集合协调机制，本质上是对gossip传播协议的扩展。在low fan-out 洪泛，每个节点仅向部分节点广播交易，这在一定程度上减少了带宽消耗；为确定消息传到了全网，在集合对账中节点会定期和其他节点进行交互协议，去发现丢失的交易广播并请求丢失的交易，Erlay中的集合对账通过PInsketch算法为每个节点编码每个节点的本地事务集，该集合由尚未发送给对等节点的事务的 shot id 组成，通过在两个连接点对等节点之间交换这些事务集的草图，可以恢复代表分别从两个对等点丢失的事务集的对称差。

虽然Erlay协议在Bit-coin 网络中展示了它的有效性，但是它并不能直接应用在高吞吐量的区块链系统中，实际中预期的区块链吞吐量可以达到每秒数千笔交易，在Erlay协议中启动集合协调的时间对性能影响很密切，如果周期太短，草图传输太频繁会损害批处理效果并降低事务传播的带宽利用率；另一方面，如果周期较长对于事务集的草图的对称差异的影响非常大。

所以这篇文章的重点来了
如何在点对点网络中使得两个节点的数据更高效的同步为一致的问题

提出了理想的Relay protocol应该具有以下四点：
1.最大限度地利用带宽效率（对应有效性的定义是有效传输的在总传输的对应的比例）
2.事务传播延迟应保持在合理的范围内
3.中继协议不应该为每笔交易引入太多的计算成本
4.中继机制不应对现有的威胁模型产生额外的脆弱性（即提出新的中继机制对现有的威胁模型如DoS、时序分析、eclipse 、交易审查等攻击具有一定的抵抗力）

Shrec设计思路

Shrec协议要在以上的所提出的四个标准里达到一个最好的权衡，交易Announcement的目的有
1.对于收到通知的节点，检查交易是否被接收并处理，因此不需要再次从其他节点获取这个交易再中继给其他节点。
（这可以通过一个接收池来实现，该池维护一组接收到的交易Announcement ）
2.Announcement 的内容也被用作从 peer 获取相应事务的 key，并检查以避免重复获取对 peer 的请求，即如果一个事务的 inflight 请求已经发送给 peer，则节点不应向不同的对等方发出对同一事务的另一个请求，以避免重复传输同一事务。
（这通常需要维护一个包含未完成事务请求的飞行池）
总之，交易Announcement的目的是尽量减少不必要和冗余的交易传输。

Announcement本身会消耗带宽，因此思考一种编码方式在Announcement的大小和有效性之间进行权衡。Shrec将每笔交易编码为一个 4 字节的 shot id ，并通过 low fan-out 的方式去宣布它，无论一个节点连接了多少对等节点，该Announcement都会广播给固定数量的对等方（例如8个），那么如何理解Shrec对Announcement进行编码以及为什么要采用如下方案，文章的介绍从A Strawman Encoding Approach开始。

稻草人编码方案

这种编码方法是通过交易的32字节的SHA-3散列中随机选择挑选 4 个字节（例如，最后 4 个字节）来简单地组装交易短 id，这种简单的方法在高吞吐量区块链系统中面临高碰撞率。
如果发生冲突，交易可能只传播到少数节点，因为大多数节点可能已经收到了冲突的通知，并错误地认为这是一个已经收到的交易，在这种情况下，生成事务的客户端必须在系统忘记它后重新发送它，这会引入更长的额外事务延迟。

使用随机数改进编码的方案

为了降低冲突率，通过引入一个随机数来与每个对等节点进行通信。具体来说，4 字节的交易 shot id 是通过将 SipHash [4] 的最后 4 个字节与交易 SHA-3 哈希相结合来构造的。 SipHash 是一个快速伪随机函数，可以看作是一个带 key 的抗碰撞散列函数，它以一条短消息和一个随机数作为输入，并输出一个 8 字节的哈希值。对于每一对peer，在它们之间传输交易announcement之前首先确定一个随机nonce，并将该nonce与交易SHA-3哈希一起使用以产生相应的SipHash短id，比特币的紧凑区块机制也使用了类似的方法。
引入随机 nonce 之后，冲突对于不同的对等点变得独立，由于只有在所有对等点的annoucement发生冲突时，才可能阻止事务正常传播，因此与strawman approach 相比，冲突率随着对等点的数量呈指数下降，可以忽略不计。此外，由于攻击者无法预测用于一对peers之间的通道的随机数，因此不可能攻击特定交易，因此这种改进的方法引入了另一个问题——由于每个对等点的随机数，相同的事务对于不同的对等点具有不同的短 id，因此从对等点接收到的交易announcement，无法在 in-flight pool 中检查是否存在已发送给其他对等点的相同交易的 in-flight 状态的交易请求，这将引入对同一事务的重复请求并导致冗余事务传输。

Shrec 编码方案

为了解决前两个解决方案中的上述问题，Shrec 采用了一种新的编码方案，它结合了 SipHash 和 SHA-3 哈希的值。具体来说，要为交易构造 4 字节的 shot id，它需要从交易的 SHA-3 散列中获取 3 个字节（例如最后三个），从 SipHash 中获取 1 个字节（例如最后一个）。该方案的一个示例如图 1 所示：来自 SipHash 的 1 个字节称为 RandomByte，而另外 3 个字节称为 FixedBytes。

Shrec为了检查刚刚从peer收到的announcement是否指的是已经收到的交易，Shrec在receive pool 中查找是否存在与announcement中的4字节短id相同的交易，再通过 2 级索引进行查找。它首先搜索一组交易，其后 3 个字节与接收到的交易 shot id 中的 FixedBytes 部分相同，然后从该集合中寻找可以产生与 shot id 中的 RandomByte 相同字节的交易，通过应用 SipHash 和相应的 nonce 为同行。
如果receive pool中没有与接收到的announcement匹配的事务，Shrec 需要通过查看inflight pool 来检查与announcement关联的事务的请求是否已经发送给另一个对等方。为此，Shrec 中的inflight pool 中的未完成请求使用shot id 的 FixedBytes 部分进行索引，该部分对于不同的对等点具有相同的表示，可以克服引入随机数的编码方案中提及的重复事务传输。在查询inflight pool时，如果在短 id 的 FixedBytes 上发生冲突，Shrec 不会立即假设正在请求事务。相反，它等待正在进行的请求的结果，并相对于收到查询短 id 的对等方重建响应事务的整个短 id。然后它检查这个重新构建的短 id 是否与查询短 id 相同。如果它们相同，则 Shrec 认为交易已经收到，否则，它会发出请求。这种编码方案的一个问题是，仅仅依靠这种编码方案并不能完全修复哈希冲突攻击的漏洞，这类似于第 3.1 节中描述的针对稻草人方法的漏洞。
需要考虑处于离线准备许多伪造交易的攻击策略，以便稍后在线碰撞特定观察到的交易。攻击者可以根据其短 id 的 FixedBytes 对所有生成的交易进行分组，那么组的总数是 224，只要每个组中有足够数量的事务（例如，256 的数倍，即一个字节的值的数量），对于任意选择的事务和随机数，该组与所选事务具有相同短 id FixedBytes 的事务中可能包含在其短 id 的 RandomByte 上与它发生冲突的概率很高的事务。这种离线过程的成本将是攻击稻草人方法成本的一小部分。当在线攻击观察到的交易时，攻击者选择与受害者具有相同短 id FixedBytes 的一组交易，并迅速将它们传播到整个网络。
为了解决这个问题，Shrec 仅在接收池中同时存在少量具有相同 FixedBytes 的短 id 的事务时，才使用事务短 id 来检查之前是否接收到事务。基本原理是在正常情况下事务哈希应该是均匀分布的，没有这种攻击，因此具有相同短 id FixedBytes 的集合中的事务数应该很少。对于每个收到的交易公告，如果 Shrec 在收到的池中观察到，公告中由短 id 的 FixedBytes 索引的交易集合包含的交易数量大于阈值，并且在与公告匹配的集合，它需要对等方重新公告交易的整个 SHA-3 哈希,在我们的实现中，我们将此阈值设置为 9，以便该机制的误报率小于 $10^{-14}$。

Shrec系统和协议

在 Shrec 中，每个节点中的主要组件包括接收池、飞行池和发送池。发送池用于缓冲其公告已发送给其他一些对等方的事务，并等待为他们的事务请求提供服务。这些组件中的主要数据结构如图 2 所示：在第 7 行，struct InflightPool 的字段 inflight_reqs 跟踪未完成的事务请求以及发生冲突时的未决请求。如果inflight_reqs中存在某个短id的FixedBytes，则表示对应事务的in-flight请求已经发出。当某个新事务将被请求并且其短 id FixedBytes 与某个正在进行的请求的冲突时，将创建一个挂起的请求并将其插入与 inflight_reqs 中的 FixedBytes 关联的列表中。 struct PendingTxReqi 中的字段索引（第 15 行）用于标识宣布此交易的对等方的已发送池中的交易。

图 3 显示了发送池的数据结构以及公告和交易请求消息如何与之交互的可视化插图，为了在事务中继过程中更好地利用网络带宽，Shrec 缓冲新收到的事务，并定期将它们的短 id 批处理到单个公告消息中，以传播到一组随机的对等点。因此，发送池以批处理的方式组织索引，这些索引用于关联公告和交易。它本质上是一个带有 2 级索引的仅附加缓冲区。第一级是批次索引，表示该交易的公告属于哪个批次。第二级索引是它在批次内的偏移量。类似地，一个批处理公告对应的所有交易请求（不包括待处理的请求）也被批处理在一个请求消息中。这个 2 级索引使公告和请求消息紧凑。在这些消息中，批处理索引仅出现一次，因为批处理消息中的所有事务共享相同的批处理索引。

图 4 显示了处理接收到的批量通知以生成相应的事务请求数据包的算法。

图 5 显示了处理响应的事务以消耗冲突的未决请求的算法。

接收池和发送池中的数据都以时间滑动窗口方式管理，以允许系统忘记那些很久以前到达的信息。 在我们的实现中，我们将生存时间设置为 5 分钟，这比传播交易到达网络中大多数节点的延迟要长得多。之前的一份报告显示，将交易传播到比特币中 90% 的节点需要 18 秒。

冲突及安全假设

对Shrec模型的分析

首先是找到向在其接收池中没有此类交易的 m 个对等方发送一个以 SHA-3 哈希 x 作为其原始标识符的新生成交易的冲突率。通常，所有参与者共享相似的接收池。为简单起见，我们假设所有 m 个对等方在此新事务的传播期间共享相同的静态接收池。令 S 为接收池中交易的 SHA-3 哈希集。
在 Shrec 中，x 的短 id 由一个 3 字节的 FixedBytes 和一个 1 字节的 RandomByte 组成。 FixedBytes 从 x 中提取并用函数 E 表示：{0, 1}256 → {0, 1}24。 RandomByte 是从具有 128 位密钥（随机随机数）的 SipHash 函数在 x 上计算的，并由函数 PRF 表示：{0, 1}256 × {0, 1}128 → {0, 1}8。在本节的以下部分中，SHA-3 哈希的 FixedBytes 和 RandomByte 指的是短 id 的相应部分。对于任何 h ∈ {0, 1}24，让 Sh 将 S 中的 SHA-3 散列与其短 id 中的 FixedBytes h 分组。

在正常情况下的碰撞率

当向其他对等点宣布交易时，Shrec 随机选择 m 个不同的密钥 ki (i ∈ [m]) 并将不同的短 id 发送给 m 个对等点。下面的分析研究了冲突率，它是指所有 m 个对等方错误地认为新生成的交易已收到的概率。
第 3.3 节描述了如果 S 包含太多与 x 具有相同 FixedBytes 的 SHA-3 哈希，则所有参与者都应该请求一个带有 x 的整个 SHA-3 哈希的公告。我们用 t 表示阈值。当 |SE(x)| > t，参与者将转发 SHA-3 哈希 x 而不是其短 id，冲突率将为 0。
当|SE(x)| ≤t，只有在 SE(x) 中找到与 x 具有相同 RandomByte 的散列时，每个对等方才会错误地跳过 x 的短 id 的公告。由于 PRF 的伪随机性，不同 SHA-3 哈希或 nonce 下的 RandomByte 冲突事件是独立的。
估计给定固定 x 的碰撞率：

设 p(s) := 1 − (1 − 2−8)s。 我们假设 SHA-3 哈希 x 是从 {0, 1}256 中均匀随机挑选的，并且与接收到的池 S 无关。所以对于任何 h ∈ {0, 1}24，Pr[E(x) = h] = 2−24 . 前面的等式声称如果 E(x) = h 和 |Sh | 碰撞率将是 p(|Sh |)m ≤ t。 当考虑所有可能的 h 时，随机 x 的碰撞率将是：

在以下计算中，我们假设共享的接收池包含少于 150w 个事务（假设 5 分钟滑动窗口在 5000 tps 吞吐量下），并且每个节点向 m = 8 个对等方宣布短 id。 在正常情况下，我们可以假设 S 包含交易的独立且均匀随机的 SHA-3 散列。 所以每个组 Sh 将包含超过 8 个元素，概率很小（< 10-15）。 由于 max1≤s ≤8 p(s)8/s < 2−43，碰撞率的上限可以为：

这个速度意味着如果每秒处理 5000 笔交易，一次碰撞至少需要 600 年才能发生。

针对交易攻击

第 3.1 节描述了一种攻击，该攻击可以防止目标交易与预先生成的伪造交易池的传播。这种攻击建模如下：攻击者可以生成具有统一随机 SHA-3 哈希 id 的多项式交易并存储它们，之后，攻击者将获得一个带有随机 SHA-3 哈希 x 的受害者交易，它根据 x 从其存储中挑选几笔交易并将这些交易发送到所有完整节点，以使它们错误地认为已经收到了受害者交易，这些交易的 SHA-3 散列由集合 C 表示。
在 Shrec 解决方案中，只有与 x 具有相同 FixedBytes 的 SHA-3 哈希可能与 x 有冲突的短 id。所以我们假设 C 只包含 SHA-3 哈希 x '，其中 E(x ') = E(x )。此外，C 应该包含不超过 t 个交易，以避免触发机制使得所有节点在公告中都需要完整的 SHA-3 哈希。
这种攻击是通过随机挑选的随机数 k 具有与 C 中的 SHA-3 哈希冲突的短 id的冲突率来衡量的，应用布尔不等式和对C的假设，对于C的单独的 SHA-3 哈希，这个碰撞率由RandomByte 与 x 之和的限制：

对于随机 SHA-3 哈希 x ‘，冲突率 Prk[PRF(x,k) = PRF(x′,k)] 将为 1/256。 由于 PRF 的伪随机性，攻击者无法在多项式时间内找到具有 SHA-3 哈希 x̄’ 的交易，因此与随机挑选的 x’相比，x̄’在碰撞率方面具有不可忽略的优势。 因此在这个前提下与一个对等方的冲突率将是 t /256。 发送者有 1 - (t /256)8 的概率将该交易发送给至少 8 个对等方中的一个。

目标攻击下的传播覆盖率

我们更关心有多少完整节点将在目标攻击下接收交易，让网络包含 n 个全节点，我们研究交易 Tx 的传播覆盖率。
专注于一个事务时，low fan-out 转发策略近似等价于让每个节点在所有全节点中随机选择 m 个对等节点，发送失败概率为 t /256 的事务（攻击者针对目标攻击的最大努力） .我们的传播过程模型初始具有 n·m 个项目的转发计划列表 A。 A 中的每个项目由从 n 个节点中随机挑选的一个接收节点和一个成功位组成，该位将以 1 - t /256 的概率设置。该模型还维护一个接收队列，该队列由一个随机节点初始化。
在每一轮中，模型从接收队列中弹出第一个节点。如果该节点之前从未从接收队列中弹出，它将接收事务 Tx。此时，模型通过从列表 A 中弹出 m 个元素，过滤出未设置成功位的接收者，并将其他接收者推入接收队列，来模拟将事务转发给对等方的过程。当接收队列为空时，传播终止。
如果传播在恰好 i 个节点收到交易 Tx 时终止，则 A 中的前 m·i 个元素必须包含不超过 i 个唯一的成功接收者。我们估计此事件的概率如下：对于随机列表 A，第一个 m·i 元素中设置成功的位数是二项分布 B(m·i, 1 − t/256) 中的随机变量，记为 Z。给定 Z = z， z 从 n 个节点中随机选择替换的随机节点将包含不超过 i 个唯一节点，其概率最多为$(ni)(i/n)z$。考虑所有可能的 z，当 i 个节点收到交易时传播终止的概率上限为

因此，交易 Tx 将被传播到至少 u 个节点对应失效概率 $(iu-1)q(n,i)$，等于 $1.22\times 10^{-}8$ 当 m = 8,n = 5000,u = 4980,t = 9 时为 10−8。这意味着即使在目标攻击下，事务 Tx 也会传播到 99.6% 的完整节点。

评价

我们使用 Rust 在 Conflux [34] 中实现了 Shrec 事务中继协议。我们还在相同的代码库上实现了其他三种不同的事务传播机制以进行比较，包括 BTCFlood、Erlay [43] 和第 3.2 节中描述的 SipHash 协议。 BTCFlood 和 SipHash 协议是基于泛洪的解决方案。 BTCFlood 以交易的 SHA-3 散列作为其 id 来通告，而 SipHash 方案使用 SipHash 的最后 4 个字节在事务散列上作为通告的 id。
请注意，Erlay 结合了低扇出泛洪和周期性集合协调。在我们的设置中，每个节点每秒都会将草图传播给所有对等节点以进行协调。为了与 Erlay 论文 [43] 中报告的设置保持一致，我们使用事务 SHA-3 哈希的 8 字节 SipHash 作为其 id。一秒内接收到的交易的 id 由 PinSketch [19] 算法用参数 l 编码，生成一个 8×l 字节的草图。当一个节点接收到一个草图时，它会用自己的本地解码草图来提取对称差异。如果对称差小于l，则解码过程总是成功，否则，解码失败。正因为如此，选择一个合适的 l 是困难的。如果 l 太大，它不会像预期的那样节省带宽。另一方面，如果 l 太小，则解码失败不会提供有关节点应请求哪些事务的信息。此外，解码草图的计算成本很高，因为它与最大对称差的大小成二次方。因此，为了找到最佳权衡，我们逐渐增加变量 l 以使 PinSketch 在不过度消耗 CPU 的情况下达到至少 99% 的成功率。

实验设置

我们使用 Amazon EC2 上的 1,000 个 m5.2xlarge 虚拟机实例评估所有协议。每个实例有 4 个内核和 16GB 内存。在实验中，我们在每个实例上运行 1 个 Conflux 全节点。 Conflux 采用账户模型。每次实验前，系统会预先创建一百万个账户。每个账户都有足够的资金用于转账。在实验过程中，简单的支付交易是在整个网络中指定的全局吞吐量下随机生成的工作负载，其中每个节点对交易生成过程的贡献是均匀的。平均事务大小为 110 字节，每个节点每 0.2 秒产生和传播一个批处理公告。在每个实验中调整全局工作负载吞吐量以达到每个协议的性能容量。

Conflux 支持比比特币和以太坊更高的区块生成率。与比特币类似，它也采用紧凑块来避免通过交易传播协议以外的块传输交易。紧凑块可能包含重复事务的信息，这可能会引入其他带宽和执行开销。然而，这种开销与事务中继协议的影响是正交的。在实验中，我们将全局块生成速率配置为每秒 4 个块，块大小限制为 3000 个事务。这种设置可以满足我们实验中的工作负载吞吐量，并引入由块中重复事务引起的最小开销。

当一个新的 Conflux 节点被初始化时，它必须在网络中发现至少一个其他现有节点才能参与。每个节点将发出 8 个出站连接，最多可以接收 32 个入站连接。为了避免孤立的子图，网络拓扑的初始化是部分随机的：节点以循环方式连接它们的第一个传出连接，然后每个节点进一步初始化7个额外的传出连接到随机选择的对等点。这导致每个节点平均有大约 13 个连接。通过将低扇出设置为 4 个和 8 个对等方来评估 Shrec，分别用 SR-4 和 SR-8 表示，并且还向所有连接的对等方泛洪，称为 SR-Flood。对于所有其他协议，我们将泛洪扇出设置为 8。我们通过限制每个节点的最大可用网络带宽并在每对节点之间的通信中注入 0∼300ms 的随机延迟来模拟实际部署中的网络环境。我们分别评估了带宽限制为 10 Mbps 和 20 Mbps 的系统，以更好地了解不同网络资源限制下的权衡。

在实验中，我们旨在回答以下问题：
(1) Shrec 在不同网络约束下的系统吞吐量与其他协议相比如何？
(2) Shrec 在减少所需公告信息和冗余事务的带宽消耗方面的效果如何？
(3) Shrec 中的低扇出机制对事务打包延迟有什么影响？

系统性能概览

在本实验中，我们比较了系统在不同事务中继协议下可实现的最佳吞吐量，测量了总传出消息的每个节点的网络带宽消耗。

图 6(a) 显示了 10 Mbps 带宽限制下的结果。 Shrec 明显优于所有其他替代解决方案。 BTCFlood 和 SipHash 明显受限于网络带宽。 BTCFlood 以 1108 TPS 的吞吐量消耗了 80% 的网络带宽，而 SipHash 以 3639 TPS 饱和带宽。相比之下，Erlay 无法充分利用网络带宽，因为它的草图编码和解码是计算密集型的，这使得它受 CPU 限制。
当泛洪扇出为 4 时，Shrec 以 6894 TPS 实现最高吞吐量。当扇出增加时，吞吐量会降低，因为公告传播需要更多的网络带宽。这表明，在受限的网络环境下，应该使用较低的扇出来实现更高的吞吐量。
为了了解 Shrec 在相对不受约束的网络环境下的表现，我们还评估了具有 20Mbps 带宽限制的系统。 BTCFlood 和 SipHash 显着提高了它们的吞吐量，因为它们严重受限于网络带宽。然而，20Mbps 对它们来说仍然过于受限，因此它们的吞吐量仍然显着低于 Shrec。 Erlay 在如此高的带宽限制下并没有提高其吞吐量，因为它受限于 CPU 处理。
有趣的是，具有不同扇出的 Shrec 实现了相似的吞吐量，因为系统不再受限于 20Mbps 限制下的带宽。根据我们的调查，在这种情况下，系统受限于事务执行吞吐量。先前的工作表明，存在许多潜力来进一步提高以 merkle 树[40] 访问为界的类似以太坊的交易的执行效率，例如 Ponnapalli 等。等人[48]提出了一种解决方案来改进 merkle 树的访问，效率比以太坊实现高 100 倍。在这种情况下，具有 Shrec 的系统的吞吐量将再次在网络带宽低于 20Mbps 限制时成为瓶颈。

带宽和 CPU 消耗明细

为了证明 Shrec 的性能提升是通过减少 CPU 和网络资源消耗来实现的，我们对这些因素进行了更详细的评估。
为了解这些协议的传输有效性，我们在所有协议都可以支持的 500 TPS 工作负载吞吐量下重新运行实验，并分析它们的带宽使用情况。
图 7 分解了公告、交易和其他与区块相关的消息之间的带宽使用情况。对于 BTCFlood 和 Erlay，总带宽消耗分别为 3.5 Mbps 和 2.8 Mbps，公告消耗的带宽最多，因为它们由 32 字节的事务哈希组成。相比之下，SR-4利用4字节短ID和低扇出设计，实现了75%的传输效率，在相同吞吐量下将总带宽消耗降低到仅0.5 Mbps。

尽管 SipHash 使用大部分带宽进行交易传输，但与 Shrec 相比，它仍然需要更多的带宽，因为 SipHash 中传输的大多数交易都是重复的，如第 3.2 节所述。图 8 比较了在网络级别接收到的事务吞吐量和在 20Mbps 带宽限制的实验中的实际去重吞吐量。 SipHash 接收的交易数量是预期的两倍多，将这些带宽浪费在冗余数据上。 Shrec 对 SipHash 进行了改进，利用飞行池来防止重复获取请求，并且不会在重复事务传输上浪费任何带宽。但是SipHash不支持inflight pool，因为不同peer提供的同一笔交易的short id完全不同。

为了了解所有协议的 CPU 成本，我们在单线程节点上运行公告生成和处理的逻辑作为基准。该实验由作为输入的交易驱动。我们用不同数量的交易进行实验。对于每个实验，我们运行多次来测量平均 CPU 时间。图 9 显示了结果。除 Erlay 外，所有协议的运行时间几乎随事务数量线性增加。如图所示，Erlay 的计算成本明显高于其他协议，因为它与吞吐量成二次方。当输入的交易数约为 800 时，与 16 个对等方一起解码草图需要 3.52 秒。考虑可实现的最佳吞吐量 (826 TPS) 的情况，这将耗尽 EC2 m5.2xlarge 实例上的大部分 CPU 资源。这证实了 Erlay 协议受限于 CPU 计算而不是网络带宽。相比之下，Shrec 的计算成本非常低。运行 9000 个事务只需要 109 毫秒和 172 毫秒的 CPU 时间，SR-4 和 SR-8 传播事务，这对于普通的 4 核机器来说是相当实惠的，并且为系统的其他部分逻辑留下了足够的 CPU 预算。

事务打包延迟

我们已经证明 Shrec 可以通过消耗更少的带宽来实现更好的吞吐量。现在我们进一步分析它达到最佳可实现吞吐量时的延迟性能。
图 10 描述了 20 Mbps 带宽上限下 SR-4 和 SH-8 的事务打包延迟。在此设置中，系统不受带宽限制。打包延迟包括交易传播时间、在所有未打包交易中选择的等待时间以及使用工作量证明生成块的时间。对于这两种情况，超过 80% 的事务可以在 20 秒内打包。平均而言，将扇出节点的数量从 8 个减少到 4 个只会将事务生成到打包的延迟从 10.79 秒增加到 12.24 秒，仅增加了 1.45 秒。我们认为选择扇出 4 而不是 8 以减少带宽消耗是合理的，因为与共识层的交易确认时间相比，延迟增加几乎可以忽略不计，即比特币为 1 小时，Conflux 为 23 秒。

大规模模拟

为了更好地理解 Shrec 中的低扇出效应，我们通过模拟测量了 20,000 个节点上的事务传播和打包延迟。块生成速率设置为每秒 4 个块。在模拟中，交易从源节点生成并在迭代中传播，其中一次迭代代表交易广播的一跳。迭代时间设置为 1 秒，事务池大小设置为 100,000，与我们在 20 Mbps 带宽限制的实验中测量的值相同。图 11 绘制了平均传播延迟和打包延迟，并显示增加扇出变得越来越没有好处。例如，将扇出从 8 倍增加到 16 只将打包延迟从 13.2s 减少到 12.3s，但增加了大约 18% 的带宽消耗。这是因为在整个网络中广播交易所需的跳数为 O(logd N )，其中 d 是平均度数（即扇出），N 是网络中的节点数。

相关工作

区块链中的交易传播。

比特币 [42] 和以太坊 [1] 开创了去中心化公共区块链系统。它们的主要功能之一是以去信任的方式提供互联网规模的安全交易账本。在这样的系统中，交易需要及时地在整个网络中传播，以便将它们打包到新生成的块中并以低延迟进行处理。两个系统都采用flooding机制的变体来完成交易传播。由于这些系统只能实现非常低的交易处理吞吐量，这主要是其共识协议的瓶颈，因此可用的网络带宽通常有足够的预算来容忍基于泛洪的简单交易传输方案的低效率。
比特币交易泛滥的一个问题是它无法随着每个节点连接的对等点数量的增加而扩展。 Erlay [43] 观察到了这个问题，并提出了low fan-out flooding 和基于草图的集合协调的组合，以减少带宽消耗并在连接性增加时保持带宽使用几乎恒定。
最近，许多新的共识协议和账本结构 [5, 22, 24, 29, 32–34, 38, 41, 46, 47, 51, 52, 56, 57] 被提出并应用于公共区块链，以显着改善系统吞吐量达到每秒数千个事务。这些系统通常不再是共识协议的瓶颈，而是可用的网络带宽。虽然 Erlay 在比特币场景中是有效的，但由于其 set sketch 机制的计算成本太高，在目标交易吞吐量如此之高时成功率很低，因此无法应用于这些更先进的系统。此外，如果没有仔细设计交易公告编码，即使是low fan-out flooding也很容易消耗大量稀缺的网络带宽，从而显着限制可实现的吞吐量。相比之下，Shrec 优化了短交易 id 的编码，以达到Announcements的有效性和开销之间的最佳平衡。

连接的安全效应

比特币和以太坊中许多与网络相关的安全问题已经通过相应的攻击 [2, 3, 6, 7, 13, 15, 23, 25, 27, 30, 36, 39] 进行了审查，这些攻击试图增加双花或拒绝服务的可能性或侵犯用户隐私。他们中的许多人假设受害节点的连接对等点数量有限。这导致最近文献 [6, 14] 反复建议增加节点之间的连接数量以使网络更加健壮， Shrec 在其事务公告机制上坚持low fan-out flooding，因此不会在网络连接增加时引入更多的传输开销。

结构化的点对点网络

与分散式区块链系统中使用的点对点八卦网络不同，结构化点对点网络也广泛用于另一系列利用拓扑信息做出有效路由决策的系统，包括树状结构基于多播协议 [9, 10, 54] 和分布式哈希表 (DHT) [11, 37, 49, 53, 55]。然而，这些设计使协议泄露了有关网络结构的信息，并在对抗环境中引入了安全漏洞。例如，以太坊使用 Kademlia DHT [37] 来维护其网络拓扑，因此遭受了低资源日蚀攻击 [36]。
这些 DHT 系统中的一个典型权衡是在路由表维护中的带宽消耗和依赖于所需查找跃点数的查询延迟之间进行权衡，库马尔等人通过识别和形式化验证这种权衡[31]，和李等人提出了一种 DHT 设计，根据可用的网络带宽预算自动优化权衡 [35]，同样Shrec 也可以允许全节点根据网络带宽预算调整对等点的数量来洪泛交易公告。

结论

公共区块链系统的最新发展导致吞吐量显着提高，对交易传输效率提出了更高的要求和更多的挑战，Shrec 通过其新颖的用于交易公告编码的混合哈希方案，帮助区块链系统实现高交易传输效率和强大的安全保障。 通过显着缓解网络带宽瓶颈，这会导致更高的系统吞吐量。
这篇文章的工作致力于降低交易的带宽消耗，解决思路我画示意图如下：

@Shrec: Bandwidth-Efficient Transaction Relay in High-Throughput Blockchain Systems