交易八卦广播的目标之一就是让交易进入矿工所在的网络“中心”的原链接：

https://ethresear.ch/t/scalable-gossip-for-state-network/8958

作者： Piper Merriam

在我之前的八卦播出网设计中，其实可以看到我为国家网设计八卦播出的初步尝试。在前一篇文章中，我介绍了一种允许节点参与八卦广播而不处理完整事务池的设计。

在更高层次上，我们关于交易八卦广播的问题陈述如下(忽略DOS攻击/安全要求):

交易来自整个网络。

一些网络参与者本身需要维护一个完整的交易池(例如矿工和跑步者)。

一些网络参与者缺乏足够的资源来处理完整的事务池(例如，轻型客户端)。

我提出的交易八卦广播方案使用距离指示器[我们称之为半径]，它允许节点调整他们必须自己处理的交易池的大小。节点采用一组简单的规则来管理与之相连的一组对等节点，从而形成网络拓扑。半径最大的节点视为网络的中心，半径最小的节点视为网络的边缘。

该计划有效的主要原因有两个：

首先，我们预计节点的半径值会有很大不同，但同时它们会相对较大。这种差异来自于参与者保持“完全”半径和“更大”半径的动机。正是这些节点连接了网络边缘的节点。

其次，我们对更大半径值的期望是从键空间中推断出来的。根据Peter最近关于事务池的文章，geth节点默认可以维护多达4000个事务。在任何时候，整个网络中有多达40，000到400，000个待定事务。轻节点不能处理4000个事务，但是处理5%不是问题。因此，我们期望半径值通常在整个密钥空间的1%到100%之间。

将同样的设计应用到状态 gossip 广播上（并不奏效）

我最初试图将这种设计应用于国家网络的八卦广播，但失败了。主要原因如下：

首先，状态网络中节点之间的半径值差异会小得多。我们预计网络参与者不太可能保持“完整”的半径。这将导致网络中缺少一个充当连接边缘的“中心”。

第二，半径值会很小。假设有一个200 GB的状态，每个节点平均提供100MB的存储空间，复制因子为10，那么我们需要一个由20000个节点组成的网络。平均每个节点需要存储0.002%(1/20，000)的数据。

正是这两个差异从根本上改变了网络拓扑结构，导致了原有八卦广播网络设计的失败。

与交易 gossip 广播不同的目标

，别忘了，交易八卦广播的目标之一就是让交易进入矿工所在的网络“中心”。处于网络边缘的节点并不真正关心他们是否能看到所有的未决事务，即使他们看不到任何事务。他们主要关心的是他们是否能够可靠地广播他们的事务并将它们打包成块。

地位网不仅缺乏中心，而且数据流与八卦广播相反。状态八卦广播的目标是将数据发送到网络边缘进行存储。

另外，在交易八卦播报中，消息来自全网；在状态网络中，我们预计新数据只会来自少数友好的桥节点。这些桥节点负责生成证书并将其发送到状态网络。

中继机制会导致 DOS 攻击和不可归因的错误

我想到的改进方向之一就是引入中继节点。

我们预计每个节点将对网络中0.002%的数据感兴趣(数据量非常小)。我认为根据我的结论可以建立不同的网络模型，但是一个简单的方法是根据DHT网络中每个节点的路由表为八卦节点之间的连接建立一个模型。在这样的网络中，数据需要log(n)跳才能到达需要它的节点。

这里的问题是，如果一个节点转发了其他节点不感兴趣的数据，但是这个数据需要经过一次以上的跳转，那么它就会成为一个放大向量。恶意节点可以通过在八卦网络中广播无用数据来放大DOS攻击。

一个笨办法

目前我更倾向于一种“笨”的方法，从非网络层面解决以上问题。

有“一小组”状态提供者节点为每个块中的新状态数据生成证书。

每个证书预计有大约2000个trie节点。一些节点是新数据或更新数据。只有这个子集需要发送到网络。

众所周知，每个节点只关心每个块中0.002%的数据，这意味着不同节点的数据之间几乎没有重叠。如果一个块包含2000条新数据，我们可以预见每条数据将被发送到一个完全不同的节点。这意味着，为了在块时间内广播新块的证明数据，状态提供者每15秒向2000个不同的节点发送2000个不同的证明。做到这一点不是不可能，但会很难。一旦证明大小增加或网络延迟稍高，状态提供者就不能在块时间内发送完整的证明数据。

幸运的是，我们可以有多个数据提供者。我们可以合理地预期，少数(但不是少数)状态提供者将发送认证数据。在这个模型下，我们可以设计一个能够在不同的状态提供者之间平均分配负载的系统。

每个状态提供者为每个新块生成一个证书。状态提供者将根据与它的node _ ID的距离对证明中包含的每一项数据进行排序，从最近的数据开始，查询对这些数据感兴趣的节点，并广播它们。在这个模型中，负载均匀地分布在不同的状态提供者之间。当那些远离节点标识的数据到达时，状态提供者会发现节点对这些数据的兴趣被削弱了，因为节点标识靠近这些数据的提供者已经广播了这些数据。

可以改进/扩展/优化之处

也许，我们可以稍微优化一下这个方案。

我们的网络结构不仅需要存储叶节点，还需要存储中间节点。也就是说，如果根据叶节点和对等节点的需要来划分分块证明，那么这些碎片化的证明之间就会有很多重叠。比如你要证明一个叶节点，它的证明也会包含它的默克尔路径上所有中间节点的数据证明。

如果网络中的一个节点想要存储一个叶子，那么TA希望获得叶子节点的中间节点也可以在网络中找到。如果这些中间节点不可用，甚至没有人会请求叶节点的数据，因为本地没有中间节点的数据，也不可能沿着这些中间节点找到对叶节点的需求。我们或许可以利用这一点，将广播数据的责任分散到整个网络。

状态提供者只通过流言传播叶节点数据的证明。

节点一收到想要存储的内容的证明，就会找出父证明——对上一级中间节点数据的证明——，并发送出去。

这个“递归”过程允许状态提供者只向网络发送叶节点数据，并将广播中间节点数据的责任分配给那些对叶节点数据感兴趣的节点。这些节点会将上层中间节点的数据证明逐级推送到网络中，直到所有节点将最终状态根推送到网络中。

(结束)

(文本中有很多超链接，可以点击左下角阅读原文，从EthFans网站获取)