TL;DR: GIP-0081 に関する公開ディスカッションで紹介された重要なポイント: 有料インデックス作成: - この提案の動機は、インデックス付きサブグラフを取得する開発者に優しい方法を設計することです。 - インデックス作成契約では、インデックス付けされるサブグラフと、「完了したインデックス付けされた作業」の単位あたりの価格を指定します。 - この提案には、ゲートウェイを保護するための 2 つの規定が含まれています。1 つは初期同期の最大量 (より高いコスト)、もう 1 つはエポックごとの継続的なインデックス作成の最大量 (より低いコスト) です。 - システムは自動化されます。インデクサーは、各チェーンに保存されているエンティティとブロックされたインデックスに対する最低支払い要件を設定し、インデックス作成プロトコルはこれらのパラメーターに基づいて自動的に承認または拒否します。 - エッジ & ノード チームは、合理的な価格設定を決定するために、運用コストに関するインデクサーからの意見を積極的に求めています。

皆さん、こんにちは。Indexer オフィスアワー会議議事録、セッション 190 へようこそ。

ビデオリンク: https://youtu.be/imm3TFLCYkw

Boson Protocol の創設者 Justin Banon による GRTiQ ポッドキャストをご覧ください。 Boson Protocol は分散型ビジネス インフラストラクチャを構築しており、従来の電子商取引仲介を Web3 の最小限の抽出プロトコルに置き換えることを目的としています。

重要なリポジトリの最新アップデート

プロトコルの重要な変更に関する最新の更新情報

コア開発の更新:

Edge & Node のプロトコル エンジニアである Matias が、GIP-0081: インデックス付き決済について紹介します。

以下の一部はプレゼンテーション スライドからの抜粋であり、Matias から詳細が追加されています。一部のコメントは軽く編集しています。

Matias | Edge & Node: GIP-0081: インデックス支払いが Graph フォーラムに投稿されました。興味があればチェックしてみてください。

GIP-0081 は、ゲートウェイがサブグラフにサービスを提供するためにインデクサーに料金を支払うためのメカニズムとして提案されています。

サブグラフを提供し、この相互作用を調整するメカニズムがあると述べました。では、スプライト開発者の観点から、これを行う現在の方法は何でしょうか?

現在、サブプロット開発者には次のものが必要です。

私が今説明した厳選されたアプローチにはいくつかの欠点がありますが、今日私たちが知っているインデックス市場全体の基礎であることは否定できません。したがって、これはなくなるわけではありません。この提案はいかなる形でもそれを変更するものではありません。 GIP-0081 はこれを次の方法で補完します。これについてはこれから説明します。

ゲートウェイがサブグラフを提供するためにインデクサーに料金を支払うことができるようにメカニズム全体を支えているのが、インデックス作成プロトコルと呼ばれるものです。最も簡略化されたバージョンには次の項目があります。

ゲートウェイを保護するための条項:

これはゲートウェイによって実装されるアルゴリズムであり、どのインデクサーがどのサブグラフを受け取るかを選択するためのプロトコルです。このダイナミックには大きな力があり、ゲートウェイはそれに対して多くの制御を持っており、提案ではそれを仕様の一部として実装していますが、オフチェーンコンポーネントであるため、厳密には GIP の一部ではありません。

IISA では次のことが要求されます。

ゲートウェイは、データ コンシューマとインデクサーの関係の中間に位置し、大量のクエリを集約し、インデクサーの過去のパフォーマンスと現在の全体的なパフォーマンスを独自に把握して、将来のインデックス デバイスを最適に選択できます。

これまで、インデックス支払いメカニズムのオンチェーン部分について説明してきましたが、これは Graph Horizo​​n に関連付けられており、第 1 四半期にはリリースされないため、私たちは、新しい契約やあらゆる種類の新しいオンチェーンインタラクションなど、これらのアイデアの多くをテストできます。

Josh Kauffman | StreamingFast.io: エポックごとに 2 つの量がありますか? 1 つは同期フェーズ用、もう 1 つは定常状態用ですか? (同期とクエリのみではエポックごとに予想されるコストが異なるため)

Josh は説明します: 私の質問は、設定できるエポックごとの最大コストについてです。インデクサーのコストは、同期フェーズでは非常に高くなりますが、同期後の定常状態でははるかに低くなるように思えます。したがって、同期フェーズを処理できるように、エポックごとの最大値をコンシューマーとゲートウェイが設定する必要があることは明らかですが、悪用を避けるために、定常状態フェーズでは最大値を低くするのが理にかなっていると私は考えています。

