6. State Management

6.1 Merkle-Patricia Trie (MPT)

Kortana maintains its entire world state within a cryptographically authenticated Merkle-Patricia Trie (MPT) that strictly adheres to the Ethereum Yellow Paper specification. The trie combines a radix-16 search tree with cryptographic Merkle hashing, ensuring that any single modification to account balances, contract storage, or execution nonces results in a completely deterministic, non-forgeable 32-byte state_root.

The MPT utilizes three distinct node types to optimize memory and disk layout:

Leaf Nodes: Store key-value data with an encoded 2-nibble prefix and the RLP-encoded account or storage value.
Extension Nodes: Compact shared key paths into single nodes, preventing trie deepening when keys share common prefixes.
Branch Nodes: 17-element arrays containing 16 nibble pointers (0x0 through 0xF) and an optional value slot for intermediate terminal keys.

All nodes are hashed using Keccak-256 and stored in the dedicated state_trie RocksDB column family.

6.2 World State & Account Model

The World State represents the global mapping of 20-byte Address values to AccountState structures. Kortana operates an account-based ledger model supporting two distinct account categories:

Externally Owned Accounts (EOAs): Accounts controlled directly by private keys (secp256k1 or Ed25519). An EOA possesses an execution nonce (tracking transaction count) and a liquid DNR balance. Its storage_root is initialized to the empty trie hash (56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421), and its code_hash is the Keccak-256 hash of empty data (c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470).
Contract Accounts: Accounts instantiated with immutable executable bytecode (either EVM bytecode or KVM modules). A contract account contains a nonce, a DNR balance, a code_hash pointing to stored bytecode in RocksDB, and a dedicated storage_root pointing to an independent sub-trie holding the contract's persistent key-value storage slots.

6.3 State Proofs (EIP-1186)

Because Kortana's world state trie matches Ethereum's MPT specification byte-for-byte, the node natively implements EIP-1186 state proofs via the eth_getProof JSON-RPC endpoint.

When a client requests a state proof for an account and its associated storage keys, the node traverses the global state trie and the contract's sub-trie, gathering the exact sequence of RLP-encoded trie nodes from the root to the target leaf. The resulting cryptographic proof allows light clients, cross-chain bridge relayers, and off-chain zero-knowledge provers to verify account balances and storage values against the finalized block header state_root without running a full node.

6.4 Known Limitation: No Archive State

[!WARNING] Kortana does not currently maintain an archive state. The world state stores data by current value. State query methods (eth_getBalance, eth_getStorageAt) accept a block parameter but will ignore historical parameters and return the current state. Tooling querying historical balances will silently receive the present balance.

In the current kortana-node implementation, historical intermediate state trie nodes are pruned upon block finalization to conserve NVMe disk storage and maintain maximum write throughput. The world state database holds the authoritative state at the latest finalized block tip. Applications requiring historical state queries at arbitrary past block heights should utilize dedicated indexing solutions or external data lake synchronizers that record state diffs as blocks are finalized.