作者：Marco González
编辑：Randall Roland
翻译：Josh Chung
每周，节点操作员、Antelope 核心开发人员以及社区成员聚在一起，讨论当前热门话题。节点圆桌会议的主要目标是：
“…为节点操作员改进 Antelope 协议（具体而言）”。
“...to improve the Antelope protocol (specifically) for node operators”.
以下是此次半月摘要中的两个圆桌会议：
6 月 21 日：P2P 改进文件中列出了问题和解决方案
6 月 28 日：区块修剪、Leap 5.0 计划、交易瞬时确认（IF）、编译器优化（OC）
6 月 21 日：P2P 改进文档中列出问题和解决方案
6 月 21 日的会议继续讨论 P2P。在 GitHub 文档回答最近几周的一些反馈主导了本次讨论。
概述
指导文档清楚地定义了问题。定义了一个与以前的反馈密切相关的可接受的解决方案。
更新
会议中发布了 Leap 4.0.3 补丁。
分解 P2P 改进指导文件
指导文件页面分解为几个部分：问题、解决方案、问题、资源和评论。
问题：机会、受众和策略
不同的目标用户群体有不同的需求。现在更好地理解了优先事项。
确定受众是基于 Antelope，并且：
关注 “可靠性、成本效益以及简洁解决方案” 的 “熟悉技术的个人”（节点运营者）
“technically proficient individuals” (node operators) concerned with “reliable, cost-effective, and simplified solutions”
为了让问题与核心开发协调同步，需要专注于 “改善用户体验和基础设施效率”。成功的实施预计将带来 “Antelope 协议更广泛的普及与成功”。
回到目标用户的机会，最高优先级事项如下：
列表中排名最高的是 “改进可用块的追赶模式的对等连接选择（improve catch up mode peer selection for available blocks）”。
带宽是最近几周的常见讨论。下一个优先事项是改进 “对等带宽消耗（peer bandwidth consumption）” 的控制。避免滥用和自动轮换对等连接是重点。
第三个重要优先事项是 “将对等连接标记为内部或外部的功能（ability to label peer connections as internal or external）”。在这里取得成功预计将解决 “内部基础设施中的信任（层）（trust (levels) within internal infrastructure）” 问题。
请参阅文档和/或视频以获取其他问题的描述，包括基于终端的 UI、对等连接黑名单和同步。
定义解决方案并确定风险
上述产品机会的名称为 “P2P 改进（P2P Improvements）”。GitHub 文档上列出了四个主要的成功指标：
改善新节点或重新启动节点的同步时间
减少获取新节点配置所需的步骤数
提高通过 P2P 网络传输交易的可靠性
提高通过 P2P 网络传输交易的速度
确定风险的过程参考了由硅谷项目组撰写的一篇文章（四个大风险）的思想。关于并行时间表的 P2P 对等连接发现的 RFP（P2P Peer Discovery RFP）中提出了一个问题：
“是否存在冲突或重叠的风险？”
“Is there any risk of conflict or overlap?”
请参阅文档页面以获取更多资源和问题。
会议评论和反馈
参与者的回复包括：
内部节点和瓶颈
存储速度至关重要
bloks-log 被认为是涉及读取和本地对等连接（例如操作和同步的数量）的问题
同步选项有限
带宽与状态范围（如果带宽足够且轮换对等连接，则可能不是问题）
结束对话
会议在澄清问题中结束。有人问到限制带宽（减缓）作为带宽管理策略。从反馈中可以得知，相比断开对等连接，限制带宽是一种可选择。
开发团队邀请节点运营者帮助引导下一步。注意文档页面中的任务拆分（“特性/史诗，Features/Epics”）部分。带宽和控制机制在这里被提到。
6 月 28 日：区块修剪、Leap 5 计划、交易瞬时确认、编译器优化
6 月 28 日的会议确定了区块修剪作为需要改进的领域。Leap 5.0 的规划包括准备时间、新标准、交易瞬时确认（IF）、编译器优化（OC）等等。
概述
节点运营者们分享了他们在当前块修剪过程中的经验。讨论了诊断、自动化等解决方案类型。会议的最后三分之一讨论了 Leap 5.0 的规划和准备工作。
更新
Leap 4.0 没有新的更新
开发团队继续为发布 5.0 候选版本重新制定时间表
更多关于 Leap 5.0 的内容将在后面的章节中讨论。
社区关注点
会议开放讨论了社区关注的问题。讨论从修剪区块以及当前 4.0.3 与 5.0 预期的不同问题开始。区块修剪引起讨论兴趣。使用 leap-util 修剪 bloks-log 异常的解决方案引出了几条评论。需要将修剪扩展到数百个块，这似乎可以得到改善。可以识别错误（异常）的更小修剪是一个值得添加的功能。
更深入讨论的主题
开场中有两个主题似乎引起共鸣：
leap-util 的格式和内容（例如 smoke test）
需要回滚 bloks-log
以下是提到的具体事项列表。与会议记录一致，列表项按照一般的时间顺序和逻辑顺序排列：
显示与功能
最小修剪的潜在改进
确保安全的解决方案
建议添加连续（逐个）修剪
可以确定损坏块的修剪诊断工具
小心不自动删除块的自动修复解决方案
公共节点与私有节点解决方案
区分公共节点与私有节点的通过快照进行完整修复的功能
社区似乎希望有更简单的诊断和恢复工具。有关更多详细信息，请访问 leap-util 无法成功运行详细的 smoke test，无法修剪 blocklog。#1348。
Leap 5.0 计划
如前所述，发布 Leap 5.0 候选版本计划已经开始。开发团队致力于缓解共识升级涉及的漫长而复杂的过程。Leap 5.0 将建立一个标准程序。需要几个月时间来准备社区。计划专注于在假期前发布，因此从 9 月开始推出。
预计 Leap 将每年进行两次重大更新。其中一次可能需要共识升级。减少节点运营成本是其中的主要关注点。这包括在添加新链时为节点运营商降低成本。对有关经验和优化（RAM、CPU 和磁盘空间）的好处进行了评论。强调了更多人升级到 4.0 的重要性。
5.0 的两个主要协议升级功能是：
交易瞬时确认（Instant Finality, IF）
优化编译器（Optimizing Compiler, OC）功能
交易瞬时确认（IF）似乎是两者中最重要的关键点。交易瞬时确认（IF）仍然是 ENF 对新 EOS 最初计划的一个关键举措。优化编译器（OC）功能主要是为了提高 EVM 性能，但还包括出块节点等整体优化编译器（OC）好处。更多信息，请参见添加 eos-vm-oc-enable 自动模式 ＃1322。
其他项目正在并行开发中，预计将在未来发布，以免延迟 5.0。
结束对话
会议以对 5.0 中优化编译器（OC）功能的审查结束。目前的开发关注基础改进。优化编译器（OC）应该首先在 eosio 系统合约上运行（例如用于代币和 EOS EVM），然后再运行其他功能。新功能和为 Leap 5.0 做准备可能仍然是未来会议的重点。
资源与引用：