所有收藏
EOS Support 媒体
节点圆桌会议半月摘要 [2023.4 #2]
节点圆桌会议半月摘要 [2023.4 #2]

发布于 2023 年 5 月 12 日

Dario Cesaro avatar
作者：Dario Cesaro
一周前更新

作者：Marco González

编辑：Randall Roland

翻译：Josh Chung

每周，节点操作员、Antelope 核心开发人员以及社区成员聚在一起，讨论当前热门话题。节点圆桌会议的主要目标是：

“…为节点操作员改进 Antelope 协议（具体而言）”。

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

该会议在每周三晚上 10 点（UTC+8）举行，持续时间一个小时。如果想要学习 EOS 节点操作基础知识，可以查看 EOS 网络基金提供的教程和文档。

4 月 19 日和 26 日的圆桌会议探讨了 Leap 开发。4 月 19 日设想了 Leap 5.0 版本可能会带来的影响。4 月 26 日，此时 v4.0.0 已经上线，该次会议收集了对 v4.0.0 反馈意见，探讨了一个新提案。

4 月 19 日：“Leap 5.0 及其未来的期望和愿景”

这次会议探讨 EOS 网络未来的潜力，会议中的氛围特别好，如梦如幻。你可以在 EOS Nation GitHub 上查看 4 月 16 日的会议记录，在 ENF 的 YouTube 上观看录制的圆桌会议视频。

概述

Antelope 5.0 版本还有好几个月才会发布，现在正在紧张有序地开发中。开发团队欢迎社区对代码更新方面的反馈。这份摘要中你可以了解到参与者的点评，你也可以在 Github 中分享自己的想法。

我们先了解一些更新：

  • Leap v4.0.0 即将到来

  • Antler 工具

  • CDT 演示预计在一两周内进行

4 月 19 日的圆桌会议由 Antelope 团队主导，探讨了 5.0 版本及其未来的希望、抱负和梦想。

以下摘要根据 Brian Hazzard 提供的笔记撰写。Antelope Leap 5.0 版本计划于 2023 年秋季发布。请保持关注，时间也可能提前到九月之前发布。

EOS 主网 5.0 版本代表着社区的未来和愿景。参与者被要求表达他们的愿望（思想和梦想）。讨论的子主题包括：

  • 当前兴趣

  • 相对容易实现的小更新

  • 实用、有趣和通用的痛点缓解行动

  • 引人注目的，有争议的、令人惊喜的因素

  • 节点运营商和用户的梦想和抱负

上述子主题帮助开始了 5.0（及其未来）的开发方向的探讨。以下是九位参与者的简要概述：

  • Ross：动态对等发现，自动选择最佳对等点，轻松查看上一个区块

  • Daniel: 多链友好，实用的 ETH 构建块，Graph 集成

  • Micheal: 更详细的管理终端（“GetInfo2”），指示安全/同步节点的健康查询（“已准备就绪”）

  • Marco（MachnBird Sparo）：方便易用的支付处理流程和硬件

  • Aaron: 与所提交规则一致的特定规则临时授权权限

  • Kevin：区块验证的并行化，100K TPS 以及水平扩展

  • Denis：通过整合和提高效率改善本地资源使用

  • Tony：用于日志记录的 Loki 集成和本地监控解决方案

  • J.P.：通过营运 API 改进对等节点管理，轻松了解新功能/修复更新

  • Mathew：集成 WAX RNG，在 IPv6 中实现自动启动 nodeos 和压缩快照格式

展望

收集社区反馈是当前开发的核心。对 5.0 版本开发的早期反馈可能是最有价值的。

4月26日：nodeos 5.0 API/Serialization 提案

随着 Leap v4.0.0 的上线，开发开始专注于 5.0 版本的开发。欢迎在 EOS Nation 的 GitHub 上查看 4 月 26 日会议的会议记录，ENF 的 hackmd.io 链接中可以找到（更新的）Nodeos 5.0 API/serialization 时间限制提案，还可以在 ENF 的 YouTube 频道观看会议视频。

概述

会议讨论中再次强调了社区反馈的重要性，并以问答形式进行了讨论。更新内容包括：

  • 本周发布了 V4.0.0 版本，有些节点操作员已经在开始使用；

  • CDT v4-rc1 可能会在下周发布。

5.0 版本的 API/Serialization 时间限制提案

以下是该提案的简要概述，主要包括两个变化：

  • ABI 序列化限制；

  • 非原子 API 项约束。

大多数 ABI（应用程序二进制接口）请求现已将反序列化移至 HTTP 线程池。这样做可以提高 nodeos 的响应性能，但是需要对非原子 API 返回的项数量进行限制。具体来说，针对 http_max_response_time 的请求必须指定范围和最大时间。请注意，有效请求始终返回至少一个对象，最多返回 1,000 个对象，且默认最大值为 1,000 个对象。

该提案的主要指导需求总结如下：

  • API 节点应成功处理任何原子请求；

  • 非原子 API 调用应指定最大请求时间；

  • 必须防备用户提供的 “abi-bombs”（ABI 炸弹）。

讨论

讨论比平常更加自由，针对以下主题进行了热烈的争论。

get_block 发生变化的原因

将 get_block 放在 HTTP 线程可以提高程序的性能并避免卡顿现象。

时间监控

推荐使用 Prometheus 而不是使用类似历史解决方案的工具。Prometheus 可以帮助很多方面的监测任务。在愿望清单中，有一个轻便、易得的解决方案，可以被广泛使用。

开发者使用场景

在讨论中简要讨论了开发者使用插件的可能性。提到了推进插件，提到了trace_api_plugin，并且提到了一些开发者（特别是金融领域的开发者）对第二层解决方案的不信任。

其他主题

其他引起大量讨论的主题包括：

  • 失败（或冻结）的原因；

  • 最大响应时间；

  • 关于历史记录解决方案的更多信息；

  • 快照。

展望

Leap 5.0 版本肯定会引发激烈的讨论和更多的提议。正确处理这个面向性能的提案能够为 5.0 版本的顺利推进打下基础。参与者似乎都注重质量而非快速推出解决方案。

资源与引用：

这是否解答了您的问题？