Límites de recuperación ante fallos de Blind Vault y MemChain
Qué se recupera tras una interrupción, qué cubren las pruebas y por qué durabilidad ante corte eléctrico, recuperación de claves y despliegue fleet son afirmaciones distintas.
Límites de recuperación ante fallos de Blind Vault y MemChain
Implementado en source
Blind Vault guarda ciphertext inmutable en transacciones SQLite WAL acotadas; un registro committed puede leerse tras process restart. MemChain AOF valida framing/enlaces semánticos y corta solo una cola física incompleta; un registro completo corrupto se conserva y falla cerrado. Una tarea processing vencida puede volver a pending tras su lease, sin garantizar reanudación exacta del model call ni ausencia de duplicados.
Pruebas automatizadas
Pasaron 5 tests base: Blind Vault retry/pull, continuidad del issuer tras restart, AOF torn-tail repair, complete corruption no-truncate y stale-claim reset. En la commander integration line reparada también pasaron 6 tests replica-recovery store de restart recovery, compatibilidad V1, corrupción y conflict/rollback fail-closed. No son evidencia de un fleet crash drill.
Fleet actual
El snapshot 2026-08-31 muestra 3 followers con local verified commitment history, pero sin active coordinator, strict checkpoint threshold ni witness-certified tip. El drill r6 sigue sin verificar.
SQLite synchronous=NORMAL y flush sin fsync no prueban zero-loss ante power loss. El AOF legacy puede contener Facts legibles por el nodo y no es ciphertext history; sealed storage es otra ruta. No se recuperan identity/key perdidas, una replica completa, consensus ni finality.