# なぜWeb3は読み取れないのか
数年前まで、ブロックチェーンのスループットをどう増やすかが業界で議論されていました。今日では多くのネットワークがすでに数万回の処理に対応でき、一部は数十万回をうたっています。しかし、データをブロックチェーンに書き込むことは、課題の半分にすぎないことが分かりました。さらに、それを見つけて、インデックス化して、検証し、アプリケーションへ届ける必要があります。
その結果、データ生成の速度が、ところによってはそれを処理するインフラ能力を上回るようになりました。ForkLogが、このようにブロックチェーンはどう変わっているのかを整理しました。
約10年前、ブロックチェーンの発展は、いわゆるスケーラビリティのトリレンマで語られていました。この考え方では、ネットワークは安全性、分散性、生産性（性能）の間で妥協を迫られます。しかし2026年になると、仮にスループット問題を部分的に解決できても、新たな課題が生まれることが明らかです。
ブロックチェーン自体にはユーザー・インターフェースがありません。この役割を担うのはさまざまなアプリケーションです。そしてそれらは、常にデータを取得し続けなければなりません。
ネットワークが速く動けば動くほど、こうした種類のデータ処理量は増えます
ユーザーの間にはよくある誤解があります。データがブロックチェーンに記録されているなら、あとは単に取得するだけだ、というものです。実際はまったく逆です。「生の」データをブロックチェーンからリアルタイムに直接読み取るのは、遅い・高い・技術的に難しいプロセスです。Web3エコシステムでは、ウォレットをdappアプリとつなぐ中間のインフラ層が広く普及しています。
たとえばウォレットアプリは、ユーザーが自分の残高を数秒のうちに見るために、RPCプロバイダー、インデクサ、分析プラットフォーム、キャッシュサーバー、専用のデータベースなどに問い合わせます。
プロセスは次のように構成されています。
実際には、多くの人気Web3アプリは追加の情報処理レイヤーを経由して動いています。たとえばブロックチェーンが1秒あたり50,000件のオペレーションを処理したとして、何百万ものウォレットが画面を更新するために同時にRPCリクエストを送るとしましょう。プロバイダーのサーバーでは、その負荷に耐えられません。ユーザーのためにデータを読み、インデックス化し、ソートすることは、非常に複雑な計算タスクです。インデクサやデータアクセスサービスは、処理・構造化・配送に追加時間が必要なため、ネットワークの最新状態から数ブロック遅れることがよくあります。問題は「古いインフラ」に限りませんが、もちろんそうした面もあります。より深いのは、Web2とWeb3のアーキテクチャ間にある衝突です。
ユーザーとアプリは、いつものインターネットと同じくらい、また頻繁にブロックチェーンとやり取りします。たとえばSNSのタイムラインをスクロールすると、アプリはいいね、コメント、画像を更新するためにサーバーへ1秒あたり何千回ものリクエストを行います。Web2のトレーディングボットは、1分あたり何百万回も取引所サーバーへ問い合わせることがあります。GoogleやAmazonのサーバーがそれを難なく受け止められるのは、集中型で、データがざっくり言えば世界中の何千台ものミラーサーバーへ即座にコピーできる「巨大な1つのデータベース」に置かれているからです。
しかしブロックチェーンは別物で、そうした形にはハードウェア的に対応していません。つい最近まで、その速度の最大の障害は数学と暗号でした。世界中の何千台ものコンピュータを、取引が正しいこと（コンセンサス）について素早く合意させる必要がありました。開発者たちはこの問題を、「並列実行」できるように機械を「学習」させ、コンセンサスと実行を分離しました。たとえばSolana、Monad、Aptosは、Ethereumの典型的な逐次モデルとは異なり、独立したトランザクションの並列実行をサポートしています。またMonadでは特に、トランザクションの順序の合意と、その後の実行が明確に分離されています。一方でSolanaとAptosでは、並列性はruntimeのアーキテクチャと状態ベースの競合管理によって実現されています。
その結果、1秒あたり数万件のトランザクション（TPS）を承認することは可能です。しかしここに罠があります。
歴史的に、ブロックチェーンは4つの機能を同時に担ってきました。
性能の向上は、4つすべての機能に同時に負荷を増やします。システムは、インフラがそれを読むよりも速くデータを生成してしまい、いわゆる「indexer gap」が生まれます。
Solanaエコシステムの最大級のインフラプロバイダーの1つであるHeliusのドキュメントでは、ブロックチェーンの逐次構造はデータの整合性と高いスループットの確保に適している一方で、過去の問い合わせを遅く非効率にしてしまうと、はっきり明記されています。そのため大半の企業は、ブロックチェーンの上に独自のインデクサと別個のデータベースを構築せざるを得ません。
ChainScore Labsのアナリストは、indexer gapをSolanaエコシステムの主要な課題の1つだと呼んでいます。彼らの評価では、高いブロック頻度とトランザクションの並列実行が膨大なデータの流れを生み出すネットワーク構造に対して、従来のインデックス化手法はうまく対応できていません。
つまり、次のような効果が起きます。ネットワークはほぼ瞬時に処理を承認できますが、アプリケーション側では、それらの処理の結果を処理するのに、はるかに多くの時間が必要になります。
もっと正確に言うと、プロセッサ、ハードディスク、ネットワークケーブルのスループットです。ブロックチェーンのスケーラビリティは、それを取り巻くインフラのスケーラビリティと一致しないことが分かりました。そしてそれに、できるだけ早く対処する必要があります。
TPSが100,000のネットワークを想像してください。トランザクションを書き込むだけでなく、
そのため、高いスループットは、コンセンサス、トランザクション実行、ネットワーク上に重なるインフラサービスの間で、リソース競争を生みます。
この中で一部の技術が並行して発展してきたことで、この問題は今すぐ解決しなければならなくなりました。人間にとっては、遅延が数秒あるいは数分でも許容できる場合があります。しかしAIエージェント、トレーディングシステム、自律型サービスにはもう許されません。マシンがオンチェーンデータに基づいて意思決定するのであれば、古い情報は誤り、機会損失、あるいは直接的な財務損失につながります。
その一方で、Ethereum Foundationは2026年の改訂ドキュメントで、アーカイブノードは3〜12TBのディスク容量を要し、初回同期は十分強力な機器でも最大で1か月かかり得ると示しています。制限要因は、SSDの速度、メモリ容量、プロセッサ性能です。
さらに、Gethの開発者は、従来のアーカイブ保存モデルについても別途説明しています。そこでは、Ethereumのデータベースサイズが20TB超になり、同期に数か月かかったとのことです。まさにそれゆえ、状態を保存するための新しいpath-basedアーキテクチャを作る必要が生じました。
つまり、はい。「鉄」、プロセッサ、ネットワーク帯域、CPU—情報の増加を追いかけるレースにおける、現実の物理的制約です。ただし、それだけではありません。現代のサーバーはすでに膨大な量のデータを処理できます。問題は別です。ネットワークの数千という独立した参加者が、それに対していくら支払うべきなのか、という点です。
たとえば、エコシステムに完全に参加するには数十TBのSSD、数百GBのRAM、そして高価な通信チャネルが必要になるなら、インフラを運用するオペレーターの数は必然的に減ります。そうして新たな中央集権化が生まれます。
形式上はデータを処理できますが、安く、かつ分散的に同時に実現することはできません。情報処理のコストが、トランザクションそのもののコストよりも速く上がり始めます。
レースの参加者たちはすでに、勝者になるのは、トランザクションをより速く、より安く、より確実に「利用可能な情報」に変換できるネットワークだと理解しています。そして今年、市場は予想外に注目を「モジュール型ブロックチェーン」への移行へと動かしました。
最初の世代のネットワークがすべての課題を同時に処理しようとしていたのに対し、新しい世代は責務を専門のレイヤーに分割します。1つのネットワークの代わりに、別個のレイヤーが登場しました。
開発者たちはこのプロセスをデータセンターの進化に例えています。以前は1台のサーバーがすべての機能を同時に担っていました。今日では、計算、データ保存、ネットワークサービスが互いに独立してスケールします。
市場で最も急成長している方向性の1つがDAネットワークです。ぱっと見のアイデアは奇妙です。他のブロックチェーンのデータを一時的に保存するために、なぜ別のブロックチェーンを作るのか？ しかしまさにそれが起きています。モジュール型アーキテクチャでは、トランザクションの実行とデータ保存は別々に存在し得ます。Rollupは、メインネットではなく外部のDAレイヤーにデータを公開します。これにより、スケーリングのコストを大幅に下げ、スループットを増やせます。
数年前までは、RPCは単なる技術的な詳細だと考えられていました。しかし今日では、それは暗号インフラにおける最重要の要素の1つになっています。2026年5月、Triton OneはSolana Foundationと共同で、更新されたRPC 2.0のアナウンスをリリースしました。これはネットワークにおける「データ読み取りアーキテクチャ」を構築するための新しいアプローチです
その中心となる考え方は、ネットワークの現在の状態へのアクセスと、その履歴を分離することです。これを実現するために、2つの独立したモジュールが導入されます。1つはリアルタイムにアカウント状態をインデックス化し、もう1つは過去のデータの取り扱いを最適化します。ブロックチェーン全体を完全に走査するのではなく、システムはアプリケーションの具体的なリクエストに応じて適応型インデックスを構築します。これにより、遅延と処理コストが下がります。
このように、TritonとSolanaは、いくつかのシステム上の制約を取り除こうとしています。高価で非効率なRPCノードのモノリシックなアーキテクチャ、JSON-RPCの標準リクエストの狭い範囲、そしてデータ処理のために開発者が自前または独自（プロプライエタリ）のソリューションに依存しがちである点です。新モデルでは、読み取りがコンセンサスから別途スケールし、履歴へのアクセスも、コロナ（カラム）型のストレージと事前ソートされたデータの活用によって高速化されます。
このプロジェクトは、エコシステムにすでに導入されているツール—バリデータからのデータストリーミング（Geyser、Yellowstone gRPC）や、履歴処理のためのソリューション—を土台にしています。インフラ全体はオープンソースとして提供され、その発展はSolana Foundationの参加も含めて調整されています。
その結果、Solanaは実質的に「ユニバーサルなRPC」から、モジュール型で専門特化されたデータ・インフラへ移行しようとしています。そこでは、開発者の障壁を下げ、ブロックチェーンデータの扱いを、従来のデータベースと同じくらい使いやすいものにするはずだ、とされています。
もしSolanaが読み取りレイヤーを標準化できれば、スループットが高いだけでなく、発展したアプリケーション向けインフラを備えるネットワークとしての立場を強化できる可能性があります。しかし同時に、独立したRPCプロバイダーやインフラ・プラットフォームとの競争も激しくなります。彼らは新しい標準に合わせるか、その上に追加サービスを提案する必要が出てきます。
モジュール型アーキテクチャは一部のインフラ上の制約を解消しますが、それらを別のレイヤーへ移します。コストを下げてデータへのアクセスを簡単にする意図は明確です。そうでないとDeFi、NFT、ウォレット、分析、コンプライアンスのツールが動きません。しかし、Web3の性質そのものに「段階的に複雑化が連鎖する」効果があるようにも思えます。ある課題を解決すると、必ず新たな挑戦が生まれるからです。
新しい仕組みは確実に、より複雑なインフラの上部構造を要求します。インデクサ、ストレージ、キャッシュ、別個のコンベア、そして新しい障害ポイントです。単一でシンプルなRPCレイヤーの代わりに、エコシステムは複数の並行した実装、互いに噛み合わない最適化、そしてインフラプロバイダーへの依存のさらなる増加を得る可能性があります。その場合、形式上のオープンなアーキテクチャが、必ずしも本当にオープンで、誰にとっても使いやすいアクセスモデルであるとは限りません。
現時点では、市場は「誰がよりうまくネットワークからデータを取り出せるか」という競争から、「それらのデータを最初に使った製品を作るのは誰か」という競争へと移っています。誰が、そしてどれくらい支払うのかは、おそらく近いうちに分かるでしょう。
1.12M 人気度
198.67K 人気度
72.19K 人気度
288.21K 人気度
Web3はなぜ読めないのか――ForkLog
数年前まで、ブロックチェーンのスループットをどう増やすかが業界で議論されていました。今日では多くのネットワークがすでに数万回の処理に対応でき、一部は数十万回をうたっています。しかし、データをブロックチェーンに書き込むことは、課題の半分にすぎないことが分かりました。さらに、それを見つけて、インデックス化して、検証し、アプリケーションへ届ける必要があります。
その結果、データ生成の速度が、ところによってはそれを処理するインフラ能力を上回るようになりました。ForkLogが、このようにブロックチェーンはどう変わっているのかを整理しました。
速ければ速いほど長くかかる
約10年前、ブロックチェーンの発展は、いわゆるスケーラビリティのトリレンマで語られていました。この考え方では、ネットワークは安全性、分散性、生産性（性能）の間で妥協を迫られます。しかし2026年になると、仮にスループット問題を部分的に解決できても、新たな課題が生まれることが明らかです。
ブロックチェーン自体にはユーザー・インターフェースがありません。この役割を担うのはさまざまなアプリケーションです。そしてそれらは、常にデータを取得し続けなければなりません。
ネットワークが速く動けば動くほど、こうした種類のデータ処理量は増えます
ユーザーの間にはよくある誤解があります。データがブロックチェーンに記録されているなら、あとは単に取得するだけだ、というものです。実際はまったく逆です。「生の」データをブロックチェーンからリアルタイムに直接読み取るのは、遅い・高い・技術的に難しいプロセスです。Web3エコシステムでは、ウォレットをdappアプリとつなぐ中間のインフラ層が広く普及しています。
たとえばウォレットアプリは、ユーザーが自分の残高を数秒のうちに見るために、RPCプロバイダー、インデクサ、分析プラットフォーム、キャッシュサーバー、専用のデータベースなどに問い合わせます。
プロセスは次のように構成されています。
実際には、多くの人気Web3アプリは追加の情報処理レイヤーを経由して動いています。たとえばブロックチェーンが1秒あたり50,000件のオペレーションを処理したとして、何百万ものウォレットが画面を更新するために同時にRPCリクエストを送るとしましょう。プロバイダーのサーバーでは、その負荷に耐えられません。ユーザーのためにデータを読み、インデックス化し、ソートすることは、非常に複雑な計算タスクです。インデクサやデータアクセスサービスは、処理・構造化・配送に追加時間が必要なため、ネットワークの最新状態から数ブロック遅れることがよくあります。問題は「古いインフラ」に限りませんが、もちろんそうした面もあります。より深いのは、Web2とWeb3のアーキテクチャ間にある衝突です。
ユーザーとアプリは、いつものインターネットと同じくらい、また頻繁にブロックチェーンとやり取りします。たとえばSNSのタイムラインをスクロールすると、アプリはいいね、コメント、画像を更新するためにサーバーへ1秒あたり何千回ものリクエストを行います。Web2のトレーディングボットは、1分あたり何百万回も取引所サーバーへ問い合わせることがあります。GoogleやAmazonのサーバーがそれを難なく受け止められるのは、集中型で、データがざっくり言えば世界中の何千台ものミラーサーバーへ即座にコピーできる「巨大な1つのデータベース」に置かれているからです。
しかしブロックチェーンは別物で、そうした形にはハードウェア的に対応していません。つい最近まで、その速度の最大の障害は数学と暗号でした。世界中の何千台ものコンピュータを、取引が正しいこと（コンセンサス）について素早く合意させる必要がありました。開発者たちはこの問題を、「並列実行」できるように機械を「学習」させ、コンセンサスと実行を分離しました。たとえばSolana、Monad、Aptosは、Ethereumの典型的な逐次モデルとは異なり、独立したトランザクションの並列実行をサポートしています。またMonadでは特に、トランザクションの順序の合意と、その後の実行が明確に分離されています。一方でSolanaとAptosでは、並列性はruntimeのアーキテクチャと状態ベースの競合管理によって実現されています。
その結果、1秒あたり数万件のトランザクション（TPS）を承認することは可能です。しかしここに罠があります。
歴史的に、ブロックチェーンは4つの機能を同時に担ってきました。
性能の向上は、4つすべての機能に同時に負荷を増やします。システムは、インフラがそれを読むよりも速くデータを生成してしまい、いわゆる「indexer gap」が生まれます。
Solanaエコシステムの最大級のインフラプロバイダーの1つであるHeliusのドキュメントでは、ブロックチェーンの逐次構造はデータの整合性と高いスループットの確保に適している一方で、過去の問い合わせを遅く非効率にしてしまうと、はっきり明記されています。そのため大半の企業は、ブロックチェーンの上に独自のインデクサと別個のデータベースを構築せざるを得ません。
ChainScore Labsのアナリストは、indexer gapをSolanaエコシステムの主要な課題の1つだと呼んでいます。彼らの評価では、高いブロック頻度とトランザクションの並列実行が膨大なデータの流れを生み出すネットワーク構造に対して、従来のインデックス化手法はうまく対応できていません。
つまり、次のような効果が起きます。ネットワークはほぼ瞬時に処理を承認できますが、アプリケーション側では、それらの処理の結果を処理するのに、はるかに多くの時間が必要になります。
Web3の速度が「当たり前の物理」（そしてそれ以上）に行き詰まった理由
もっと正確に言うと、プロセッサ、ハードディスク、ネットワークケーブルのスループットです。ブロックチェーンのスケーラビリティは、それを取り巻くインフラのスケーラビリティと一致しないことが分かりました。そしてそれに、できるだけ早く対処する必要があります。
TPSが100,000のネットワークを想像してください。トランザクションを書き込むだけでなく、
そのため、高いスループットは、コンセンサス、トランザクション実行、ネットワーク上に重なるインフラサービスの間で、リソース競争を生みます。
この中で一部の技術が並行して発展してきたことで、この問題は今すぐ解決しなければならなくなりました。人間にとっては、遅延が数秒あるいは数分でも許容できる場合があります。しかしAIエージェント、トレーディングシステム、自律型サービスにはもう許されません。マシンがオンチェーンデータに基づいて意思決定するのであれば、古い情報は誤り、機会損失、あるいは直接的な財務損失につながります。
その一方で、Ethereum Foundationは2026年の改訂ドキュメントで、アーカイブノードは3〜12TBのディスク容量を要し、初回同期は十分強力な機器でも最大で1か月かかり得ると示しています。制限要因は、SSDの速度、メモリ容量、プロセッサ性能です。
さらに、Gethの開発者は、従来のアーカイブ保存モデルについても別途説明しています。そこでは、Ethereumのデータベースサイズが20TB超になり、同期に数か月かかったとのことです。まさにそれゆえ、状態を保存するための新しいpath-basedアーキテクチャを作る必要が生じました。
つまり、はい。「鉄」、プロセッサ、ネットワーク帯域、CPU—情報の増加を追いかけるレースにおける、現実の物理的制約です。ただし、それだけではありません。現代のサーバーはすでに膨大な量のデータを処理できます。問題は別です。ネットワークの数千という独立した参加者が、それに対していくら支払うべきなのか、という点です。
たとえば、エコシステムに完全に参加するには数十TBのSSD、数百GBのRAM、そして高価な通信チャネルが必要になるなら、インフラを運用するオペレーターの数は必然的に減ります。そうして新たな中央集権化が生まれます。
形式上はデータを処理できますが、安く、かつ分散的に同時に実現することはできません。情報処理のコストが、トランザクションそのもののコストよりも速く上がり始めます。
市場はどう反応したか
レースの参加者たちはすでに、勝者になるのは、トランザクションをより速く、より安く、より確実に「利用可能な情報」に変換できるネットワークだと理解しています。そして今年、市場は予想外に注目を「モジュール型ブロックチェーン」への移行へと動かしました。
最初の世代のネットワークがすべての課題を同時に処理しようとしていたのに対し、新しい世代は責務を専門のレイヤーに分割します。1つのネットワークの代わりに、別個のレイヤーが登場しました。
開発者たちはこのプロセスをデータセンターの進化に例えています。以前は1台のサーバーがすべての機能を同時に担っていました。今日では、計算、データ保存、ネットワークサービスが互いに独立してスケールします。
市場で最も急成長している方向性の1つがDAネットワークです。ぱっと見のアイデアは奇妙です。他のブロックチェーンのデータを一時的に保存するために、なぜ別のブロックチェーンを作るのか？ しかしまさにそれが起きています。モジュール型アーキテクチャでは、トランザクションの実行とデータ保存は別々に存在し得ます。Rollupは、メインネットではなく外部のDAレイヤーにデータを公開します。これにより、スケーリングのコストを大幅に下げ、スループットを増やせます。
数年前までは、RPCは単なる技術的な詳細だと考えられていました。しかし今日では、それは暗号インフラにおける最重要の要素の1つになっています。2026年5月、Triton OneはSolana Foundationと共同で、更新されたRPC 2.0のアナウンスをリリースしました。これはネットワークにおける「データ読み取りアーキテクチャ」を構築するための新しいアプローチです
その中心となる考え方は、ネットワークの現在の状態へのアクセスと、その履歴を分離することです。これを実現するために、2つの独立したモジュールが導入されます。1つはリアルタイムにアカウント状態をインデックス化し、もう1つは過去のデータの取り扱いを最適化します。ブロックチェーン全体を完全に走査するのではなく、システムはアプリケーションの具体的なリクエストに応じて適応型インデックスを構築します。これにより、遅延と処理コストが下がります。
このように、TritonとSolanaは、いくつかのシステム上の制約を取り除こうとしています。高価で非効率なRPCノードのモノリシックなアーキテクチャ、JSON-RPCの標準リクエストの狭い範囲、そしてデータ処理のために開発者が自前または独自（プロプライエタリ）のソリューションに依存しがちである点です。新モデルでは、読み取りがコンセンサスから別途スケールし、履歴へのアクセスも、コロナ（カラム）型のストレージと事前ソートされたデータの活用によって高速化されます。
このプロジェクトは、エコシステムにすでに導入されているツール—バリデータからのデータストリーミング（Geyser、Yellowstone gRPC）や、履歴処理のためのソリューション—を土台にしています。インフラ全体はオープンソースとして提供され、その発展はSolana Foundationの参加も含めて調整されています。
その結果、Solanaは実質的に「ユニバーサルなRPC」から、モジュール型で専門特化されたデータ・インフラへ移行しようとしています。そこでは、開発者の障壁を下げ、ブロックチェーンデータの扱いを、従来のデータベースと同じくらい使いやすいものにするはずだ、とされています。
モジュール化は問題を解決するのか？
もしSolanaが読み取りレイヤーを標準化できれば、スループットが高いだけでなく、発展したアプリケーション向けインフラを備えるネットワークとしての立場を強化できる可能性があります。しかし同時に、独立したRPCプロバイダーやインフラ・プラットフォームとの競争も激しくなります。彼らは新しい標準に合わせるか、その上に追加サービスを提案する必要が出てきます。
モジュール型アーキテクチャは一部のインフラ上の制約を解消しますが、それらを別のレイヤーへ移します。コストを下げてデータへのアクセスを簡単にする意図は明確です。そうでないとDeFi、NFT、ウォレット、分析、コンプライアンスのツールが動きません。しかし、Web3の性質そのものに「段階的に複雑化が連鎖する」効果があるようにも思えます。ある課題を解決すると、必ず新たな挑戦が生まれるからです。
新しい仕組みは確実に、より複雑なインフラの上部構造を要求します。インデクサ、ストレージ、キャッシュ、別個のコンベア、そして新しい障害ポイントです。単一でシンプルなRPCレイヤーの代わりに、エコシステムは複数の並行した実装、互いに噛み合わない最適化、そしてインフラプロバイダーへの依存のさらなる増加を得る可能性があります。その場合、形式上のオープンなアーキテクチャが、必ずしも本当にオープンで、誰にとっても使いやすいアクセスモデルであるとは限りません。
現時点では、市場は「誰がよりうまくネットワークからデータを取り出せるか」という競争から、「それらのデータを最初に使った製品を作るのは誰か」という競争へと移っています。誰が、そしてどれくらい支払うのかは、おそらく近いうちに分かるでしょう。