Helix: Sistema de Pruebas STARK

Descripción General

Helix es el motor de la pista de auditoría de ULedgerNET. Se ejecuta como un proceso sidecar junto a cada nodo validador y produce pruebas STARK: puntos de control criptográficos que comprimen todo el historial de la salida de consenso del council en una prueba corta y verificable.

Helix es la característica que convierte la afirmación "la pista de auditoría no puede falsificarse" en un enunciado demostrable en lugar de una declaración de política. No es un componente opcional; es el fundamento de la garantía de evidencia de manipulación de ULedgerNET.

¿Qué Es una Prueba STARK?

Una STARK (Scalable Transparent ARgument of Knowledge, o Argumento de Conocimiento Transparente y Escalable) es una prueba criptográfica de que un cómputo se realizó correctamente, sin requerir que el verificador vuelva a ejecutarlo.

En el contexto de ULedgerNET:

El cómputo es: "el council de nodos alcanzó consenso BFT sobre estos bloques, en este orden, con estas raíces de transactions."
La prueba es: un artefacto corto (de unos pocos kilobytes) que garantiza matemáticamente lo anterior.
El verificador es: cualquier parte que tenga las claves públicas del council, incluido un auditor independiente sin acceso a ningún nodo activo.

ULedgerNET utiliza Plonky3, un sistema de pruebas STARK recursivo, para generar estas pruebas.

¿Por Qué Pruebas STARK para las Pistas de Auditoría?

Los registros de auditoría tradicionales fallan en estas condiciones:

Compromiso del administrador: un administrador malintencionado puede alterar o eliminar archivos de registro.
Compromiso del sistema: un atacante que controle la base de datos puede reescribir el historial.
Acceso del proveedor: el operador de la plataforma puede modificar registros de forma silenciosa.
Ataques basados en el tiempo: los registros de hace semanas pueden ser retrofechados si el sistema de registro carece de integridad de secuencia.

Los puntos de control STARK eliminan estos modos de falla:

Inmutable: una vez que se genera y distribuye una prueba de punto de control, alterar los bloques subyacentes produciría una prueba diferente, detectable de inmediato por cualquier verificador.
Transparente: las pruebas STARK no requieren una configuración de confianza (trusted setup). No existe una ceremonia secreta ni una parte de confianza cuyo compromiso pudiera socavar el sistema de pruebas.
Compacta: el plegado recursivo de pruebas significa que todo el historial de la cadena se representa en una prueba de tamaño constante, sin importar cuántos bloques existan.
Independiente del verificador: un auditor puede verificar la prueba usando únicamente el artefacto de la prueba y las claves públicas del council. No se requiere acceso al sistema activo, al SDK ni a los archivos de billetera.
Anclada poscuántica: los puntos de control se firman con firmas secp256k1 (clásica) y ML-DSA-87 (poscuántica), lo que asegura que la prueba siga siendo válida incluso si la criptografía clásica es vulnerada.

Arquitectura de Helix

