原文链接:

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

作者: Piper Merriam

在我之前的新式买卖 gossip 播送网络规划中其实能够看到我最初在为状况网络规划 gossip 播送方面的尝试。在之前的文章中,我介绍了一种规划,能够让节点在无需处理完好买卖池的情况下参与 gossip 播送。

从较高层面上来说,咱们关于买卖 gossip 播送的问题陈说如下(忽略 DOS 进犯/安全性要求):

  • 买卖来自整个网络。

  • 一些网络参与者自身就需求保护完好的买卖池(例如,矿工、抢跑买卖者)。

  • 一些网络参与者缺少满足的资源来处理完好的买卖池(例如,轻客户端)。

我提议的买卖 gossip 播送计划采用了间隔方针【咱们称之为 radius(半径)】,让节点能够自行调整它们必须处理的买卖池规模。节点采用一组简单的规则来办理与之衔接的对等节点集合,从而形成网络拓扑结构。半径最大的节点被视为网络的“中心”,半径最小的节点被视为网络的“边际”。

该计划之所以有用,首要的两点原因如下:

第一,咱们预期,节点的半径值会有很大不同,但 一起 都会相对较大。这种差异源自那些有动力保护“完好”半径以及“较大”半径的参与者。正是这些节点将坐落网络边际的节点衔接到了一起。

第二,咱们关于半径值较大的预期是依据键空间推测出的。依据 Peter 最近关于买卖池的文章,geth 节点默认最多可保护 4000 笔买卖。在任意时刻,整个网络中的待处理买卖高达 4 万至 40 万笔。轻节点无法处理 4000 笔买卖,可是处理其间 5% 不成问题。因而,咱们预期半径值通常在整个键空间的 1% 至 100% 之间。

将同样的规划应用到状况 gossip 播送上(并不见效)

我最初尝试将这种规划应用到针对状况网络的 gossip 播送上,可是没有成功。首要原因如下:

第一,状况网络中各节点在半径值上的差异会小得多。咱们预期不太可能会有网络参与者保护“完好”半径。这会导致网络中缺少一个起到衔接边际作用的“中心”。

第二,半径值会很小。假设有 200 GB 的状况,平均每个节点供给 100MB 的存储空间,且复制因子为 10,那么核算下来咱们需求一个由 2 万个节点组成的网络。平均每个节点需求存储 0.002%(1/20,000)的数据

正是上述两个不同之处从根本上改变了网络拓扑结构,导致原来的买卖 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 间隔这些数据较近的供给商现已播送了这些数据。

能够改善/扩展/优化之处

或许,咱们能够略微优化一下这个计划。

咱们的网络结构需求存储的不只是叶节点,还有中心节点。也就是说,假如按叶子节点和对等节点的需求来切割区块证明,这些碎片证明之间会出现大量堆叠。例如,当要你要证明一个叶节点的时分,其证明中也会包括对其默克尔路径上所有中心节点的数据的证明。

假如网络中的某个节点想存储某个叶子,TA 当然期望获得该叶子节点的中心节点也能够在网络中找到。假如这些中心节点不可得,甚至都没有人会请求叶子节点数据,由于本地还没有中心节点的数据,还无法顺着这些中心节点发现对叶子节点的需求。咱们或许能够利用这一点在整个网络中分散播送数据的职责。

  • 状况供给商经过 gossip 方法播送叶节点数据的证明。

  • 节点一收到自己想要存储的内容的证明,就会找出 “父证明” —— 对上一级中心节点数据的证明 —— 并发送出去。

这一 “递归” 进程能够让状况供给商只需将叶节点数据发送至网络,并将播送中心节点数据的职责分配给那些对叶节点数据感兴趣的节点。这些节点会一级一级地把上一层级的中心节点的数据的证明推送到网络中,直到所有节点都把最终的状况根推送到网络中。

(完)

(文内有许多超链接,可点击左下 ”阅读原文“ 从 EthFans 网站上获取)

视野开拓

带宽badwidth就是心智的容量,包括两种能力,分别为认知能力和执行控制力。稀缺会降低所有这些带宽的容量,致使我们缺乏洞察力和前瞻性,还会减弱我们的执行控制力-《稀缺》

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注