织梦CMS - 轻松建站从此开始!

我的网站

当前位置: 主页 > 竞争币 > 以太坊

观点 | 用于状态网络的可扩展广播方案(2)

时间:2021-03-30 13:55来源:未知 作者:admin 点击:
状态网络不仅缺少中心,而且数据流向与交易 gossip 广播相反。状态 gossip 广播的目标是将数据发送到网络边缘进行存储。 另外,在交易 gossip 广播中,消

状态网络不仅缺少中心,而且数据流向与交易 gossip 广播相反。状态 gossip 广播的目标是将数据发送到网络边缘进行存储。

另外,在交易 gossip 广播中,消息来自整个网络;在状态网络中,我们预期新数据只会来自一小部分友善的桥节点。这些桥节点负责生成证明,并将这些证明发送到状态网络。

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

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

我们预期每个节点会对网络中 0.002% 的数据(体量很小)感兴趣。我认为,根据我的结论可以构建出多个不同的网络模型,但是一种简单的做法是,根据 DHT 网络中每个节点的路由表为 gossip 节点之间的连接构建模型。在这样一个网络中,数据需要经过 log(n) 跳才能到达需要它的节点那里。

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

一个笨办法

目前,我比较偏向于一个 「笨」 办法,旨在从非网络层面解决上述问题。

  • 有 「一小批」 状态提供商节点为每个区块内新的状态数据生成证明。

  • 每个证明预期有大约 2000 个 trie 节点。其中一部分节点是新数据或更新后的数据。只有这个子集需要发送到网络中。

已知每个节点只关心每个区块中 0.002% 的数据,也就是说不同节点感兴趣的数据之间很少有重叠。如果一个区块内包含 2000 条新数据,我们可以预见每条数据要发送给完全不同的节点。这就意味着,为了在区块时间内广播新区块的证明数据,一个状态提供商每 15 秒要将 2000 个不同的证明发送给 2000 个不同的节点。要做到这点不是不可能,但是会很难。一旦证明大小增加或网络延迟稍微高一点,状态提供商就无法在区块时间内发送完整的证明数据。

幸好我们可以有不止一个数据提供商。我们可以合理预期将会出现数量不多(但是不会很少)的状态提供商发送证明数据。在这个模型下,我们可以设计一个能够在不同状态提供商之间平均分配负载的系统。

每个状态提供商都会为每一个新区块生成证明。状态提供商会按照距离其节点 ID (node_id)的远近对该证明包含的每项数据进行排序,先从那些距离最近的数据开始,查询对这些数据感兴趣的节点,并将它们广播出去。在这个模型中,负载会在不同状态提供商之间平均分配。等轮到那些距离其节点 ID 较远的数据时,状态提供商会发现节点对这些数据的兴趣减弱,因为其节点 ID 距离这些数据较近的提供商已经广播了这些数据。 (责任编辑:admin)

织梦二维码生成器
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
栏目列表
推荐内容