Architettura dello Storage

Savitri Network utilizza RocksDB come backend di storage principale con column family per l'isolamento dei dati e pattern di accesso efficienti.

Column Family

Column Family	Chiave	Valore	Scopo
CF_BLOCKS	altezza (u64 LE)	Blocco (bincode)	Storage blocchi
CF_TRANSACTIONS	tx_hash (32 byte)	Transazione (bincode)	Ricerca transazioni
CF_ACCOUNTS	indirizzo (32 byte)	Account (24 byte)	Saldo + nonce
CF_METADATA	chiave stringa	vario	Testa della catena, configurazione
CF_RECEIPTS	tx_hash	Ricevuta (bincode)	Ricevute delle transazioni
CF_CONTRACTS	indirizzo	ContractInfo	Stato degli smart contract
CF_GOVERNANCE	proposal_id	Proposta (bincode)	Proposte di governance
CF_ORACLE	feed_id	OracleData	Feed degli oracoli
CF_BONDS	indirizzo	Importo cauzione	Cauzioni dei validatori
CF_VOTE_TOKENS	indirizzo	Saldo VoteToken	Token di voto per la governance
CF_TREASURY	chiave	Stato treasury	Treasury di rete
CF_VESTING	schedule_id	VestingSchedule	Vesting dei token
CF_REWARD_COINS	indirizzo	Saldo ricompense	Ricompense dei nodi
CF_FEE_METRICS	chiave	Dati commissioni	Monitoraggio commissioni
CF_SUPPLY_METRICS	chiave	Dati offerta	Offerta di token
CF_ACTIVE_NODES	node_id	Attività	Stato attivo del nodo
CF_MONOLITHS	monolith_id	Monolith	Compressione blocchi
CF_FL	chiave	Dati FL	Apprendimento federato
CF_POU	node_id	Punteggio PoU	Punteggi di consenso

Codifica dell'Account

Gli account utilizzano una codifica compatta a larghezza fissa di 24 byte:

Byte 0-15:  saldo (u128, little-endian)
Byte 16-23: nonce  (u64, little-endian)

Compatibilità con versioni precedenti: il vecchio formato a 16 byte (solo saldo, nonce=0) è ancora supportato.

Gli account vuoti (saldo=0, nonce=0) non vengono mai salvati per risparmiare spazio di archiviazione.

State Root

La state root viene calcolata tramite snapshot lessicografico del database:

seed  = H("STATEv1-LE")
leaf  = H("STATE" || key || value)  per ogni coppia chiave-valore
root  = rolling_accumulate(seed, leaf_1, leaf_2, ..., leaf_n)

Le chiavi vengono iterate in ordine lessicografico per garantire il determinismo.

Trait dello Storage

Tutti i backend di storage implementano il StorageTrait:

pub trait StorageTrait: Send + Sync {
    fn get_cf(&self, cf: &str, key: &[u8]) -> Result<Option<Vec<u8>>>;
    fn put_cf(&self, cf: &str, key: &[u8], value: &[u8]) -> Result<()>;
    fn delete_cf(&self, cf: &str, key: &[u8]) -> Result<()>;
    fn get_cf_prefix(&self, cf: &str, prefix: &[u8]) -> Result<Vec<(Vec<u8>, Vec<u8>)>>;
    // ... operazioni batch, iterazione, ecc.
}

Deserializzazione Sicura

Tutta la deserializzazione bincode utilizza un limite massimo di dimensione per prevenire l'esaurimento della memoria:

const MAX_BINCODE_SIZE: u64 = 16 * 1024 * 1024; // 16MB

Caching

Livello di cache LRU per i dati a cui si accede frequentemente:

• Cache account: riduce le letture RocksDB per le verifiche saldo/nonce
• Cache storage contratti: memorizza i risultati SLOAD nell'esecuzione dei contratti
• Cache punteggi: cache LRU per la valutazione TX nel mempool (evita il ricalcolo)

Configurazione RocksDB

Parametro	Sviluppo	Produzione
Dimensione cache	256 MB	1024 MB
Buffer di scrittura	16 MB	64 MB
Max file aperti	100	1000
Intervallo sync	5s	30s
Compressione	Disabilitata	Abilitata

Operazioni Batch

Le scritture batch atomiche garantiscono la coerenza:

let mut batch = storage.batch();
batch.put_cf(CF_ACCOUNTS, &addr, &account.encode());
batch.put_cf(CF_TRANSACTIONS, &tx_hash, &tx_bytes);
batch.put_cf(CF_BLOCKS, &height_key, &block_bytes);
batch.commit()?;

Sistema di Vesting

I piani di vesting dei token supportano tre tipi:

Tipo	Comportamento
Linear	Token rilasciati linearmente nel tempo
Cliff	Nessun token prima del periodo cliff, poi lineare
Staged	Modalità di compatibilità genesis

Flag di Funzionalità

Flag	Descrizione
rocksdb	Backend RocksDB (predefinito)
memory	Backend in memoria (test)
prometheus	Esportazione metriche Prometheus
tempfile	Storage temporaneo per i test