1. 結論

2026年8月時点で、チェーン肥大化への総合耐性は Bitcoinが最も高い。

Cardanoは現在のPraos環境ではかなり健全であり、EUTXOによるstate管理、比較的低いデータ生成量、Mithrilによる高速bootstrapなどの強みを持つ。

しかし、Leios導入後は事情が変わる。

LeiosはCardanoのデータ処理能力を大幅に引き上げる一方、Cardanoには現状、履歴データのarchiving、sharding、pruningを前提とした包括的な仕組みがない。このためLeiosが実際に高い利用率を達成すれば、長期的にはstorage architectureの再設計が重要になる。

今回の再評価では、Cardanoを単純に「肥大化に強いチェーン」と評価するのではなく、

現在は肥大化が小さいが、Leios後の高スループット時代に向けた履歴管理機構は未完成

と評価するのが適切である。

2. 「チェーン肥大化」は5種類に分ける必要がある

単純なブロックチェーン容量だけでは比較を誤る。

種類	意味	主な問題
履歴肥大化	過去ブロック・トランザクションの累積	SSD/HDD容量、同期時間
State肥大化	現在有効なUTXO、Account、Contract state	RAM、SSD IOPS、検証速度
Index肥大化	Explorer・RPC用検索DB	RPCノード大型化
Snapshot肥大化	高速同期用snapshot	Bootstrapコスト
Archive肥大化	全履歴・旧state保存	データセンター依存

したがって、

「通常ノードが500GBだからチェーンが軽い」

とは限らない。

SolanaやSuiのように古い履歴を通常ノードから積極的に切り離すチェーンでは、validator自体の容量を抑えられても、ネットワーク全体で生成される履歴データは巨大になり得る。

3. 主要5チェーン総合比較

対象は以下の5チェーンとする。

Bitcoin
Cardano
Ethereum
Solana
Sui

項目	Bitcoin	Cardano	Ethereum	Solana	Sui
データ生成速度への耐性	★★★★★	★★★★☆ 現在	★★★☆☆	★☆☆☆☆	★☆☆☆☆
State肥大化耐性	★★★★★	★★★★☆	★★☆☆☆	★★☆☆☆	★★★☆☆
通常ノード容量	★★★★★	★★★★☆	★★★☆☆	★★☆☆☆	★★☆☆☆
Pruning成熟度	★★★★★	★★☆☆☆	★★★★☆	★★★★★	★★★★★
Archive依存の低さ	★★★★★	★★★★★	★★★☆☆	★★☆☆☆	★★☆☆☆
家庭・小規模運用適性	★★★★★	★★★★☆	★★★☆☆	★☆☆☆☆	★★☆☆☆
高TPS時の将来耐性	★★★★★	★★★☆☆	★★★☆☆	★★☆☆☆	★★★☆☆
総合評価	S5	S4→S3	S3	S2	S2〜S3

Cardanoの「S4→S3」は、現行PraosとLeios後を分けて考える必要があることを示す。

4. Bitcoin――最も「太らせない」設計

Bitcoinの最大の強みは、単にTPSが低いことではない。

UTXOモデル
arbitrary smart contract stateが限定的
block spaceが強く制約される
pruningが成熟している
archive機能とconsensus validationを分離できる

という構造そのものが肥大化を抑えている。

Bitcoin Coreでは、pruningを有効にしてもブロックを一度検証したうえで不要になったraw blockやundo dataを削除できる。

つまりBitcoinは、

「チェーンを最初から急速に太らせない」＋「検証後の古い履歴を捨てられる」

という二重の防御を持つ。

評価

肥大化耐性：S5

長期的にも5チェーン中、最もstorage requirementを予測しやすい。

5. Cardano――現在は優秀だがLeiosが転換点

CardanoはBitcoinと同じUTXO系統だが、スマートコントラクトを扱えるEUTXOを採用している。

Ethereumのように巨大なglobal mutable stateを中心に動作するAccount型とは性質が異なる。

これは長期的なstate growthの面で有利である。

さらにMithrilによって、genesisから全ブロックを逐次同期する代わりに、stake-certified snapshotを利用してCardano nodeを高速bootstrapできる。

したがって、

同期時間の問題と、履歴そのものの保存量の問題は分けて考える必要がある。

Mithrilは前者には強力だが、後者を自動的に解決するものではない。

6. Cardano最大の課題

Ouroboros Leiosの分析資料では、現在のCardano ledgerにはarchiving、sharding、pruningの包括的な仕組みがなく、永久storage requirementが処理したtransaction dataに応じて増加することが課題として認識されている。

現行Cardanoではデータ生成量そのものが比較的小さいため、問題はまだ深刻ではない。

しかしLeiosではデータ処理能力が大幅に増加する。

公開ロードマップ・分析では、おおむね以下のレンジが想定されている。

指標	現行Cardano	Leios想定
データ処理量の目安	約4.5 Tx-kB/s	約140〜300+ Tx-kB/s
設計解析の代表値	-	約250 Tx-kB/s
TPS目標の一例	-	最大約1,500 TPS
現行比	1	約30〜65倍

