TL;DR:关于 GIP-0081：支付索引的公开讨论中介绍的关键要点：-此提案的动机在于设计一种对开发者友好的方式来获取已索引的子图。-索引协议将规定要索引的子图以及每单位“已完成索引工作”的价格。-该提案包含两项保护网关的条款：初始同步的最大金额（成本较高）以及每个时期持续索引的最大金额（成本较低）。-该系统将实现自动化：索引器为每条链上存储的实体和被阻止的索引设置最低支付要求，索引协议将根据这些参数自动接受或拒绝。-Edge & Node 团队正在积极征求索引器对于运营成本的意见，以帮助确定合理的定价。

大家好，欢迎阅览 Indexer Office Hours 会议纪要，第 190 场！

观看 Boson Protocol 创始人 Justin Banon 的 GRTiQ 播客。Boson Protocol 正在构建去中心化的商业基础设施，旨在用 web3 的最小提取协议取代传统的电子商务中介。

重要存储库的最新更新

协议重要变更的最新更新

核心开发更新：

Matias，Edge & Node的协议工程师，在这里介绍GIP-0081：索引支付。

以下一些内容摘自演示幻灯片，并从 Matias 添加了其他详细信息。一些评论经过了轻微的编辑。

Matias | Edge & Node：GIP-0081：索引支付已在The Graph论坛上发布。如果您有兴趣，请查看它。

GIP-0081 是一种提议的机制，通过该机制，网关可以向索引器支付费用来为子图提供服务。

我提到了提供 subgraph，并且有一种机制可以协调这种交互。那么，从子图开发人员的角度来看，目前执行此操作的方法是什么？

今天，子图开发人员需要：

尽管我刚才描述的 curated 方式有一些缺点，但不可否认，它是我们今天所知道的整个索引市场的基础。所以这不会消失;本提案不会以任何方式或形式对其进行修改。GIP-0081 以以下方式对此进行了补充，我现在将对此进行解释。

支撑整个机制，以便网关可以向索引器付费以提供子图，这就是我们所说的索引协议。它最简化的版本有以下项目：

保护网关的子句：

这是由网关实现的一种算法，用于选择哪些索引器接收哪些子图的协议。这种动态中有很多力量，网关对此有很多控制权，并且该提案将其作为其中的一部分进行了规范实现，尽管由于它是一个链下组件，它并不是严格意义上的 GIP 的一部分。

IISA 需要：

网关位于数据使用者和索引器之间关系的中间，聚合了大量查询量，对索引器过去的性能和当前的总体性能具有独特的视图，网关可以使用这些数据点以最佳方式选择未来的索引器。

到目前为止，我一直在描述索引支付机制的链上部分，因为它与 Graph Horizon 相关联，它不会在第一季度推出，因此我们正在努力开发一种最小可行产品，它不需要部署新合约或任何类型的新链上交互，因此我们可以测试很多这些想法。

Josh Kauffman |StreamingFast.io：每个 epoch 是否会有两个金额：一个用于同步阶段，一个用于稳态？（因为同步和仅查询将具有不同的每 epoch 预期成本）

Josh 解释道：我的问题是关于可以设置的每个 epoch 的最大成本。在我看来，在同步阶段，索引器的成本会非常高，而在同步后的稳定状态下，成本要低得多。所以很明显，每个 epoch 的最大值必须由消费者和网关设置，以便它能够处理同步阶段，但为了避免任何滥用，在我看来，在稳态阶段有一个较低的最大值是有道理的。

Matias：索引协议有两个单独的参数，两个最大应付金额：一个用于初始同步（在幻灯片上，我提到了初始索引），但这是从子图中的初始历史记录到链头所做的所有工作，这是正确的，这将比每个 epoch 的持续最大值高得多。这解释了这样一个事实，是的，进行初始同步所需的工作比跟上每个新 epoch 要多得多。

