作者: Marco González
编辑: Randall Roland
译者: SHE
EOS 网络积极创新,会让 2023 年成为值得纪念的一年,并让 EOS 重现辉煌。节点运营商圆桌会议是社区讨论技术问题,并为下一级协议创新做准备的平台。
自从 AntelopeIO(Leap 3.1)于 2022 年 9 月首次发布,会议重点就从记录发布下一代技术转变为确定重要技术的改进功能。2022 年最引人注目的讨论包括:
计划管理
P2P改进
添加普罗米修斯出口商(Prometheus exporter)
本期 EOS 节点运营商圆桌会议双月总结涵盖至 1 月 4 日,以及 11 日和 18 日(合并)。2023 年的前两次会议采用了不同的形式,出于安全原因,并没有发布任何视频。
2023 年 1 月 4 日:探索更具成本效益的资源模型
1 月 4 日圆桌会议的主要关注点是收集对 AntelopeIO 资源模型的潜在改进更新的反馈。在前几周,WAX 上的拥堵问题被确定为可以改进的领域,以提高全面的运营绩效。会议首先确定了节点运营商遇到的痛点。
硬件、存储和 RAM 注意事项
在讨论 RAM 使用后,考虑了低级和高级硬件。潜在的痛点症结包括限制上限(低级)和经济可行性(高级)。关于新资源模型,存在以下机会:
“...更好地调整与可用存储相关的存储利用率的激励/抑制措施,尤其是在 RAM 方面”
对于这个想法是,一个新的资源模型应该专注于,以具有成本效益的方式增加可用网络存储。
“燃料”限制
“Gas”(或燃料)资源模型与原始资源、REX 和增强服务等当前选项进行了权衡。然而,历史证明,推动每笔交易都有其自身的问题。小微交易是 EOS 擅长的领域,通常是 Gas 模型的沉重负担。此外,摆脱 EOS 的内置操作还有一个心理因素。
无 Gas 操作和易用性
无 Gas 操作将 EOS 描述为易于使用的区块链。指导 EOS 进步的早期概念之一是 dApp 本身将其服务建模为用户的资源提供者。当然是用户是增加的。然而,经济可行性和滥用的可能性需要进一步审议。
编纂解决方案
讨论推动产生的一个潜在结果是编纂本地解决方案。评估资源拉取(例如用户、开发人员、钱包和节点运营商)可以识别限制。然后资源模型将准备好改善操作环境。
寻找平衡
开发新资源模型的目标是:
“......平衡网络拥塞、滥用预防、可用性和成本。”
额外记录
一个似乎以相对较少的努力可提供高回报的领域是 PowerUp 服务。不值得调研的是改进 NET 资源。
下周:1 月 11 日
议程上的主题包括继续讨论 AntelopeIO 资源模型,特别是节点服务。已经确定的关注领域包括记录 history 和 API。
1 月 11 日和1 月 18 日:Nodeos 实例
1 月11 日和 18 日已发布的会议记录不同。后者以最近两次通话的摘要开始。重点是继续讨论资源模型。
其中提到的几个软件进度更新包括:
3.1 和 3.2 补丁更新修复 Ship 不稳定问题
新的 DUNE 版本可能最早在下周准备就绪,以简化软件管理
支持文件正在更新中
会议以开发人员的反馈开场。在稍后的圆桌会议中开始讨论 Mac 开发问题。虽然 Mac 不受官方支持,但开发人员可以自行编译。一些感兴趣的主题包括 合同开发人员工具包(contract developer toolkit, CDT)编译作为 用于节点执行的 Docker 实用程序(Docker Utilities for Node Execution, DUNE)的选项。GitHub actions(和 Ubuntu)也被提到作为编译和规避 CDT 的选项。
在这一点上,一个专门针对开发人员的新圆桌会议获得了支持。
有关资源模型的之前会议
继续讨论 AntelopeIO 资源模型如何影响节点运营商。状态更新:
痛点包括 RAM 可扩展性限制、易用性和服务节点
交易失败账单
更容易和更准确的预防滥用
合并 NET 和 CPU
可能影响蓝皮书状态扩展策略(具有成本效益的存储)
降低 RAM 成本
智能合约访问账户资源信息
节点运营商反馈和未来主题
公开讨论节点运营商的反馈,如何帮助 ENF 提供解决方案。以下是已被确定认为可以简化(或顺滑)操作的主题。
EOS Nation 工具被认为是启动和运行节点有效的起点。Animus 也被共享用于跟踪端点。
用更多本地解决方案(例如 Wharf 工具包、更好的钱包、改进 powerup)取代第三方依赖被认为可以提高区块链的可用性。该解决方案被确定为低付出/高回报。其它有效的解决方案包括:
一个 PowerUp 插件
任何节点运营商轻松共同签署的能力
通过简单地返回名称、其它标识符和回溯来解决合约错误歧义
更复杂的解决方案似乎是对等和保证连接性。WAX 被认为是该领域的高需求者。如果公共节点已满,则可能存在用于私有节点和/或首选节点的选项。公共节点仍将得到维护。
专用于特定目的的节点
可以通过只读标志(来自状态文件)来减轻写入和同步节点的压力。当节点压力降低时,缩放比例会提高。通过为特定目的识别节点,可以包含更多对等节点,同时减少 RAM。
特定目的节点引发了对更精细和交互功能的讨论。例如,nodeos 应该是一个包容性的解决方案还是微服务提供优势?这里提到了 DFUSE 和 GRAPH。
另外请注意,一个只读的设计文档预计很快将会发布。
下周:1 月 25 日
日程安排问题可能会影响下一次会议。
参考资源: