Leap 3.2 已发布，它已在本次圆桌会议上揭晓。此外，还讨论了状态数据库的基本问题，即其天文数字般的高 RAM 使用率。探讨了潜在的长期的和短期的解决方案以及权衡取舍。

此外，在会议结束时，EOS网络基金会（ENF）对 NET 插件增强的细节进行了简要总结，会议还确定了下次圆桌会议的时间表和主题：Leap 4.0 的 Prometheus Exporter 黑盒 nodEOS 的功能统计。本次圆桌会议共有13人参加。

Exporter 是一个采集监控数据并通过 Prometheus 监控规范对外提供数据的组件，它负责从目标系统（Your 服务）搜集数据，并将其转化为 Prometheus 支持的格式。

软件开发是每周 EOS 节点运营商圆桌会议期间讨论的主要话题。开发人员、区块生产者、区块链工程师和社区成员想要从它提供的知识中受益，都将需要详细了解 EOS 开发过程。

一个生态系统可以通过共享和交互来健康自然地发展。ENF 收到了区块生产者和开发者对其工作进展的好评。EOS 社区意识到，他们的声音现在被听到和受到赞赏。最后，但同样重要的是，即正在对社区关注的问题做出回应。

Stephen Diesel（ENF，Leap产品经理）对 Antelope Leap 的更新总结

在这次会议开始时，Stephen 宣布了 Leap 3.2 在 Github 上发布，但它不是共识升级，因此是可选择的。

Brian Hazzard 同意在各种渠道回答有关升级的任何问题。下周将更新 Net Plugin Enhancements 文档，因为上次会议收集了很棒的想法并为 backlog 定义了一些新的潜在的功能。

来自 EOSUSA 的 Michael 不能参加会议，但他为这次会议建议了主题：状态数据库修剪（State Database Trimming）。参与者一致认为，真正的问题是使用了过多的 RAM。Per Stephen 正在起草一份 RFP，其目标是进行研究以调查 RAM 的问题。

权衡性能与 RAM 大小。

Kevin Heifner 提出了主要问题：“你愿意用多少性能来换取 RAM？你愿意用 1 个区块生产周期来将数据加载到 RAM 中（就像一个加热区块(warming bloc)）吗？” 但是，此解决方案存在垃圾邮件的高风险。

对 RAM 的巨大需求似乎从未得到满足。目前需要 128 GB 的 RAM 才能顺利运行 WAX 状态数据库。问题是普通设备没有足够的空间容纳更多 RAM。很难找到具有强大 CPU 和足够 RAM 空间的设备。也许图形设计师/动画师设备可以满足未来的需求。

短期机会

长期机会

在主持人 Daniel Keyes 简短询问他是否可以对最近讨论的增强 Net 插件的具体建议进行简短总结后，Brian Hazzard 很快谈到了以下问题，并提出在接下来的会议中更详细地介绍这些问题在内核。

EOS Nation 的 Matthew 提出的下一个 Leap 4.0 中普罗米修斯出口商（Prometheus Exporter）应该包含哪些数据的辩论：

本次圆桌参会者（13人）：