也许现在是用这种特定方法解决一些挑战的好时机。例如，如果协议被取消，则意味着需要向另一个索引器颁发新的协议，这意味着网关以及数据使用者将负责支付另一批初始索引的费用，正如您所指出的，这可能比每个 epoch 的持续索引要昂贵得多。因此，我们正在寻找改进此版本提案的方法，以最大限度地减少协议被取消的原因，如果协议被取消，甚至有一些想法可以努力将索引的初始成本降至最低。我们意识到了这些缺点，并希望我们能够足够快地发展它以解决这些问题。

stake-machine.eth ：他们是在当前索引奖励之上获得的索引器提示吗？还是完全替换？

Matias：它绝对不是一个完全的替代品，一点也不。如果您已经在索引该子图，或者该子图上已经有管理，您可以将其视为索引奖励之外的额外补充收入。但可能会出现这样一种情况：您开始看到一些没有被策划的子图，而是提供了索引协议，在这种情况下，您将没有该特定子图的索引奖励，但如果您被提供并接受，您将从索引协议中获得收入。这真的取决于子图是否经过策划，以便您从两个来源或仅从一个来源收集收入。

Matthew Darwin | Pinax：我猜也有某种超时？如果索引器同意为子图编制索引，然后休假 6 个月并且从未完成同步，该怎么办。

Matias：当然，我试图保持简单，截至今天，完整的规范甚至不是 GIP 的一部分，但想法是，我们确实涵盖了这些情况，我们必须允许它同时适用于网关和索引器，因此需要允许索引器有足够的时间进行初始同步，并且不会冒着失去任何报酬的风险他们所做的工作那个点。网关需要有一定的确定性，即打开的协议实际上正在被送达;否则，它需要去寻找其他协议。我希望 6 个月的假期不会发生，但如果网关没有看到预期的性能，它可以取消协议。

PaulieB：这些高性能数据点是否会添加到 Graph Explorer 中以实现完全透明？它在 GraphSeer 上，但不确定消费者是否使用它。

Matias：据我所知，我们已经研究了将网关用于做出决策的数据和索引索引器选择算法 （IISA） 尽可能多地开源的可能性。我不确定它是否会特别添加到 Graph Explorer 或其他方式或机制中。简短的回答是，我预计会这样，是的。如果这是由算法驱动的，那么至少对于Edge & Node网关来说应该是透明的。

NSun |Graphtronauts：对于委托人来说也是很好的信息。💯 帮助他们支持质量索引器。

Matthew Darwin |Pinax：据推测，在初始索引阶段可以定期报告“已完成的工作”以防止滥用。

Matias：我想你说的是初始索引需要很长时间的情况，所以有些子图需要几周才能被索引。我认为 GIP 目前没有对这些情况做出任何特别规定，网关需要处理它们。

Pierre |Chain-Insights.eth：那么我们必须为每个子图的每个网关做协议吗？这对我来说毫无意义。我们有多少个子图???  10,400

我们应该在协议中计算 CU（计算机单元）并根据市场进行调整（需求与提供者（供应））。

Matias：我们是否必须为每个子图的每个网关达成协议？是的，因此希望这是自动化的。索引器设置了他们需要为每个存储实体和每个链的每个阻塞索引支付的最低 GRT 金额，因此当网关提供索引协议时，它会自动被接受或拒绝。希望这些协议总体上是有利可图的。我们知道，在提供给您的协议子集中的某些特定协议中，有些可能会亏损，有些可能会赚更多的钱，而这个想法是，总的来说，这些协议是经济的。索引器选择算法会优先考虑已选取各种子图集的索引器，因为如果我们没有计算单元，正如您提到的，我们提出的任何代理都将不够准确，无法使每个协议都有利可图。我们希望，如果每个索引器提供足够的索引协议，这将成为一个经济的聚合。

简而言之，协议的接受应该根据索引器设置的参数自动进行，然后，总的来说，提供给索引器的协议袋应该足够有利可图。

Pierre |Chain-Insights.eth：之前尝试过的成本模型，我认为没有人使用，因为该协议正在动态调整价格。

