ストレージの最適化
カイア・ブロックチェーンが成長するにつれ、チェーン・データを保存するのに必要なストレージも増加する。 カイアは、この増大するストレージ要件を管理するために、主に2つのテクニックを実装している：
ステート・バッチ・プルーニング（ステート・マイグレーション）
状態移行は、実行中のノードを中断することなく、既存のノードに適用できるバッチ刈り込み機能である。
モチベーション
ブロックステート（StateDB）は、オンチェーンアカウントとコントラクトをトライデータ構造に格納する。 Trieデータ構造は、古い状態と最近の状態の両方を保存するように設計されているので、Merkleハッシュを使って検証することができる。 トランザクションが状態変更を実行すると、状態トライは無限に成長する。 本稿執筆時点（2024年8月）では、カイア・メインネットのアーカイブ・ノード・サイズは20TBを超え、フル・ノードでも10TBを超えている。
コンセプト
ステート・マイグレーションは、新しいブロックの処理に必要のない古いブロック・ステートを削除する。 それは、"古い "から "新しい "へのステートトライをコピーする。 すべてのトライノードがコピーされるわけではない。 選択ブロックの状態根から到達可能なものがコピーされる。 コピー後、古いディレクトリは削除されるので、選択したブロックの状態だけが残る。
技術的な詳細については、以下のブログ記事をお読みください： ステート・マイグレーション：ノード・ストレージの節約、 カイア・ステート・マイグレーション：ブロックチェーン・データを削減する効率的な方法
Batch Pruningの実行方法については、State Migration Guideを参照してください。
州ライブ剪定
ステート・ライブ・プルーニングは、増大するステート・データベースのサイズ問題に対する新しいソリューションである。 バッチ・プルーニング（ステート・マイグレーション）とは異なり、ライブ・プルーニングは、ノードのプロセスがブロックされると、古いステートを少しずつ自動的に削除する。
モチベーション
ブロックステート（StateDB）は、オンチェーンアカウントとコントラクトをトライデータ構造に格納する。 Trieデータ構造は、古い状態と最近の状態の両方を保存するように設計されているので、Merkleハッシュを使って検証することができる。 トランザクションが状態変更を実行すると、状態トライは無限に成長する。 本稿執筆時点（2025年8月）では、カイア・メインネットのアーカイブ・ノード・サイズは20TBを超え、フル・ノードでも10TBを超えている。
これまでの状態移行では、最近の状態を選択的にコピーして古い状態を削除し、残りを削除することでこの問題を軽減していた。 これにより、ノード全体のサイズを5TB未満に抑えることができる。
とはいえ、国家移民には欠点もある。 これは、数日かかる可能性のあるステートトライ全体を横断するという高いオーバーヘッドに悩まされる。 また、状態移行は手動でトリガーしなければならない。 これらの制限を克服するために、ライブ・プルーニング技術が導入された。
コンセプト
トライの刈り込みは、トライのノードが古い かどうかが不明なので難しい。 元のステートトライ構造では、トライノードは、それぞれが異なるブロックを構成する複数のトライの一部になることができる。 トライノード（口座残高など）が別の値に更新されても、他の親ノードがまだ必要としている可能性があるため、トライノードを削除することはできない。 この問題はハッシュ重複問題と呼ばれている。
ライブ・プルーニングは、同じ内容のトライノードを意図的に重複させる。 Live Pruningでは、トライノードはハッシュで参照されるのではなく、ExtHashで参照される。 ExtHashは、コンテンツの32バイトのハッシュと7バイトのシリアル・インデックスです。 直列インデックスは単調増加なので、すべてのトライノードは一意である。
Hash: 32-byte Keccak256ExtHash: 32-byte Keccak256 + 7-byte Serial index
こうすることで、トライノードのコンテンツが変更されるたびに、そのトライノードは廃止されたと仮定しても問題ない。 Merkleハッシュは、直列インデックスを無視するだけで、同じように計算することができ、コンセンサスの点で非ライブ・プルーニング・ノードと互換性がある。
技術的な詳細については、このブログ記事をお読みください：[StateDB Live Pruningによるブロックチェーンデータ容量の効率的管理】(https://medium.com/klaytn/strong-efficient-management-of-blockchain-data-capacity-with-statedb-live-pruning-strong-6aaa09b05f91).
ライブ・プルーニングを有効にする方法については、ライブ・プルーニング・ガイドを参照してください。
データ圧縮
データ圧縮は、LevelDB内蔵のSnappy圧縮アルゴリズムを選択したデータベーステーブルに適用することで、ブロックデータのストレージサイズを縮小します。
モチベーション
ヘッダ、トランザクションボディ、レシートからなるブロックデータは、EVMトランザクションのABIエンコーディング標準のため、多くの場合、非常に繰り返しの多いバイトシーケンスを含んでいる。 例えば、SolidityのABIエンコーディングでは、32バイトのワードアライメントを満たすためにゼロパディングが使用され、その結果、トランザクションコールデータに長いゼロが含まれることになります。 トランザクションの受信は、イベントログと戻り値に同様のパターンを示す。
このような自然な冗長性があるにもかかわらず、カイアの基盤となるLevelDBストレージ・エンジンはデフォルトで圧縮を利用していなかったため、反復的なデータが不必要にディスク容量を消費していた。 2025年7月現在、カイア・メインネットのフルノードは4.2TB以上のストレージを占有しており、約3.6TBが非圧縮ブロックデータに起因している。
コンセプト
Kaia v2.1.0は、LevelDBのSnappy圧縮アルゴリズムをデータベースのテーブルに選択的に適用します。 --db.leveldb.compression`フラグを指定すると、きめ細かい制御が可能になる：
- ヘッダー、ボディ、レシートを圧縮（冗長性が高く、大幅な節約になる）
- 州のトライデータを除外（ランダムに見える、圧縮効果は最小限）
既存のノードでは、手動でデータベースの圧縮をトリガーすると、古い非圧縮データが圧縮形式に書き換えられる。 この "ハウスキーピング "プロセスは、SSTableをマージし、削除を調整し、副作用として圧縮を適用する。
**結果:**メインネットのフル・ノードでは、ストレージの総量が約50%削減され（~2TBの節約）、特にボディ・テーブルとレシート・テーブルで大きな効果が得られました。 この処理には約10時間かかり、通常のブロック処理と同時に実行できる。
技術的な詳細については、このブログ記事をお読みください：カイアv2.1が圧縮によって2TBを取り戻すまで。
圧縮を有効にする方法については、ノードストレージの最適化ガイドを参照してください。
フラットトライ・ステート・スキーム（実験的）
FlatTrieは、過去のアカウント状態の保存方法を再構築することで、アーカイブノードの状態データベースのサイズを大幅に削減する実験的な状態保存方式です。
モチベーション
アーカイブ・ノードは、すべてのブロックの高さですべてのアカウントの完全な履歴データを保持し、タイムトラベル・クエリーと包括的なブロックチェーン分析を可能にしなければならない。 2025年8月現在、カイア・メインネットのアーカイブ・ノードには35TB以上のディスク容量が必要で、そのうち31TB（89％）がステート・データベースに消費されている。
従来のMerkle Patricia Trie（MPT）構造は、アカウントデータ（リーフ）と、Merkleツリーを形成する中間ブランチノードの両方を格納する。 アーカイブノードはこれまで、複数のブロックの高さに対して完全なMPTを保持していたため、中間ノード（それ自身はアカウントデータを伝達しない）が無限に蓄積される原因となっていた。
State Migration](https://medium.com/klaytn/klaytn-v1-5-0-state-migration-saving-node-storage-1358d87e4a7a)（バッチ刈り込み）や[StateDB Live Pruning](https://medium.com/klaytn/strong-efficient-management-of-blockchain-data-capacity-with-statedb-live-pruning-strong-6aaa09b05f91)のような既存のストレージ最適化は、基本的に履歴データを削除する必要があるため、完全な履歴を保持する必要があるアーカイブノードには適用できない。
コンセプト
FlatTrieは、Erigon Ethereumクライアントから転用された実験的な状態保存スキームである。 それは、以下のような方法で状態記憶装置を再構築する：
- フラットなキー・バリュー・テーブルに過去の口座状態を保存（単純な住所→口座データのマッピング）
- 最新のブロックの完全なMPTのみを、すべての中間ブランチノードで保持する。
- 必要なブランチノードのみを一時的に構築することにより、オンデマンドで過去のMerkleルートを再構築する。
このアプローチでは、完全なアカウント状態の履歴とあらゆるブロックのMerkleルートを検証する能力を維持しながら、過去の中間ノードの永続的なストレージを排除する。
**Erigonの実装はイーサリアムのアカウント構造を前提としている。 カイアは、人間が読めるアドレスや複数のキータイプといった独自の機能をサポートするため、異なるRLPエンコーディングを使用している。 この統合には、ErigonのMerkleハッシュモジュールをアカウントを不透明なバイト列として扱うように修正する ことと、KaiaのマルチスレッドTrieインターフェースとErigonのシングルスレッドMDBXデータベースの要件をブリッジするために3つのアダプターレイヤー（DomainsManager、WriteBuffer、DeferredContext）を作成することが必要でした。
結果: Kairosのテストネット実験では、FlatTrieアーカイブノードは、従来のアーカイブノードと比較して、総ストレージ消費量を約75%削減し、ステートデータベースのサイズを80%以上削減しました。 メインネットのアーカイブ・ノードについても、同様の節約効果が見込まれる（～35TBから～10TBへ）。
制限事項: 実験的な v2.1.0 の実装では、ブロックの巻き戻し (debug_setHead API) や Merkle 証明の生成 (eth_getProof API) や状態の刈り込み機能はサポートされていない。 これらの制限は、FlatTrieが過去のブランチノードを破棄するという設計上の選択に由来する。
技術的な詳細については、このブログ記事をお読みください：カイアの実験的FlatTrie for Archive Nodes.
FlatTrieを有効にする方法については、ノード・ストレージの最適化ガイドを参照してください。