State Management
Bitplanet uses BitSDK's KVStore backed by an IAVL tree for state storage. This page explains the core storage architecture, key encoding schemes, and storage patterns.
Storage Architecture
IAVL Tree Foundation
BitSDK stores all state in an IAVL (Immutable AVL) tree:
Key Properties:
Immutable Snapshots: Each block height creates a new tree version
Merkle Proofs: State commitment in block headers enables light client verification
Balanced Structure: O(log n) read/write operations via self-balancing AVL+ tree
Historical Access: Archive nodes maintain full history; pruning nodes keep recent N versions
State Commitment:
Block Header
└─ App Hash (root of all modules)
├─ x/brahma Store Hash
├─ x/evm Store Hash
├─ x/bank Store Hash
└─ ... (other module stores)Module Store Organization
Each BitSDK module has an isolated KVStore identified by unique prefixes. The x/brahma module uses:
Benefits:
Prevents key collisions between modules
Enables efficient range scans per prefix
Logical separation of data types
Key Encoding Schemes
Length-Prefixed Encoding (AITensor Keys)
Critical for preventing collisions with variable-length AI IDs:
Format:
Example:
Why Length-Prefix:
Without prefix:
"ab" + height:3100could collide with"abc" + height:100With prefix:
0x0002|ab|3100vs0x0003|abc|100→ distinct keysEnables deterministic parsing and range queries
Simple Concatenation (Other Keys)
Most keys use direct prefix + identifier:
Storage Patterns
Circular Buffer (Market Cap History)
Fixed-size rolling window prevents unbounded growth:
Implementation:
Purpose:
Smooth market cap volatility (30-block average) - see Inflation Mechanism
Prevent consensus failures from non-deterministic state
Enable historical queries without storage bloat
AI Insertion Order
Tracks creation sequence of all AIs for deterministic reward distribution:
Storage Structure:
Implementation:
Purpose:
Reward Eligibility: Only first N AIs receive inflation (default: 500) - see Inflation Mechanism
Anti-Spam: Prevents dilution attacks via mass AI creation
Deterministic Iteration: Same order across all validators
Performance: O(1) lookups, O(N) iteration for rewards
Tensor Merging (Concurrent RfCs)
Multiple submissions in same block are merged:
Process:
Load existing tensor at current height
For each contributor:
If exists: Add contributions element-wise
If new: Append row
Store merged tensor
Purpose:
Prevents data loss from concurrent submissions
Accumulates all contributions within a block - see AI Tensor Matrix
Maintains accurate historical records
Range Queries
Prefix-Based Iteration
Enables efficient queries without full store scans:
All contributors for AI at height:
First N AIs:
Processing Limits
Governance parameters prevent unbounded iteration:
max_ais_for_rewards
500
Max AIs processed per block
max_ai_block_heights
1,000
Max historical blocks per AI
max_tensor_rows_per_block
1,000
Max contributor rows per block
These limits ensure operations complete within block time constraints. See Inflation Mechanism for how these parameters affect reward distribution.
Storage Optimization
Lazy Loading
Values loaded only when accessed:
Iterators don't load all values into memory
Reduces memory footprint
Improves query performance
Deterministic Ordering
Lexicographic key ordering ensures:
Consistent iteration across validators
Predictable range query results
Consensus-safe operations
Big-Endian Encoding
Block heights and indices use big-endian encoding:
Enables natural lexicographic ordering
Efficient range queries by height
Deterministic across architectures
Pruning Strategies
Archive Nodes:
Keep all historical IAVL versions
Enable queries at any block height
Higher storage requirements (~1TB+)
Pruning Nodes:
Retain recent N versions only (configurable)
Reduce storage footprint (~100GB)
Sufficient for validation and recent queries
Default Strategy:
Keep last 100,000 blocks + every 10,000th block
Balances storage efficiency with historical access
Data Integrity
Collision Resistance
Length-prefixed keys prevent unintended collisions:
Overflow Protection
Safe arithmetic when calculating storage offsets:
Validate AI ID length < 65,535 bytes (uint16 max)
Check array bounds before indexing
Use big-endian for consistent byte ordering
Validation at Write Time
State transitions validate before storage:
Contribution arrays match type count
Addresses are valid format
Allocations don't overflow uint64
Last updated