Especificación Criptográfica

Especificación completa de todas las primitivas criptográficas utilizadas en Savitri Network.

Esquema de Firmas

Propiedad	Valor
Algoritmo	Ed25519
Biblioteca	ed25519-dalek
Clave privada	32 bytes
Clave pública	32 bytes (punto de Edwards comprimido)
Firma	64 bytes
Dirección	Clave pública codificada en hexadecimal (64 caracteres hex)

Firma de Transacciones

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 de Bloques

Los bloques son firmados por el proponente usando Ed25519 sobre el hash del encabezado de bloque (SHA-512).

Identidad de Pares

Los pares libp2p usan Ed25519 para sus claves de identidad de par (separadas de las claves de cuenta).

Funciones de Hash

SHA-256

Uso	Entrada	Salida
Mensaje de firma de transacción	Bytes canónicos TX	32 bytes
Compromiso monolítico	Campos del encabezado	32 bytes
Hash de enunciado ZKP	Campos del enunciado	32 bytes
Derivación de clave AES	Contraseña	32 bytes

SHA-512

Uso	Entrada	Salida
Hash de bloque	"BLK" + byte de versión + bytes de encabezado	64 bytes
Compromiso de encabezados	Árbol binario de encabezados de bloque	64 bytes

BLAKE3

Uso	Entrada	Salida
Hash rápido	Uso general	Variable
Cómputo de estado	Datos de estado	32 bytes

Keccak256

Uso	Entrada	Salida
Ranuras de almacenamiento de contratos	address || base_slot	8 bytes (u64)
Mapeos anidados	key || inner_hash	8 bytes (u64)

Separación de Dominios

Todos los cómputos de hash incluyen etiquetas de dominio para prevenir colisiones entre dominios:

Dominio	Etiqueta	Hash	Salida
Bloque	"BLK" + version: u8	SHA-512	64 bytes
Raíz TX	Etiqueta de hoja "TXv1"	Acumulador progresivo	32 bytes
Raíz de estado	Semilla "STATEv1-LE" + hoja "STATE"	Instantánea lexicográfica	32 bytes

Raíz de Transacciones

Calculada como un acumulador progresivo sobre bincode canónico de transacciones:

accumulator = H("TXv1")
for tx in transactions:
    leaf = bincode::serialize(tx)
    accumulator = H(accumulator || leaf)
tx_root = accumulator

Raíz de Estado

Calculada a partir de una instantánea lexicográfica de la base de datos:

seed = H("STATEv1-LE")
for (key, value) in storage.iter_sorted():
    leaf = H("STATE" || key || value)
    seed = H(seed || leaf)
state_root = seed

Cifrado

AES-256-GCM (En Reposo)

Usado para:

• Cifrado de claves privadas en el SDK
• Cifrado de columnas de base de datos móvil
• Cifrado de datos de dispositivos en el conector IoT

Propiedad	Valor
Algoritmo	AES-256-GCM
Tamaño de clave	256 bits
Tamaño de nonce	96 bits (12 bytes)
Tamaño de etiqueta	128 bits (16 bytes)
Derivación de clave	Basada en contraseña

Cifrado P2P

Propiedad	Valor
Protocolo	Noise (patrón de intercambio XX)
Intercambio de claves	X25519
Cifrado	ChaChaPoly
Multiplexación	Yamux

Derivación de Claves (Móvil)

BIP-39

• Lista de palabras: Inglés (2048 palabras)
• Entropía: 128 bits (12 palabras) o 256 bits (24 palabras)
• Mnemónico → Semilla: PBKDF2-HMAC-SHA512 (2048 rondas)

BIP-44

• Ruta: m/44'/1337'/0'/0/0
• Tipo de moneda: 1337 (Savitri)
• Cuenta: 0
• Cambio: 0 (externo)
• Índice: 0

Jerarquía de Claves

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)

Pruebas de Conocimiento Cero

Consulta Arquitectura ZKP para más detalles.

Backend	Curva	Sistema de Prueba	Caso de Uso
Mock	N/A	Siempre válido	Pruebas
Arkworks	BN254	Groth16	Producción
PLONK	BN254	PLONK	Uso general

Propiedades de Seguridad

Operaciones en Tiempo Constante

Toda la verificación de firmas usa comparación en tiempo constante (mediante el crate subtle) para prevenir ataques de canal lateral por tiempo.

Eliminación Segura de Claves

Las claves privadas se borran de forma segura al hacer drop usando el crate zeroize tanto en el SDK como en la aplicación móvil.

Protección contra Repetición

• Transacciones: Basada en nonce (incremento monótono por cuenta)
• Actualizaciones FL: Nonce por ronda por entrenador
• Fuentes de oráculos: Seguimiento de número de secuencia
• Mensajes P2P: Deduplicación mediante Gossipsub