ブロックチェーンデータ徹底解説

各ブロックチェーンは、トランザクションとイベントの不変の記録を保持しています。Web3アプリケーションは、アラート、ダッシュボード、意思決定、新機能の開発などにブロックチェーンデータを利用しています。分散型アプリケーションからインフラストラクチャ、NFTまで、あらゆるものを支えているという点で、これはWeb3にとって極めて重要です。

このガイドでは、オンチェーンデータとオフチェーンデータから、ブロックチェーンのインデックス作成やsubgraphまで、ブロックチェーンデータのあらゆる側面を取り上げます。このガイドを読み終える頃には、ブロックチェーンデータがどのように生成され、保存され、アクセスされるのかについて、より深い理解が得られるはずです。

オンチェーンデータとは?

オンチェーンデータとは、単純にブロックチェーンネットワーク上に保存されているすべての情報のことです。これはそのネットワーク上で発生したすべてのトランザクションの不変の記録であり、誰でも公開で閲覧できます。オンチェーンデータにはさまざまな種類があります。例えば:

• トランザクションデータ: ブロックチェーン上の各トランザクションに関する情報で、送信者と受信者、送金額、トランザクション手数料などが含まれます。
• ブロックデータ: ブロックチェーン上の各ブロックに関する情報で、前のブロックのハッシュ、ブロックに含まれるトランザクション、ブロックのタイムスタンプ、マイナー手数料や報酬などが含まれます。
• スマートコントラクトデータ: ブロックチェーン上にデプロイされたすべてのスマートコントラクトに関する情報で、コントラクトコード自体、コントラクトの状態、コントラクトが発行するイベントなどが含まれます。

オフチェーンデータと異なり、オンチェーンデータは改変できません。これはブロックチェーンネットワークの全体像を把握する上で重要な特性です。このデータは、ブロックチェーン上での資産の移動を追跡したり、トランザクションが正常に処理されたことを検証したり、ネットワークの活動状況についての知見を得たりするために使用できます。

オンチェーンデータの課題は、それに効果的にアクセスするのが煩雑になりがちなことです。データ自体は容易に入手できる一方で、オンチェーンデータは機械可読な形式でエンコードされています。これはセキュリティを優先する一方で、人間にとっての可読性を犠牲にするものです。人間可読な形式にはJSONやXMLなどがありますが、ここでABI(application binary interface)が重要な役割を果たします。

データ構造はどのように定義されるのか?

前述の通り、オンチェーンデータは通常のデータとは異なる方法で保存されています。多くの場合、バイトコードのような機械可読な形式で保存されています。

ABI(application binary interface)は、開発者がデータを監視し、人間可読な形式にデコードするのに役立ちます。スマートコントラクトにおけるデータ構造はABIを使って定義されます。ABIは関数セレクタとして機能し、スマートコントラクトとどのように相互作用するか、また各関数が受け取り返すデータ型を定義するのに役立ちます。言い換えれば、ABIは人間と機械の双方が容易に理解できる形でデータ構造を表現するための標準的な方法です。

ブロックチェーンデータはどこに保存されるのか?

ブロックチェーンデータは一般的に分散台帳に保存されます。つまり、単一の場所ではなく、ノードのネットワーク上に保存されます。ノードはブロックチェーンデータの保存とセキュリティ確保の基本的な構成要素であり、各ノードがデータのコピーを保持しています。以下に、いくつかのノードの種類と、それらが高レベルでどのように機能するかを示します。

• フルノード: 名前が示す通り、フルノードはブロックチェーンの全履歴に加えて、ネットワークの最新状態(最新の128ブロック)を保存します。すべてのクライアントが着信トランザクションを検証するために必要となるのは、この最新状態です。理論上はすべての過去の状態をフルノードから導出することは可能ですが、これには相当な計算能力が必要です。開発者はブロックチェーンの最新のデータと状態にアクセスする必要がある場合、フルノードに対してクエリを実行すべきです。参考までに、Ethereumでは新しいブロックが生成される平均時間は約13秒であり、直近28〜29分のチェーン状態しか取得できません。
• アーカイブノード: 完全なブロックチェーン履歴に加えて、アーカイブノードは各ブロックの過去の状態の記録も保持します。これにより、アーカイブノードはフルノードと比較して、過去のデータへのリクエストをはるかに効率的に処理できます。開発者は過去のデータが必要な場合、アーカイブノードにクエリを実行すべきです。フルノードのように状態の再生成が不要だからです。分析ツールなど、高速な履歴アクセスを必要とするツールを構築する開発者にとって、アーカイブノードは理想的です。
• ライトノード: これらのノードはブロックヘッダーのみを保存します。つまり、ネットワーク上で取引を行うために必要な最小限のデータです。開発者はブロックヘッダーから基本的なブロックチェーンデータを取得する際、ライトノードにクエリを実行することを選択する場合があります。