Matias: インデックス作成プロトコルには 2 つの個別のパラメーターがあり、支払われる最大金額が 2 つあります。1 つは初期同期用です (スライドでは初期インデックスについて言及しました)。しかし、これはサブグラフの初期履歴からすべての作業のチェーン ヘッドまで行われます。 、これがエポックごとの持続最大値よりもはるかに高くなるのは正しいです。これは、はい、最初の同期を行うには、新しいエポックを維持するよりもはるかに多くの作業が必要であるという事実を説明しています。

おそらく今が、この特定のアプローチでいくつかの課題に対処する良い時期かもしれません。たとえば、契約がキャンセルされた場合、別のインデクサーに新しい契約を発行する必要があることを意味します。これは、データ コンシューマーと同様にゲートウェイも、初期インデックスの別のバッチの料金を支払う責任があることを意味します。あなたが指摘したように、各エポックの連続インデックス作成よりもはるかに高価である可能性があります。したがって、私たちは、契約がキャンセルされる理由を最小限に抑えるためにこのバージョンの提案を改善する方法を検討しており、契約がキャンセルされた場合のインデックス作成の初期コストを最小限に抑えるために取り組むいくつかのアイデアも考えています。私たちはこれらの欠点を認識しており、それらに対処できるほど迅速に開発できることを期待しています。

stake-machine.eth: 彼らは現在のインデックス作成報酬に加えてインデクサー チップを獲得していますか?それとも完全な交換ですか?

マティアス: それは間違いなく、完全な代替品ではありません。すでにサブグラフにインデックスを作成している場合、またはすでにサブグラフのキュレーションを行っている場合は、これをインデックス作成の報酬に加えて追加の副収入とみなすことができます。ただし、キュレーションされていない代わりにインデックス作成プロトコルが提供されているサブプロットが表示される状況が発生する可能性があります。その場合、その特定のサブプロットに対するインデックス作成報酬は得られませんが、提供され、収入を受け取ることを受け入れた場合は、インデックス契約より。それは、2 つのソースから収益を集めるようにサブプロットが厳選されているか、それとも 1 つだけから収益が得られるかによって異なります。

Matthew Darwin | Pinax: 何らかのタイムアウトもあると思います。インデクサーがサブグラフのインデックス付けに同意し、その後 6 か月間休んだまま同期が完了しない場合はどうなるでしょうか。

Matias: もちろん、今日の時点では完全な仕様は GIP の一部ですらないので、シンプルにしようとしましたが、アイデアとしては、これらのケースをカバーし、それをゲートウェイとインデクサーの両方に適用できるようにする必要があるということです。そのため、インデクサーには、最初の同期を実行するのに十分な時間を与え、その時点までに行った作業に対する補償を失う危険を冒さないようにする必要があります。ゲートウェイは、開いたプロトコルが実際に配信されているという確信を持っている必要があります。そうでない場合は、他のプロトコルを探す必要があります。 6か月の休暇が起こらないことを願っていますが、ゲートウェイが期待したパフォーマンスを発揮できない場合、契約をキャンセルする可能性があります。

PaulieB: これらの高性能データ ポイントは、完全な透明性を実現するために Graph Explorer に追加されるのでしょうか? GraphSeer 上にありますが、消費者が使用しているかどうかは不明です。

Matias: 私の知る限り、ゲートウェイが意思決定を行うために使用するデータとインデックスのインデクサー選択アルゴリズム (IISA) を可能な限りオープンソースにする可能性を検討してきました。具体的に Graph Explorer に追加されるのか、それとも他の方法やメカニズムで追加されるのかはわかりません。簡単に言うと、そうなると予想しています。これがアルゴリズムによって駆動される場合、少なくともエッジおよびノー​​ド ゲートウェイに対して透過的である必要があります。

NSun | Graphtronauts: 委任者にとっても素晴らしい情報です。 💯 高品質のインデクサーのサポートを支援してください。

Matthew Darwin |Pinax: おそらく、悪用を防ぐために、最初のインデックス作成段階で「完了したジョブ」が定期的に報告される可能性があります。

NSun | Graphtronauts: 委任者にとっても素晴らしい情報です。 💯 高品質のインデクサーのサポートを支援してください。