250kB/sを1年間、常時フル利用する極端な上限計算では、

約7.9TB/年

に相当する。

一方、4.5kB/s相当なら、

約142GB/年

程度となる。

これはあくまでcapacityを常時使い切る仮定であり、実際のチェーン成長量の予測ではない。

重要なのは、

LeiosはCardanoの処理能力問題を解決する一方、その成功によって永久storage問題を顕在化させる可能性がある

という点である。

7. Mithrilはpruningではない

ここは重要な区別である。

Mithrilは、

過去履歴を消す技術ではなく、信頼可能なsnapshotを使って高速にbootstrapする技術

である。

したがって、

Mithril ≠ history expiry / pruning

である。

Bitcoin pruningやEthereumのhistory expiryとは役割が異なる。

このためLeios時代のCardanoでは、将来的に、

Mithril
history pruning
archival layer
distributed history availability

などを組み合わせる方向が合理的と考えられる。

これは将来予測を含むが、Leios側が永久storage requirementを課題として明示している以上、自然な技術的発展方向である。

8. Ethereum――履歴肥大化とState肥大化の二重問題

Ethereumでは複数のデータが独立して増加する。

historical blocks
receipts
account state
contract storage
historical state

Ethereumはすでにhistory pruning / expiryへ大きく方向転換している。

Gethでは古いblock bodiesやreceiptsをpruneしながらfull validationを維持できる。

EIP-4444を中心とするhistory expiryの思想も、

全ノードが全履歴を永久保存する必要はない

という方向を明確にしている。

しかしEthereumの本質的問題はhistoryだけではない。

State growth

現在有効なaccountやcontract storageはvalidationに必要である。

そのためEthereum roadmapでは、

history expiry
state expiry
weak statelessness
strong statelessness

が別々の課題として扱われている。

Ethereumは肥大化問題が大きい一方、

肥大化問題をprotocol architectureそのものによって解決しようとしているチェーン

でもある。

9. Solana――保存するより高速に流す設計

SolanaはBitcoinやCardanoとは思想が大きく異なる。

validatorには高性能CPU、大容量RAM、複数の高速NVMeなどが要求される。

Ledgerについても全履歴を無制限にvalidatorが保持するのではなく、古いデータを削除していく運用が前提になる。

つまり、

全validatorが全歴史を永久に保持する必要はない

という設計思想である。

これは高TPSチェーンとして合理的だが、完全履歴は、

RPC
indexer
archival infrastructure
外部ストレージ

などへ移される。

したがってSolanaでは、

validator storage

と

ecosystem-wide archival storage

を区別する必要がある。

さらにSolanaの場合、storage容量だけでなくRAM、CPU、network bandwidth、NVMe性能などの総合的なnode operating costが高い。

そのため長期的には、

チェーン肥大化そのものより、ノード運用コストによるcentralization圧力

が重要な問題になる。

10. Sui――大量データをpruning前提で管理

Sui公式資料では、通常ノードと履歴保存ノードの容量差が非常に大きい。

公開資料の一例では、

Sui storage	容量
Validator	約250〜400GB
Pruned Full Node	約2.5TB
Unpruned Full Node	約16TB
Full-node snapshot	約1.6TB
Checkpoint bucket	約30TB

またunpruned full nodeでは負荷に応じて数十GB/day規模でデータが増える例が示されている。

仮に、

10GB/day → 約3.65TB/年
40GB/day → 約14.6TB/年

となる。

Suiはこの問題を前提としてpruningを重要な設計要素にしている。

さらにstorage feeを徴収し、object削除時にstorage feeの大部分をrebateする仕組みを持つ。

つまりSuiは、

「ストレージは有限資源である」という前提をprotocol economicsにも組み込んでいる

点が特徴的である。

11. 評価軸を変えると順位も変わる

チェーン全体のデータ生成量を抑えられるか

良い順の概念評価：

Bitcoin > Cardano現行 > Ethereum > Sui ≈ Solana

通常validatorが大量履歴を抱えずに済むか

概念的には、

Bitcoin > Cardano > Ethereum > Sui > Solana

に近い。

古い履歴を通常ノードから切り離すarchitecture

ここでは、

Solana ≈ Sui > Bitcoin > Ethereum > Cardano

となる。

Cardanoは現在のデータ生成量が比較的小さいため問題が表面化しにくいが、高throughput時代を考えるとこの弱点は重要になる。

12. Cardanoをどう評価するべきか

Cardanoは、

現在の低肥大化チェーン

とは評価できる。

しかし、

肥大化対策が完成したチェーン

とはまだ評価できない。

現行Praosでは、

EUTXO
比較的低いthroughput
Mithril

によって問題が小さく抑えられている。

しかしLeiosでcapacityが30〜65倍級に拡大すれば、

historical block storage
Cardano DB
DB Sync
indexer
explorer
archival availability
SPO SSD容量
snapshot size
bootstrap infrastructure

が本格的な課題になる可能性がある。

13. Cardanoには構造的な強みもある

