作者：Marco González

编辑：Randall Roland

翻译：Josh Chung

每周三，网络节点与 Antelope 核心开发者以及其他一些社区成员齐聚一堂，举行每周节点圆桌会议。节点圆桌会议的目的是：

"......为节点操作员改进 Antelope 协议（特别是）。"

“...to improve the Antelope protocol (specifically) for node operators”.

会议每周三晚上 10 点（UTC+8）举行，持续时间约一个小时。

三月份的前两个圆桌会议中，会议继续围绕特殊节点话题进行，方向集中在最佳实践方面。3 月 1 日的圆桌会议探讨了网络节点目标与最佳实践。3 月 8 日的会议完成了单功能块中继节点的讨论。如果您关注即将到来的“代码冻结”（code freeze），可以关注一下 3 月 8 日圆桌会议后几天的公告。Leap 4.0.0 测试网发布方面，开发团队计划在三月底或四月初完成。

《Antelope 节点角色分类草稿》 包含了全面的注释。如果想从头到尾了解关于特殊节点分类的讨论，请访问 GitHub 上名为 “Post Upgrade meetings” 的部分。

历史节点解决方案和最佳实践

观看 ENF 的 YouTube 频道上的 3 月 1 日圆桌讨论。也可以到 EOS Nation (Leap) GitHub 上阅读会议记录。

3 月 1 日的圆桌会议是有关特殊用途节点的第四次讨论。其中探讨的一个问题是在生态中实现更高效的资源模型。这包括三次打击规则与主观计费需求。

小组对历史提供者（History provider）的注释进行了补充。在草稿文件中特别提到有关历史的主要节点类型包括：

提供历史数据的二层（Layer-2）方案包括：

关于“状态历史”（state history），问题包括：

此外，请查看关于历史（history）的后续建议。

资源提供者节点（Resource Provider Node）是节点分类中的最后一个节点类型，它是第三个二层（Layer-2）解决方案。其目标是提高用户体验。虽然资源提供者节点（Resource Provider Node）目前运行在 node.js 上，但它可能最终像 API 插件一样去中心化。分类草稿文件将资源提供者节点（Resource Provider Node）定义为：

“接受并解释客户端的交易，对其进行验证，并执行业务逻辑以确定节点是否会共同签署交易以支付 CPU/NET/RAM 费用。”

“Accepts and interprets transactions from clients, validates them, and performs business logic to determine if the node will cosign a transaction to cover CPU/NET/RAM costs.”

会议继续讨论最佳实践，继续在探索最优化配置方面努力。探讨最佳实践的一个重要目的是确定 Antelope 网络（例如 WAX、Telos 等）的最低要求。

最佳实践可能会引起争议，因为不同的网络有不同的需求。例如，以下这些都会因区块链网络利用率的变化而变化：

设备要求

设备要求是最佳实践讨论的重点。运营商在更改节点类型时应检查所有的 nodeos 配置。例如，在启动-停止或不间断运行切换时应重新调整 CPU 以符合 AtticLabs 的建议。有关 AtticLabs 和其他设备要求（如 ECC RAM、x86 处理器等）的内容，请参阅分类草稿文档。

最后，圆桌会议提到了有关安全最佳实践和不重复使用硬件密钥的注意事项。

出块节点（Block Producer Nodes）增加了一些最佳实践建议。建议包括：

Chain API 节点的讨论已经结束，得出了应该提供什么的结论（例如，只使用 Getinfo 简化，尽管 Prometheus 可以提供其他解决方案）。

请记住，某些节点类型将需要可变配置。

会议结束时，跟进了其他事项（在分类草案文档的 “Next Steps” 部分）。

你可以观看 ENF 的 YouTube 频道的 3 月 8 日圆桌会议记录视频。也可以阅读 EOS Nation（Leap）GitHub 上的会议记录。

Antelope 团队报告称，他们正在按计划进行，计划在本月底或 4 月初发布 Leap 4.0 候选版本。Antelope Leap 4.0.0 的面向未来的开发目前已经结束。“代码冻结”（code freeze）的公告即将发布。

首先讨论了出块节点的 nodeos 配置最佳实践。节点之间的连接几乎总是内部的。使用 WireGuard 密钥（例如）保护内部节点网络是一种有效的方法。WireGuard 只是其中一种选择。这些密钥可以防止意外的烦人连接。

在接下来的步骤中，特殊用例场景（例如重新同步）被列入了跟进项目。并建议考虑提高效率。

圆桌会议讨其余时间集中讨论了单功能块中继节点（Block-only Relay Node）及其配置最佳实践。会议详细讨论了连接数量（number of connections）。在之前的会议中，认为 10 到 15 个连接是适当的数量。不过，这个小的连接范围只是一个起点。

对于 Leap 3.2，将单功能块中继节点（Block-only Relay Node）的连接数最大化在 25-50 之间是安全的。需要提醒的是：

对单功能块中继节点（Block-only Relay Node）设备的第一个要求是需要多个设备同时运行，以避免单点故障。

讨论的大部分内容都集中在连接和速度上。强调了可靠的互联网连接。同时需要写入速度快的磁盘。有关全日志与部分块日志的最佳实践，请参阅分类草案文件中的其他最佳实践。值得注意的是，Leap 4.0 预计将具有自动节点连接功能。

这里有一个重要的区别，即一个常见的误解。在 Antelope 链上，快照只是当前状态。这与以太坊的定义不同。因此，对于 Antelope 链，对于内部中继，对于完整的块日志，只需要 “足够多” 的对等网络即可，不需要完整的历史记录。

在分类草案讨论中，一直提到调整最佳实践之外的变量的影响。例如，纯单功能块中继节点只接受块，不接受其他内容。此外，Leap 4.0 可能不需要单功能块中继节点。

预计下周的圆桌讨论将继续讨论 API 节点（API Node）的 nodeos 配置最佳实践。

资源与引用：