ブロックチェーンの基本概念であるブロック、チェーン、ハッシュ値、Proof of Work(PoW)、ナンスについて解説します。Pythonによる簡易的な実装例を通して、ブロックチェーンが改ざんに強い理由を理解することができます。

本ブログは 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 とのパートナーシップの構築にも取り組んでいます。