--- title: "ブロックチェーンデータ徹底解説" description: "ブロックチェーンデータがweb3インフラとアプリケーション全体でどのように生成、保存、アクセス、利用されるかを学びます。" --- # ブロックチェーンデータ徹底解説 各ブロックチェーンは、トランザクションとイベントの不変の記録を保持しています。Web3アプリケーションは、アラート、ダッシュボード、意思決定、新機能の開発のためにブロックチェーンデータに依存しています。これは分散型アプリケーションからインフラストラクチャ、NFTに至るまであらゆるものを支えているため、web3にとって極めて重要です。 このガイドでは、オンチェーンデータとオフチェーンデータから、ブロックチェーンインデックスとsubgraphまで、ブロックチェーンデータのあらゆる側面を取り上げます。このガイドを読み終える頃には、ブロックチェーンデータがどのように作成、保存、アクセスされるかについて、より深い理解が得られているはずです。 ## **オンチェーンデータとは何か** オンチェーンデータとは、単純にブロックチェーンネットワーク上に保存されているすべての情報のことです。これはネットワーク上でこれまでに発生したすべてのトランザクションの不変の記録であり、誰でも公開で閲覧できます。オンチェーンデータには次のようなさまざまな種類があります。 - **トランザクションデータ:** ブロックチェーン上の各トランザクションに関する情報、例えば送信者と受信者、転送額、トランザクション手数料などを扱います。 - ブロックデータ: ブロックチェーン上の各ブロックに関する情報、例えば前のブロックのハッシュ、そのブロックに含まれるトランザクション、ブロックのタイムスタンプ、さらにマイナー手数料と報酬などを扱います。 - **スマートコントラクトデータ:** ブロックチェーン上にデプロイされたすべてのスマートコントラクトに関する情報、例えばコントラクトコード自体、コントラクトの状態、コントラクトが発行するイベントなどを扱います。 オフチェーンデータとは異なり、オンチェーンデータは変更できません。これはブロックチェーンネットワークの全体像を把握する上で重要な点です。このデータは、ブロックチェーン上での資産の移動を追跡したり、トランザクションが正常に完了したことを検証したり、ネットワーク活動に関する知見を生み出したりするために使用できます。 オンチェーンデータの課題は、効果的にアクセスするのが煩雑になり得るという点です。データは容易に入手できるものの、オンチェーンデータは機械可読な形式でエンコードされており、これはセキュリティを優先する一方で人間可読性を犠牲にしています。人間可読な形式にはJSONやXMLのような種類がありますが、ここでABI(application binary interface、アプリケーションバイナリインターフェース)が登場します。 ### **データ構造はどのように定義されるか** 前述の通り、オンチェーンデータは通常のデータのようには保存されていません。むしろ、バイトコードのような機械可読な形式で保存されることが多いです。 ABI(application binary interface)は、開発者がデータを監視し、人間可読な形式にデコードするのに役立ちます。スマートコントラクトにおけるデータ構造はABIを使って定義されます。ABIは関数セレクタとして機能し、スマートコントラクトとどのように相互作用するか、また各関数が受け取り返すデータ型を定義するのに役立ちます。言い換えれば、人間にも機械にも容易に理解できる方法でデータ構造を表現するための標準的な方法です。 ### **ブロックチェーンデータはどこに保存されるか** ブロックチェーンデータは一般的に分散台帳に保存されます。つまり単一の場所に保存されているのではなく、ノードのネットワーク上に保存されているということです。ノードはブロックチェーンデータの保存とセキュリティ確保の基本的な構成要素であり、各ノードがデータのコピーを保持しています。以下に、いくつかの異なる種類のノードと、それらが大まかにどのように機能するかを示します。 - フルノード: その名の通り、フルノードはブロックチェーンの全履歴に加えて、ネットワークの最新状態(直近128ブロック)を保存します。この最新状態は、すべてのクライアントが受信トランザクションを検証するために必要とするものです。理論上、以前のすべての状態はフルノードから導出可能ですが、これには相当な計算能力が必要です。開発者は、ブロックチェーンの最新のデータと状態にアクセスする必要がある場合にフルノードへクエリを行うべきです。参考までに、Ethereumでは新しいブロックが生成される平均時間は約13秒であり、取得できるチェーン状態は直近28〜29分のものに限られます。 - アーカイブノード: 完全なブロックチェーン履歴に加えて、[アーカイブノードは各ブロックの過去の状態の記録も保持します](https://www.alchemy.com/overviews/archive-nodes)。これにより、アーカイブノードはフルノードと比較して、過去のデータに対するリクエストをはるかに効率的に処理できます。アーカイブノードはフルノードのように状態の再生成を必要としないため、開発者は過去のデータが必要な場合にアーカイブノードへクエリを行うべきです。分析ツールやその他、高速な履歴アクセスを必要とするツールを作成する開発者にとって、アーカイブノードは理想的です。 - ライトノード: これらのノードはブロックヘッダーのみを保存するノードであり、ネットワーク上でトランザクションを行うために必要な最小限のデータです。開発者はブロックヘッダーから基本的なブロックチェーンデータを取得する際に、ライトノードへクエリを行うことを選択する場合があります。 ノードだけがデータを保存する方法ではありません。データはオフチェーンで、データベース、クラウドストレージサービス、あるいはオンプレミスのサーバーに保存することもできます。データをオフチェーンに保存することはオンチェーンほど安全ではないかもしれませんが、コストが低く、アクセスも高速であるため、多くのアプリケーションにとって依然として有用です。データがオフチェーンに保存される場合、通常はオフチェーンデータの所在を特定するために必要な情報のみがブロックチェーン上に保存されます。 ### スマートコントラクトとブロックチェーンストレージ スマートコントラクトはノード内のブロックチェーン上に保存されていますが、スマートコントラクト自体にもデータ保存のための仕組みがあります。スマートコントラクト内のデータは、コントラクトストレージレイアウトと呼ばれるものに保存されます。[コントラクトストレージレイアウトとは、コントラクトのストレージ変数が長期メモリ内でどのように配置されるかを規定するルールを指します](https://www.alchemy.com/docs/smart-contract-storage-layout)。 [Solidity](https://www.alchemy.com/overviews/solidity)(スマートコントラクトを構築するための高水準プログラミング言語)の場合、EVMに変数をどこに保存すべきかを指示できる3種類のメモリがあります: memory、calldata、storageです。 Memory: 関数の実行中に必要となる一時的なデータを保存するために使用されます Calldata: 関数の引数を含む特殊なデータ位置です Storage: データがブロックチェーン上に永続的に保存される場所です ### **データストレージとファイルストレージの違い** データストレージは、その最も単純な形態では、後で取得して使用できるようにデータを保存するプロセスです。一方ファイルストレージは、実際のファイルがファイルに関するメタデータとは異なる場所に保存される場合、データストレージとは別のものです。この分離は通常、パフォーマンスの向上、コストの削減、セキュリティの向上を目的として行われます。 ファイルストレージをデータストレージから分離する一般的な方法は、IPFSやArweaveのような分散型ファイルストレージシステムを使用することです。これらのシステムでは、ユーザーが分散されたコンピュータのネットワーク上にファイルを保存できるようになり、ブロックチェーン自体に保存する必要のあるデータ量を減らすことで費用対効果を高めることができます。 大まかに言うと、ファイルに関するメタデータはオンチェーンに保存され、ファイル自体はオフチェーンに保存されます。アプリケーションがファイルにアクセスする必要がある場合、メタデータからIPFSまたはArweaveのURLを取得できます。その後、アプリケーションはこのURLを使ってIPFSまたはArweaveからファイルをダウンロードできます。 #### **IPFSとは何か** IPFSはコンテンツアドレス方式のシステムを使用しており、各ファイルはCID(content identifier、コンテンツ識別子)に基づいて識別されます。CIDは一意のハッシュであり、保存場所に関わらず常に同じファイルを指し示します。 これは、ファイルが変更または更新されると、ハッシュも変わることを意味します。このコンテンツアドレス方式により、ファイルは位置ではなくCIDに基づいて保存・取得することができます。 IPFSの動作の一般的な流れは以下の通りです。 1. ファイルに対してCIDが作成される 1. ファイルがIPFSネットワークにアップロードされる 1. IPFSは、そのCIDに関連付けられたファイルをネットワーク内のどのノードが保持しているかについての情報を、DHT(distributed hash table、分散ハッシュテーブル)に保存する 1. ハッシュを使ってDHTにクエリを行い、そのファイルを保存しているノードを見つけることができる 1. CIDはトークンスマートコントラクト内に保存される #### **Arweave** Arweaveは、コンテンツの保存とアクセス、およびメタデータ内でのコンテンツ参照にCIDを使用する、もう一つの分散型ストレージソリューションです。主な違いは、Arweaveがノードにデータを永続的に保持するインセンティブを与えることで、インセンティブと永続性に対して異なるアプローチを取っている点です。 ### **データパブリッシングとデータストレージとデータアベイラビリティの違い** ブロックチェーンデータをより良く理解するためには、データパブリッシング、ストレージ、アベイラビリティが何を意味するかも理解する必要があります。これらの用語を簡潔に定義すると、**データパブリッシング**はブロックチェーン上で他者がデータにアクセスできるようにするプロセスであり、**データストレージ**はブロックチェーン上にデータを保持するプロセスであり、**データアベイラビリティ**はブロックチェーンネットワーク上のすべての参加者がデータにアクセスできることの保証です。 データアベイラビリティが重要なのは、バリデータがEthereumブロックチェーンにブロックを追加する際、そのブロックのすべてのトランザクションデータをネットワーク上の他のバリデータにブロードキャストしなければならないためです。バリデータはすべてのトランザクションデータを実行する任務を負っており、これはブロックチェーンがバリデータの実行能力に応じた数のトランザクションしか処理できないことを意味します。これが、要約するとデータアベイラビリティ問題です。 データアベイラビリティに関する中核的な問題の一つは、ブロック全体にアクセスすることなく(データパブリッシング)、あるブロックが公開されたかどうかを知ることです。 データパブリッシングにおける主な課題は、ブロックプロデューサーが未知の内容を含むブロックの上に新たなブロックを生成しないという点です。これは、公開されていないデータを含むブロックが完全に無視される可能性があることを意味します。データが公開されると、そこでデータストレージの問題が生じますが、そのデータがフルノードによってどれくらいの期間保存されるかは不明確です。ノードにデータの保持を強制することはできないため、これはデータアベイラビリティへの懸念をさらに高めるものであり、懸念すべき点です。 #### モジュラーブロックチェーンと代替データアベイラビリティ モジュラーブロックチェーンとは、特定の機能に取り組むブロックチェーンです。例えば、あるモジュラーブロックチェーンはデータアベイラビリティに焦点を当て、実行やコンセンサスといった他のタスクは他のブロックチェーンやシステムに依存する場合があります。 モジュラーブロックチェーンは、オフチェーンデータストレージ、データ圧縮、シャーディングなど、さまざまな手法を用いることで、calldataの公開をEthereumに投稿するよりも安価にする代替データアベイラビリティレイヤーを構築しています。 代替データアベイラビリティレイヤーを使用するモジュラーブロックチェーンの一例がEigenDAです。EigenDAはArweaveの上に構築された分散型データアベイラビリティレイヤーです。EigenDAは、ユーザーがcalldataをArweaveに公開し、そのcalldataが公開されたことをEthereumに証明できるようにします。これにより、ユーザーはオンチェーンでcalldataを保存することに伴う高額なガス料金を支払うことなく、calldataをEthereumに公開できます。 ### **オンチェーンデータの種類** オンチェーンデータとは何かを説明したところで、次はオンチェーンデータのさまざまな種類と、それらがどのように生成、保存、アクセスされるかについてより詳しく見ていきます。 #### **トランザクションデータとは何か** トランザクションデータには、ブロックチェーン上のトランザクションに関するすべての情報、例えば以下が含まれます。 - 送信者 - 受信者 - 転送額 - トランザクション手数料 - トランザクションのタイムスタンプ このデータは、ユーザーがブロックチェーン上でトランザクションを行うたびに生成されます。その後、トランザクションを検証し台帳に追加するために、ネットワークノードにブロードキャストされます。 トランザクションデータは、Merkleツリーと呼ばれる木構造のデータ構造によって保存・検証することができます。Merkleツリーは高速なデータ検証を可能にする二分木で、ツリー内の各ノードはそれが含むデータのハッシュです。Merkleツリー内のデータの整合性を検証するには、そのツリーのルートハッシュさえあれば十分です。データをMerkleツリーに保存することは、ブロックチェーンのサイズをできるだけ小さく保つ上で役立ちます。Merkleツリーについてはさらに詳細な内容があるため、[Alchemyのドキュメントでより詳しく](https://www.alchemy.com/docs/merkle-trees-in-blockchains)読むことができます。特にEthereumでは、データは[Patricia Merkle Trie](https://www.alchemy.com/docs/patricia-merkle-tries)を使って保存されています。これはradix trie(Patricia trie)とMerkleツリーを組み合わせたものです。 トランザクションデータに素早くアクセスするには、Ethereumのトランザクションであれば[Etherscan](https://www.alchemy.com/dapps/etherscan)のようなブロックチェーンエクスプローラーを単に使用することができます。ブロックチェーンエクスプローラーを使うと、ユーザーはすべてのトランザクションデータを閲覧・検索でき、トークンの移動の追跡、不正なトランザクションの特定、ブロックチェーンアプリケーションの開発などに利用できます。特定のトランザクションに関するデータを見つけるには、トランザクションハッシュが必要です。アプリケーションのためにブロックチェーンデータへ定期的にアクセスする必要がある場合は、Alchemyが役立ちます。 #### **メタデータ** メタデータとは、ブロックチェーン上のトランザクションや資産に関する追加情報を提供するデータです。これには次のような追加詳細が含まれる場合があります。 - 資産の名前またはシンボル - 資産の総供給量 - 資産の所有履歴 - 資産のコントラクトアドレス トランザクションデータとは異なり、メタデータはブロックチェーンの運用に必須ではありませんが、ブロックエクスプローラー、ウォレット、ダッシュボードなど、開発者がアプリケーションを作成する際に有用です。メタデータは、スマートコントラクトやブロックチェーンによって定義される形で自動的に生成される場合(例: トランザクションメタデータ)もあれば、ユーザーによって手動で定義される場合(例: 資産メタデータ)もあります。 メタデータにアクセスするために、開発者は**getMetadata**クエリを使用できます。これらのクエリを使用するには、開発者は[Alchemy API](https://www.alchemy.com/docs/reference/nft-api-quickstart)のようなブロックチェーンAPIを使用する必要があります。**getMetadata**クエリを使用することで、開発者はユーザーがブロックチェーンネットワークを理解し相互作用するのに役立つさまざまなアプリケーションを構築できます。 #### **イベントデータ** イベントデータとは、スマートコントラクトがトランザクションを実行する際に発行するデータのことです。このデータには次のような情報が含まれる場合があります。 - 発生したイベントの種類 - イベントを発行したスマートコントラクトのアドレス - イベントの詳細(例: 転送されたトークンの量、資産の新しい所有者など) この情報は、開発者がスマートコントラクトの活動を監視するのに役立ち、ログを通じてアクセスできます。ログとは、ブロックチェーン上で発生したすべてのイベントの記録であり、スマートコントラクトによって生成されます。これらのログはトランザクションレシートに記載されており、[eth_getLogs](https://www.alchemy.com/docs/deep-dive-into-eth_getlogs)にリクエストを送ることで閲覧できます。 #### **Calldata** Calldataとは、関数が呼び出される際にスマートコントラクトへ渡されるデータです。言い換えれば、外部の呼び出し元からの関数引数がスマートコントラクトに渡される前に保存される、一時的なデータストレージの一形態です。Calldataには、整数、文字列、配列など、あらゆる種類のデータを含めることができます。これはスマートコントラクト同士やユーザーとの間の通信を可能にするため重要であり、例えばNFTスマートコントラクトにおいて、NFTの所有権をユーザーに転送する際にcalldataが使用されることがあります。 ブロックチェーン上のすべての操作にはガス料金が課され、calldataの使用も例外ではありません。L2トランザクションがEthereumに投稿される際、calldataがそのトランザクションに含まれます。これは、Ethereumネットワークがトランザクションを検証し、呼び出されているスマートコントラクト関数を実行するためにcalldataが必要だからです。calldataによって消費されるガスは、calldataのサイズとcalldataに含まれるデータの種類によって決まります。Ethereumでは、1ブロックが含むことのできる最大calldataは[1,048,576バイト](https://eips.ethereum.org/EIPS/eip-4488)です。 #### **Blob** Blob(binary large object)は、あるブロックに添付されたblobが正しいデータを保持していることをネットワークに確認させることで、トランザクション検証をより効率的にするために設計されています。Blobは、calldataのコストを削減しブロックあたりのcalldataサイズを増やすための提案である[proto-danksharding](https://www.alchemy.com/overviews/danksharding)との関連で導入されました。 Proto-dankshardingは、blob-carrying transaction(blobを運ぶトランザクション)と呼ばれる新しい種類のトランザクションを導入することで、ブロックチェーンにおけるcalldataを安価にするとされています。Blob-carrying transactionは通常のトランザクションと似ていますが、データblobを含めることができます。 Blob-carrying transactionは通常のトランザクションよりも安価です。これは、処理に必要なガスがそれほど多くないためです。これはデータblobがオフチェーンに保存され、トランザクションに含める必要がないためです。 データblobとblob-carrying transactionの導入により、Ethereumブロックチェーン上で大量のデータをより安価に保存・処理することが可能になります。 ## **ブロックチェーンインデックスとは何か** 本の索引には、キーワードやアイデアが言及されているページ番号が記載されています。同様に、ブロックチェーンインデックスとは、ブロックチェーンデータを検索・クエリしやすい形で整理・保存するプロセスです。これはブロックチェーンデータを扱う上で理解しておくべき重要な点です。なぜなら、これによりユーザーはより効率的かつ効果的な方法でデータにアクセスし分析することができるからです。 ブロックチェーンは時系列順の構造に従っているため、データは多数のブロックにまたがって散在し、絡み合った状態になり得ます。インデックスは、ブロックチェーン*データ*のインデックスを作成することでこの問題を解決することを目指します。 このインデックスはデータベースであり、検索・クエリのために最適化された形式でブロックチェーンデータのサブセットを保存します。データをインデックス化するには、トランザクション関連情報のインデックス化、アドレスのインデックス化、スマートコントラクトの相互作用のインデックス化など、さまざまなインデックス化手法があります。インデックス化されたデータは、GraphQL、Alchemy、その他のweb3プロトコルが提供するAPIを通じて開発者がアクセスできます。 ### **一般的なインデックスのユースケース** ブロックチェーンインデックスが、開発者がより効率的にデータを検索・クエリするためにいかに有用であるかがわかったところで、インデックスの一般的なユースケースをいくつか見てみましょう。 **トランザクション履歴のインデックス化** - [Uniswap](https://www.alchemy.com/dapps/uniswap)プールのような取引量や流動性を追跡したり、最大のトレーダーやクジラを特定したりするために使用できます。 **分析・レポート作成のためのインデックス化** - トランザクション量、ガス料金、ユーザー活動などのさまざまな指標に関するレポートを生成するために使用できます。特定のスマートコントラクト、暗号資産、市場動向のパフォーマンスを追跡・分析する際や、ユーザー活動(例: アクティブなウォレット数、処理されたトランザクション数など)を理解する際に特に役立ちます。 **メタデータのインデックス化** - NFTの所有権と転送を追跡するために使用できます。実用的な例としては、特定のNFTコレクションのトランザクションインデックスに対してクエリを行い、購入・所有履歴やその他の関連詳細を把握できるNFT分析ツールが挙げられます。 **スマートコントラクトイベントのインデックス化** - トークンの移動(例: 特定のERC-20トークンの転送イベント)、貸し借りの活動を追跡したり、[NFT市場](https://www.alchemy.com/dapps/best/nft-marketplaces)をより良く理解したりするために使用できます。これらはほんの一例に過ぎません。全体として、スマートコントラクトイベントのインデックス化は、スマートコントラクトの活動を監視するのに役立ち、これは脆弱性の特定や新しいアプリケーション・サービスの機会の発見に役立ちます。 #### **オフチェーンインデックスとオンチェーンインデックス** インデックスはオンチェーンにもオフチェーンにも保存でき、それぞれに独自の利点とトレードオフがあります。例えばSatsumaは、Alchemyが買収したオンチェーンインデックスプロトコルです。Satsumaは、APIのためのクエリ言語である[GraphQL](https://www.alchemy.com/dapps/graphql)を使用し、ネットワークブロックとスマートコントラクトをスキャンするsubgraphを使うことで、単一のAPI呼び出しでさまざまなソースからデータを収集する仕組みを持っています。オフチェーンインデックスプロトコルは、ノードのローカルストレージにインデックスを保存する(例: SubQuery)か、AWSのような従来型のクラウドサーバーに保存することで機能し、これはオンチェーンインデックスよりも高速な場合があります。オフチェーン・オンチェーンどちらのインデックスプロトコルを使う場合でも、開発者は容易にクエリ言語を使用できます。 - **GraphQL** - 開発者はGraphQLを使って、特定のERC20トークンの転送履歴をsubgraphにクエリすることができます。 - SQL - 開発者はSQLを使って、特定のブロックチェーン上にデプロイされたすべてのスマートコントラクトのリストをオフチェーンインデックスにクエリすることができます。 - Elasticsearch - 開発者はElasticsearchを使って、特定のブロックチェーン上で最も人気のあるNFTをオフチェーンインデックスにクエリすることができます。 ## **ブロックチェーンデータはどのようにアクセスされるか** オンチェーンデータとその保存方法について学んだところで、開発者が実際にどのようにブロックチェーンデータへアクセスできるのかについて、さらに詳しく掘り下げてみましょう。 ### **ノードへのクエリ** ブロックチェーンデータへアクセスする最も直接的な方法の一つはノードへクエリを行うことですが、これは最もリソースを消費する方法でもあり得ます。 ノードへクエリを行うには、フルノードまたはアーカイブノード(前述の通りブロックチェーンの完全なコピーを含むノード)を介してデータにアクセスするためにJSON-RPCを使用する必要があります。JSON-RPCを使ってノードへクエリを行うには、開発者は呼び出したいメソッド、そのメソッドのパラメータ、JSON-RPCのバージョンを含むJSONオブジェクトをノードに送信する必要があります。 これは、ノードへのクエリに使用できるJSON-RPC APIを提供するAlchemyのようなソリューションを通じて容易に行うことができます。 イベントフィルタは、特定のブロックチェーンイベントについてノードへクエリを行う際にも有用です。イベントフィルタを使用するには、フィルタリングしたいイベントの種類とそのイベントのパラメータを指定する必要があります。イベントフィルタを使う簡単な方法は、[AlchemyのNode API](https://www.alchemy.com/supernode)を利用することです。AlchemyのNode APIは、ノードを稼働させるためのすべてのインフラストラクチャに加え、ノードとの相互作用やクエリを容易にするAPIとSDKを含む、フルマネージドサービスです。 ### **webhookによるデータストリーミング** webhookによるデータストリーミングは、ブロックチェーンデータに関するリアルタイムの更新を受け取る方法です。イベントデータは、カスタムwebhookとwebhook変数を使ってストリーミングすることができます。これは、Alchemyのようなブロックチェーンインデックスサービスを選び、サーバー上にwebhookエンドポイントを作成し、イベントを購読し、webhook変数を設定することで行います。特にAlchemyでは、新規トランザクション、新規スマートコントラクトのデプロイ、スマートコントラクトの状態変化など、さまざまなブロックチェーンイベントによってトリガーされる[カスタムwebhook](https://www.alchemy.com/docs/reference/custom-webhook-variables)を作成できます。Alchemyは最近、開発者がより高い精度でデータストリームを絞り込み、変数を使ってwebhookクエリを容易に更新できるように、[カスタムwebhookをアップグレード](https://www.alchemy.com/blog/custom-webhooks-variables-filters-block-freshness)しました。 ### **Subgraphへのクエリ** Subgraphは、コミュニティによって作成されるオープンソースのAPIであり、Indexer、Curator、Delegatorからブロックチェーンデータを取得するために使用されます。Subgraphは GraphQLを使って構築されているため、開発者はGraphQL APIを使ってsubgraphへクエリを行うことができます。Subgraphはホスト型でも自己ホスト型でもかまいません。ホスト型のsubgraphは、GraphQL APIのURLにGraphQLクエリを送信することでクエリできます。自己ホスト型のsubgraphは、subgraphをGraphQLサーバーにデプロイすることでクエリできます。これは、開発者が自分自身のsubgraphをデプロイできるSatsumaのようなソリューションを通じて行うことができます。 ### **データウェアハウスへのクエリ** データウェアハウスは、通常は構造化された形式で過去のデータをクエリするために最適化されています。一方データレイクは、通常は非構造化または半構造化された大量のデータを保存します。[Dune Analytics](https://www.alchemy.com/dapps/dune-analytics)は、データレイクからデータをクエリ、抽出、可視化するために使用できるツールです。Duneは、さまざまなチェーン、データセット、生のブロックチェーンデータなどを探索できるデータセットエクスプローラーなどのツールを提供することでこれを実現しています。また、データベースをバックフィルし、カスタムwebhookでデータをストリーミングすることで、自分自身のデータレイクを作成することもできます。 ## **結論** まとめると、ブロックチェーンデータを理解することは、web3インフラストラクチャやアプリケーションを利用または構築しようとするあらゆる開発者にとって有用です。オンチェーンデータはブロックチェーン上に保存され、トランザクションデータ、メタデータ、イベントデータ、calldata、blobといったさまざまな種類に分類できます。このデータはノードに保存され、それぞれのユースケースに応じたさまざまな方法でアクセスすることができます。