分散型金融 (DeFi) の取引判断には、ブロックチェーンの価格と流動性データが必要です。 しかし、ブロックチェーンノードへの直接クエリは非効率的でリソースを大量に消費するため、タイムリーな意思決定のボトルネックとなります。 ブロックチェーンは効率的なデータクエリに最適化されておらず、データは順次 (ブロックごとに) 保存されています。 特定の情報を取得するには、多くの場合、ブロックチェーン全体をスキャンする必要があります。 インデクサーは、この問題に対するソリューションを提供します。 インデクサーは新しいブロックとトランザクションを監視し、最適化されたセカンダリデータベース (リレーショナルデータベースなど) にデータを保存するように設計できます。 これらのデータベースには、アプリケーションが直接クエリできる直接アクセス用のインデックスが含まれています。 インデクサーは、ブロックチェーンへの直接クエリと比較して高速な応答時間を提供し、過去および現在のブロックチェーンデータへの効率的なアクセスにより、DeFi アプリケーションのユーザー体験を向上させます。 ブロックチェーンインデクサーは広く利用可能ですが、既存のソリューションがブロックチェーンや必要なデータをサポートしていない場合、AWS 上にカスタムインデクサーを構築する必要があります。 本記事では、ブロックチェーンのシーケンシャルなデータ構造を DeFi アプリケーション向けに効率的にクエリできる形式に変換する、ブロックチェーンインデクサーの重要な役割とアーキテクチャについて説明します。 また、AWS 上でブロックチェーンインデクサーを構築するためのアーキテクチャガイダンスを提供します。 インデックス作成モード ブロックチェーンインデクサーには 2 つの異なるモードがあり、それぞれ異なる要件が適用されます。 バックフィル – 初回起動時、インデクサーはジェネシスから現在のヘッドまでのすべての履歴ブロックを並列プロセスで処理し、取り込み速度を最大化しています。ブロックチェーンデータは不変であるため、バックフィル中にチェーンのブロック再編成を考慮する必要はありません。 フォワードフィル – このモードでは、インデクサーは新しいブロックを発見次第すぐに取り込みます。ただし、ブロック再編成によるブロックチェーン先端の変更により、以前のブロックが無効になる可能性があるため、セカンダリデータストアが実際のブロックチェーンデータと一貫性を保つためのメカニズムが必要です。 ソリューション概要 インデクサーがブロックチェーンノードから直接抽出し、変換ロジックが変更された場合、ブロックチェーン全体を再インデックス化する必要があります (これは時間がかかります)。 代わりに、1 回抽出し、必要に応じて複数回変換とロードを行う方法を提案します。 ブロックチェーンデータを保存する中間ストレージレイヤーを作成することで、変換処理はノードに繰り返しクエリを実行するのではなく、ローカルコピーに対して処理を実行できるようになります。 次の図は、インデクサーの主要なコンポーネントを示しています。 ブロックチェーンノードは Ethereum ブロックチェーンに接続されています。 バックフィル(過去データ取得)とフォワードフィル(新規データ取得)のコンポーネントは、ブロックチェーンノードからデータを取得します。 抽出後、データは中間ストレージとしての Amazon Managed Streaming for Apache Kafka (Amazon MSK) にロードされます。 データは Amazon Managed Service for Apache Flink で変換され、 Amazon Relational Database Service (Amazon RDS) のようなデータベースにロードされます。 以下のセクションでは、抽出、変換、読み込み (ETL) プロセスについて詳しく説明します。 抽出 ブロックチェーンノードは、ブロックチェーン自体へのゲートウェイです。 すべてのブロックのローカルコピーを保持し、ブロックチェーンネットワークを通じて伝播される新しいブロックを受信します。 ブロックチェーンノードは、標準化された JSON-RPC 呼び出しを使用してクエリを実行できます。 ブロックチェーンのインデックス作成には、フルノードまたはアーカイブノードのいずれかが必要です。 フルノードはすべてのトランザクションを保持しますが、過去の状態データはプルーニングされます。一方、アーカイブノードは完全な状態履歴を保持します。 提案するアーキテクチャではアーカイブノードを前提としています。これは、フルノードを使用する場合、必要なデータがすべて含まれていることを検証する必要があるためです。 バックフィル データ取り込みの最初のステップは、ブロックチェーンの開始時点 (ジェネシスブロック) からチェーンの最新ブロックまでの過去データの取り込みです。 この過去データの取り込みコンポーネントは、過去のブロックを処理し、関連データを抽出して、Apache Kafka トピックにプッシュします。 Amazon MSK は中間ストレージとして機能します。 これにより、データを保持しつつ、複数の独立したコンシューマーがデータを処理できます。 この例では、blocks、transactions、logs という 3 つの異なるトピックを使用し、それぞれのデータを保持します。 理論的には、バックフィリングコンポーネントは、インデクサーがゼロから開始する際に一度だけ実行する必要があります。 すべての履歴データを取り込んだ後は、フォワードフィリングコンポーネントのみが、Kafka トピックをブロックチェーンの最新状態と同期させるために必要となります。 しかし、バックフィリングコンポーネントを再実行する必要がある理由はさまざまです。最初の実行時に一部のデータが取りこぼされた可能性がある場合、転送先のデータスキーマの変更、または修正された ETL ロジックのバグなどが考えられます。 バックフィリングコンポーネントを再実行する可能性があるため、高速化に重点を置いています。 バックフィリングコンポーネントの一般的なアーキテクチャは、次の図のようになります。 データ抽出には、 Paradigm が開発したオープンソースの抽出エンジン cryo を使用します。 これは、並列的な RPC 呼び出しを使用してブロックチェーンノードからデータを抽出し、ローカルファイルとして保存します。その後、これらのファイルを Kafka トピックにプッシュできます。 バックフィル中、インデクサーはブロックチェーンノードにクエリを送信します。 スロットリングを回避し、クエリへの応答を確実にするために、専用ノードを使用することをお勧めします。 ネットワークレイテンシーを削減するために、このノードをインデクサーの近くに配置することをお勧めします。 サンプルアーキテクチャでは、単一の Amazon Elastic Cloud Compute (Amazon EC2) インスタンスを使用して、ノードのホストとインデックス処理ロジックの実行の両方を行っています。 フォワードフィル バックフィル後、インデクサーはフォワードフィルモードに切り替わります。 フォワードフィルは継続的かつ順次実行され、ノードを監視して新しいブロックを検出します。 このコンポーネントは 2 つの機能を実行します。1/ ブロックチェーンノードを監視し、到着した新しいブロックを取り込む、2/ ブロック再編成 (reorg) を認識し続けます。 多くのブロックビルダーが同時に新しいブロックを作成しているため、生成されたブロックが無効になる可能性があります (より長いチェーンのフォークが存在する場合)。 インデクサーは reorg を認識する必要があります。ブロック reorg が発生した場合、フォークの起点まで遡る必要があります。 ブロック reorg は次のことを検証することで検出されます。1/ 各新しいブロックに前のブロックのハッシュが含まれていること、2/ ブロック番号が順次増加していること。 いずれかの条件が満たされない場合、reorg が発生しており、インデクサーはフォーク前の最後のブロックまで巻き戻す必要があります。 ワークフローには 3 つのステップがあります (上の図に示されています)。 現在の正規チェーンの先頭 (緑) に従わない新しいブロック (紫) が出現します。 インデクサーは新しいブロックから共通の祖先 (緑) まで遡ります。 インデクサーは共通の祖先までの、以前に保存されたブロックを削除します。インデクサーは新しい正規ブランチから新しいブロックを取り込みます。 次の図は、フォワードフィリングコンポーネントのアーキテクチャを示しています。 これは、ブロックチェーンノードがチェーンの再編成を正しく処理する機能に依存しています。 これを実現するために、Reth クライアントの Execution Extensions (ExEx) 機能を使用します。 クライアントは各新しいブロック (およびreorg) を ExEx に通知し、ExEx はデータをカスタムの送信先に送信できます。 reorgを処理するために、ExEx は巻き戻しと新しくコミットされたブロックの両方を Kafka にプッシュします。 Kafka トピックはこれらのブロックを順次保存し、その後変換ロジックが実行されて最終的なデータシンクのデータを更新または削除します。 変換 Apache Flink を使用すると、Kafka トピックに対してコンシューマーを実行し、データのフィルタリングと変換を行うことができます。 Flink アプリケーションは Java で記述されており、データのフィルタリングや変換に適しています。 アドレスまたはイベントデータのデコードによって、特定のスマートコントラクトに対するフィルタリングを実行できます。 変換されたデータは、再び Kafka トピック、Amazon RDS などのデータベース、または Amazon Simple Storage Service (Amazon S3) 上のファイルとして保存できます。 コンシューマーは元のデータを変更しないことに注意することが重要です。 変換ロジックに変更が発生した場合、最初の Kafka メッセージからインデックスを再構築するためにコンシューマーを再起動するだけで済み、データソース（ノード）自体に戻る必要はありません。 データの構造によっては、複数のコンシューマーを並列で実行できる可能性があります。 ロード コンシューマーは、データをカスタムシンクにロードできます。 Uniswap の例では、データをカスタム PostgreSQL テーブルに保存します。 フロントエンドはテーブルをクエリして、適切なデータを取得できます。 ソリューション全体の最終的なアーキテクチャは、次の図に示されています。 まとめ AWS ベースのブロックチェーンインデクサーは、単方向データフローと抽出プロセスと変換プロセスの分離により、最適化されたデータアクセスを実現します。 このアーキテクチャは、バックフィルによる効率的な履歴データ処理を可能にしながら、再編成検知機能を備えたフォワードフィルによってリアルタイムデータの整合性を維持します。 このソリューションは、MSK、Managed Flink、RDS を含む AWS サービスを活用して、ブロックチェーンの順次的な構造を効率的にクエリ可能な形式に変換する、スケーラブルで信頼性の高い基盤を構築します。 このソリューションをデプロイすることで、開発者は直接ノードにクエリを実行する際のパフォーマンス制限を回避しながら、貴重なブロックチェーンインサイト（洞察）を得ることができます。 詳細情報 このソリューションをご自身でデプロイするには、 GitHub の詳細なデプロイメントガイド に従ってください。 インデクサーのデモでは、デフォルトでアーカイブノードを持つ reth 実行クライアントを使用し、カスタムシンクにデータをストリーミングする方法を提供します。このストリーミング機能はフォワードフィリングプロセスで使用されます。 このソリューションは、バックフィリングのために cryo を使用して履歴データを効率的に抽出し、カスタム reth ExEx を通じてリアルタイムデータを取得し、Flink を使用してこのデータを処理および変換し、分析のために構造化データをリレーショナルデータベースに保存します。 このソリューションは、オンチェーンデータの規模と複雑さに対応できるブロックチェーンのインデックス作成と分析のための信頼性の高い基盤を提供し、ブロックチェーンデータから価値ある洞察を得るのに役立ちます。 これを拡張するには、以下を検討してください。 異なるプロトコルやトークンのための Flink アプリケーションの追加 データ可視化ダッシュボードの実装 特定のオンチェーンイベントに対するアラートの設定 予測分析のための機械学習モデルとの統合 本記事は、2025 年 11 月 25 日に公開された Building a blockchain indexer on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 著者について Christoph Niemann Christoph は Dune Analytics の Web3 ソリューションエンジニアであり、AWS の元シニアブロックチェーンアーキテクトです。ブロックチェーンを扱い、ブロックチェーンデータのソリューションを開発する深い経験を持っています。 Arvind Raghu Arvind は AWS の Web3 および Confidential Compute のグローバル責任者です。顧客やパートナーと緊密に連携して Web3 および Confidential Computing ソリューションを開発するアーキテクトと GTM ストラテジストのチームを率いています。 Forrest Colyer Forrest は AWS で Web3 と分散型テクノロジーを専門とするシニアスペシャリストソリューションアーキテクトです。ブロックチェーンなどのテクノロジーに依存するワークロードを構築する際に、業界を超えた顧客に対して深い技術的ガイダンスを提供し、また Web3 分野の ISV とのパートナーシップの構築にも取り組んでいます。