Matthew Darwin |Pinax: おそらく、悪用を防ぐために、最初のインデックス作成段階で「完了したジョブ」が定期的に報告される可能性があります。

Matias: 最初のインデックス作成に長い時間がかかるため、一部のサブグラフのインデックス作成に数週間かかる状況について話していると思います。現在、GIP はこれらのケースに対して特別な規定を設けていないと思います。ゲートウェイがそれらを処理する必要があります。

Pierre |Chain-Insights.eth: では、すべてのサブグラフのすべてのゲートウェイに対してプロトコルを実行する必要がありますか?これは私にとって意味がありません。サブプロットはいくつありますか? 10,400

契約の中で CU (Computer Unit) を計算し、市場 (需要とプロバイダー (供給)) に応じて調整する必要があります。

Matias: すべてのサブグラフのすべてのゲートウェイについて合意が必要ですか?そうですね、これが自動化されるといいですね。インデクサーは、ストレージ エンティティごと、チェーンごとにブロッキング インデックスごとに支払う必要がある GRT の最低額を設定するため、ゲートウェイがインデックス作成プロトコルを提供すると、そのプロトコルは自動的に受け入れられるか拒否されます。これらの契約が全体として利益をもたらすことを願っています。私たちは、提供されているプロトコルのサブセット内で、損失を被るプロトコルもあれば、より利益を得るプロトコルもあることを承知しており、これらのプロトコルは全体として経済的であるという考えです。インデクサー選択アルゴリズムでは、さまざまなサブアトラスを選択したインデクサーが優先されます。これは、前述したように、計算ユニットがなければ、私たちが考え出すプロキシはすべてのプロトコルで利益を生むほど正確ではないためです。各インデクサーが十分なインデックス作成プロトコルを提供すれば、これが経済的な集約になることを期待しています。

つまり、契約の受諾はインデクサーによって設定されたパラメータに従って自動的に行われ、全体としてインデクサーに提供される契約バッグは十分な利益をもたらす必要があります。

Pierre |Chain-Insights.eth: 以前に試行されたコストモデルですが、プロトコルが価格を動的に調整していたため、誰も使用しなかったと思います。

Matias: 私が説明してきたのは「完了した作業」の代用であり、コスト モデルと考えることができます。市場は間違いなく良くなり、私たちはそれに向けて取り組んでいますが、まだそのレベルには達していないので、これは市場への足がかりになるという考えです。ノードがゲートウェイにあり、プロキシがそれほど正確ではない場合、その機能である価格検出が最適化されないことは明らかです。したがって、できるだけ早くこの状況から抜け出したいのですが、現時点では、MVP のためにそれが私たちにできる最善のことです。サブグラフのインデックスを作成するのに実際にどのくらいの作業が必要か決定論的に理解できるかどうかを確認するためのサブグラフ ガス実験を思いつくことを伴う別のワークフローがあります。その後、最も重要なこととして、市場を構築します。しかし、これは最終的なものであり、この GIP の一部ではありません。

Vince | Nodeify: これらのインデックス作成コストは平均化されますか?自己ホスト型のベアメタルを方程式に含めることなく、上限とベルの曲線は極端になります。つまり、Hetzner 対 AWS または Google Cloud です。同期/インデックス作成のコストがかかりますが、ネットワークごとの要件のコストもかかります。 (イーサリアム 4 TB、Arbitrum One、20+ TB)

マティアス: さて、私たちは肉体に入ります。これはとても興味深いですね。あなたやこの懸念を持つ誰かと喜んで話し合うことができれば幸いです。可能な限り多くのデータに基づいて初期価格を決定いたします。一部の大規模なインデクサーは小規模なインデクサーとは構造が大きく異なることがわかっており、インデックス作成プロトコルがさまざまなインデクサーをサポートできるようにしたいと考えています。これは、規模のメリットがあるインデクサーにとってインデックス契約の方が収益性が高いことを意味する可能性がありますが、これは小規模なインデクサーを排除するものではありません。その多くは、それらを含めることに関するものです。したがって、データが多ければ多いほど、より適切な意思決定を行うことができます。これはバランスを取る必要がありますが、小規模なインデクサーや新興のインデクサーがシステムに参加できるようにしたいと考えています。

