Mecanismo de Consenso de ULedgerNET

Descripción General

ULedgerNET emplea un mecanismo de consenso Tolerante a Fallas Bizantinas (BFT) basado en Consejo. Este diseño proporciona finalidad inmediata, elección de líder determinista y resiliencia contra fallas bizantinas de hasta ⅓ de los nodos participantes.

Modelo de Consenso

Estructura del Consejo

El consenso es gestionado por un consejo de nodos autorizados que participan en la producción y validación de bloques.

🔍 click to expand

Propiedades Clave

Propiedad	Valor	Descripción
Umbral de Consenso	66.67% (⅔)	Votos requeridos para la finalización del bloque
Tamaño Mínimo del Consejo	3 nodos	Mínimo para tolerancia a fallas byzantinas
Tolerancia a Fallas	f < n/3	Puede tolerar hasta ⅓ de nodos maliciosos
Finalidad	Inmediata	No se requiere confirmación probabilística

Protocolo de Votación de Tres Fases

ULedgerNET utiliza un protocolo de confirmación en tres fases para alcanzar el consenso:

🔍 click to expand

Detalles de las Fases

Fase 1: PreVote

🔍 click to expand

Verificaciones de Validación:

• Integridad del hash del bloque
• Firma válida del líder
• Altura de bloque correcta
• Prueba Merkle válida
• Verificación de prueba ZK

Fase 2: PreCommit

🔍 click to expand

Fase 3: Commit

🔍 click to expand

Elección de Líder

Selección Determinista

El líder para cada ronda de votación se selecciona de forma determinista basándose en:

• Hash del bloque anterior
• Altura del bloque
• Número de ronda actual

🔍 click to expand

Rotación de Líder

🔍 click to expand

Propiedades:

• Impredecible más de un bloque por adelantado (depende del hash del bloque)
• Determinista dados los mismos valores de entrada
• Rota al agotarse el tiempo de la ronda para garantizar vivacidad

Tiempo de Espera y Recuperación

Mecanismo de Tiempo de Espera

🔍 click to expand

Escenarios de Recuperación

Escenario	Acción de Recuperación
Líder Sin Conexión	Tiempo agotado → Nueva elección de líder
Partición de Red	Continuar con la mayoría de ⅔ disponible
Líder Malicioso	Votos rechazados → Tiempo de ronda agotado
Red Lenta	Duración de tiempo de espera configurable

Estructura del Voto

Cada voto en el protocolo contiene:

🔍 click to expand

Validación de Votos

1. Validación Estructural

   • El votante está en el consejo
   • Etapa de voto correcta
   • Número de ronda coincidente
   • Altura de bloque válida

2. Validación Criptográfica

   • Verificación de firma usando la clave pública del votante
   • Verificación de integridad del mensaje

Diagrama de Flujo de Consenso

🔍 click to expand

Gestión del Consejo

Unirse al Consejo

🔍 click to expand

Abandonar el Consejo

🔍 click to expand

Consideraciones de Rendimiento

Optimizaciones

1. Agrupación de Votos: Los votos pendientes se ponen en cola y se procesan en lotes
2. Buffer de Propuestas: Las propuestas futuras se almacenan en buffer para entrega fuera de orden
3. Validación Paralela: La validación de bloques ocurre de forma concurrente en todo el consejo

Escalabilidad

Tamaño del Consejo	Mensajes de Consenso	Impacto en Latencia
3 nodos	~6 por bloque	Línea base
5 nodos	~10 por bloque	+10-20%
10 nodos	~20 por bloque	+30-50%
20+ nodos	~40+ por bloque	Considerar fragmentación

---

Siguiente: Cross-Merkleization