21. Storage Engine

Kortana relies on a robust, heavily tested storage layer to ensure that state and blockchain data survive process crashes and host reboots.

21.1 RocksDB Backend

The primary storage backend is RocksDB.

• 14 Column Families: Data is segregated logically. Blocks, headers, receipts, state trie nodes, and staking data each reside in their own optimized column family.
• Atomic Batches: When a block is finalized, all state changes (balances, contract storage, updated receipts) are written to RocksDB as a single atomic batch. Either all changes commit, or none do.

21.2 Write-Ahead Log (WAL)

Every state mutation is appended to a Write-Ahead Log before being flushed to the main database. This ensures that even if the node is killed via SIGKILL (kill -9) mid-write, the data can be recovered on startup.

21.3 Checkpoints

The storage engine takes regular checkpoints. These allow node operators to perform fast backups or rollbacks without taking the database offline.

21.4 Crash Recovery Protocol

[!IMPORTANT] Crash & Restart: On startup, the node reads the BUILD-INFO, validates the genesis configuration, and checks the database for consistency. If the process crashed during a write, the node replays the WAL, rebuilds the state trie to the last finalized block, recomputes the state root, and seamlessly resumes synchronization.

21.5 IStore Interface & MemoryStore

The entire storage architecture sits behind an abstract IStore C++ interface. While production runs on RocksDbStore, the test suite heavily utilizes an in-memory implementation (MemoryStore), allowing the 1,700+ tests to run in seconds without touching the disk.

Part VI — JSON-RPC API Reference

Kortana exposes a powerful, dual-purpose JSON-RPC interface. It provides exact, byte-for-byte compatibility with Ethereum's eth_ API while exposing Kortana's native consensus, staking, and governance layers through custom ktn_ methods.

---