本記事は、2025 年 9 月 25 日に公開された Improve Solana node performance and reduce costs on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 Solana Agave v2.0.14 は 2024 年 10 月 18 日にリリースされました。 それ以降、Solana ノードのオペレーターから、mainnet-beta の最新スロットとの同期を維持するのに苦労することがあるという報告がありました。 Solana の StackExchange で「catch up」を検索すると、この課題に関する多数の投稿が見つかります。 以前の投稿 では、AWS で Solana ノードを実行する方法を説明しました。 この投稿では、より高速な運用と初期同期のためにノードを設定する方法を解説します。 さらに、 Amazon Elastic Compute Cloud (Amazon EC2) で Solana ノードのデータ転送のコスト効率を高めるための実験的なトラフィック最適化手法を共有します。 Solana Agave v2.x における変更点 Solana Agave v2.x における最も重要な変更の 1 つは、新しい中央スケジューラです。 これは v1.18.x にも存在していましたが、デフォルトでは無効になっていました。 v2.x のアップデートにより、中央スケジューラがデフォルトで有効になりました。 Solana Agave クライアントのコアコンポーネントとして、中央スケジューラはトランザクション処理アーキテクチャを大幅に変更します。 これは、以前の 4 スレッドによる処理モデルに代わるシングルスレッドによる調整メカニズムである Scheduling Thread を導入します。 この変更について詳しくは、 Introducing the Central Scheduler: An Optional Feature of Agave v1.18 を参照してください。 この変更は、推奨される最小 CPU クロック速度に大きな影響を与え、トランザクション処理の最適なパフォーマンスのために、要件が 2.8 GHz から 3.2 GHz に増加しました。 これに基づき、 以前のブログ記事 で Solana ノードを実行するための推奨 AWS インスタンスタイプを更新し、 R7a および I7ie EC2 インスタンスファミリーに切り替えました。 これらのインスタンスファミリーは、さまざまな構成で Solana ノードを実行するために必要な 384 GiB から 1.5 TiB 超の RAM も提供します。 Agave v2.2.15 では、処理ロジックの「ホットパス（頻繁に実行される処理経路）」からブロックストレージ操作を削除することに焦点を当てた、その他の重要なパフォーマンス最適化が導入されました。 これにより、ブロックストレージデバイスに必要な 1 秒あたりの入出力操作数 (IOPS) とレイテンシーが削減され、クラウド上で Agave クライアントを実行するコストがさらに削減されました。 アジア太平洋 AWS リージョンにおける Solana の同期における課題の克服 Solana Agave ノードが起動時に事前ダウンロードされたスナップショットを持っていない場合、クライアントは信頼できるバリデーターノードからそのスナップショットをダウンロードします。 これらのノードは --known-validator フラグで設定され、 Anza RPC ノード起動コマンドの例 に示されています。 しかし、これらの信頼できるバリデーターは、北米またはヨーロッパの AWS リージョンに配置されていることが多く、東京、香港、ソウル、シンガポールなどのアジア太平洋リージョンで実行されているクライアントにとって問題となります。 これらの場所でのスナップショットのダウンロード速度は、通常、北米またはヨーロッパリージョンのクライアントと比較して遅くなります。 スナップショットをダウンロードした後、Agave はスナップショットのスロットが最新より 2,500 スロット以上遅れているかどうかをチェックします。 この差が 2,500 より大きい場合、クライアントはスナップショットを再ダウンロードし、同期プロセスがさらに遅延します。 この問題は GitHub issue #24486 に記録されています。 デフォルトでは、 maximum_local_snapshot_age パラメータは 2,500 に設定されています 。 スナップショットの再ダウンロードを避けるためにこの値を増やすことはできますが、この方法は推奨しません。 Solana は 400 ミリ秒ごとに新しいスロットを生成する (1 分あたり約 150 スロット) ため、この値を高く設定しすぎると、ノードが最新のスロットに追いつかなくなる可能性があります。 アジアパシフィックリージョンで Solana ノードを実行する際のスナップショットダウンロードパフォーマンスを向上させるには、以下を推奨します。 信頼できるノードを特定する: validator.app を使用して、アジア太平洋地域のあなたの場所に近い 信頼できるノードの識別子 を見つけます。 これらの識別子を agave-validator 起動コマンドの --known-validator フラグのパラメータとして設定します。 警告 マークが付いているバリデーターノードの使用は避けてください。 スナップショットソースを制限する: --only-known-rpc フラグを使用して、信頼できるノードからのみスナップショットをダウンロードするようにクライアントを設定します。 最小ダウンロード速度を設定する: --minimal-snapshot-download-speed フラグを使用して、必要な最小スナップショットダウンロード速度を定義し、低速なソースからのダウンロードを防ぎます。テストでは、104,857,600 (100 MiBps) を使用しました。 これらの最適化を実装することで、初期同期を高速化し、アジア太平洋リージョンにおける Solana ノードのデプロイをより高速で信頼性の高いものにすることができます。 Agave RPC ノードのデータ転送コストの最適化 Solana Agave クライアントは、 Turbine と呼ばれるデータ伝播プロトコル により、大量のアウトバウンドデータトラフィックを生成します。 近年、月間トラフィック量は増加しており、 RPC のみとして構成されたノード であっても、現在は 100 TiB から 200 TiB 以上の範囲になっています。 これらのコストをより効果的に管理するために、Solana ノードの同期を維持するために最小限必要なアウトバウンドデータスループットを決定するための一連の実験を実施しました。 まず、ノードの「Slots Behind」メトリクスを 1 分ごとにチェックし、初期同期が完了した後に実行するスクリプトを作成しました。 1 分間隔は、Solana ノードが正常に同期しているか、遅れ始めているかを確実に検出できるのに通常十分です。 「Slots Behind」メトリクスがゼロに達し、ノードが完全に同期されたことを示すと、別のスクリプトがユーザー定義の帯域幅制限を MiBps 単位で適用します。 「Slots Behind」メトリクスが 10 を超えると、ノードが追いつくまで制限が一時的に解除されます。 運用効率を維持するために、システムはこれらの制限から内部ネットワークトラフィックを除外します。 標準的な内部 IP 範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16) 内のトラフィックは制限の対象外とし、内部 IP を使用する AWS アプリケーションが正常に機能することを確保します。 この機能は RPC ノードに対して非常に効果的ですが、コンセンサスノードには実装すべきではありません。 コンセンサスノードでアウトバウンドトラフィックを制限すると、パフォーマンスが低下するため、最適なネットワーク参加のためには推奨されません。 このトラフィック最適化手法をテストするために、 eu-central-1 リージョンで 5 台の i7ie.12xlarge EC2 インスタンスを使用して 5 日間の比較テストを実施しました。 4 つのノードにトラフィックシェーピングスクリプトを設定し、1 つのコントロールノードには制限を設けず、「Current Slots」と「Slots Behind」のメトリクスを収集して、ノードの同期速度と安定性を比較しました。 テストの結果、ノードは 20 MiBps という低いアウトバウンドトラフィック帯域幅 (月間約 6.5 TiB) で同期を維持でき、最適な価格対パフォーマンス比は 40-50 MiBps で達成され、推定データ転送コストを 85% 以上削減できることが示されました。 テスト期間全体を通じて、5 つのノードすべてが同期を維持し、アウトバウンド帯域幅を削減してもノードの同期状態に影響しないことが確認されました。 驚くべきことに、Agave v2.2.16 でアウトバウンドトラフィック帯域幅を 20-50 MiBps に制限したノードは、制限のないコントロールノードと比較して最大 5%より一貫して同期を維持しました。 Agave RPC ノードのトラフィックシェーピングの設定 これらの結果に基づき、AWS Blockchain Node Runners の Solana ブループリントに動的トラフィックシェーピングを導入しました ( Optimizing Data Transfer Costs を参照)。 その実装の主要な部分は以下のとおりです。 net-rules-start.sh はトラフィックシェーピングを有効にします。 #!/bin/bash # Specify max value for outbound data traffic in Mbps. LIMIT_OUT_TRAFFIC_MBPS=20 # Step 1: Create nftables rules to mark packets going to public IPs # Create table if it doesn't exist if ! nft list table inet mangle >/dev/null 2>&1 ; then nft add table inet mangle fi # Create chain if it doesn't exist if ! nft list chain inet mangle output >/dev/null 2>&1 ; then nft add chain inet mangle output { type route hook output priority mangle\ ; } fi # Check if specific private IP return rule exists if ! nft list chain inet mangle output | grep -q "10\.0\.0\.0/8.*172\.16\.0\.0/12.*192\.168\.0\.0/16.*169\.254\.0\.0/16.*return"; then nft add rule inet mangle output ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } return fi # Check if mark rule with value 1 exists if ! nft list chain inet mangle output | grep -q "meta mark set 0x00000001"; then nft add rule inet mangle output meta mark set 1 fi # Step 2: Set up tc with filter for marked packets INTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1) # Check if root qdisc already exists if ! tc qdisc show dev $INTERFACE | grep -q "qdisc prio 1:"; then tc qdisc add dev $INTERFACE root handle 1: prio fi # Step 3: Add the tbf filter for marked packets # Check if filter already exists if ! tc filter show dev $INTERFACE | grep -q "handle 0x1 fw"; then tc filter add dev $INTERFACE parent 1: protocol ip handle 1 fw flowid 1:1 fi # Check if tbf qdisc already exists on class 1:1 if ! tc qdisc show dev $INTERFACE | grep -q "parent 1:1"; then tc qdisc add dev $INTERFACE parent 1:1 tbf rate "${LIMIT_OUT_TRAFFIC_MBPS}mbit" burst 20kb latency 50ms fi net-rules-stop.sh はすべてのトラフィックシェーピングを削除します: #!/bin/bashINTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1)# Remove tc rulestc qdisc del dev $INTERFACE root 2>/dev/null# Remove nftables rules# Delete the entire mangle table (removes all chains and rules)nft delete table inet mangle 2>/dev/nullexit 0 ; 簡単にするために、自動化スクリプト net-rules-start.sh と net-rules-stop.sh は systemd サービス net-rules.service を通じて制御されます。 [Unit] Description="ipables and Traffic Control Rules" After=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/opt/instance/network/net-rules-start.sh ExecStop=/opt/instance/network/net-rules-stop.sh [Install] WantedBy=multi-user.target net-syncchecker.sh は、内部からアクセスする API を使用してノードの同期ステータスをチェックし、net-rules サービスでトラフィックシェーピングのオンとオフを切り替えます。これは 1 分ごとに呼び出す必要があるため、 systemd timer や cron のような他のサービス を使用してスケジュールできます。 #!/bin/bash INIT_COMPLETED_FILE=/data/data/init-completed MAX_SOLANA_SLOTS_BEHIND=10 # Check if jq is available if ! command -v jq &> /dev/null ; then echo "Error: jq is required but not installed" exit 1 fi TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") if [ -z "$TOKEN" ] ; then echo "Error: Failed to get EC2 metadata token" exit 1 fi EC2_INTERNAL_IP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/local-ipv4) # Start checking the sync node status only after the node has finished the initial sync if [ -f "$INIT_COMPLETED_FILE" ] ; then SOLANA_SLOTS_BEHIND_DATA=$(curl -s -X POST -H "Content-Type: application/json" -d ' {"jsonrpc":"2.0","id":1, "method":"getHealth"}' http://$EC2_INTERNAL_IP:8899 | jq .error.data) SOLANA_SLOTS_BEHIND=$(echo $SOLANA_SLOTS_BEHIND_DATA | jq .numSlotsBehind -r) if [ "$SOLANA_SLOTS_BEHIND" == "null" ] || [ -z "$SOLANA_SLOTS_BEHIND" ] then SOLANA_SLOTS_BEHIND=0 fi if [ $SOLANA_SLOTS_BEHIND -gt $MAX_SOLANA_SLOTS_BEHIND ] then if systemctl is-active --quiet net-rules ; then systemctl stop net-rules fi fi if [ $SOLANA_SLOTS_BEHIND -eq 0 ] then if ! systemctl is-active --quiet net-rules ; then systemctl start net-rules fi fi fi 本番環境で使用する前に、この投稿のコードまたは AWS Blockchain Node Runners について: これらのスクリプトを安全な環境でレビューおよびテストしてください 必要に応じて入力検証を追加してください 適切なエラー処理とログ記録を実装してください 必要最小限の権限でスクリプトを実行してください まとめ この記事では、Solana Agave v2.x で導入された変更により必要な CPU クロック速度が増加したことを確認し、アジア太平洋地域における Solana Agave クライアントの同期時間を改善する方法を検討し、Solana RPC ノードのデータ転送コストを最適化する方法を紹介しました。 これらの最適化をご自身のノードでテストするか、 AWS Blockchain Node Runners イニシアチブの Solana ブループリント を使用してください。 さらに質問がある場合は、 AWS re:Post で「blockchain」タグを付けて質問するか、 Solana StackExchange でディスカッションに参加するか、 Solana コミュニティ にお問い合わせください。 著者について Tao Gong Tao はブロックチェーン技術の愛好家です。AWS 上で革新的なソリューションを構築するために顧客と協力し、ビジネス上の課題を克服し、AWS サービスを効率的に採用できるよう支援しています。 Jinsong Zhu Jinsong は AWS のシニアソリューションアーキテクトで、大手 Web3 および暗号資産企業向けに高性能、低レイテンシー、コスト最適化されたクラウドソリューションの設計を専門としています。 Nikolay Vlasov Nikolay は、AWS Worldwide Specialist Solutions Architect 組織における分散型台帳技術インフラストラクチャのグローバルリードです。顧客が AWS 上で分散型ウェブおよび台帳技術のワークロードを実行できるよう支援しています。

