TL;DR: The Graph 的TAP迁移截止日期是2024年12月3日,大约34%的索引器已经升级,占查询量的81.6%。问答讨论的重点是TAP的配置设置,特别是关于RAV(收据聚合凭证)请求和管理非聚合费用,建议从默认值开始并根据查询量进行调整。
大家好,欢迎阅览 Indexer Office Hours 会议纪要,第 184 场!
观看 Persistence Labs 首席运营官 Jeroen Develter 的 GRTiQ 播客。Jeroen 的 web3 之旅始于传统金融、咨询领域,并跃入了加密货币和区块链的世界。
重要存储库的最新更新
- Geth 新版本 v1.4.12 :
- 日期:2024-11-19 13:53:28 UTC
- 该版本删除了已弃用的个人 RPC 命名空间和 –unlock 命令,这表明密钥管理发生了重大变化。它还包括优化、数据库改进和各种错误修复,以及跟踪器配置的重大更改。
- 紧急指标:黄色
- 紧急原因:密钥管理更改需要用户进行调整。
- Reth 新版本 v1.1.2
- 日期:2024-11-19 16:27:10 UTC
- 此版本包括性能改进和错误修复,并为全新硬分叉做好了显著的准备。这些更改专门优化了有效负载作业获取并解决了待处理事务排序,这使得 OP-reth 用户及时更新至关重要。
- 紧急指标:红
- 紧急原因:OP-reth 用户的硬分叉准备。
- sfeth/fireeth:新版本 v2.8.0 :
- 日期:2024-11-14 14:55:01 UTC
- CombinedFilter 中集成了 nil 安全检查,增强了事务处理过程中的稳定性。此外,对 substreams 和 dmetering 的更新包括对计量功能的改进。
- 紧急指标:黄色
- 紧急原因:提高稳定性,并非立即构成威胁。
- Avalanche:新版本 v1.11.13 :
- 日期:2024-11-18 22:24:03 UTC
- 此版本为平台引入了新的 API,并修复了 RPCChainVM 指标初始化和兼容性改进。建议 Operator 更新到最新的插件版本,以增强兼容性和稳定性。
- 紧急指标:黄色
- 紧急原因:重要的修复和新功能需要及时关注。
- 索引器服务和代理(TS):新版本v0.21.8:
- 日期:2024-11-18 19:23:13 UTC
- 此版本包括一些小更新,通过淡化子图高度冲突消息来改进用户界面,并修复了索引代理中的轮询间隔参数。未发现影响系统性能或安全性的关键更改。
- 紧急指标:绿
- 紧急原因:低影响的更改,没有关键问题。
- 索引器服务和点击代理(RS):新版本索引器-tap-agent-v1.7.3:
- 日期:2024-11-13 19:04:13 UTC
- 版本 1.7.3 通过删除托管适配器检查解决了一个错误,这可能会影响交易处理。所有操作员都应查看此更改以确保无缝功能。
- 紧急指标:黄色
- 紧急原因:重要修复,不是关键,但建议尽快更新。
协议重要变更的最新更新
- 在 The Graph 中增强仲裁:工作组启动、仲裁委员会扩展和流程更新
- 新的仲裁工作组将暂时承担仲裁分析师的职责,直到新的分析师入职。
- 仲裁委员会的扩大加强了 The Graph 在仲裁中维护高标准的承诺。
- 仲裁程序正在积极审查中,以确定需要改进的地方。
- 请参阅论坛帖子以获取常见问题解答和参考资料。
- 有关争议 #GDR-19 的信息请求
- 此争议与 GDR-18 有关,因为同一索引器重复了之前导致被罚没的行为。
- 常规:对非本地链使用 hardhat-secure-accounts #1070 (open)
- 常规:Bump Ignition 版本到 0.15.7 #1069 (Open)
- 修复:为部署脚本添加了缺少的参数,并将 SubgraphService 的运行次数减少到 50 次 #1062(Open)
今天的讨论是 TAP 迁移问答,来自 GraphOps 的 Ana 和来自 Semiotic Labs 的 Gustavo。TAP 是用于查询 The Graph 的新小额支付系统。
🚨 索引器需要在2024年12月3日前迁移到TAP。
该会议以 Ana 的 IOH TAP 迁移问答说明为指导,这些说明已与讨论中的一些背景信息一起复制到本节中。评论经过轻微编辑
Ana |GraphOps:让我们从什么是 TAP 开始?
TAP (Timeline Aggregation Protocol) 概述:
- 取代旧的 Scalar 支付系统。
- 具有高效小额支付、减少链上交易和索引器对收据的控制等关键功能。
- 通过允许索引器接受来自多个网关的查询来启用分散式网关。
索引器需要做什么?
- 更新索引器堆栈以运行 indexer-agent(版本 0.21.4 或更高版本),替换 indexer-service 以运行 Rust 版本,并添加新组件 indexer-tap-agent。
- Indexer repo (indexer-agent)
- Indexer-rs 代码库(indexer-service 和 indexer-tap-agent)
- 资源:
- 如果使用 Kubernetes,请使用 launchpad-charts/graph-network-indexer
- 如果使用 Docker Compose,请使用 StakeSquid 堆栈
- TAP 迁移指南
Mickey |The Graph |E&N:如果索引器错过了截止日期怎么办?网关不会将任何新查询路由到它们,直到它们升级或...?
- Gustavo |Semiotic Labs:网关目前提供 Scalar 和 TAP 的收据。一旦我们到达截止日期,网关将仅支持 TAP 收据。如果您的版本低于 1.0,则不会再收到查询。
- Ana:谢谢,这很有意义。因此,如果要继续获取查询,则需要迁移。
Mickey |The Graph |E&N:有什么方法可以判断有多少百分比的索引器已经转移到 indexer-rs/tap 了?
- Ana:判断索引器是否已迁移到 TAP 的一种方法是,他们在 GraphSeer 中的索引器配置文件上是否有标有 TAP READY 的徽章。
- Gustavo:在 Semiotic,我们正在密切跟踪这个数字,检查索引器是否正在运行高于 1.0 的版本。在我们跟踪的 88 个索引器中,有 30 个运行的索引器为 1.0 或更高版本,约占索引器的 34%。
- 我们还在跟踪每个查询在上个月提供的查询数量,因此我们目前有 81.6% 的查询通过 TAP 运行。
- Ana:我认为您所说的是查询量最高的索引器已经升级。
- Gustavo:是的。在排名前 10 的索引器中,有 9 个已升级。实际上,在前 14 个索引器中,有 13 个已经升级。
Mickey |The Graph |E&N:我的印象是,很多索引器在升级时遇到了问题 - 这种印象正确吗,如果是这样,那么 12 月 3 日的最后期限是否现实,以便让每个人都在那之前升级?(没有阴影,只是好奇这是否足够稳定)
- Gustavo:我认为我们正按计划 [迁移] 大多数查询。在 12 月 3 日截止日期之前迁移 100% 的索引器有点困难,但我认为我们可以轻松达到 95%。我们在这里为您提供支持,以便我们可以尝试达到 100%。
Mickey |The Graph |E&N: 为什么是88个[索引器]?这些只是实际服务于查询的吗?
- Gustavo:我们使用服务质量 (QoS) 子图来检查所有活跃的索引器,所以基本上,如果它们在上个月服务了一个查询,那么它们就会出现在 88 个列表中。我们主要关心查询,如果提供查询的索引器使用的是最新版本,我们对此感到满意。
paka |E&N :我也有信心将大部分查询流量带到 TAP。
Mickey |The Graph |E&N:好的,明白了!好的策略。
Mickey |The Graph |E&N:您是否会单独联系那些提供查询但尚未升级的落后者?
- Gustavo:我们正在联系我们接触的索引器。我们有一个列表,我们正在联系每个列表,从最大的开始。目前,尚未升级的两个最大的是升级索引器[Edge & Node]和Pinax。我们正在与Edge和Node紧密合作,以便他们可以支持升级到1.0以上的版本。只要我们与该索引器有联系,我们就会逐个从服务量最大的查询到服务量最少的查询。
Ana:欢迎索引器标记任何已迁移的索引器以寻求帮助。如果您有任何疑问,请随时与我们联系。
Gustavo | Semiotic Labs: 如果有人有任何问题,我将在The Graph Discord中📁︱indexers和📁︱indexers -software频道回答。
- 未聚合的费用和 RAV 请求:
- 问题:索引者可能会看到他们的未聚合费用趋于稳定,尤其是在 rav_request_trigger_value 设置得太低时。
- 解释:rav_request_trigger_value确定索引器何时向发件人请求收据聚合凭证 (RAV)(您可以将发件人视为网关)。如果此值太低,则可能无法足够频繁地满足触发器,从而导致费用累积而未汇总。
- 方案:更新您的rav_request_trigger_value,计算公式为 max_amount_willing_to_lose_grt / trigger_value_divisor。
Ana:有一个仪表板; 我把它放在这儿。在未聚合面板中,您可以看到触发器值。在我的情况下,RAV 触发器值为 3。其工作方式是,当收到新收据时,其值将添加到未聚合费用中,并且系统会不断检查未聚合费用总额是否超过触发值。
当满足触发条件时,通过检查时间戳缓冲区来创建 RAV 请求,以确定将收据视为回执的时间回溯时间,并且它将根据 RAV 请求回执限制限制回执的数量。
如果我们快速查看配置,这里有几件事很重要:
- max_amount_willing_to_lose_GRT
- trigger_value_divisor
这两个决定 trigger 值。
- timestamp_buffer_secs,即考虑收据的时间
- max_receipts_per_request,因此 RAV 最多可以包含 10000 个收据
如果任何收据无效,则它们将单独存储在索引器元数据数据库的 Scaler TAP receipts invalid 表中。当 max_receipt_value_GRT 高于此值时,收据无效。
配置:maximal-config-example-toml
Gustavo:我只想谈谈这里发生了什么,以及为什么我们有很多配置。对于大多数索引器来说,这些配置不会成为问题,因为它们没有大量的查询量。
如果每秒的分配太多或查询太多,则可能会变得有点困难,这就是您需要更新和配置这些内容的原因。通常我建议您先尝试默认值,然后看看。当前默认值为:
- max_amount_willing_to_lose_GRT = 20
- trigger_value_divisor = 10
- 这意味着,每次您尚未汇总的收据总额(也称为未汇总费用)达到 2 GRT 时,我们都会尝试汇总。但是,如果该值始终大于 2,则需要更改这些值。
- 尽量将max_amount_willing_to_lose_GRT保持在较低水平。但是,如果 RAV 请求失败,并且你当时收到了很多收据,因为你是一个大型索引器,那么你会很快阻止发件人。
- timestamp_buffer_secs = 60
- request_timeout_secs = 5
- max_receipts_per_request = 10000
前 15-20 个索引器需要更新这些值。
Pierre | Chain-Insights.io:我的理想价值观是什么?Default 对我仍然有好处?我似乎没有 RAV 请求。
Gustavo:让我检查一下......触发值 Total Unaggregated 费用。所以,首先有一些更新。您使用的是哪个版本?
Pierre:最新版本。
Gustavo:通常,当您到达触发器 RAV 时,它应该尝试创建一个 RAV 请求。如果这没有发生,我们需要进行调查。
Pierre | Chain-Insights.io:对我来说不:
tap:
max_amount_willing_to_lose_grt: 20
tap.rav_request:
trigger_value_divisor: 2
timestamp_buffer_secs: 60
request_timeout_secs: 5
max_receipts_per_request: 10000
Gustavo:所以你的触发值大约是 10,对吗?
Pierre 发帖说:是的,20 / 2
Gustavo:因此,只有在达到 10 GRT 或给定分配的收据达到 10000 个收据时,您才会触发 RAV 请求。由于您的查询量,我建议 0.1 左右,或者:
max_amount_willing_to_lose_grt: 1
trigger_value_divisor: 10
max_receipts_per_request: 1000
Pierre 发帖说:好的,谢谢。
Gustavo:如果每秒没有那么多查询,则需要有更多的 RAV 请求或具有更大的触发值。
这完全取决于您打开的分配数量和每秒接收的查询数量,以及每个分配每秒的查询数量和您拥有的任何突增。
在 TAP 中,在某个时间点聚合后,包含该时间点之前时间戳的收据将不起作用。它们被认为是无效的,所以这就是我们有这个缓冲区的原因。我们只接受 60 秒后的收据。这是因为在不同计算机之间同步 clocks 很困难。网关向您发送收据并定义时间戳,它可以在您的时钟之前或之后 5 秒。
我们将默认值设置为介于两者之间的某个位置,即每秒有 1-2 个查询,每 15 分钟会收到 1 个 RAV 请求。但是,如果您的内存少于此数量,则可能需要更新到更低的max_amount_willing_to_lose_grt。如果超过此数量,则可能需要更新到更多。
Gemma |LunaNova:这些值是按分配还是跨所有分配?
calinah |GraphOps:每个分配
Pierre | Chain-Insights.io:更新到以下版本后:
calinah |GraphOps:很好,您的接收率提高了。
Gustavo:是的,这很好。因此您希望为控制面板做的是,未聚合的费用应始终保持在 0.1,因此每次您有 RAV 请求时,它都会下降一点,然后在 15 分钟后,您有足够的收据来触发另一个 RAV 请求。
Josh Kauffman |StreamingFast.io:有人可以分享他们为这些价值观设定的内容吗?
Marc-André |Ellipfra:作为参考,我使用这些值进行竞选。我不是特别推荐它们,因为它们或多或少是随机设置的。max_willing_to_lose 非常高,以避免过于频繁地拒绝网关,我打算在某个时候降低它:
max_amount_willing_to_lose_grt = "1000.0"
[tap.rav_request]
timestamp_buffer_secs = 30
trigger_value_divisor = 50
request_timeout_secs = 20
max_receipts_per_request = 2000
- 发件人拒绝问题:
- 发件人未在 tap.sender_aggregator_endpoints 中列出。
- 发件人的托管余额不足以支付未付费用。
- 未汇总费用超过max_fee_per_sender限制。
- 问题:索引器可能会遇到发件人被拒绝的情况,从而导致查询处理和收入中断。
- 拒绝原因:发件人被拒绝的三个主要原因:
- 解决方案:每个拒绝原因的具体解决方案:
- 验证 发件人是否在 tap.sender_aggregator_endpoints 部分中配置正确。
- 调查托管资金的潜在问题并确保足够的余额。
- 如果未汇总费用经常达到限制,请查看并可能调整 max_amount_willing_to_lose_grt 设置。
- 注意:索引器 TAP 代理将始终以以下名称开头:
2024-11-13T08:41:31.200776Z ERROR indexer_tap_agent::agent::sender_accounts_manager: There was an error while starting the sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490, denying it. Error: No sender_aggregator_endpoints found for sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490
at tap-agent/src/agent/sender_accounts_manager.rs:311
in ractor::actor::Actor with id: "0.0"
对于未在 tap.sender_aggregator_endpoints 中或通过 env vars 以 INDEXER_TAP__SENDER_AGGREGATOR_ENDPOINTS__<address 格式配置的任何发件人>
- indexer-agent 上的 collect-receipt-endpoint 错误:
{"level":40,"time":1731239677641,"pid":1,"hostname":"graph-network-indexer-agent-0","name":"IndexerAgent","msg":"The option '--collect-receipts-endpoint' is deprecated. Please use the option '--gateway-endpoint' to inform the Gateway base URL."}
Gustavo:您想要拒绝发件人的原因是发件人没有向您付款,因此他们没有足够的托管,或者他们询问您的金额达到了您愿意损失的金额。可能发生的另一件事是,我们为此使用无效收据,因此,如果您拥有的无效收据数量是您愿意丢失的最大数量,您将因此阻止发件人。
max_receipt_value_grt的快速更新是,这仅适用于该服务。要使 TAP 成为最低信任,这些必须是小额支付,因此一旦网关向您发送收据,这是他们将接受的最大收据值,但不会被视为无效收据。
无效收据是指您收到、提供查询,然后发现收据无效的收据。
Ana:对于无效收据,如果任何条件发生变化,它们是否会生效,或者一旦收据被标记为无效,就不再重试了?
Gustavo:没有重试。该表仅用于日志记录,因此您可以访问数据库并查看发生了什么以及收据失败的原因。
Ana:这是有道理的。此外,在 TAP 控制面板上,您可以查看发件人是否已被阻止。
- RAV 请求错误:
- 问题:RAV 请求期间的错误可能会中断聚合过程。
- 错误示例:看起来 RAV 请求没有有效的收据...您可以通过增加 rav_request_trigger_value 来解决此问题。
- 解释:此错误表明 rav_request_trigger_value 不足阻止收据包含在 RAV 请求中。
- 溶液:错误消息中提供了解决方案 – 增加rav_request_trigger_value。
- 软件版本:对 indexer-agent、indexer-service 和 tap-agent 使用所需的软件版本。
- 配置文件演练:
- 共享配置:indexer-service 和 tap-agent 共享一个通用的 TOML 配置文件。
- 区块链地址和终端节点:
- 重要:使用正确的合约地址、网关终端节点和链 ID。
- 日志级别配置:要为适当的日志记录设置 RUST_LOG 环境变量,请使用 RUST_LOG=indexer_tap_agent=debug,info。
- 指标和 Grafana 仪表板:
- 指标终端节点:所有组件都公开了 Prometheus 的端口 7300 上的指标。
- Grafana 仪表板:indexer-rs/docs/dashboard.json
Pierre | Chain-Insights.io:现在,直到 12 月 3 日,只有一个发件人处于活动状态?
# collect-receipts-endpoint: "<https://gateway-arbitrum.network.thegraph.com/collect-receipts>" DEPRECATED
gateway-endpoint: "<https://gateway-arbitrum.network.thegraph.com>"
- Ana:据我所知,这是正确的,所以只有边缘和节点发送器是活跃的,每个人都在使用。GraphOps 希望在 12 月底到 1 月初将一些索引器加入到我们的网关。
Pierre:这好吗,还是我应该恢复以激活 collect-receipt-endpoint ?
- Ana:使用 gateway-endpoint 很好。基本上,您唯一需要知道的是,您可以选择使用哪个 CLI 标志,但无论如何您都会看到相同的错误,这是一个令人困惑的错误,因此您不必在此处执行任何操作。
Ana:一些已经迁移的索引器对他们发现的想要分享的内容有什么评论吗?
- Marc-André |Ellipfra:设置和监控仪表板至关重要。它在每个版本中都变得更加稳定,但你永远不知道。
Gustavo:如果你有任何功能请求或关于如何更好地配置它的想法,请随时在 indexer-rs repo 中提出问题。
我们很乐意查看每个问题和功能请求,以便我们可以使系统更好,技术更稳定,并希望达到更好的水平。感谢您抽出时间详细讨论 TAP。
#区块链数据索引 #web3数据分析 #TheGraph
所有评论