イベントドリブンの開発： 最適化されたDappsとSubgraphを解き明かす
The Graph
The Graph Builders Blogの創刊号へようこそ！The Graph Builders Blogは、ビルダーが集まり、互いに学び合い、その知識をコミュニティと共有するためのものとして始まりました。
今回の投稿は、RubiconのDenver Baumgartner氏によるものです。RubiconのGitHubレポにあるこちらの投稿でサブグラフの例をご確認ください。
この投稿では、The Graphを使用する際にスマートコントラクトとサブグラフの開発を強化できるイベント駆動開発（EDD）の概念を紹介します。
イベントとサブグラフのイベントハンドリングの理解
Solidityでは、イベントは、スマートコントラクト内で特定のアクションが発生したときに、Ethereumブロックチェーンとそのユーザーにログと通知を行うためのメカニズムです。スマート コントラクトがイベントを発行すると、ブロックチェーンに保存されるメッセージが作成されます。
外部アプリケーションはこのログにアクセスしてクエリすることができ、イベントは状態の変化を伝え、それに応じて行動を起こすための便利な方法となります。最も広く使われているWeb3ライブラリの1つであるEthers.jsでは、この目的のためにイベントフィルター（インデックスされたパラメータのみ）を作成することが可能です。こちらでご覧になれます。サブグラフでは、サブグラフマッピングでこれらのイベントを処理するために「eventHandlers」を使用します。
イベントは、イベントキーワードの後に、イベント名とその引数をカッコで囲んで定義します。以下に、イベント定義とそれを呼び出す関数の例を示します：
この例では、サブグラフに関連するパラメータを持つRecordOfferイベントを定義しています：
- id: オファーのユニークなID
- pair: オファーのペア（例：ETH-USDC)
- maker: オファーを行ったアドレス
- pay_gem: オファーが売却する（または支払う）アセット
- buy_gem: オファーが購入するアセット
- pay_amt: 支払われる（または売却される）金額
- buy_amt: 買われる金額
- pay_amt/buy_amtの比率により、オファーの価格が決定
オファー機能を使うと、ユーザーは売りたい資産、見返りに受け取りたい資産、それぞれの資産の金額（これがオファーの「価格」を決定）を記載したオファーを作成することができます。オファー関数が正常に呼び出されると、オファー自体の関連情報を含むRecordOfferイベントがブロードキャストされます。これによって、チェーンステートを呼び出すことなく、そのオファーからの関連情報をインデックス化することができ、インデックス化の効率が向上し、リソースコストが削減されます。
The Graphには、インデックスを作成しながらイベントを処理するために必要なコードの生成を自動化するための素晴らしいツール群「codegen」が存在します。サブグラフの開発に関しては、The Graphのドキュメントに豊富なリソースが用意されていますので、サブグラフの開発をより実践的に行いたい方はチェックしてみてください。
この記事では、codegenがコントラクトのアプリケーション・バイナリ・インターフェース (ABI)を取得し、以下のようなマッピングでアクセスできるイベント用のクラスを作成することを知っておく必要があります：
さて、基本を理解した上で、イベントドリブン開発について紹介していきます。
イベントドリブン開発(EDD)とは？
イベントドリブン開発（EDD）とは、分散型アプリケーション（dapps）向けのデータ豊富なスマートコントラクトの作成を中心とした開発戦略です。EDDは、エンドアプリケーションやユースケースを念頭にスマートコントラクトのイベント基盤を構築し、ユーザーに現在および過去のデータを効果的に提供するのに役立ちます。
EDDの重要な原則の1つは、スマートコントラクトが豊富で関連性の高いイベントを発することを保証することです。このアプローチは、Dappの堅牢な基盤を構築するために不可欠であり、サブグラフのインデックス作成とクエリ処理を最適化するのに役立ちます。この最適化によって、フロントエンドの操作性と全体的なユーザーエクスペリエンスが大幅に向上し、ダンプのスケーラビリティとユーザビリティに貢献します。
イベントリッチなスマートコントラクトを重視することで、Dappやサブグラフの構築やスケーリングに資するデータリッチな環境を構築することができます。このシンプルなコンセプトが、あなたのDappのさらなる発展にどのような影響を及ぼすのか、見ていきましょう。
EDDの利点
- Dappランニングの改善： フロントエンドを書く前に、特定のイベント、それが含むデータ、そしてそれらが発せられるタイミングについて批判的に考えることで、リファクタリングによる時間の浪費を防ぎ、より自信を持ってユーザー体験を計画することができます。
- スケーラビリティとレスポンシビリティ： EDDはサブグラフの最適化に有利です。サブグラフは、callHandlersやblockHandlersとは対照的に、eventHandlersでより迅速にイベントをインデックスするからです。Dappがスケールする必要がある場合、重要な瞬間ごとに、関連するすべてのメタデータが添付されたリッチなイベントを発行するようにスマートコントラクトを記述すると、データ需要に合わせてサブグラフをスケールさせることが可能になります。
- 保守性： EDDのモジュール構造は、コードのメンテナンスとデバッグを簡素化します。コードベースをイベントに沿って整理することで、開発者は問題をより簡単に特定し解決することができ、トラブルシューティングに必要な時間と労力を削減することができます。
- コラボレーションの強化： スマートコントラクトのデータをインデックスする複数のサブグラフがあり、それぞれのサブグラフが独自のマッピングとスキーマを持っているとします。このような状況は、開発の初期段階で戦略を検討しない限り、すぐに圧倒されることになります。EDDを開発プロセスに組み込むことで、スマートコントラクトチームとサブグラフチームの間で、イベントを議論し最適化するための重要な焦点となります。
EDDのもう一つの大きな利点はコストです。
実際に私たちのチームは、アプリケーションのRPC使用量を大幅に削減することで、プロダクショングレードのアプリケーションをサポートするためのコストを大幅に削減することができました。たとえば、プールの現在の残高を取得するために 1000人のユーザーが1回のRPC呼び出しを発生させていたのを、PostgreSQLサーバーへの1000回のGraphQL呼び出しに変更することができます。さらに、このPostgreSQLは、特定のサブグラフにカスタマイズすることができます。シャーディング、キャッシュヒットの最適化、その他様々なインデクサーのトリックについては別の記事で紹介します。
要するに、サブグラフを念頭に置いてプロトコルをスケールさせることが重要なのです。
スマートコントラクトでEDDを使う
EDDを理解したところで、Rubicon FinanceでEDDをどのように使っているのか、スマートコントラクトから説明します。
スマートコントラクトにイベントドリブンの考え方を取り入れるために、私たちはダップのインターフェイスの観点からスタートし、スタックを逆算していきました。
上記のイベントと機能のコンテキストでは、ユーザーはオファーを出すだけでなく、過去のオファーや未処理のオファーのステータスも見たいと考えていることが分かっています。私たちのコントラクトでは、オファーに更新が発生するたびに（誰かがオファーの作成者と取引する、オファー作成者がオファーをキャンセルする、オファーが他のオファーとマッチする）、オファーの状態変化に関するすべての関連情報をイベントとして発行するようにしています。
これらのイベントを事前に決定することで、スマートコントラクトの作成時に、EDDを活用してアプリケーションのデータフロー全体を計画することができるようになりました。
スキーマの観点からは、アプリケーションのさまざまなコンポーネントを駆動する重要なデータ構造を数多く作成することができるようになりました。その優れた例が、ローソク足データです：
コントラクトはトレードが発生するとトレードデータを発行するので、これらのイベントをサブグラフのエンティティにマッピングするだけで、ローソク足チャートビューをリアルタイムで更新することができます！
ここから、私たちのアプリケーションは、最新のローソク足のような特定のサブグラフのエンティティの更新を聞くために、graph-clientを通してライブポーリングを利用し、それに応じてUIを更新することができます。これは、チェーンからデータを取得し表示するための非常に効率的な方法です。イベントが発生したときに反応するだけでなく、データを取得するためにノードを実行したり、お金を払ったりする必要がなくなります。
もし、まだgraph-clientを試したことがないのであれば、ぜひ調べてみることをお勧めします。フォールバックパターンなど、様々な便利な設定があり、サブグラフやインデクサーのネットワークを管理することで、ユーザーにシームレスで高アップタイムの体験を提供することができます。
また、イベントによって、スマートコントラクトの現在の状態をサブグラフマッピングで再現することができ、あるブロックでのコントラクトの状態を確認したいときに、履歴分析に役立ちます。この例として、Rubiconの流動性プールにおけるユーザーの残高を追跡することが挙げられます。発生したすべての入金、出金、送金がわかれば、どの時点でもユーザーの残高を把握することができます。タイムトラベルクエリはこの目的に役立ちますが、サブグラフをプルーンする機能が削除され、スケールアップ時のパフォーマンスが向上します（特にエンティティが更新される場合、更新されない場合はimmutableにする）。実際には、異なるアプリケーションのニーズを複数のサブグラフに分割することが有効であることが分かっています。
要するに、以下のような開発プロセスに従うのがベストであることがわかりました：
- アプリケーションのユーザーインターフェイスを決定し、ユーザーがアプリケーションをナビゲートする際にどのようなユーザーエクスペリエンスを提供するかを決定する。これらはすべて、スマートコントラクトの基本的な機能（Rubiconの場合は、オーダーブックプロトコルと関連する流動性プール）に依存しています。
- 設計したユーザーインターフェイスを実現するスキーマを定義します。インターフェイスのモックアップを作成したら、アプリケーションに入力するために必要なデータを知るのは比較的簡単です。迷ったときは、シンプルなほうがいいでしょう。
- 定義したスキーマに入力できるスマートコントラクトイベントを実装します。これは、特にプロトコルが複雑になるにつれて厄介になることがあり、いつ、どこでイベントを発するべきかを知るために、基礎となるスマートコントラクトを深く理解する必要があります。スマートコントラクトとユーザーとのやり取りを図式化することで、このフェーズで役に立ちます。
以上のようなアプローチにより、Rubiconはバックエンドをサブグラフに完全に依存したアプリケーションを構築することができました。これにより、集中型バックエンドに依存する必要がなくなり、完全分散型アプリケーションの基礎ができました。
ノードに関する注意点：誰もが、可能であれば、ノードを動かすべきです。クライアントの多様性は単に重要なだけでなく、真に分散化されたインターネットを構築するための集団的努力の成功において不可欠です。
アップグレード可能なプロキシコントラクトとEDDの併用
アップグレード可能なプロキシコントラクトについてよく知らない、もっと知りたいという方のために、OpenZeppelinにはこのトピックに関する豊富な知識があります。要するに、アップグレード可能なプロキシ契約では、ユーザーがアクセスする契約からコアロジックを分離することで、スマートコントラクトを長期的に更新することができます。これにより、アクセスポイントはそのままで、ロジックを更新することができます。これは素晴らしいことですが、コントラクトのイベントを更新する際に奇妙な動作が発生することがあります。
イベントをアップグレードして、より多くのデータ、より少ないデータ、または異なるデータを含むようにしたい場合、さまざまなシナリオが存在します。プロキシコントラクトを利用すれば、このようなことが簡単にできます。しかし、マッピングを更新する際に、同じイベント名を異なるパラメータ構造でインデックスすることができないことに気づきました。これは、多くのSubgraph開発者にとって不幸な現実であり、EDDの良い習慣に従うことで、回避できることを望みます。
つまり、過去に使用したイベントを更新し、新しいデータを取得したい場合は、イベントの名前を変更します。これにより、レガシーデータのインデックスを継続しながら、その新しいイベントのインデックスを作成することができます。これを可能にするには、更新されたコントラクトABIを修正して、このレガシーイベントを含める必要があります。
この例では、LogMakeは、この記事で調べたRubiconMarket.solコントラクトのv1からのレガシー・イベントです。Timestampはトランザクション自体から取得できる変数であり、イベントに含める必要はありません。後方互換性を失うことなくこのイベントを変更するには、以下のように古いイベントを非推奨とし、新たに命名したイベントを使用すれば問題ありません。
ここで、コントラクトABIにいくつかの変更を加える必要があります。そのためには、プロトコルのv1のABIのLogMake部分を見つけ、サブグラフのv2のABIを更新して、そのイベントを含めるだけです。
さて、新しく更新されたABIの中で、subgraph.yamlファイルを更新して、レガシーなv1イベントとライブなv2イベントの両方をカバーすることを確実にすることができます。これは、以下のようなものになります：
このようなところでしょうか！
プロキシを使用することで、エコシステムが構築されてきた主要なアクセス・アドレスを変更することなく、バージョン間でコントラクトを更新することができます。イベントドリブン開発の原則に従うことで、レガシーイベントと最新イベントの両方にインデックスを付けるためにサブグラフを変更するだけで、既存のスキーマ構造からアプリケーションを動作させることができます。さらに、プロトコルのアップグレードの際に、すべてのデータを失うこともありません。
RubiconはEDDを利用して、プロトコルのv1からv2へコントラクトを更新する際に、シームレスなユーザーエクスペリエンスを提供しています。つまり、ユーザーは何もしなくても、同じインターフェースで操作し、すべての履歴データにアクセスし、プロトコルの最新バージョンを利用することができるのです。これは、私たちが非常に誇りに思っていることであり、最高のDeFi体験を提供するための継続的な取り組みであり、すべてEDDのおかげです。
EDDは万能なソリューションではないかもしれませんが、Dapp開発の旅の一部として検討する価値はあります。重要なイベントを特定し、イベントドリブン型のスマートコントラクトを設計し、サブグラフを使用することで、スケーラブルで保守可能、かつ応答性の高い分散型アプリケーションを作成することができます。EDDの可能性を追求し、開発ツールボックスへの貴重な追加となり得るかどうかを評価するよう、私たちは呼びかけます。
Rubiconについて
Rubiconは、Ethereum上に構築されたオーダーブックプロトコルで、人類のためにより良い市場を構築することにより、グローバル金融を加速し民主化することを使命としています。オーダーブックは、市場における非対称な情報への対処を支援し、時間をかけて伝統的な金融において最も広く使用されているシステムとなっています。完全にオープンソースで誰もがアクセスできるRubiconは、公正で信頼できる中立的な市場を世界にもたらすことを約束します。イーサリアムがワールドコンピュータなら、Rubiconはワールドオーダーブックであると言えるでしょう。
The Graph Builders Blogに寄稿する
分散型プロジェクトとして、知識を共有することがエコシステム全体の成長と発展に不可欠であると固く信じています。The Graph Builders Blogは、The Graphエコシステムを構築する開発者や関係者が、The Graphを使った分散型アプリケーションの構築に関する洞察、経験、ベストプラクティスを共有するためのプラットフォームです。
Graph Builders Blogに投稿することで、あなたの専門知識を披露し、ソリューションを共有し、同じ考えを持つビルダーのコミュニティに触れる機会を得ることができます。私たちは、あなたの洞察が他の人を刺激し、教育し、完全に分散化された未来のビジョンに貢献することを確信しています。
The Graph Builders Blogの著者になる特典
- The Graphの編集者があなたのブログを承認すると、The Graphのサイトで紹介され、数十万人の読者にリーチすることができ、あなたはブログの著者として指名されます。
- 約30万人のTwitterフォロワーを含むソーシャルメディアへの投稿で、あなたをハイライトし、タグ付けされます。
- 「The Graph Builders Blog Author」POAPをお渡しします。
- LinkedInや履歴書にThe Graph Builders Blogの著者として追加できるようになります。
The Graph Builders Blogへの寄稿を希望される方は、こちらのフォームにご記入ください。