Matias：我一直在描述的是 “work done” 的代理，你可以把它看作是一个成本模型。市场肯定更好，我们正在努力实现这个目标，但我们还没有达到那个水平，所以这个想法是这是通往市场的垫脚石，因为正如你提到的，如果我们把代理的设置集中在边缘和节点网关中，而代理并不是超级准确，那么显然价格发现， 这是它的函数，不会是最优的。所以我们宁愿尽快摆脱这种情况，但现在，这是我们能为 MVP 做的最好的事情。还有另一个工作流需要提出一个子图Gas实验，看看我们是否能够确定性地了解索引子图实际需要多少工作，然后，最重要的是，建立一个市场。但这只是最终的，不是这个 GIP 的一部分。

Vince |Nodeify：我们是否平均了这些索引成本？上限和钟形曲线将是极端的，即Hetzner与AWS或Google Cloud的对比，而不会将自托管的裸机放入等式中。有同步/索引成本，但每个网络也有要求成本。（以太坊 4 TB，Arbitrum One，20 + TB）

Matias：现在我们进入肉体。这很有趣。我们很乐意与您或任何有此担忧的人进行对话。我们很乐意根据尽可能多的数据做出初步定价决策。我们知道，有些大型索引器的结构与小型索引器截然不同，我们希望确保索引协议可以支持各种索引器。这可能意味着指数协议对于具有规模经济的指数机构来说将更有利可图，但这并不是要把小型指数机构排除在外。这在很大程度上是关于包括他们。因此，我们拥有的数据越多，我们就越能更好地做出决策。这是一种平衡行为，但我们绝对希望确保较小的索引器和新的新兴索引者能够参与系统。

Matthew Darwin |Pinax：我认为索引器应该共享（链下）每个网络占用的“空间量”，然后网关可以用它来定价，每条链都不同？

Matias：有 RPC 成本，每个子图的存储实体数量与 GB 的比率也非常不同。有很多移动的部分。当然，如果能得到这些数据就太好了。了解每个网络的空间量之外，例如您为该空间支付了多少费用，因为在裸机上运行与 Google Cloud 或其他任何内容不同，因此也很棒。我们很乐意考虑到所有这些。

Matthew Darwin |Pinax：但是“区块索引”也可能覆盖大小......网关知道 StartBlock 与 CurrentBlock，因此可以将其包含在价格中。

Matias：我不确定你指的是大小......具体是哪种尺寸？

Matthew ：我刚才的意思是，从我之前关于索引器共享网络占用的大小或空间量的评论中，真的如果一个子图有一个起始区块和当前区块，当网关发送价格时，需要索引的区块数量是一种指标，表明索引器需要多少空间来运行 RPC 节点。因为你知道，如果你要求在 Arbitrum 中索引 3 亿个区块，这与以太坊中的 1800 万个区块是一个非常不同的数字。我预计网关会为以太坊示例支付更多费用。

Matias：为了适应这一点，每条链的每个区块都有不同的价格。代理已经考虑到了这一点。同样，它不会完美，但我们希望它能发挥作用。

Vince |Nodeify：我希望有一天我们可以提供存档而不是全节点。可用的索引器数量将大大增加，然后我们可以对 full 而不是 archive needed 收费，这也将降低客户的价格，因为许多客户不需要存档支持。

Matias：我猜你指的是需要时间旅行的子图。对于这个提案，我没有评论，但我认为那里还有改进的余地，因为真的没有办法判断消费者是否会使用，或者有多少消费者实际上在使用时间旅行功能。

聊天评论：

Matthew Darwin |Pinax：我认为它已经足够好了。Vince |Nodeify、跟踪与非跟踪支持。

Slimchance：存档节点不用于时间旅行，而是用于 Ethereum 调用。执行eth_calls的子图需要一个存档节点，即使没有进行时间旅行查询也是如此。

Vince |Nodeify：这是一个非常小的数量，大多数使用最新的数据。

Slimchance：时间旅行与修剪有关——对此可能会提出类似的问题。

Matthew Darwin |Pinax：子图的元数据应该提前告诉您是否需要存档节点还是完整节点。

Pierre |Chain-Insights.eth：抱歉，我目前反对这个提议。为子图编制索引是无利可图的，这会增加索引器管理这些协议的时间和资源。它应该是自动化的。对于一个市值 20 亿的加密项目来说，这毫无意义，而且它与知识图谱提案不一致。