ノードはデータを保存する唯一の方法ではありません。データはデータベース、クラウドストレージサービス、あるいはオンプレミスサーバーなど、オフチェーンにも保存できます。オフチェーンでのデータ保存はオンチェーンほど安全ではないかもしれませんが、コストが安く、アクセスが速いため、多くのアプリケーションにとって依然として有用です。データがオフチェーンに保存される場合、通常はオフチェーンデータの場所を特定するために必要な情報のみがブロックチェーン上に保存されます。

スマートコントラクトとブロックチェーンストレージ

スマートコントラクトはノード内のブロックチェーン上に保存されますが、スマートコントラクト自体もデータ保存のための仕組みを持っています。スマートコントラクト内のデータは、コントラクトストレージレイアウトと呼ばれる仕組みで保存されます。コントラクトストレージレイアウトとは、コントラクトのストレージ変数が長期記憶の中でどのように配置されるかを規定するルールを指します。

Solidity(スマートコントラクト構築のための高水準プログラミング言語)の場合、変数をどこに保存するかをEVMに指示できるメモリの種類は3種類あります: memory、calldata、storageです。

Memory: 関数の実行中に必要となる一時的なデータを保存するために使用されます

Calldata: 関数の引数を格納する特別なデータ位置です

Storage: データがブロックチェーン上に永続的に保存される場所です

データストレージ vs. ファイルストレージ

データストレージとは、最も単純に言えば、後で取得して使用できるようにデータを保存するプロセスです。一方ファイルストレージは、実際のファイルがファイルに関するメタデータとは異なる場所に保存される場合、データストレージとは別のものとなります。この分離は通常、パフォーマンスの向上、コストの削減、セキュリティの向上を目的として行われます。

ファイルストレージをデータストレージから分離する一般的な方法は、IPFSやArweaveのような分散型ファイルストレージシステムを使うことです。これらのシステムはユーザーが分散したコンピュータのネットワーク上にファイルを保存することを可能にし、ブロックチェーン自体に保存する必要のあるデータ量を減らすことで、コストを抑えられます。

高レベルで見ると、ファイルに関するメタデータはオンチェーンに保存され、ファイル自体はオフチェーンに保存されます。アプリケーションがファイルにアクセスする必要がある場合、メタデータからIPFSまたはArweaveのURLを取得できます。その後アプリケーションは、このURLを使ってIPFSまたはArweaveからファイルをダウンロードできます。

IPFSとは?

IPFSはコンテンツアドレス方式のシステムを使用しており、各ファイルはCID(content identifier)に基づいて識別されます。CIDはユニークなハッシュであり、ファイルがどこに保存されていても常に同じファイルを指します。

つまり、ファイルが変更または更新されると、ハッシュも変わるということです。このコンテンツアドレス方式により、ファイルは位置ではなくCIDに基づいて保存・取得できます。

IPFSの動作の一般的な流れは以下の通りです:

1. ファイルに対してCIDが作成されます
2. ファイルがIPFSネットワークにアップロードされます
3. IPFSは、そのCIDに関連付けられたファイルをネットワーク内のどのノードが保持しているかという情報を、DHT(distributed hash table)に保存します
4. そのハッシュを使ってDHTにクエリを実行することで、ファイルを保存しているノードを見つけられます
5. CIDはトークンスマートコントラクト内に保存されます

Arweave

Arweaveは、CIDを使ってコンテンツを保存・アクセスし、メタデータ内でコンテンツを参照する、もう一つの分散型ストレージソリューションです。主な違いは、Arweaveがインセンティブと永続性に対して異なるアプローチを取っており、ノードにデータを永続的に保持させるインセンティブを与えている点です。

データパブリッシング vs. データストレージ vs. データアベイラビリティ

ブロックチェーンデータをよりよく理解するためには、データパブリッシング、データストレージ、データアベイラビリティが何を意味するかも理解しておく必要があります。これらの用語を簡単に定義すると、データパブリッシングとはブロックチェーン上で他者にデータを利用可能にするプロセス、データストレージとはブロックチェーン上にデータを保持するプロセス、データアベイラビリティとはブロックチェーンネットワーク上のすべての参加者がデータにアクセスできることを保証することです。

