Skip to main content
The blockchain’s state is the complete snapshot of all accounts, balances, and smart contract data at a given block height. OpenGDP manages this state with a layered storage architecture designed for both efficiency and security.

​
A Tree of Trees

At the top level, OpenGDP organizes the state as a merkle tree. Instead of storing data directly, this tree references independent sub-trees, each dedicated to a specific category of state, such as account balances or EVM data. This “tree of trees” design isolates different parts of the state, reducing bottlenecks, while still committing the entire system into a single verifiable hash.

​
Storage Structures

Two specialized data structures are used to implement these sub-trees:
  • IAVL Trees: Used for native chain state, such as balances and governance data. IAVL is a self-balancing binary search tree with cryptographic hashing at every node. It provides efficient ordered iteration and logarithmic-time proofs for the existence or non-existence of data.
  • Merkle Patricia Trie: Used for EVM state to ensure full Ethereum compatibility. Keys are mapped to values through a trie where each node’s hash depends on its children. This allows secure and efficient verification of contract state.

​
Merkle State Root

Each sub-tree produces its own root hash, which acts as a cryptographic fingerprint of all data within that structure. The top-level merkle tree then combines these sub-tree roots into a single State Root. This state root is included in every block header and serves as a global commitment to the entire chain’s state. Any modification, even to a single byte of data, produces a different root and is immediately detectable by all nodes. New nodes can verify chain integrity by recomputing these roots across block history.

​
Smart Contract Storage

Each smart contract deployed on OpenGDP’s EVM receives its own isolated storage trie, implemented as a Merkle Patricia Trie within the broader EVM state.
  • The root of this trie, the storageRoot, is stored in the contract’s account field.
  • Solidity variables map to storage slots in the trie. Simple values (e.g., uint256, address) occupy fixed slots, while mappings use hashed keys: keccak256(key, slot).
This ensures that contract storage remains separate, independently verifiable, and cryptographically secure.