作者：Marco González
编辑：Randall Roland
翻译：Josh Chung
每周三，网络节点与 Antelope 核心开发者以及其他一些社区成员齐聚一堂，举行每周节点圆桌会议。节点圆桌会议的目的是：
"......为节点操作员改进 Antelope 协议（特别是）。"
“...to improve the Antelope protocol (specifically) for node operators”.
会议每周三晚上 10 点（UTC+8）举行，持续时间约一个小时。
一、2 月 1 日期会议纪要
会议主题：Leap v3.2+ 节点技术参数配置
2 月 1 日的圆桌会议探讨了 Leap v3.2 版本以及未来版本的配置参数。讨论过程中发现，节点配置话题无法在一次会议中完成，需要未来继续讨论。
1.1 Leap, DUNE, Ubuntu 更新
最近 DUNE v1.1 的发布是 Leap核心代码提高开发者和节点使用体验的重要一步。
开发者请注意，Leap v4.0 （3 月份进入测试）将不再支持 Ubuntu 18.04，的支持，请及时升级 Ubuntu 到 v20.04 或 v22.04 版本。
另外，3月份的测试不涉及共识升级。（根据 2 月 8 日会议中的信息，计划升级时间为 9 月份）
1.2 会议记录
实践证明，为特殊用途网络节点配置参数是一件很复杂的事情。我们需要创建相关的说明文档。Leap v3.2 版本的说明文档有望解决这个问题。
HTTP 响应时间方面的讨论占据了本次会议的很大一块时间。会中，参会人员一致认为这个响应时间最少要等于最大序列化时间（serialization time）。响应时间可以设置得略高一点，以确保入站（inbound）和出站（outbound）的平衡。会中举了一个 Atomic Hub 的例子，说明 HTTP 请求失败，在大块上超时的情况。
另外，会中提到，过度的请求数据（excessive call data）和整体效率（overall efficiency）相关主题也需要考虑做进一步探讨。在会议预期可以从 “boost libraries” 和改变策略方向入手。
欢迎前往 EOS 网络基金会 YouTube 频道观看会议视频。
1.3 总结
下周讨论主题：特殊用途节点
如何最好地配置特定需求的节点这一主题，预计仅下周的会议无法完全讨论完。
该主题将按以下几个方面进行探讨：
减轻压力（alleviating pressure）
只读（read-only）
效率（efficiency）
区块传送（block progagation）
以上列举的几个方面并非独立互斥，它们往往是相互关联的。比如减轻压力和效率方面就是相互关联的。特殊用途节点及其分类涉及到抽象的概念。讨论中会尽可能具体一点。
二、2 月 8 日期会议纪要
本次会议主题：特殊用途节点
2月8日的圆桌会议开始对节点的不同配置和使用方式进行分类。正在开发的 Antelope 节点分类文件会在 Leap v4.0（预计 3 月底上 Jungle 测试网）之前到来。最早在9月进行主网共识升级。
2.1 更新
除了 3 月和 9 月这两个时间节点，我们可以继续关注 Leap 4.0 代码完成进度。
2.2 网络节点分类
特殊用途节点是所有潜在用例的一个概念模型。滤清节点的用途和配置方面的话题在开发者社区已经提出有一段时间了。Leap 4.0 版本的推出后，节点的日常管理维护体验将有一个质的飞跃。
Brian Hazzard 将节点间的头脑风暴过程比作 "乐高积木"。正如人们可能看出的那样，Antelope节点的特质和其伴随的角色往往是抽象的。欢迎社区对我们的节点分类提反馈建议。
点击后面链接查看节点当前分类列表：draft taxonomy of the roles that different antelope nodes play（羚羊节点角色划分草案）。
当前分类已在前面提到的草案中列出。本次圆桌会议探讨分类是：
出块节点（Block Producer Node）：受制于BP共识，组织、添加区块到区块链
区块中继节点（Block Relay Node）：接收对等区块，验证区块头，然后中继给其他中继节点
交易中继节点（Transaction Relay Node）：接收对等区块，验证签名，然后中继给其他中继节点
下面我们介绍一下草案中各类型的节点，更多详细内容请查看 draft taxonomy of the roles that different antelope nodes play（羚羊节点角色划分草案）
2.2.1 出块节点
出块节点特性：
确认交易，避免交易失败
高效接收待处理交易
隔离资源滥用（例如，TCP、UDP 和互联网）。
物理隔离确保密钥安全
维持一个开放的通道（用于传入和传出）
保持较低连接数（keep peers low, 3 到 5 个）。
最佳参数配置：
运行 HTTP API 访问，以监控本地网络
出块节点 API 黑名单
详情请查看草案。
2.2.2 区块中继节点
中继的定义可以看出，它是一个最基本的一个分类。中继涉及到维护与对等节点的连接以及验证区块头。Stephen Diesel 的评论如下：
"好区块进去，好区块出来。"
“Good blocks go in, good blocks go out.”
中继节点的优势在于，它可以比出块节点保持更多的连接数（10-15 个）。另外，需要注意的是，虽然一个区块中继节点可能是公开的，但它不应该被宣传（例如在 bp.json 上）。
Stephen 的评论说明了维护一个能够持续提供区块中继的连接数（a peer group）的必要性。维护一个开放的通道不仅涉及同步交易，还涉及接受新区块的准备工作。未能保持准备状态被认为是造成出空块的原因之一。
2.2.3 交易中继节点
与区块中继节点一样，交易中继节点也可以在验证头之后负责中继区块。交易中继节点的不同之处在于它也能接受：
未完成的交易
来自首选连接（preferred peers）的交易
来自 P2P 或 API 的公共交易
2.2.4 补充说明
Kevin Heifner 分享了一个正在完善的改善区块头验证后的区块传送的解决方案。 EOSUSA 的 Michael 分享了他的节点设置的图表（见 2 月 8 日圆桌会议记录）。
更多细节仍然在完善中，当前的节点都包含以下三个基础方面：
nodeos
代码
网络连接
欢迎查看 EOS 网络基金会 YouTube 频道的会议视频。
2.3 总结
接下来的会议将要介绍的节点分类：
Push API 节点
Chain API 节点
State API 节点
开发者节点
节点分类系列讨论预计将在下周继续进行，重点讨论上述分类。
资源与引用：