Specifica Crittografica
Specifica completa di tutte le primitive crittografiche utilizzate nella Savitri Network.
Schema di Firma
| Proprietà | Valore |
|---|---|
| Algoritmo | Ed25519 |
| Libreria | ed25519-dalek |
| Chiave privata | 32 byte |
| Chiave pubblica | 32 byte (punto di Edwards compresso) |
| Firma | 64 byte |
| Indirizzo | Chiave pubblica con codifica esadecimale (64 caratteri hex) |
Firma delle Transazioni
message = from_hex_bytes || to_hex_bytes || amount_le_u64 || nonce_le_u64 || fee_le_u128
hash = SHA-256(message)
sig = Ed25519_sign(signing_key, hash)
Firma dei Blocchi
I blocchi vengono firmati dal proposer tramite Ed25519 sull'hash dell'intestazione del blocco (SHA-512).
Identità dei Peer
I peer libp2p utilizzano Ed25519 per le loro chiavi di identità peer (separate dalle chiavi dell'account).
Funzioni Hash
SHA-256
| Utilizzo | Input | Output |
|---|---|---|
| Messaggio di firma transazione | Byte TX canonici | 32 byte |
| Impegno Monolith | Campi intestazione | 32 byte |
| Hash statement ZKP | Campi statement | 32 byte |
| Derivazione chiave AES | Password | 32 byte |
SHA-512
| Utilizzo | Input | Output |
|---|---|---|
| Hash blocco | "BLK" + byte versione + byte intestazione | 64 byte |
| Commit intestazioni | Albero binario delle intestazioni blocco | 64 byte |
BLAKE3
| Utilizzo | Input | Output |
|---|---|---|
| Hash veloce | Uso generale | Variabile |
| Calcolo dello stato | Dati di stato | 32 byte |
Keccak256
| Utilizzo | Input | Output |
|---|---|---|
| Slot storage contract | address || base_slot | 8 byte (u64) |
| Mapping annidati | key || inner_hash | 8 byte (u64) |
Separazione dei Domini
Tutti i calcoli hash includono tag di dominio per prevenire collisioni tra domini:
| Dominio | Tag | Hash | Output |
|---|---|---|---|
| Blocco | "BLK" + version: u8 | SHA-512 | 64 byte |
| Radice TX | Tag foglia "TXv1" | Accumulatore rolling | 32 byte |
| Radice di stato | Seed "STATEv1-LE" + foglia "STATE" | Snapshot lessicografico | 32 byte |
Radice delle Transazioni
Calcolata come accumulatore rolling sul bincode canonico delle transazioni:
accumulator = H("TXv1")
for tx in transactions:
leaf = bincode::serialize(tx)
accumulator = H(accumulator || leaf)
tx_root = accumulator
Radice di Stato
Calcolata da uno snapshot lessicografico del database:
seed = H("STATEv1-LE")
for (key, value) in storage.iter_sorted():
leaf = H("STATE" || key || value)
seed = H(seed || leaf)
state_root = seed
Cifratura
AES-256-GCM (A Riposo)
Utilizzato per:
- Cifratura delle chiavi private nell'SDK
- Cifratura delle colonne del database mobile
- Cifratura dei dati dei dispositivi nel connettore IoT
| Proprietà | Valore |
|---|---|
| Algoritmo | AES-256-GCM |
| Dimensione chiave | 256 bit |
| Dimensione nonce | 96 bit (12 byte) |
| Dimensione tag | 128 bit (16 byte) |
| Derivazione chiave | Basata su password |
Cifratura P2P
| Proprietà | Valore |
|---|---|
| Protocollo | Noise (pattern di handshake XX) |
| Scambio di chiavi | X25519 |
| Cifrario | ChaChaPoly |
| Multiplexing | Yamux |
Derivazione delle Chiavi (Mobile)
BIP-39
- Wordlist: Inglese (2048 parole)
- Entropia: 128 bit (12 parole) o 256 bit (24 parole)
- Mnemonica → Seed: PBKDF2-HMAC-SHA512 (2048 iterazioni)
BIP-44
- Percorso:
m/44'/1337'/0'/0/0 - Tipo di moneta: 1337 (Savitri)
- Account: 0
- Change: 0 (esterno)
- Indice: 0
Gerarchia delle Chiavi
mnemonic → seed (512 bits)
→ master_key (via HMAC-SHA512)
→ m/44' → m/44'/1337' → m/44'/1337'/0'
→ m/44'/1337'/0'/0 → m/44'/1337'/0'/0/0
→ ed25519_private_key (32 bytes)
→ ed25519_public_key (32 bytes)
→ address (hex-encoded, 64 chars)
Prove a Conoscenza Zero
Vedi Architettura ZKP per i dettagli.
| Backend | Curva | Sistema di Prove | Caso d'Uso |
|---|---|---|---|
| Mock | N/A | Sempre valido | Test |
| Arkworks | BN254 | Groth16 | Produzione |
| PLONK | BN254 | PLONK | Uso generale |
Proprietà di Sicurezza
Operazioni a Tempo Costante
Tutta la verifica delle firme utilizza confronti a tempo costante (tramite crate subtle) per prevenire attacchi side-channel basati sul timing.
Azzeramento delle Chiavi
Le chiavi private vengono azzerate al drop tramite il crate zeroize sia nell'SDK che nell'app mobile.
Protezione dal Replay
- Transazioni: Basata sul nonce (monotonicamente crescente per account)
- Aggiornamenti FL: Nonce per round per trainer
- Feed oracle: Tracciamento del numero di sequenza
- Messaggi P2P: Deduplicazione Gossipsub