データアベイラビリティが重要なのは、バリデータがEthereumブロックチェーンにブロックを追加する際、そのブロックのすべてのトランザクションデータをネットワーク上の他のバリデータにブロードキャストしなければならないためです。バリデータはすべてのトランザクションデータを実行する役割を担っているため、ブロックチェーンが処理できるトランザクション数は、バリデータが実行できる量に限られます。これが、データアベイラビリティ問題を端的に表したものです。

データアベイラビリティの中核的な問題の一つは、ブロック全体(データパブリッシング)にアクセスすることなく、そのブロックが公開されたかどうかを知ることです。

データパブリッシングにおける主な課題は、ブロックプロデューサーが未知の内容を含むブロックの上に新たなブロックを生成しないという点です。つまり、公開されていないデータを含むブロックは完全に無視される可能性があります。データが公開されると、そこでデータストレージの問題が浮上します。しかし、フルノードがそのデータをどれだけの期間保持し続けるかは明確ではありません。ノードにデータの保持を強制することはできないため、これは懸念すべき点であり、データアベイラビリティに関する懸念をさらに深めることになります。

モジュラーブロックチェーンと代替データアベイラビリティ

モジュラーブロックチェーンとは、特定の機能に特化して取り組むブロックチェーンのことです。例えば、あるモジュラーブロックチェーンはデータアベイラビリティに焦点を当てる一方、実行やコンセンサスといった他のタスクについては他のブロックチェーンやシステムに依存する場合があります。

モジュラーブロックチェーンは、オフチェーンデータストレージ、データ圧縮、シャーディングなど、さまざまな技術を用いることで、calldataをEthereumに投稿するよりも安く公開できる代替データアベイラビリティレイヤーを構築しています。

代替データアベイラビリティレイヤーを利用するモジュラーブロックチェーンの一例がEigenDAです。EigenDAはArweave上に構築された分散型データアベイラビリティレイヤーです。EigenDAはユーザーがcalldataをArweaveに公開し、そのcalldataが公開されたことをEthereumに対して証明することを可能にします。これにより、ユーザーはオンチェーンにcalldataを保存することに伴う高額なガス料金を支払うことなく、calldataをEthereumに公開できます。

オンチェーンデータの種類

オンチェーンデータとは何かを取り上げたところで、次はオンチェーンデータのさまざまな種類と、それらがどのように生成、保存、アクセスされるかについてさらに詳しく見ていきます。

トランザクションデータとは?

トランザクションデータには、ブロックチェーン上のトランザクションに関連するすべての情報が含まれます。例えば:

• 送信者
• 受信者
• 送金額
• トランザクション手数料
• トランザクションのタイムスタンプ

このデータは、ユーザーがブロックチェーン上でトランザクションを実行するたびに生成されます。その後、ネットワークノードにブロードキャストされ、トランザクションが検証されて台帳に追加されます。

トランザクションデータは、Merkle treeと呼ばれる種類のツリーデータ構造によって保存・検証できます。Merkle treeは高速なデータ検証を可能にする二分木であり、ツリー内の各ノードはそのノードが含むデータのハッシュとなっています。Merkle tree内のデータの整合性を検証するには、ツリーのルートハッシュさえあれば十分です。データをMerkle treeに保存することは、ブロックチェーンのサイズをできるだけ小さく保つ上で役立ちます。Merkle treeについてはさらに詳細な内容があるため、Merkle treeについての詳細はAlchemyのドキュメントをご覧ください。特にEthereumでは、データはPatricia Merkle Trieを使用して保存されます。これはradix trie(Patricia trie)とMerkle treeを組み合わせたものです。

トランザクションデータに素早くアクセスしたい場合は、EthereumのトランザクションであればEtherscanのようなブロックチェーンエクスプローラーを使うだけで済みます。ブロックチェーンエクスプローラーを使うと、ユーザーはすべてのトランザクションデータを閲覧・検索でき、トークンの移動の追跡、不正なトランザクションの特定、ブロックチェーンアプリケーションの開発など、さまざまな用途に利用できます。特定のトランザクションに関するデータを見つけるには、そのトランザクションハッシュが必要です。アプリケーションのためにブロックチェーンデータへ定期的にアクセスする必要がある場合、Alchemyが役に立ちます。

メタデータ

メタデータとは、ブロックチェーン上のトランザクションと資産について追加の情報を提供するデータです。これには例えば以下のような詳細情報が含まれます。

• 資産の名前やシンボル
• 資産の総供給量
• 資産の所有履歴
• 資産のコントラクトアドレス