Matthew Darwin |Pinax : インデクサーは各ネットワークが占める「スペースの量」を (オフチェーンで) 共有する必要があると思います。その後、ゲートウェイはそれを使用してチェーンごとに異なる価格設定を行うことができますか?

Matias: RPC コストがあり、サブグラフごとの GB に対するストレージ エンティティの数の比率も大きく異なります。可動部分がたくさんあります。もちろん、このデータがあればそれに越したことはありません。また、ベアメタルでの実行は Google Cloud や他のものとは異なるため、ネットワークあたりのスペースの量以外にも、そのスペースにいくら払っているかなどを知ることもできます。これらすべてをご考慮いただければ幸いです。

Matthew Darwin |Pinax: しかし、「ブロック インデックス」もサイズをカバーする可能性があります... ゲートウェイは StartBlock と CurrentBlock を知っているため、価格に含めることができます。

マティアス: どのサイズのことを言っているのかわかりません...正確にはどのサイズですか?

Matthew Darwin |Pinax: しかし、「ブロック インデックス」もサイズをカバーする可能性があります... ゲートウェイは StartBlock と CurrentBlock を知っているため、価格に含めることができます。

マティアス: どのサイズのことを言っているのかわかりません...正確にはどのサイズですか?

Matthew: 私が今言いたかったのは、インデクサー共有ネットワークによって占有されるスペースのサイズまたは量に関する前のコメントから、実際にサブグラフに開始ブロックと現在のブロックがある場合、ゲートウェイが価格を送信するときに、インデックス付きブロックの数は、インデクサーが RPC ノードを実行するために必要なスペースの量を示します。なぜなら、Arbitrum で 3 億ブロックのインデックスを作成するように要求した場合、それはイーサリアムの 1,800 万ブロックとは大きく異なる数字だからです。私はゲートウェイがイーサリアムのサンプルに対してもっとお金を払うことを期待しています。

マティアス: これに対応するために、各チェーンの各ブロックには異なる価格が設定されています。エージェントはこれを考慮しました。繰り返しますが、完璧ではありませんが、うまくいくことを願っています。

Vince | Nodeify: いつか完全なノードの代わりにアーカイブを提供できることを願っています。利用可能なインデクサーの数が大幅に増加し、必要なアーカイブではなく完全な料金を請求できるようになります。これにより、多くの顧客がアーカイブ サポートを必要としないため、顧客の価格も削減されます。

マティアス: タイムトラベルを必要とするサブプロットのことを言っているのだと思います。この提案についてはコメントしませんが、消費者がそれを使用するかどうか、あるいは何人の消費者が実際にタイムトラベル機能を使用しているかを実際に知る方法がないため、改善の余地があると思います。

チャットのコメント:

Matthew Darwin |Pinax: それは十分だと思います。 Vince | Nodeify、追跡および非追跡のサポート。

Slimchance: アーカイブ ノードはタイムトラベルには使用されませんが、イーサリアム呼び出しに使用されます。タイム トラベル クエリがない場合でも、eth_calls のサブグラフを実行するにはアーカイブ ノードが必要です。

Vince | Nodeify: これは非常に少数であり、ほとんどが最新のデータを使用しています。

Slimchance: タイムトラベルは枝刈りに関連しています - これについては同様の質問があるかもしれません。

Matthew Darwin |Pinax: サブグラフのメタデータは、アーカイブ ノードが必要かフル ノードが必要かを事前に通知する必要があります。

Pierre |Chain-Insights.eth: 申し訳ありませんが、現時点ではこの提案に反対です。サブグラフのインデックス作成は利益が得られず、これらのプロトコルを管理する際のインデクサーの時間とリソースが増加します。それは自動化されるべきです。 20億ドルの暗号プロジェクトにとって、これは意味がなく、ナレッジグラフの提案とも矛盾します。

マティアス: フィードバックは歓迎です。具体的に対処できる問題があるかどうかはわかりませんが、喜んでチャットさせていただきます。

Abel | GraphOps: ピエール、チャットまたは音声に追加のコンテキストを追加しますか?