デジタル資産決済により、迅速かつ低コストのピアツーピア取引が可能になります。 ブロックチェーンベースの決済システムは、従来の決済方法で企業が直面する主要な課題に対処します。 これには、高い処理手数料、キャッシュフローに影響を与える決済遅延、業務に影響を及ぼす複雑な国際取引などが含まれます。 この投稿では、ブロックチェーンベースのデジタル資産決済システムがどのようにコストと遅延を削減できるかを説明します。 USDC 、 PYUSD 、 USDG などのステーブルコインを例として、AWS 上でサーバーレス決済システムを構築する方法を紹介します。 このソリューションは、従来の決済方法に代わる低コストでスケーラブル、かつ分散型の選択肢を提供します。 実装は GitHub リポジトリ で公開されています。 この投稿は、デジタル資産決済ソリューションの技術的な概要を示すものであり、法的助言や規制上のガイダンスを意図したものではありません。 法的コンプライアンス、検証、確認の要件は管轄区域によって異なる場合があり、読者ご自身の責任です。 この投稿で説明されている決済ソリューションを実装または使用する前に、ご自身でデューデリジェンスを実施してください。 ブロックチェーンベースの決済のメリット デジタル資産決済を導入する企業には、魅力的なメリットがあります。 コスト管理 決済処理のオーバーヘッドの削減 決済効率 ブロックチェーンの確認後に資金にアクセスできます。正確なタイミングはネットワークによって異なります (数秒から数分) グローバル展開 複数の仲介業者を介さずに国境を越えた取引を実行し、為替手数料を排除します トランザクションの可視性 オンチェーン検証による完全なトランザクションの透明性により、監査の効率化 デジタル資産決済は、さまざまなステークホルダーにメリットをもたらします。 加盟店 – 高速で低手数料の決済により、EC （イーコマース）を効率化します。 金融機関 – 決済時間を短縮し、国際送金や資金管理を促進します。 共通のメリット – 通貨交換と決済処理の手数料を最小化します。 最終的に、デジタル資産決済は、マーチャントや金融機関が技術革新を進め、コストを最小化し、新たな機会を引き出すのに役立ちます。 ソリューション概要 このソリューションにより、企業は Ethereum を含む Ethereum Virtual Machine (EVM) 互換ネットワーク全体で、デジタル資産による消費者からの支払いを、完全な自動化と安全な資金処理で受け入れることができます。 テストネットとメインネット環境の両方に対応しています。 リポジトリ では、デジタル資産支払いソリューションをデプロイして使用する手順を順を追って説明しています。 このソリューションの主な機能は以下の通りです。 デジタル資産決済ソリューションの 3 つのコアコンポーネントについて、さらに詳しく見ていきましょう。 請求書ジェネレーター このコンポーネントを使用すると、請求書を生成し、顧客から直接支払いを受け付けることができます。 請求書ジェネレーターは以下の機能を提供します: 確定的な請求書生成 – 請求書ジェネレーターは、請求書とブロックチェーンアドレスの 1 対 1 のマッピングを容易にします。これにより、各支払いが対応する請求書に正しく紐付けられることが保証されます。このシステムは、 アトミックカウンター を Amazon DynamoDB に保存してウォレットインデックスを維持し、高い同時実行シナリオでもスレッドセーフなアドレス生成を維持します。 効率的な鍵管理 – BIP32 / BIP44 は、階層的決定性鍵導出関数を使用して、 AWS Secrets Manager に保存された単一のプライマリシードから多数の鍵パスを生成し、複数のアカウントとアドレスの構造化された管理を可能にします。 UI ですぐに使える出力 – 請求書ジェネレーターは、請求書の入金アドレスと Data URL 形式の Base64 エンコードされた QR コードの両方を返します。これは HTML の タグに直接埋め込むことができます。 セキュリティとプライバシーの強化 – 各顧客は一意の 1 回限りの支払いアドレスを受け取ります。これにより、アドレスの再利用を防ぎ、パブリックブロックチェーン上でユーザーのプライバシーを保護することができます。 簡素化された会計処理 – 合理化された追跡により、会計と監査が容易になります。 定期支払いのシナリオでは、安定した顧客識別子から支払いアドレスを導出するようにソリューションを拡張できます。 これにより、各顧客に対して一貫したウォレットアドレスが作成され、定期支払いが合理化され、顧客の許可リスト登録プロセスが簡素化されます。 支払いの自動検出 「The Watcher」は、自動的な更新情報とイベント駆動型通知による支払い状況の監視を可能にします。 自動支払い検出コンポーネントは、以下の機能を提供します。 最適化されたデータベースクエリ – DynamoDB グローバルセカンダリインデックス ( status-index ) を使用して、 pending 状態の請求書のみをクエリします。これにより、請求書の総量が増加してもクエリのパフォーマンスが維持され、DynamoDB の読み取り消費量が大幅に削減されます。 リアルタイム残高検証 – ETH および ERC-20 トークンの残高を請求書の金額と照合して検証します。 自動ステータス更新 – 十分な支払いが検出されると、請求書を自動的に paid としてマークします。(デフォルトでは、このソリューションはファイナリティやリオーグを考慮しません。より強力な保証が必要な場合は、Watcher の eth_getBalance に finalized ブロックタグを渡すことができます。) 即時通知 – 支払い確認時に Amazon SNS を通じて加盟店への通知をトリガーします。 資金照合 請求書の支払いを受け取った後、資金は安全な管理のために指定された財務ウォレット (できれば高度にセキュアなコールドウォレット) に自動的に移動されます。 これにより、数分以内にオフラインで支払いが安全に処理され、加盟店が選択したウォレットへの資金集約のための監査可能なメカニズムがサポートされます。 ファンド照合プロセスは、以下の機能を提供します。 DynamoDB Streams によるトリガー – フィルタリングされたストリームトリガーを通じて確認済みの支払いを検出します (ステータスが paid )。ネットワークの混雑や一時的なブロックチェーンの問題に対処するための組み込みメカニズムを備えています。 ガスの最適化 – コスト効率の高いトランザクションのために、ネットワークのガス価格を動的に計算します。 ガス補充メカニズム – 専用のホットウォレット「ガスタンク」が、ネットワークのネイティブトークン (例: ETH) の準備金を保持します。これは、ERC-20 インボイスを補充するためだけに使用され、最小限のガス料金で コールドストレージの金庫に集約できるようにします。 安全な転送 – 秘密鍵はメモリ内で決定論的に導出され、保存されません。これらは個々のインボイスからの転送を実行するために使用されます。これは Lambda 内で行われ、AWS は オペレーターによるアクセスはありません 。 ステータスの更新 – 正常に完了すると、インボイスのステータスを swept に更新します。 次の図は、ソリューションのアーキテクチャを示しています。 このアーキテクチャは、サーバーレスなデジタル資産決済処理の PoC （ Proof of Concept ）を目的としており、本番環境で使用できる状態ではありません。 セキュリティ、信頼性、コンプライアンス、監査可能性に関する本番環境の基準を満たすには、追加の機能強化が必要です。 以下のフローの各ステップの番号は、Ethereum ネットワーク上でのステーブルコイン決済を示しており、上記のアーキテクチャ図の番号に対応しています。 加盟店は、 Amazon API Gateway が提供する /create-invoice REST API へのリクエストを通じて、ステーブルコインのインボイスを作成します。これは API キーを使用して保護されています。 AWS Lambda 関数である Invoice Generator がトリガーされ、 AWS Secrets Manager からニーモニック シードフレーズ を取得します。シードフレーズは、インボイスに対応するキーペアを作成 (および復元) するために必要です。 Invoice Generator は Amazon DynamoDB のアトミックカウンターをインクリメントします。アトミックカウンターの値はインデックスを表します。これはシードフレーズと共に使用され、特定の支払いに対する 階層的決定性 (HD) ウォレットアドレスを決定論的に導出します。 Invoice Generator Lambda 関数は新しいインボイスを作成し、 status: pending として DynamoDB に保存します。データは AWS Key Management Service (AWS KMS) を使用して保管時に自動的に暗号化されます。 前のステップで生成された QR コードには、送金先アドレス、通貨、金額がエンコードされており、加盟店に返されます。加盟店は QR コードを顧客と共有します。顧客は、入金アドレスに適切な金額の資金を送信することで、ステーブルコインの支払いを行います。 Amazon EventBridge スケジュールを通じて、Watcher という Lambda 関数が毎分トリガーされます。Watcher は DynamoDB から保留中のインボイスを取得し、提供された RPC エンドポイントを通じて行われた支払いを確認します。支払いが到着した場合、インボイスを paid に更新します。 Watcher Lambda 関数は、 Amazon Simple Notification Service (Amazon SNS) を使用して、加盟店に支払い確認を送信します。 CryptoInvoices データベースで支払いが検出されると (ステータスが paid に遷移すると)、 Amazon DynamoDB Streams を使用してイベントが発行されます。これにより Lambda Sweeper 関数がトリガーされます。 Sweeper 関数は資金の集約トランザクションに必要なガスを計算し、これが ERC20 インボイスであるため Eth をリクエストします。 十分な Eth が利用可能になると、Sweeper 関数はインボイスに関連付けられたトークンをオフラインの保管用ウォレットに送信します。Sweeper 関数は、HD ウォレットのシードフレーズをリクエストし、トランザクションに署名するための秘密鍵を導出することでこれを行います。その後、インボイスは CryptoInvoices データベースで swept としてマークされます。資金の集約プロセス中にエラーが発生した場合、失敗がログに記録され、最大 3 回の再試行が行われます。 加盟店は、API Gateway を使用して公開された REST エンドポイントを通じてインボイスを管理できます (インボイスの現在のステータスを表示したり、保留中のインボイスをキャンセルしたりできます)。 支払い、支払い監視、資金の回収フローの詳細な図解については、 GitHub リポジトリ を参照してください。 まとめ このサーバーレスソリューションは、AWS 上でデジタル資産決済を処理するための安全で効率的、かつコスト効率の高いシステムを提供します。 AWS のサービスとブロックチェーン技術を活用することで、組織は決済処理コストを削減し、資金へのより迅速なアクセスを実現し、キャッシュフローを向上させ、グローバルに事業を展開できます。 本記事は、2025 年 10 月 2 日に公開された Processing digital asset payments on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 GitHub で完全なコードを確認し、AWS 上で安全なサーバーレスデジタル資産決済ソリューションの構築を始めましょう。 著者について Simon Goldberg Simon は、AWS のブロックチェーン/Web3 スペシャリストソリューションアーキテクトです。仕事以外では、音楽制作、読書、クライミング、テニス、ハイキング、コンサート鑑賞、Web3 テクノロジーの研究を楽しんでいます。 David Dornseifer David は、AWS のブロックチェーンおよびコンフィデンシャルコンピュートアーキテクトです。彼は、お客様がエンドツーエンドのブロックチェーンおよびコンフィデンシャルコンピュートソリューションの設計、開発、スケーリングを支援することに注力しています。主な専門分野は、デジタル資産の保管と鍵管理ソリューションです。