CardanoがEthereumより有利な点の一つがEUTXOである。

Ethereumはglobal stateを更新するAccount型である。

CardanoはUTXOを消費して新しいUTXOを生成する。

そのため概念上、

過去のtransaction history

と

現在validationに必要なledger state

を分離しやすい。

したがってCardanoは、

「現在pruningが十分ではないから、将来的にもpruningが困難」

という意味ではない。

むしろ推測としては、

EUTXO + Mithrilは将来的なhistory pruningと相性が良い可能性がある。

Mithrilで認証されたstate snapshotを取得し、それ以前の古い履歴を別のavailability layerへ移す構成は技術的に自然である。

14. 肥大化問題の本質は分散性

最終的に重要なのはストレージ容量そのものではない。

Node Cost → Node Count → Decentralization

という連鎖である。

Chain	肥大化・ノードコストによる分散性リスク
Bitcoin	非常に低い
Cardano現行	低い
Ethereum	中程度
Sui	中〜高
Solana	高い

Solanaは大容量RAMや高速NVMeなどを要求するため、家庭レベルのvalidator運営から遠くなりやすい。

一方Leiosは、throughputを引き上げながらSPO hardware requirementを比較的穏当な範囲に維持することを重要な設計目標としている。

つまりCardanoにとってLeiosの成功条件は、

TPSを増やすことだけではなく、SPO decentralizationを維持したままTPSを増やすこと

である。

15. 2030年前後のCardano：5段階シナリオ

以下の確率はCGTAによる推定であり、公式予測ではない。

Scenario	状況	推定確率
S5 最良	Leios + Mithril + history pruning / archival layerが整備され、SPOが1〜2TB級で長期運営可能	20%
S4	Leios稼働後も実利用データ量はmoderate。SSD価格低下もありpruning未完成でも実用上大きな問題にならない	35%
S3	Leios普及でDBが数TB級へ。大型SPOには問題ないが小規模SPO負担が増える	30%
S2	高利用率が続き年間数TB規模で履歴が増加。archive/pruning整備が後追いになる	12%
S1 最悪	Leios高負荷とarchive設計遅延が重なりSPO運用コストが急増、集中化圧力が高まる	3%

中心シナリオはS4〜S3と考える。

Leios導入だけで直ちにデータ爆発が起こるわけではない。

むしろ、

Leiosが成功し、Cardanoが本当に大量利用されるほどstorage architecture改革の必要性が高まる

という構造である。

16. 最終ランキング

現在のチェーン肥大化耐性

Bitcoin — S5
Cardano — S4
Ethereum — S3
Sui — S2〜S3
Solana — S2

ただし、

高TPS化した将来も同じ設計で長期間耐えられるか

という評価ではCardanoの順位は低下する。

EthereumとSuiはすでに、

全履歴を全ノードに永久保存させない

方向へarchitectureを移している。

Cardanoはまだこの部分を本格的に完成させていない。

17. CGTA再評価

今回の再調査では、Cardanoについて以前より少し厳しく評価する。

最大の理由は、Ouroboros Leiosの開発資料自身が、

現在のCardanoにはarchiving、sharding、pruningの包括的な仕組みがなく、永久storage requirementが課題になる

という問題を認識しているためである。

ただし、これは現在のCardanoが危険という意味ではない。

むしろ、

Leios以前には緊急性が低かった問題が、Leiosによる大幅なcapacity増加によって重要になる

と理解する方が正確である。

そしてCardanoには、

EUTXO
Mithril
分散型SPO
Leios

という基盤がある。

そのため将来、

EUTXO + Mithril + history pruning + distributed archival

という構成へ発展すれば、Bitcoin型の高い検証可能性と、高throughputチェーンの処理能力の中間に位置する興味深いstorage architectureになり得る。

Cardanoにとって「チェーン肥大化」は現在の危機ではない。

しかし、Leiosが成功した未来では避けて通れない次世代スケーリング課題である。

参考情報源

Ouroboros Leios GitHub — Challenges / Impact Analysis

https://github.com/input-output-hk/ouroboros-leios

Ouroboros Leios Roadmap

https://leios.cardano-scaling.org/docs/roadmap/

Cardano Developer Portal — Running Cardano / Mithril bootstrap

https://developers.cardano.org/docs/operators/node/running-cardano/

Cardano Docs — Mithril

https://docs.cardano.org/developer-resources/scalability-solutions/mithril

Bitcoin Core

https://bitcoincore.org/

Bitcoin.org — Bitcoin Core pruning関連資料

https://bitcoin.org/

Geth — History Pruning

https://geth.ethereum.org/docs/fundamentals/historypruning

Geth — Archive Node

https://geth.ethereum.org/docs/fundamentals/archive

Ethereum.org — Statelessness Roadmap

https://ethereum.org/roadmap/statelessness/

Solana / Agave Validator Requirements

https://solana.com/

Sui Documentation — Sui Storage

https://docs.sui.io/develop/sui-architecture/sui-storage

作成日：2026-08-12 JST Cardano Epoch：648