Pierre 氏は次のように説明しました: あなたが最善を尽くして提案をしたことは知っていますが、ソフトウェア アップデートによる多くの変更が見られ、グラフ ノードの新しいバージョンのデバッグさえできていません。現在、The Graph of Knowledgeの提案があります。これは単なるArbitrumやEthereumではなく、Knowledge Graphになります。たくさんの提案がありますが、提案の整合性を図るために誰も話し合っていないような気がします。インデクサーとして、私は経験豊富なインデクサーではなく、新しいインデクサーです。しかし、インデックスを作成したい [サブグラフ] にすでに取り組む必要があることがわかりました。それには何週間もかかりません。いくつかのサブプロットがあるので、必要です。 3 か月分のインデックスを作成します。それには長い時間と多くのリソースが必要であり、現在の収益は持続不可能です。もちろん、大金を投資してくれる校長がいたら、何らかの形で利益が出るかもしれません。 Yaniv でさえ、The Graph プロトコルの設計にはいくつかの欠点があると述べましたが、私たちはいくつかの欠点があるものを何とかするために懸命に取り組んでいます。欠陥を修正すると、作成できるようになります。 […] 調整は私が期待していたものではないと思います。

いくつかの問題を解決して多数のゲートウェイを用意したいと考えていたようですが、それがフルタイムの仕事になってしまいました。持続可能なほど十分な収益が得られますか?このプロトコルと管理をすべて手動で行うと、どれくらいの GRT が得られるのかわかりません。提案の第 1 段階では、自動化にさらに取り組む必要があります。 […]

Matias: あなたの懸念が自動化であることがわかりました。ここで期待されるのは、プロトコルの公開と収集が自動化されることです。そのため、インデクサーは、各チェーンに保存されている各エンティティおよびブロックされたインデックスごとにどのくらいの報酬を受け取ることができるかを理解し、価格を設定するだけで済みます。インデクサー スタックは、これらのパラメーターに一致するすべてのプロトコルを自動的に受け入れます。したがって、正しく行う場合、プロキシが十分に優れている場合、インデクサーの観点からは、これはオプトインで自動になるはずです。うまくいけば、少し間違っていても、全体としてはインデクサーにとって利益が得られるでしょう。これは、物事をゼロから自動化することで、関係者全員の収益性の観点から、より正確かつ公平になるように取り組むことができることを意味します。

ピエール: わかりました、ありがとう。唯一知っておいていただきたいのは、最低額を設定すると、さまざまな理由から、手数料が安くなり、より多くの利益を得られるインデックス会社が常に存在するため、最低額かつ低額の価格競争になるということです。結局、大手インデックス会社は、私はもうこれで終わり、他のところに行くつもりだと言うでしょう。 […]

Matias: 私が MVP の一部として説明しているのは、おそらくオンチェーン反復の最初の反復ですが、価格はゲートウェイによって設定され、インデクサーごとの価格があるということです。したがって、承認または拒否は実際にはインデクサー次第ですが、価格を下げることはできません。ゲートウェイが価格をどのように設定するか、またはゲートウェイが設定できる価格については現在取り組んでおり、それが私がデータと会話を求めた理由です。その考え方は、ゲートウェイが初心者や小規模なインデクサーでも利益を出せるレベルに価格を設定することで、プロトコルのこの部分への幅広い参加を奨励し、可能な限り分散化できるようにするというものです。

Rem |エッジ & ノード: 私たちは自動化に取り組んでおり、すべてのインデクサーが最初の MVP リリースに参加するとは限りません。長期的には、インデクサーがサブグラフを選択するために必要な作業量を、現在よりも削減することを計画しています。

Vince | Nodeify は次のように述べています。どちらかと言えば、中小企業が倒産するまでは余裕があるため、略奪的な価格設定を行っている大企業でしょう。

MoonBoi: 📢 —インデクサーのお知らせ

ビジネスの運営コストをより深く理解するために、インデックス作成者が私たちに連絡したい場合は、ぜひご連絡ください。私たちはこの提案が持続可能であることを保証するために懸命に取り組んでおり、その取り組みの 1 つは、インデックス作成機関が受け取ることができる支払いが、提供する作業のコストを確実に反映するようにすることです。

上のリンクは先週の Discord のお知らせです。

マティアス: 他に懸念がある場合は、後でいつでも私にご連絡いただくか、フォーラムにコメントを残していただければ、誰もが恩恵を受けることができます。インデクサーの皆様から直接 ([email protected]) にご連絡いただき、価格調査にご協力いただければ幸いです。これは幅広い参加を保証するために重要です。

(関連する専門用語、コメント、コード ライブラリ、ハイパーリンクなどについては、ブログを参照してください)

#ブロックチェーンデータインデックス #ThegGraph #web3data