はじめに こんにちは、サイオステクノロジーの安藤 浩です。 前回の記事では、Ethereum Sepoliaテストネット上のフルノードを構築し、イベントログからERC-721やERC-1155の所有者を特定する方法をご紹介しました。 前回の記事は以下です。 [web3] Ethereum の Sepolia上のイベントログから ERC-721, ERC-1155 の所有者の見つけ方 今回はその続編として、WebSocketを活用したリアルタイムでの所有者の移転が行われた際の監視の方法をお伝えします。 WebSocketを使ったイベント監視の仕組み Ethereumのフルノードは通常HTTPSによるRPC通信を提供していますが、リアルタイム監視にはWebSocketが適しています。WebSocketを使うことで、新しいイベントが発生した時点で即座に通知を受け取ることができます。 前提条件 Sepoliaテストネット上のフルノードがすでに構築されていること 上記に記載の前回の記事でフルノードを構築してください。 [web3] Ethereum の テストネット: Sepolia上での フルノード構築 設定手順 1. Gethの起動設定を変更する まず、GethでWebSocketを有効にするために、起動コマンドに以下のオプションを追加します。 --ws --ws.api eth,net,web3 実際のコマンド例は以下のようになります： gethlocal --sepolia --ws --ws.api eth,net,web3 --http --http.api eth,net,engine,admin --authrpc.jwtsecret 【jwt.hexファイルのパス】 --datadir 【データディレクトリのパス】--syncmode snap 2. WebSocketでイベントをサブスクライブするコード src/sub.ts というファイルを以下の内容で作成します。 import WebSocket from 'ws'; // Geth ノードの WebSocket エンドポイント const wsUrl = 'ws://localhost:8546'; // WebSocket クライアントを作成 const ws = new WebSocket(wsUrl); ws.on('open', () => { console.log('WebSocket connection established.'); const contractAddressList = [ '0xE88Df35e01e3e33Df38FB0B5e324282feCeb20c2', //ERC-721 '0x412E008d6157568F8c621FbF899e7717F0442a94' //ERC-1155 ]; contractAddressList.forEach((contractAddress) => { // eth_subscribe を使用してトランザクションログを監視 const subscriptionRequest = { jsonrpc: '2.0', id: 1, method: 'eth_subscribe', params: ['logs', { address: contractAddress, // 特定のコントラクトアドレスを指定 topics: [] // トピックフィルタを指定（空配列はすべてのイベントを受信） } ] }; ws.send(JSON.stringify(subscriptionRequest)); }); }); ws.on('message', (data: any) => { const response = JSON.parse(data.toString()); if (response.method === 'eth_subscription') { console.log('New log:', response.params.result); } else { console.log('Response:', response); } }); ws.on('error', (error: any) => { console.error('WebSocket error:', error); }); ws.on('close', () => { console.log('WebSocket connection closed.'); }); 実行すると、WebSocketの接続が確立され、以下のようなレスポンスが表示されます： [nodemon] starting `ts-node src/sub.ts` WebSocket connection established. Response: { jsonrpc: '2.0', id: 1, result: '0x8debf94ebabaea3a86f403b2e2791a19' } リアルタイム監視の実例 ここでは、実際にNFT関連のトランザクションが発生した際に受信したイベントログをいくつか紹介します。 1. OwnershipTransferredイベント New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x', blockNumber: '0x7a2cce', transactionHash: '0xa8edf869ba4fd375f2fdfc51e557d7a3237299f2583242bb43d839f5930fcf78', transactionIndex: '0x1e', blockHash: '0x57e194d69b6dd85dc431228189c8bf551d0e91a74ed14c6eecfba581c580c73c', logIndex: '0x1a', removed: false } このイベントは、コントラクトのオーナーシップ移転を示しています。Etherscanでは こちら で確認できます。 2. TransferSingleイベント New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0xc3d58168c5ae7397731d063d5bbf3d657854427343f4c083240f7aacaa2d0f62', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001', blockNumber: '0x7a2d00', transactionHash: '0xa9f80aced3eb829117ef1cdfaba629a6ae625af9e44febe91bfed5b3dfec3565', transactionIndex: '0x43', blockHash: '0x3823f72b6cf3590915be2b19bc2bff5acbf4f35a772c91e69b3dc4d5804bc7e2', logIndex: '0x43', removed: false } このログはERC-1155のTransferSingleイベントで、単一のトークン移転を記録しています。トランザクションは こちら で確認できます。 New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0xc3d58168c5ae7397731d063d5bbf3d657854427343f4c083240f7aacaa2d0f62', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001', blockNumber: '0x7a2d0c', transactionHash: '0xb20b71a0e8b8d47ee30fa20c0afc74f82d83aa508492d6128a4dbf7258e91960', transactionIndex: '0x37', blockHash: '0x4a83395b33fd6dd60302d8d340fd4afb114b4b1208cc94b5246ff39162e0173e', logIndex: '0x64', removed: false } 3. TransferBatchイベント New log: { address: '0x412e008d6157568f8c621fbf899e7717f0442a94', topics: [ '0x4a39dc06d4c0dbc64b70af90fd698a233a518aa5d07e595d983b8c0526c8f7fb', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x00000000000000000000000036da942099c028275321130b5e503f37da446487', '0x000000000000000000000000cebc36de334ce12dfd08f4c39e833016263ba5b0' ], data: '0x000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002', blockNumber: '0x7a2d5e', transactionHash: '0xd35a028d7c9a9d98d7ac103f6fa75b0496967e947791572b8a8a87b2407d78b2', transactionIndex: '0x8', blockHash: '0x1f9f0e0134a8b7c57156df86e84262c4037256a7f7f143a184f57922fd1ad3b1', logIndex: '0x13', removed: false } こちらはERC-1155のTransferBatchイベントで、複数のトークンが一度に移転されたことを示しています。詳細は Etherscan で確認できます。 イベントデータの活用方法 受信したイベントログを解析することで、以下のような情報を取得できます： ERC-721：  event Transfer  から直近の送信先を特定 ERC-1155： event TransferSingle  と  event TransferBatch  から所有者と所有量を計算 これらの情報をリアルタイムで処理し、データベースに記録することで、常に最新のNFT所有状況を把握することができます。 まとめ Ethereumフルノードを使ったWebSocket接続により、NFTの所有権移転をリアルタイムで監視できることがわかりました。この方法は、NFT取引プラットフォームやウォレットサービスなど、常に最新の所有権情報を必要とするアプリケーションで特に有用です。 参考資料 Geth PubSub API ドキュメント ERC-721 非代替性トークン規格 ERC-1155 マルチトークン規格   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post [web3] Ethereum フルノードを使ったERC-721, ERC-1155の所有者のリアルタイム監視方法 first appeared on SIOS Tech. Lab .