はじめに こんにちは。 @Sakamoto です。 この記事は、 Merpay & Mercoin Advent Calendar 2025 の4日目の記事です。 2025年9月からメルコインでフロントエンドのインターンを始め、12月初めでちょうど3か月になりました。期間中はメルコインに加え、メルカリNFTの開発にも参加しました。 本記事では、インターン期間中に取り組んだタスクを振り返り、そこで得た学びや気づきをまとめます。 チームについて 今回のインターンではメルコインとメルカリNFTでフロントエンドエンジニアとして参加しました。それぞれ扱うプロダクトの特性が大きく異なるため、求められる視点や進め方にも違いがありました。 メルコイン 暗号資産交換業としてガバナンスやリーガルと関わりが深く、単に機能を実装するだけでなく、背景となる法律や制約を理解したうえで開発を進める必要があります。 メルコインのフロントエンドチームはお客さま対応のための社内ツールのフロントエンド開発、LP（ランディングページ） の作成などを担当しています。 メルカリNFT NFTの売買を可能にするプロダクトを持つチームで、2025年1月に提供を開始し、現在も毎週のように新機能が追加されています。 そのため、よりスピード感のある開発が求められる環境でした。 メルカリNFTのフロントエンドチームは主にメルカリNFTのフロントエンド開発を担当しています。 取り組み概要 メルコイン 社内ツールのフロントエンド改修 メルカリNFT 買取機能の実装・改善 メルカリNFTのくじをメルカリアプリ内から購入できるようにするための対応 リリース後のメモリ監視 その他 Web3領域のドメイン知識の習得 社内の多職種の方とのコミュニケーション エンジニア業務でのAI活用 ここでは太字の6つについてまとめようと思います。 社内ツールのフロントエンドの改修 背景 メルコインで進行しているプロジェクトの一部として、口座の状況、暗号通貨の配信価格など、お客さまからのお問い合わせに必要な情報を確認できる社内ツールの改修を担当し、フロントエンドの仕様整理から実装、QAチームとのテストケースの調整まで、一連の開発プロセスに関わりました。 やったこと 社内ツールの改修にあたって、 表記揺れがないか バリデーションに過不足はないか エラーハンドリングが適切か UIの整合性があるか API連携が正しいか 変更に柔軟に対応できる設計か といったポイントを確認し、後工程での手戻りが起きにくい状態まで仕様書のレビューを行いました。 その上で自分の実装スピードや改修範囲を考慮し、適切なバッファを含めて工数見積もりを行いました。 実装では、各マイクロサービス間の通信にはgRPCが使われているため、Protocol Buffersの定義からモックを作り、UIとの接続を進めると同時にCypressでのE2Eテストも作成・改修に取り組むことができました。 またQAチームとはテストケースや指摘内容を確認しながら、仕様と実装の齟齬をなくすことに努めました。 学び gRPCやProtocol Buffers、Cypressといったこれまで触れる機会の少なかった技術に取り組んだことで、フロントエンド以外の領域にも一部理解が広がりました。 あわせて、仕様書の精度をどう高めるか、どの程度のバッファを見込んで工数を組み立てるか、レビューされやすいコードにするにはどんな書き方がよいかなど、プロダクト開発全体を俯瞰する視点も身についたと感じています。 買取機能の実装・改善 背景 メルカリNFT内のGMV（流通取引総額）を伸ばすための施策として、NFTくじを購入したお客さまが買取依頼を出せる機能の追加をしました。 それに伴い、商品詳細ページに新しいUIや状態管理が必要となり、この部分の改修を担当しました。 また、このタスクがメルカリNFTのコードを触る最初の機能開発だったため、既存コードや周辺仕様のキャッチアップを素早く進める必要もありました。 やったこと 仕様書を確認し、商品詳細ページのどのタイミングで買取ボタンを表示するか、どの状態をどう見せるかといったUIの出し分けを整理しました。 その上で、実装した内容の品質を担保するためにVRT（Visual Regression Test）を活用し、Playwrightを用いたインテグレーションテストも追加・修正しました。 学び Playwrightを使ったインテグレーションテストやVRTの活用など、これまで触れる機会のなかったテスト手法を実際に使いながら理解を深められました。 また、買取前後でUIが複雑に変化する仕様だったこともあり、コンポーネントの責務をどう分けるか、保守性と可読性をどこまで両立できるか、といった設計面の学びも多かったです。 スピードが求められる環境の中でも、既存実装の調査や理解を並行して進めることの重要性を実感しました。 リリース後のメモリ監視 背景 メルカリNFTでは、サービスを安定して提供し続けるために、リリース後のリソース状況の監視や挙動の確認を継続的に行っています。 特にメモリ使用量は、トラフィックの増減や特定機能の利用状況によって変動しやすいため、定期的に観測し、必要に応じて挙動を調査する運用を行っています。 今回の取り組みでは、本番環境のメモリ使用状況をより細かく把握し、どのタイミングでどう増減しているのかを整理しながら、今後の安定した運用につなげるための調査を進めています。 やったこと まずは「いつ・どんな状況でメモリが増えるのか」を把握するために、各Podのメトリクスを確認し、傾向を調査しました。 その上で、なぜそのような増加が起こるのか仮説を立て、順に検証を進めました。 Datadogからログやメトリクスを細かく確認しつつ、他チームにも相談し、Node.jsやNext.jsの内部挙動、キャッシュやSSR周りの可能性など、さまざまな観点から情報を集めることで検証の方向性を調整しています。 学び 日々の調査の中で得られる学びは非常に多いと感じています。 Node.jsやNext.jsが内部でどのようにメモリを使うのか、CPU・GCの仕組み、キャッシュの扱いなど、技術的な理解が大きく深まりました。 同時に、進行中の問題を扱う際のコミュニケーションの取り方や調査内容のまとめ方、仮説の立て方と検証の進め方、進捗が見えにくいタスクをどうやって周囲と共有するかなど、機能開発とは異なるスキルも求められることを実感しています。 Web3領域のドメイン知識の習得 メルコインとメルカリNFTの両方に関わる中で、Web3に関する基礎知識を継続的に身につけることを意識してきました。 暗号資産やNFTの基本概念をはじめ、法規制やコンプライアンス、チェーンの仕組み、トランザクションの流れ、ウォレットの挙動など、業務に必要な知識は社内ドキュメントとして多く整理されています。 日々の開発と並行して、それらの資料を自分から探して読み、背景となるドメイン理解を深めるようにしてきました。 Web3は学ぶ範囲も広く、継続して取り組みたい領域です。 社内の多職種の方とのコミュニケーション もう一つ意識的に取り組んでいたのが、社内の多職種の方とのコミュニケーションです。 プロダクト開発では、さまざまな職種と連携しながら仕様の確定やリリースに向けた調整を進める必要があります。 そのため、日々のやり取りだけでなく、会社の施策として実施されているチービルやメンターランチの機会を活用しつつ、自分からも声をかけて1on1やランチの機会をつくるようにしていました。 チーム全体が話しかけやすい雰囲気を持っていたこともあり、積極的にコミュニケーションを取ることができました。 また、普段どのように技術をキャッチアップしているのか、どんな観点で仕様を見ているのか、なぜ今のキャリアを選んだのかといった話を聞くことで、自分の知らなかった考え方や知識に触れる機会も多くありました。 開発スキルだけでは得られない学びが多く、視野を広げるきっかけになったと感じています。 エンジニア業務でのAI活用 CursorなどのAIツールも積極的に活用し、コード全体の構造を素早く把握したり、関連部分の洗い出しを効率よく進めるようにしていました。 開発・実装では、メンターの方からのアドバイスも参考にしながら、どの情報を渡すと意図が正確に伝わるかといった点を意識するようにしました。 仕様を明確にまとめてコンテキストとしてAIに渡すことで、実装の方向性がぶれにくくなり、提案されるコードの品質も安定するようになりました。 また、AIから返ってくるコードはそのまま使うのではなく、自分の考えとの違いを確認したり、なぜその書き方になるのかを読み解くことで理解を深めるきっかけにもなりました。 結果として、実装を効率化するだけでなく、コードの設計方針を比較しながら学べる良い教材のような存在にもなっていたと思います。 まとめ 3か月を通して、メルコインとメルカリNFTのそれぞれ異なる特徴を持つプロダクトの開発に携わり、多くの学びを得ることができました。 機能実装だけでなく、仕様の詰め方、テストの考え方、多職種とのコミュニケーションなど、エンジニアとして必要なスキルを幅広く経験できた期間だったと感じています。 残りの1か月も、これまでの学びを活かしながら、より深い理解と確かなアウトプットを積み重ねていきたいと思います。 明日の記事は @Fabさんです。引き続きお楽しみください。

はじめに こんにちは、サイオステクノロジーの安藤 浩です。 前回の記事では、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 .