踏上 Stellarator 之旅：第三部分

Bitget App

交易“智”变

Bitget

资讯中心

DFINITY2024/11/23 03:00

作者:DFINITY

作为本系列的最后一部分，Kamil Popielarz 和 Yvonne-Anne Pignolet 将分享有关提高互联网计算机入口消息吞吐量的最新进展。

在这个由三部分组成的系列中，我们将揭示能够显著改善在互联网计算机协议（ICP）上运行的应用程序的数据处理的技术成就。
此次升级是 ICP 路线图中的 Stellarator 里程碑，目前正在全网推广，Stellarator 在链上数据存储和吞吐量方面取得了突破，使每个子网能够承载超过 1TB 的内存，并能更快地上传数据，为之前受存储和吞吐量限制的数据丰富型应用程序释放了机遇。
这一进步使开发人员能够构建需要大规模数据处理的复杂应用程序，从而为区块链技术带来新的实用水平。
作为本系列的最后一部分，Kamil Popielarz 和 Yvonne-Anne Pignolet 将分享有关提高互联网计算机入口消息吞吐量的最新进展，如果您错过了本系列的前几部分，可以在这里和这里找到它们。
增加入口消息吞吐量
如果您和我们一样，那么等待数据上传到 dapp 并不是您最喜欢的消遣，因此，我们很高兴地宣布，网络神经系统（NNS）正在推出互联网计算机协议的优化，以提高共识吞吐量。
这些协议更改减少了传播区块所需的带宽消耗和时间，同时保持了 ICP 的安全属性，因此，用户将花更多时间更快地享受与 ICP dapp 的交互。
背景
互联网计算机协议协调其网络节点，即使某些节点偏离协议，也能提供去中心化的计算服务。
众所周知，ICP 可以托管任意结合了代码和数据的应用程序，这些应用程序称为容器，容器可以处理用户提交的入口消息，也可以通过交换和执行消息与其他容器进行交互。
网络节点不再在所有节点上复制每个容器的执行，而是被划分为多个分片，称为子网，每个子网都采用强大的共识协议来确保其节点上托管的容器的执行和状态一致。
共识协议负责创建和验证区块，每个区块包含一组容器消息，在就这些区块的顺序和内容达成一致后，节点可以以确定且一致的方式执行相应的容器代码，从而保持计算服务的完整性。
块有效负载包含用户提交的入口消息，用于触发复制的容器调用，在收到来自用户的入口消息后，节点将执行一系列检查（例如，签名、大小、到期时间），如果这些检查成功，节点会将消息添加到其入口池，并使用 ICP 的对等（P2P）协议将消息广播到子网中的其他节点。
当轮到某个节点创建区块提案时，该节点会从其入口池中包含一组入口消息，随后，该节点会将此提案广播给其对等节点。
然而，由于大多数对等体已经在其本地池中拥有大多数这些入口消息，因此该过程浪费了带宽。
这种方法的另一个缺点是，向所有对等方发送一个包含 1000 条 4KB 消息的提案比发送一个包含 1000 个哈希值的提案要花费更多的时间。
假设副本具有建议的最低带宽 300Mbit/s，则向具有 13 个节点的子网中的所有对等节点广播包含 4MB 有效负载的区块提案需要：4MB * (13-1) / 300Mbit/s = 1.28 秒。
如果每个哈希值小于 50 字节，则同一提案可以以快 800 倍以上的速度传送到所有节点，对于较大的子网，这些差异会累积起来，因此影响会更大。
优化
为了减少提案交付时间和带宽消耗，协议已得到改进，允许节点在区块中包含对入口消息的引用（哈希值），而不是完整消息，由于节点无论如何都会使用 P2P 协议广播入口消息，因此副本应该能够通过使用引用从其各自的入口池中检索所有入口消息来重建区块提案。
但是，节点的本地入口池中可能会丢失一些入口消息，这种情况可能是由于网络状况不佳、池已满、节点崩溃或恶意节点行为造成的，节点需要拥有提案的所有入口消息才能验证和 / 或执行提案，要获取丢失的入口消息，节点可以从发布提案的对等节点请求它们尚未拥有的消息。
为了增加在提出包含其哈希值的块之前所有入口消息都存在于所有对等方的入口池中的机会，入口池实现的某些方面进行了更改。
首先，节点现在直接向对等节点发送入口消息，而不是向对等节点发送广告并等待对等节点请求，这至少节省了一次往返，从而使向对等节点广播入口消息的速度更快。
此外，入口池大小的管理也得到了改进，到目前为止，消息数量和它们可以占用的总大小都有全局限制，如果超出这些限制，节点将拒绝对等节点广播的任何入口消息。
因此，在负载非常大的情况下，单个子网上的节点最终可能会得到几乎不相交的入口池，在这种情况下，对于每个区块提议，所有节点都必须向区块制造者请求所有消息，这会增加延迟并降低吞吐量。
为了解决这个问题，全局边界被替换为每个对等节点的边界，到目前为止，只要入口池中仍有空间容纳该对等节点，节点就会接受来自该对等节点的入口消息。
由于在任何给定时间，诚实副本都会将入口消息广播到每个对等边界，因此我们可以高度确信，即使在重负载下，同一子网上的节点也会具有高度相交的入口池。
为了尽量减少对整体协议的更改，在 P2P 和共识之间添加了一个新组件，负责从发送方的提案中删除入口消息并将其重新添加到接收方，P2P 和共识逻辑的其余部分保持不变。
绩效评估
为了说明优化的影响，我们在具有 13 个节点的测试网子网中进行了实验，并在节点之间施加 300ms RTT，将带宽限制为 300 Mbps。
实验表明，通过传输许多小消息（大约 4KB），吞吐量从 2MB/s 增加到 6MB/s。
类似地，在我们发送大消息（略低于 2MB）的实验中，吞吐量也从 2MB/s 增加到 7MB/s。
请注意，在实验中我们仅关注共识吞吐量，而我们发送消息的容器并没有做任何有意义的工作。
下图显示了上述实验中的吞吐量：

图 1：小消息的吞吐量，当前实现可以维持大约 2MB/s 的每条大小为 4KB 的消息，而新实现可以维持大约 6MB/s 的每条大小为 4KB 的消息，请注意，在旧实现中，子网需要额外三分钟来处理数据。

图 2：大消息的基准吞吐量，当前实现可以维持 2MB/s 大小的消息，而新实现可以维持 2MB/s 大小的消息，请注意，在旧实现中，子网需要额外三分钟来处理数据。
我们还进行了实验，证明节点加入子网（追赶）和节点故障以及具有许多容器或许多节点的子网的性能至少与以前一样好（并且在许多情况下要好得多）。
结论
这些协议的变化改善了互联网计算机的用户体验，为进一步的变化以处理更多更大的消息奠定了基础。
这些更改已在某些主网子网上启用，在这些子网上，您可以亲身体验到这些好处也适用于实际网络条件和变化的负载，而不仅仅是使用合成流量模式进行的小实验。
请告诉我们您的反馈，您可以随时在 DFINITY Developers X 频道和开发者论坛上分享您的想法，并继续关注即将发布的更多技术路线图更新。