本ブログは 2025 年 11 月 13 日に公開された AWS Blog “ Amazon Inspector detects over 150,000 malicious packages linked to token farming campaign ” を翻訳したものです。 Amazon Inspector のセキュリティリサーチャーは、 npm レジストリにおいて、 tea.xyz トークンファーミングキャンペーンに関連する 15 万件以上のパッケージを特定し、報告しました。これはオープンソースレジストリ史上最大規模のパッケージフラッディングインシデントの 1 つです。2024 年 4 月に Sonatype のリサーチャーが報告した当初の 1.5 万件 をはるかに上回り、サプライチェーンセキュリティにおける重大な転換点となっています。リサーチチームは、高度なルールベースの検出と AI を組み合わせて、自己複製型の攻撃パターンを発見しました。この攻撃では、脅威アクターがパッケージを自動生成・公開し、ユーザーが気づかないうちに暗号通貨報酬を得ていました。これにより、最初の特定以降、このキャンペーンがいかに急激に拡大してきたかが明らかになりました。 このインシデントは、金銭的インセンティブが前例のない規模でレジストリ汚染を引き起こすという脅威の進化と、ソフトウェアサプライチェーンを守るための業界とコミュニティの連携の重要性の両方を示しています。Amazon Inspector チームは、革新的な検出手法を通じて、巧妙で従来の手法では見つけにくい新しいタイプの脅威を検出する能力を発揮しました。また、悪意あるパッケージ識別子 (MAL-ID) の割り当てと対応の調整のために Open Source Security Foundation (OpenSSF) と迅速に連携したことは、セキュリティ組織が新たな攻撃ベクトルに対して迅速かつ効果的に対応する方法のモデルを示しています。オープンソースコミュニティが成長を続ける中、このケースは、金銭的インセンティブが存在する場所には新たな脅威が出現するという警告であると同時に、協調的な防御がサプライチェーン攻撃への対処にいかに役立つかを示しています。 検出 2025 年 10 月 24 日、Amazon Inspector のセキュリティリサーチャーは、npm レジストリ内の疑わしいパッケージパターンの検出能力を強化するために、AI と組み合わせた新しい検出ルールをデプロイしました。数日以内に、システムは tea.xyz プロトコル (オープンソース開発者に報酬を与えるために設計されたブロックチェーンベースのシステム) に関連するパッケージを検出し始めました。 11 月 7 日までに、リサーチャーは数千のパッケージを検出し、組織的なキャンペーンの可能性があるとして調査を開始しました。翌日、評価結果を検証しパターンを分析した後、OpenSSF に連絡を取り、調査結果を共有して対応を調整しました。OpenSSF のレビューと合意を得て、Amazon Inspector のセキュリティリサーチャーは発見したパッケージを OpenSSF の悪意あるパッケージリポジトリ に体系的に提出し始め、各パッケージは 30 分以内に MAL-ID を受け取りました。この作業は 11 月 12 日まで続き、最終的に 15 万件以上の悪意あるパッケージが発見されました。 調査で明らかになった内容は以下のとおりです。 tea.xyz トークンファーミングキャンペーンに関連する 15 万件以上のパッケージ 有用な機能を持たないパッケージを作成する自己複製型の自動化プロセス パッケージをブロックチェーンウォレットアドレスにリンクする tea.yaml ファイルの体系的な組み込み 複数の開発者アカウントにわたる組織的なパッケージ公開 従来のマルウェアとは異なり、これらのパッケージには明らかに悪意のあるコードは含まれていません。代わりに、自動複製と依存関係チェーンを通じてパッケージメトリクスを人為的に水増しすることで tea.xyz の報酬メカニズムを悪用し、脅威アクターがオープンソースコミュニティから金銭的利益を得ることを可能にしています。 新たな攻撃ベクトルとしてのトークンファーミング このキャンペーンは、サプライチェーンセキュリティにおける懸念すべき進化を表しています。これらのパッケージは認証情報を盗んだりランサムウェアを展開したりするわけではありませんが、重大なリスクをもたらします。 レジストリ汚染: npm レジストリは低品質で機能しないパッケージで溢れ、正当なソフトウェアを見えにくくし、オープンソースコミュニティへの信頼を低下させます リソースの悪用: レジストリのインフラストラクチャ、ネットワーク帯域、ストレージが、金銭的利益のためだけに作成されたパッケージによって消費されます 悪用の前例: このキャンペーンの成功は、他の報酬ベースのシステムでも同様の悪用を促し、金銭的利益のための自動パッケージ生成を常態化させる可能性があります サプライチェーンリスク: 無害に見えるパッケージでも不要な依存関係を追加し、予期しない動作を引き起こしたり、依存関係の解決に混乱を生じさせる可能性があります OpenSSF との連携: 迅速な対応 Amazon Inspector のセキュリティリサーチャーと OpenSSF の連携により、迅速な対応と以下のようなメリットがもたらされました。 脅威インテリジェンスの即時共有: リサーチャーの調査結果は OpenSSF の悪意あるパッケージリポジトリと共有され、コミュニティに包括的な脅威データが提供されました MAL-ID の割り当て: OpenSSF は検出されたパッケージに MAL-ID を迅速に割り当て、コミュニティ全体でのブロックと修復を可能にしました。割り当ての平均時間は 30 分でした 協調的開示: 両組織は協力して、より広いオープンソースコミュニティに脅威について通知しました 検出基準の強化: このキャンペーンからの知見は、オープンソースセキュリティコミュニティ全体での検出能力の向上とポリシー推奨に活用されています この連携は、業界のリーダーとコミュニティ組織がソフトウェアサプライチェーンの保護にどのように協力できるかを示す好例です。MAL-ID の迅速な割り当ては、オープンソースレジストリの整合性を維持するという OpenSSF のコミットメントを示しています。また、リサーチャーの検出作業と脅威インテリジェンスは、進化する攻撃パターンに先んじるために必要な高度な知見を提供しています。 技術的詳細: リサーチャーがキャンペーンを検出した方法 Amazon Inspector のセキュリティリサーチャーは、ルールベースの検出と AI を活用した技術を組み合わせて、このキャンペーンを発見しました。リサーチャーは、以下のような疑わしい特徴を特定するためのパターンマッチングルールを開発しました。 tea.yaml 設定ファイルの存在 オリジナルの機能を持たない最小限またはクローンされたコード 予測可能な命名パターンと自動生成のシグネチャ 関連パッケージ間の循環依存関係チェーン 公開パターンを監視することで、リサーチャーは自動化ツールを使って高速にパッケージを作成する組織的なキャンペーンを明らかにしました。 脅威への対応方法 お客様の環境でこのような脅威を検出し対処するには、標準的なインシデント対応プロセスに従ってください。 開発環境をスキャンするには、以下の手順を推奨します。 Amazon Inspector の使用: tea.xyz トークンファーミングに関連するパッケージの 検出結果 を確認し、推奨される修復手順に従ってください パッケージの監査: 低品質で機能しないパッケージを削除してください サプライチェーンの強化: ソフトウェア部品表 (SBOM) を適用し、パッケージバージョンを固定し、CI/CD 環境を分離してください この投稿についてご質問がある場合は、 Amazon Inspector タグ付きの AWS re:Post にコメントを追加するか、 AWS サポート にお問い合わせください。 Chi Tran Chi は Amazon Web Services のシニアセキュリティリサーチャーで、オープンソースソフトウェアサプライチェーンセキュリティを専門としています。オープンソースソフトウェア内の悪意あるパッケージを検出する Amazon Inspector のエンジンの研究開発をリードしています。Amazon Inspector の SME として、複雑なセキュリティ実装や高度なユースケースについてお客様に技術的なガイダンスを提供しています。専門分野はクラウドセキュリティ、脆弱性リサーチ、アプリケーションセキュリティです。OSCP、OSCE、OSWE、GPEN などの業界認定資格を保有し、複数の CVE を発見し、オープンソースセキュリティイノベーションに関する特許を出願中です。 Charlie Bacon Charlie は AWS の Amazon Inspector セキュリティエンジニアリングおよびリサーチ責任者です。Amazon Inspector やその他の Amazon Security 脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスのチームをリードしています。AWS 入社前は、金融およびセキュリティ業界で 20 年間にわたり、リサーチと製品開発の両方でシニアロールを務めました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

分散型金融 (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 とのパートナーシップの構築にも取り組んでいます。

本記事は、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 上で分散型ウェブおよび台帳技術のワークロードを実行できるよう支援しています。