トランザクションデータとは異なり、メタデータはブロックチェーンの運用に不可欠なものではありませんが、ブロックエクスプローラー、ウォレット、ダッシュボードといったアプリケーションを開発者が構築する上で有用です。メタデータは、スマートコントラクトやブロックチェーンによって定義される形で自動的に生成される場合(例: トランザクションメタデータ)と、ユーザーによって手動で定義される場合(例: 資産メタデータ)があります。

メタデータにアクセスするために、開発者はgetMetadataクエリを使用できます。これらのクエリを使用するには、開発者はAlchemy APIのようなブロックチェーンAPIを使用する必要があります。getMetadataクエリを使うことで、開発者はユーザーがブロックチェーンネットワークを理解し、それと相互作用するのに役立つさまざまなアプリケーションを構築できます。

イベントデータ

イベントデータとは、スマートコントラクトがトランザクションを実行する際に発行するデータのことです。このデータには以下のような情報が含まれます。

• 発生したイベントの種類
• イベントを発行したスマートコントラクトのアドレス
• イベントの詳細(例: 転送されたトークンの量、資産の新しい所有者など)

この情報は、開発者がスマートコントラクトの活動を監視するのに役立ち、ログを通じてアクセスできます。ログとは、ブロックチェーン上で発生したすべてのイベントの記録であり、スマートコントラクトによって生成されます。これらのログはトランザクションレシートに記載されており、eth_getLogsにリクエストを送ることで閲覧できます。

Calldata

Calldataとは、関数が呼び出される際にスマートコントラクトへ渡されるデータのことです。言い換えれば、外部呼び出し元からの関数引数がスマートコントラクトに渡される前に保存される、一時的なデータストレージの一形態です。Calldataには、整数、文字列、配列など、あらゆる種類のデータを含めることができます。Calldataは、スマートコントラクト同士やユーザーとの通信を可能にする点で重要です。例えば、NFTスマートコントラクトにおいて、NFTの所有権をユーザーに移転するためにcalldataが使われることがあります。

ブロックチェーン上のすべての操作にはガス料金が発生し、calldataの使用も例外ではありません。L2のトランザクションがEthereumに投稿される際、そのトランザクションにはcalldataが含まれます。これは、Ethereumネットワークがトランザクションを検証し、呼び出されているスマートコントラクト関数を実行するために、calldataが必要となるためです。Calldataによって消費されるガスは、calldataのサイズと、calldataに含まれるデータの種類によって決まります。Ethereumでは、各ブロックに含めることができるcalldataの最大サイズは1,048,576バイトです。

Blob

Blob(binary large object)は、ブロックに添付されたblobが正しいデータを保持していることをネットワークが確認できるようにすることで、トランザクション検証をより効率的にするために設計されています。Blobは、calldataのコストを削減し、ブロックあたりのcalldataサイズを増やすための提案であるproto-dankshardingとの関連で導入されました。

Proto-danksharding は、blob-carrying transaction と呼ばれる新しい種類のトランザクションを導入することで、ブロックチェーンにおけるcalldataを安くすると言われています。Blob-carrying transactionは通常のトランザクションと似ていますが、data blobを含むことができます。

Blob-carrying transactionは、処理に必要なガスが少なくて済むため、通常のトランザクションよりも安価です。これは、data blobがオフチェーンに保存され、トランザクションに含める必要がないためです。

Data blobとblob-carrying transactionの導入により、Ethereumブロックチェーン上で大量のデータをより安価に保存・処理することが可能になります。

ブロックチェーンのインデックス作成とは?

本の索引には、キーワードやアイデアが言及されているページ番号が記載されています。同様に、ブロックチェーンのインデックス作成とは、検索やクエリを容易にする形でブロックチェーンデータを整理し保存するプロセスのことです。これはブロックチェーンデータを扱う上で理解しておくべき重要な点です。なぜなら、これによりユーザーはより効率的かつ効果的にデータへアクセスし、分析できるようになるからです。

ブロックチェーンは時系列順の構造に従っているため、データは多数のブロックにまたがって散在し、複雑に絡み合ってしまう可能性があります。インデックス作成は、ブロックチェーンデータのインデックスを作成することで、この問題の解決を目指します。

このインデックスは、検索やクエリに最適化された形でブロックチェーンデータのサブセットを保存するデータベースです。データをインデックス化する方法には複数あり、例えばトランザクション関連情報のインデックス化、アドレスのインデックス化、スマートコントラクトの相互作用のインデックス化などがあります。インデックス化されたデータは、GraphQL、Alchemy、その他のWeb3プロトコルが提供するAPIを通じて開発者がアクセスできます。

一般的なインデックス作成のユースケース

ブロックチェーンのインデックス作成が、開発者がより効率的にデータを検索・クエリするためにいかに役立つかを理解したところで、いくつかの一般的なインデックス作成のユースケースを見ていきましょう。

