TL;DR: 索引器们讨论了迁移到新的支付系统（TAP）的问题，表示需要等待下一次索引器代理发布后再进行迁移，并解释了为什么不是所有人都应该同时迁移。他们还讨论了索引器文档的状态，以及需要有一个地方可以获取与发布版本相匹配的最新信息。IOH欢迎了两位新成员，并听取了他们到目前为止在索引方面的经验。
大家好，欢迎阅览 Indexer Office Hours 会议纪要，第 177 场！
视频链接：https://youtu.be/FK5CpdlYSFM
观看 Cubist 联合创始人兼首席执行官 Riad Wahby 的 GRTiQ 播客，Cubist 是一家致力于为 web3 开发人员和企业增强安全性和简化密钥管理的公司。
重要存储库的最新更新
- Erigon：新版本 v3.0.0-alpha4
- Ana |GraphOps：此版本只能在测试网上进行测试，我不确定是否有人测试过它。
聊天中的讨论
Johnathan |Pinax：我们正在测试 BSC Erigon3 和 Chapel Erigon 3，以太坊将是下一个。适用于 BSC 的 Erigon3 现已准备就绪，v1.2.* 版本在 Bohr 硬分叉后将不再支持。
Vince |Nodeify：确保你回放那些 subs，如果你错过了上周的很多分叉，或者你的 POI 可能在外太空。
Vincent |Data Nexus：等等，Erigon2 将不支持下一个 HF [硬分叉]吗？我们刚刚完成了从头开始同步 Erigon2 的执行步骤。😭
- Geth新版本：
- 1.14.11 版：
- 一个次要版本，旨在解决 CI 管道中的问题，以发布新的稳定和最新的 Docker 映像，并更改了整合 amd64 和 arm64 标记的 Docker 映像构建过程。
- 它还包括更新，例如从 RPC 中删除 totalDifficulty 字段、修复模拟后端以及新的多平台 Docker 映像构建方法。
- 1.14.10 版：
- 修复了 v1.14.9 中引入的 blob 池回归问题的修补程序版本，提醒用户及时更新，但除了 blob 事务传播问题之外，没有其他的风险。
- 它还包括引擎 API 中的无状态生成等更新，以及对模拟调用中 gas cap 行为的更改。
有关不同客户端的信息
- Nimbus：新版本 v24.9.0 ：
- 一个低紧急性版本，侧重于信标 API 改进和稳定性修复，例如解析 DNS 主机名和防止在 UPnP 初始化期间崩溃。
- 建议用户在正常的两周周期内进行更新。
Launchpad 图表：
- 发布了新的图表版本，其中包含增强功能和错误修复：
- Erigon
- Celo
- Arbitrum-Nitro
- Graph-toolbox
- Firehose-Ethereum
Launchpad 命名空间：
- ETH、Gnosis、Celo、Monitoring、Arbitrum 的新稳定版本
问题：
- Launchpad 图表问题：查看或报告问题
- Launchpad 命名空间问题：查看或报告问题
协议重要变更的最新更新
仲裁
- 有关争议 #GDR-17 的信息请求
新的链集成请求
- Ferrum Network Chain 集成
- 请求 Graph 节点支持 – Rupaya Mainnet
- 编排 Graph 的未来
- 修复：更新函数可见性 （OZ N-16） #1051 （合并）
- 修复：为各种合约添加安全联系人 NatSpecs （OZ N-03） #1028 （合并）
- 修复：删除多余的 getter 函数。（OZ N-15） #1050 （已关闭）
- 修复：在 AuthorizedCollector 和 TokensRescueed 中发出新事件（OZ N-14） #1049 （合并）
- 修复：删除 __ProvisionManager_init_unchained 函数中对幻数的使用 （OZ N-11） #1041 （合并）
- 修复：标准化整个代码库的命名约定 （OZ N-13） #1047 （合并）
- 修复：对 Thawing Pool Management 的调整 #1048 （Open）
一些评论经过了轻微的编辑。
Abel 提到 Fuse Network 无法按计划进行本周的 IOH，因此来自 Pinax 的 Matthew 建议了一些讨论主题，包括下面关于 Kubernetes 的一些主题。
Matthew 介绍了一些 Kubernetes 主题供讨论。如果你是索引器并且需要部署 Kubernetes 的支持，请在 IOH 上告诉我们你需要什么帮助。
Matthew：收集 Kubernetes 输入的主要收获如下：
- 基础设施代码：在 Kubernetes 中提高效率的许多方法是将所有更改提交到 Git 中，而不是在命令行上编写。对于某些人来说，这可能是一种不同的运作方式。
- 来自 Nodeify 的 Vince 问人们正在考虑或想要谈论什么样的 Kubernetes 发行版，因为有一堆不同的选择。
- 人们对应该如何做事有不同的看法，理解为什么人们以某种方式做事成为一个有趣的讨论，这样作为基础设施运营商，我们可以相互学习。
- 有些位于大型云提供商或自己部署基础设施。
- 不同大小的索引器意味着不同的要求和设置。
- Kubernetes 工具
- 监测
- Workflows
- 用户管理
- 安全
- 日志管理、统计、警报
- 当您开始部署集群时，需要考虑这些事情很重要。
Matthew 还提到转向 TAP 是一个可能的话题，索引者选择首先讨论 TAP。
TAP 是用于查询 The Graph 的新小额支付系统。它是高吞吐量、高效和信任最小化的，并通过减少对网关的信任需求来进一步去中心化 The Graph Network。
- TAP 迁移指南
最初，新的索引器服务中缺少查询指标，但现在已添加这些指标。
Nick |The Graph Foundation：我很好奇索引器在转向 TAP 方面是怎么想的？
- Vincent |Data Nexus：仅供参考，指标可用于最新的主提交。应该很快就会发布。
- Jim |Wavefive：随着指标的进展和对 escrow 的改进，我们将进行交换。
- Vince |Nodeify： If metrics， me gusta.
- Vincent |Data Nexus：您需要更新查询指标控制面板。我在这里有一个可用的仪表板 JSON：📁—indexer-software。不过，错误跟踪指标仍有待推出。如果您想查看错误代码的分布情况，请确保对这个 GitHub 问题做出反应以获得更高的优先级：错误指标信息 #332。
Matthew问：人们在等什么迁移到 TAP？
- Vince |Nodeify：我的指标。
- stake-machine.eth ：文档？
Matthew 提示：我们需要什么样的文档？我们需要更多时间吗？有人需要帮助、建议、更多的基础设施，还是更少的基础设施？
- Jim |Wavefive：具体来说，指标奇偶校验 w/ts 代理。
- stake-machine.eth ：ENV [环境] 等的示例。
Matthew：我之所以这么调侃，是因为核心开发团队希望停止维护旧的 TypeScript 代码，所以我们越早让人们转向 TAP 越好。
Ana |GraphOps：在 IOH #175 的 Semiotic 演讲中，团队提到，当索引器代理在下一个版本（即 0.21.5）上时，我们应该转向 TAP，而 0.21.5 版本尚未发布。
Vincent |Data Nexus：我今天早上刚刚完成了对 main 分支的测试，并对 Semiotic 竖起了大拇指，所以我们应该很快就会发布。只是赶不上今天的 IOH。
Gemma |LunaNova：我们通常会先等 Payne 在 prod 中测试一段时间......
Jim：我相信 Semiotic，创建这个基于 Rust 的新索引器服务的团队，不是创建以前的 TypeScript 服务的团队。因此，请务必确保我们不会错过新服务的某些内容，因为在了解索引器用户体验方面，指标是一个相当大的缺失。我想这真的是一个产品经理类型的问题，我不确定这里是否有人可以回答这个问题。
Ana：今天也会尝试测试最新的。他们 [Semiotic] 对任何反馈都非常敏感。
Jim：是的，Semiotic 团队对反馈的响应非常积极。我只是想确保我们尽量避免任何陷阱，因为我们从一个团队开始做这个，另一个团队开始做这个。如果这就是这里发生的事情。
Ana：我曾向 Abel 建议，我们这些运行 TAP 的人可以举办一次会议，分享我们学到的东西，一些问题，也许作为其中的一部分，我们还可以了解谁在运行它，谁在维护代码，以及我们将获得什么样的支持。也许这会有所帮助，并且 InfraDAO 希望参与其中。
Slimchance ：我不想代表他们发言，但我可以说，统一的发布流程一直是讨论的一部分。
Slimchance 解释：因此，我们确保其发布方式与生态系统中的其他组件相同。它们被添加到网络的 MD 文件中，并有一个适当的版本，而不仅仅是一个提交，并遵循现有组件的示例。
Slimchance ：InfraDAO 在过去四个月里一直在努力进行测试（由 Vince |Nodeify 和 Vincent |Data Nexus）——他们做得令人难以置信。🔥
Jim：如果能听到Edge & Node关于他们作为网关运营商使用新托管内容的经验，以及他们因此正在学习和改变什么，那将是一件好事。
Vince |Nodeify：我们如何使文档与版本保持一致？而不是发说明或 Discord 讨论。
Vince 解释：长期以来索引器的经验是，对于新版本或新软件，文档在那里，但不同的部分位于不同的地方。索引器社区将真正受益于一个可以访问索引器的所有内容，无论是 The Graph 文档还是在代码库中。我们有所有这些不同的组件，随着它们开始针对不同的服务增长，很难扩展点击七个代码库以了解如何运行七个不同内容的做法。
有时文档跟不上发布。当某些内容发布时，我们只能搜索它，很多时候你不得不询问其他索引器或搜索 Discord 。
让它成为索引器知道该去哪里的地方，这就是我们处理所有内容的地方 - 所有环境变量、如何运行它等。而不是 The Graph 文档、The Graph indexer repo、The Graph Node repo、this repo 和 that repo。
文档需要遵循发布计划，以后不要更新。如果您错过了一周的 IOH，但不会疑问为什么事情没有进行。
Mack：应该赏金，谁做得好，谁就让他们靠近。
Gemma |LunaNova：文档总是过时的。
Mack：老实说，它应该是代码发布过程的一部分。
Gemma |LunaNova：我同意“如何设置索引器”文档不能在每次有微小变化时都更新......但是开发人员应该保持最新状态，例如在 config 中添加新行的位置，恕我直言。
Mack 回答：是的，但指南中可以附加一个变更集列表。
Slimchance：关于目前谁在管理 TAP，Alexis 不再与 Semiotic Labs 合作，但 Anirudh 是那里的现任工程主管，Carlos 和 Gustavo 是管理 TAP 的人。他们都是伟大的工程师;没有问题。我认为我们推迟的原因之一是我们不希望每个人都同时切换。
在文档方面，自我们成立以来，索引文档一直是一个挑战，InfraDAO 已准备好提供赏金支持。我认为自测试网以来一直在运行索引器的经验丰富的工程师对管理和成为文档的负责人并不那么感兴趣。这是一个挑战。
Mack：我真的认为，负责 PR 和构建新版本的团队、开发人员应该成为这个过程的一部分。它应该是更新文档的项目之一。我知道这需要多做一些工作，但他们掌握了有关变化的所有信息。所以你减少了反馈循环，减少了跑来跑去问问题。
Ana：我对文档有不同的看法。我认为应该有最低数量的文档，但有时对它们进行改进，然后由没有直接参与过产品工作的人编写，可以通过识别用户可能不正确理解产品工作原理的差距来帮助产品团队和用户。
Mack：我同意这一点，但我确实认为如果外部有人来与实际编写代码的人合作，应该有一个流程，因为那样它会非常顺利，这是关于过程的。您不想成为编写文档的人，并且不得不追逐获得有关您需要的问题的答案，因此它只会花费更长的时间。但我确实同意你的观点，尝试获得一种中间立场的经验和方法是有价值的。
Jim：我认为这需要一种非常特殊的技能。Ana，我认为你说得完全正确，一个外部的人，一个不是索引员，但对 The Graph 有一点了解，并且是一个出色的沟通者，通常是那种可以很好地完成这类工作的人。
有人过去常常对内容进行注释，他们会 ping 参与对话的每个人，总结他们的想法，然后在论坛上展示。如果我们能找到一个可以通过资助或其他方式激励他们利用这些正确技能来做这件事的人，如果是通过 InfraDAO，那将是一个很好的途径。
Slimchance：是的，一点没错。我们还可以授权他们编写自己的资助。他们可以写下需要的东西;如果需要编写其他文档，他们可以联系知道如何编写的索引器，并使用 Grants 进行设置。如果您认为社区中有人适合这个角色，我很乐意与他们联系并授权他们改进我们的文档。
与此同时，在聊天中...
stake-machine.eth 中：Subgraph Radio 怎么样？我最近没有听说过它。
Vincent |Data Nexus：我只是有理由在一段时间内第一次检查它，而且 Grafana 的 GraphQL 数据源似乎存在问题，使我无法从仪表板中找到所需的数据。目前正在尝试解决这个问题。😅
pili |GraphOps：我们会看看！感谢您标记此内容。
上周的一位新索引员和本周的另一位新人一起回到了 IOH。
Abel 邀请 John 分享一下索引对他来说的进展。
John K.：我在几周前才设置了我的索引器，所以我确实浏览了整个文档。试图弄清楚索引器和索引器-rs（新的 Rust 版本）之间的区别，并试图弄清楚 TAP 系统是什么，这有点令人困惑。所以，是的我肯定会说文档确实需要一点工作，但我认为现在一切都很顺利。
Jim：John 先生，您正在运行什么样的基础设施？您的索引器是否有特定的目标？
John：这是一个非常简单的设置，我在裸机上，Kubernetes 上，我正在运行 Talos。
Matthew：您是否使用 Launchpad 开始？
John：我关注了 The Graph Academy 网站，我发现它真的很好，然后我认为它是 GraphOps Kubernetes 清单。
Matthew：好吧，你做到了。在 Artifact Hub 上找到这些 Helm 图表会有所帮助吗？
John：我没有使用 Helm 图表，我只是编写了自己的图表。
Vince：每个人都能看到 Kubernetes 的发展方向，拥有如此多的服务并能够扩展。随着人们转向裸机提供商并希望继续使用裸机，其中一些提供商在裸机方面对他们的网络不太友好，您自己不托管裸机，这使得云提供商更具吸引力，但也非常昂贵。我想知道您是托管自己的裸机，还是在使用在网络方面对您的 Kubernetes 集群友好的提供商？您是否使用 MetalLB 来公开您的服务？
John：我在某个位置有物理盒子，然后（我不知道这是否是一个好的设置，但它对我有用），我使用 Cloudflare 作为外部入口。
Vince：是的，这是有道理的。有些人尤其是我，喜欢使用 MetalLB 来公开服务，我尝试了一些托管裸机提供商，但他们对私有网络对这种事情并不那么友好，不知何故，它们不如公共 IP 可靠。
John：我的 CNI [容器网络接口] 是 Cilium，我正在使用 BGP 本地路由器，然后我猜它会进入 Cloudflare。
Vince：您是否因为没有找到任何内容或不了解 Launchpad 和它现在拥有的 Helm 图表而编写了自己的 Helm 图表或原始清单？您觉得在 Artifact Hub 上提供这些类型的东西会有帮助吗？
John：我很久以前就开始尝试这个了，所以我已经写了一些清单，所以我只是从示例中更新了它们，并试图弄清楚所有部分是如何组合在一起的。但如果有像预制的一样，那肯定很棒。
Mack 发布了一个资源：设置一个完整的 Erigon 以太坊节点（可能有点过时了）
Abel 邀请了新加入电话会议的 Jordan 分享他在索引方面的经验。
Jordan：我很高兴来到这里，我的背景是来自 web3 领域的开发人员。我非常愿意学习更多关于索引的知识。
Vince发帖：我将与 GraphOps 合作开发 Launchpad 图表、更新等。
calinah |GraphOps：更多有关导航 Launchpad 堆栈的文档，以防万一：Launchpad 快速入门。
pili |GraphOps：如果有人对 Launchpad 有疑问或需要任何内容，请大声联系我或@calinah |GraphOps [在 Discord 频道]。
Vince 发帖：InfraDAO 文档，另一个很棒的资源。
[视频录音中随之而来的是精神错乱的笑声......🤣]
（相关专业名词、注释、代码库、超链接等请关注博客或者公众号查找）
All Comments