┌─────────────────────────────────────────────────────────────────────┐
│                        Council (9 nodes)                            │
│                                                                     │
│  Node 1          Node 2          Node 3     ...     Node 9          │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐       ┌──────────┐     │
│  │  Blocks  │   │  Blocks  │   │  Blocks  │       │  Blocks  │     │
│  │ (BFT     │   │ (BFT     │   │ (BFT     │       │ (BFT     │     │
│  │ consensus│   │ consensus│   │ consensus│       │ consensus│     │
│  └────┬─────┘   └────┬─────┘   └────┬─────┘       └────┬─────┘     │
│       │              │              │                   │           │
│  ┌────▼─────┐   ┌────▼─────┐   ┌────▼─────┐       ┌────▼─────┐    │
│  │  Helix   │   │  Helix   │   │  Helix   │       │  Helix   │    │
│  │ Sidecar  │   │ Sidecar  │   │ Sidecar  │       │ Sidecar  │    │
│  └──────────┘   └──────────┘   └──────────┘       └──────────┘    │
└─────────────────────────────────────────────────────────────────────┘
                              │
                   Epoch batch (block headers + member data)
                              │
                              ▼
                   ┌──────────────────────────┐
                   │   Plonky3 STARK Prover   │
                   │   (Rust sidecar process) │
                   └──────────────────────────┘
                              │
                   STARK proof for this epoch
                              │
                              ▼
                   ┌──────────────────────────┐
                   │  Recursive Proof Folding  │
                   │  (prior proof ← new proof)│
                   └──────────────────────────┘
                              │
                   Checkpoint written to principal chain
                   (secp256k1 + ML-DSA-87 cross-anchor)
                              │
                              ▼
                   ┌──────────────────────────┐
                   │  Independent Auditor      │
                   │  (no node access needed) │
                   │  Verifies checkpoint proof│
                   └──────────────────────────┘

Qué Demuestra un Punto de Control

Una prueba de punto de control de Helix garantiza matemáticamente:

Consenso de quórum: los miembros del council cuyas firmas aparecen en la prueba efectivamente votaron por este punto de control. Una minoría bizantina no puede falsificar el quórum.
Encadenamiento de altura: la altura de bloque de cada punto de control es estrictamente mayor que la del punto de control anterior. Se detectan los saltos; ningún bloque puede omitirse en silencio.
Disponibilidad de datos de los member-heads: los datos de bloque de las cadenas de los miembros eran accesibles y consistentes al momento del punto de control. Se detecta cualquier retención o manipulación de los datos de los miembros.
Integridad de la cadena de recibos: los recibos de transactions forman una cadena de Merkle válida. Una transaction individual no puede insertarse ni eliminarse retroactivamente.
Comportamiento de omisión sin cambios: las épocas en las que no se produjeron bloques nuevos se registran correctamente como omitidas; la altura del punto de control no avanza falsamente.
Anclaje entre algoritmos: las firmas clásicas (secp256k1) y poscuánticas (ML-DSA-87) anclan el punto de control, lo que garantiza su durabilidad frente a futuros avances criptográficos.

Cadencia de Épocas

Helix produce puntos de control con una cadencia basada en el tiempo (acuñación automática):

Cada sidecar de Helix monitorea la cadena de su nodo en busca de nuevos bloques finalizados.
Después de un intervalo de época configurado (o cuando se alcanza un umbral de bloques), el sidecar inicia la generación de la prueba.
La generación de la prueba la realiza el subproceso del prover Plonky3 en Rust.
El punto de control completado se envía como una transaction CHECKPOINT_MARKER a la cadena principal.
El auditor independiente (que se ejecuta por separado de todos los nodos) obtiene y verifica cada punto de control a medida que aparece.

Auditor Independiente

El auditor independiente es un proceso autónomo (separado de todos los nodos validadores) que:

Se conecta a la cadena principal mediante su propio endpoint.
Obtiene cada transaction CHECKPOINT_MARKER a medida que aparece.
Verifica la prueba STARK incrustada usando la herramienta checkpoint_verify.
Registra el resultado de aprobado/fallido de cada punto de control.

El auditor no tiene acceso de escritura a ninguna cadena. No puede ser silenciado por un nodo comprometido. Su registro de verificación es la fuente de verdad sobre si la pista de auditoría está intacta.

Caos y Resiliencia

El runbook de Helix define cinco perfiles de inyección de caos para el clúster de Docker:

Perfil	Descripción
`light`	Retraso de red en un subconjunto de nodos (simula peers lentos).
`medium`	Pérdida de paquetes en un subconjunto de nodos (simula enlaces poco fiables).
`catastrophic`	Retraso y pérdida elevados (simula una casi partición).
`byzantine-a`	Un nodo envía votos contradictorios a distintos peers.
`byzantine-b`	Un nodo retiene datos de bloque mientras participa en el consenso.

Bajo todos los perfiles, el comportamiento esperado es:

El council sobrevive: el consenso BFT continúa con la mayoría honesta.
Los puntos de control se producen eventualmente: la generación de pruebas puede retrasarse, pero no detenerse.
La recuperación converge: el clúster se reconverge y reanuda la cadencia normal de puntos de control.
Se detecta la equivocación: se identifican los nodos bizantinos que intentan firmar doble.

La lista de verificación de 20 elementos (aprobado/fallido) del runbook cubre todos estos escenarios.

Qué No Demuestra Helix

Helix demuestra que el historial de la cadena se registró correctamente; no demuestra:

Que los agentes tomaron decisiones correctas.
Que la lógica de los smart contracts es correcta.
Que los datos enviados a las transactions fueran exactos o veraces.

Demuestra que lo que se haya enviado, se envió: en el orden indicado, por las billeteras indicadas, en las alturas de bloque indicadas, y acordado por un quórum de validadores.

Herramientas

Herramienta	Propósito
Binario sidecar `helix`	Se ejecuta junto a cada nodo; recopila bloques, controla el prover y envía puntos de control.
Prover Plonky3 (Rust)	Genera pruebas STARK a partir de lotes de épocas.
`checkpoint_verify`	Herramienta CLI para auditores independientes; verifica una prueba de punto de control sin acceso a los nodos.
Sidecar auditor	Proceso automatizado que obtiene y verifica todos los puntos de control en tiempo real.

Descripción General​

¿Qué Es una Prueba STARK?​

¿Por Qué Pruebas STARK para las Pistas de Auditoría?​

Los registros de auditoría tradicionales fallan en estas condiciones:​

Los puntos de control STARK eliminan estos modos de falla:​

Arquitectura de Helix​

Qué Demuestra un Punto de Control​

Cadencia de Épocas​

Auditor Independiente​

Caos y Resiliencia​

Qué No Demuestra Helix​

Herramientas​