Consenso
ULedger utiliza un protocolo de consenso Tolerante a Fallas Bizantinas (BFT). Un council fijo de nodos validadores acuerda el orden y el contenido de los bloques. Una vez que el council finaliza un bloque, este es final de inmediato - no existe una ventana de confirmación probabilística.
El council
Un council es el conjunto de nodos validadores de una cadena. En la configuración estándar de producción:
| Parámetro | Valor |
|---|---|
| Tamaño del council | 9 nodos |
| Tolerancia a fallas | Hasta 3 nodos bizantinos (maliciosos o fallidos) |
| Umbral de consenso | Se requiere un acuerdo del 66.67% (2/3) |
| Finalidad del bloque | Inmediata al confirmar |
| Máximo de transactions por bloque | 200 |
Cada nodo mantiene una copia independiente del estado completo de la cadena. Los nodos se comunican mediante libp2p (transporte QUIC, mensajería GossipSub).
Producción de bloques
El nodo líder propone un bloque
│
▼
Los miembros del council validan las transactions propuestas
(verificaciones de ancestros, de capabilities y de listas negras)
│
▼
Los miembros emiten votos (BFT de 3 fases)
│
▼
Se alcanza el quórum (6 de 9 nodos de acuerdo)
│
▼
Bloque confirmado en todos los nodos
│
▼
Se aplican los cambios de estado: billeteras, entities, contratos, tokens
El líder rota de forma determinista entre los miembros del council.
Arquitectura multicadena
Un único council opera múltiples cadenas independientes de forma simultánea. En el despliegue estándar:
| Cadena | Algoritmo | Propósito |
|---|---|---|
| Cadena principal | secp256k1 | Cadena de consenso primaria |
| Cadena de miembros A | secp256k1 | Cadena secundaria de actividad de miembros |
| Cadena de miembros B | mldsa87 | Cadena de miembros post-cuántica |
Cada cadena tiene su propia instancia de consenso BFT. Un checkpoint requiere el acuerdo del quórum antes de escribirse en la cadena principal.
Checkpoints Helix STARK
Además del consenso BFT, ULedger produce pruebas criptográficas de checkpoint a lo largo de las épocas mediante el sidecar Helix. Cada checkpoint:
- Cubre una época completa de encabezados de bloque mediante una prueba Plonky3 STARK.
- Se pliega recursivamente en la prueba de la época anterior, produciendo una prueba de tamaño constante sobre un historial de cadena arbitrario.
- Se ancla mediante firmas
secp256k1ymldsa87(anclaje entre algoritmos).
Un auditor puede verificar todo el historial de la cadena únicamente a partir de las pruebas de checkpoint, sin acceso a ningún nodo en vivo.
Para el pipeline completo de pruebas de Helix, ver Helix: Sistema de pruebas STARK.
Referencias detalladas
- Mecanismo de consenso (Glosario) - detalle del protocolo BFT, elección de líder, fases de votación
- Descripción general de la arquitectura - puertos de los nodos, configuración del council, capa de red
- Helix: Sistema de pruebas STARK - generación de checkpoints y plegado recursivo de pruebas