Matias：欢迎反馈。我不确定是否有我可以特别解决的问题，但我很乐意和我聊聊。

Abel |GraphOps：Pierre，您想在聊天或语音中添加一些额外的上下文吗？

Pierre 解释道：我知道你尽了最大的努力来提出建议，但我看到软件更新有很多变化，我们甚至没有调试 Graph Node 的新版本。现在，有一个关于 The Graph 知识的提案，它不仅是 Arbitrum 或以太坊;它将是一个知识图谱。有很多提案，但我有一种感觉，没有人会互相交谈以使他们的提案彼此保持一致。作为一名索引员，我是一名新的索引员，而不是一个有经验的索引员，但我看到我们已经必须研究我们要索引的 [子图]，而且不需要几周——我有一些子图，我要索引三个月。这需要很长时间和大量资源，而且现在的回报是不可持续的。当然，如果我有一些委托人愿意投入大量资金，那么它可能会以某种方式盈利。甚至 Yaniv 也说 The Graph 协议的设计有一些不足，但我们正在努力在有一些不足的东西上做一些事情。修复不足，然后你就可以制作了。[…]我认为这种对齐方式并不像我预期的那样。

我看到你想解决一些问题，并且有很多网关，但后来它变成了一份全职工作。它是否有足够的回报来实现可持续发展？我看不出来，因为手动执行所有这些协议和管理，我们将收到多少 GRT？该提案的第一阶段应该在自动化方面投入更多工作。[…]

Matias：我现在明白了，您关心的是自动化。这里的期望是协议的发布和收集是自动化的，因此索引器只需要了解并设定他们愿意在每个链中存储的每个实体和每个被阻止的索引获得多少奖励的价格。然后，索引器堆栈将自动接受与这些参数匹配的每个协议。因此，如果我们做对了，如果代理足够好，那么从索引器的角度来看，这应该是选择加入和自动的。希望如果我们稍微出错，总的来说，它会对索引器有利可图。这意味着从零开始就自动进行，我们可以努力使其在盈利能力方面对所有相关人员更加精确和公平。

Pierre：好的，谢谢。我唯一想让你知道的是，如果你设置一个最低限度，总会有一个指数公司收取更少的费用，而且由于多种原因，它会赢得更多，所以这将是一场最低限度和低价格的竞赛，最后，大型指数公司会说我已经完成了这个， 我要去别的地方。[…]

Matias：我所描述的作为 MVP 的一部分，可能是链上迭代的第一次迭代，价格由网关设定，并且每个索引器都是一个价格。所以接受或拒绝真的取决于索引器，但他们不能降低价格。网关如何设定价格或网关可以设定哪个价格是我们正在努力的方向，这就是我要求提供数据和对话的原因。这个想法是，网关将价格设定到即使是新手和小型索引者也能盈利的水平，这样我们就可以鼓励广泛参与协议的这一部分，并确保这可以尽可能去中心化。

Rem |Edge & Node ：我们将努力实现自动化，可能并非所有索引器都参与第一个 MVP 版本。从长远来看，我们的计划是相对于我们现在所拥有的，减少索引器选择子图所需的工作量。

Vince |Nodeify 说：如果有的话，那将是大公司以掠夺性定价让小公司倒闭，因为他们负担得起，直到他们消失。

MoonBoi： 📢 —indexers-announcements

如果任何索引者想与我们联系，以便我们更深入地了解他们的业务运营成本，那么我们很高兴收到您的意见。我们正在努力确保这个提案是可持续的，其中一项工作是确保索引机构可以收到的付款反映他们提供的工作成本。

上面链接是我们上周的 Discord 公告。

Matias：如果您有其他疑虑，可以稍后随时与我联系或在论坛中发表评论，以便每个人都能从中受益。如果索引员直接 （[email protected]） 与我们联系以帮助我们进行定价研究，我将不胜感激，这对于确保广泛参与度至关重要。

（相关专业名词、注释、代码库、超链接等请关注博客查找）

#区块链数据索引 #ThegGraph #web3数据