トランザクション履歴のインデックス作成 - これはUniswapプールのような取引量や流動性を追跡したり、最大のトレーダーやクジラを特定したりするために利用できます。

分析・レポート作成のためのインデックス作成 - これは取引量、ガス料金、ユーザー活動といったさまざまな指標に関するレポートを生成するために使用できます。特定のスマートコントラクト、暗号資産、市場トレンドのパフォーマンスを追跡・分析したり、ユーザー活動(例: アクティブウォレット数、処理されたトランザクション数など)を理解したりする際に特に役立ちます。

メタデータのインデックス作成 - これはNFTの所有権と譲渡を追跡するために利用できます。実用的な例としては、特定のNFTコレクションのトランザクションインデックスに対してクエリを実行し、購入・所有履歴やその他の関連詳細を把握できるNFT分析ツールが挙げられます。

スマートコントラクトイベントのインデックス作成 - これはトークンの移動(例: 特定のERC-20トークンの転送イベント)、貸付・借入の活動の追跡、あるいはNFT市場をより深く理解するためなど、具体的な例として挙げられます。全体として、スマートコントラクトイベントのインデックス作成は、スマートコントラクトの活動を監視するのに役立ち、脆弱性の特定や新しいアプリケーション・サービスの機会の発見にもつながります。

オフチェーンインデックスとオンチェーンインデックス

インデックスはオンチェーンにもオフチェーンにも保存でき、それぞれに固有の利点とトレードオフがあります。例えば、Satsumaは、Alchemyに買収されたオンチェーンインデックスプロトコルです。SatsumaはGraphQL(APIのためのクエリ言語)を使用しており、ネットワークブロックとスマートコントラクトをスキャンする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です。AlchemyのNode APIは、ノードを稼働させるために必要なインフラストラクチャ全体に加え、ノードとの相互作用やクエリを容易にするAPIやSDKを含む、フルマネージド型のサービスです。

Webhookによるデータのストリーミング

Webhookによるデータのストリーミングは、ブロックチェーンデータに関するリアルタイムの更新を受け取る方法です。イベントデータは、カスタムwebhookとwebhook変数を使ってストリーミングできます。これは、Alchemyのようなブロックチェーンインデックスサービスを選択し、サーバー上にwebhookエンドポイントを作成し、イベントをサブスクライブし、webhook変数を設定することで実現します。特にAlchemyでは、新しいトランザクション、新しいスマートコントラクトのデプロイ、スマートコントラクトの状態の変化といった、さまざまなブロックチェーンイベントによってトリガーされるカスタムwebhookを作成できます。Alchemyはまた最近、カスタムwebhookをアップグレードし、開発者がより高い精度のためにデータストリームを絞り込み、変数を使ってwebhookクエリを容易に更新できるようにしました。

Subgraphへのクエリ

Subgraphは、コミュニティによって作成されるオープンソースのAPIであり、Indexer、Curator、Delegatorからブロックチェーンデータを取得するために使用されます。Subgraphは GraphQLを使って構築されているため、開発者はGraphQL APIを使ってsubgraphにクエリを実行できます。Subgraphはホスト型でも自己ホスト型でも構いません。ホスト型subgraphは、GraphQL APIのURLにGraphQLクエリを送ることでクエリを実行できます。自己ホスト型subgraphは、subgraphをGraphQLサーバーにデプロイすることでクエリを実行できます。これは、開発者が自分自身のsubgraphをデプロイできるようにするSatsumaのようなソリューションを通じて実現できます。

データウェアハウスへのクエリ

データウェアハウスは、通常は構造化された形式で過去のデータをクエリするために最適化されています。一方データレイクは、通常は非構造化または半構造化された大量のデータを保存します。Dune Analyticsは、データレイクからデータをクエリ、抽出、可視化するために使用できるツールです。Duneはデータセットエクスプローラーなどのツールを提供することでこれを実現しており、さまざまなチェーン、データセット、生のブロックチェーンデータなどを探索できます。データベースにデータをバックフィルし、カスタムwebhookを介してデータをストリーミングすることで、自分自身のデータレイクを作成することもできます。

まとめ

まとめると、ブロックチェーンデータを理解することは、Web3インフラストラクチャやアプリケーションの利用・構築を検討するすべての開発者にとって有用です。オンチェーンデータはブロックチェーン上に保存され、トランザクションデータ、メタデータ、イベントデータ、calldata、blobといった異なる種類に分けることができます。このデータはノードに保存され、それぞれのユースケースに応じてさまざまな方法でアクセスできます。