Saltar al contenido
Financial Context Wiki

Tolerancia a fallos bizantinos: seguridad, vivacidad y cuórums

La tolerancia a fallos bizantinos describe cuándo un protocolo distribuido conserva seguridad y vivacidad frente a fallos arbitrarios. Deben evaluarse conjuntamente el protocolo, el modelo de red, el límite de fallos, el cuórum, los pesos, la finalidad y la recuperación.

Actualizado

Material educativo de análisis de protocolos. La etiqueta BFT o un umbral de cuórum no demuestran por sí solos seguridad, vivacidad, ejecución correcta, descentralización, finalidad ni seguridad de los activos.

Respuesta directa

La tolerancia a fallos bizantinos (BFT) es una propiedad de un protocolo distribuido concreto bajo modelos de fallos y de red concretos: mantiene sus garantías declaradas aunque algunos participantes fallen, retengan mensajes, envíen mensajes incompatibles a distintos pares o actúen arbitrariamente. BFT no es un único algoritmo ni significa que todos los servicios sigan disponibles durante cualquier partición.

Las garantías deben separarse. safety (seguridad) impide que participantes honestos decidan valores incompatibles; liveness (vivacidad) permite que entradas admisibles acaben produciendo una decisión; validity (validez) limita qué valores pueden decidirse. Un protocolo puede detenerse para preservar la seguridad cuando faltan comunicación o poder de voto honesto. Un consenso correcto tampoco demuestra que sean correctos el código de aplicación, las reglas de validez, los puentes, las claves o la gobernanza.

En una clase habitual de protocolos BFT autenticados y parcialmente síncronos, n=3f+1 réplicas toleran como máximo f réplicas bizantinas y un certificado de compromiso utiliza q=2f+1 votos. Las expresiones «menos de un tercio defectuoso» y «cuórum superior a dos tercios» proceden de ese modelo. Protocolos síncronos, protocolos asíncronos aleatorizados, protocolos de fallos por caída, cadenas de prueba de trabajo y otras construcciones BFT pueden tener otros supuestos y umbrales.

En sistemas ponderados por participación, el umbral se refiere al poder de voto definido por el protocolo, no necesariamente al número de validadores, direcciones, personas u operadores independientes. Antes de aplicar una fracción hay que indicar versión exacta, instantánea de pesos, tipo de decisión, supuesto de red, comparación de cuórum (> o >=) y conducta defectuosa.

Por debajo del umbral
25%
Participación adversaria
25%
Margen hasta el umbral
8,4%

Los resultados son aproximaciones educativas. Salvo que se indiquen, excluyen reglas del mercado, impuestos, latencia, comportamiento de oráculos y otros parámetros específicos del protocolo.

Cómo funciona

  1. Definir la decisión. Determinar si los nodos ordenan transacciones, comprometen un bloque, finalizan un punto de control, eligen líder, aceptan una transición de estado o seleccionan una bifurcación. No son decisiones intercambiables.
  2. Declarar el modelo de sistema y adversario. Registrar membresía, autenticación, cambios de permisos, pesos, corrupción adaptativa, claves comprometidas, equivocación, caídas, pérdida de mensajes, censura, denegación de servicio y posibles fallos correlacionados.
  3. Declarar el modelo de red. Distinguir sincronía, sincronía parcial y asincronía. En sincronía parcial, identificar qué solo se garantiza tras un tiempo global de estabilización desconocido y cómo se adaptan los plazos.
  4. Derivar la regla de cuórum. Usar el umbral y las reglas de bloqueo o voto exactos. En el caso clásico n=3f+1, dos cuórums 2f+1 se solapan en al menos f+1 réplicas; si como máximo f son bizantinas, la intersección contiene una honesta.
  5. Seguir cada fase y certificado. Verificar propuesta, voto, bloqueo, cambio de vista o ronda, compromiso, selección de bifurcación y recuperación. Una supermayoría firmada solo vale si se validan altura, ronda, valor, padre, dominio, época de membresía y certificado anterior.
  6. Separar las pruebas de seguridad y vivacidad. Probar qué decisiones incompatibles quedan excluidas en todo momento relevante y después comprobar que el progreso vuelve cuando se cumplen los supuestos de comunicación y participación honesta. Un plazo es una herramienta de programación, no prueba de malicia.
  7. Verificar implementación y operación. Contrastar con el modelo la diversidad de clientes, custodia de claves, conmutación de firmantes, protección antirrepetición, sincronización de estado, pruebas, cambios de miembros, monitorización, política de confirmación y recuperación.

El resultado FLP afirma que un protocolo de consenso determinista no puede garantizar terminación en un modelo totalmente asíncrono incluso con una posible caída. No afirma que la seguridad sea imposible ni que el consenso distribuido nunca funcione. Sincronía parcial, aleatoriedad, detectores de fallos, supuestos económicos o garantías más débiles modifican de formas distintas las condiciones precisas de imposibilidad.

Ejemplos calculados

1. Cuatro réplicas con igual peso

Sean n=4, f=1 y q=3. Dos conjuntos de tres votos se solapan en al menos 3+3-4=2 réplicas. Con una sola réplica bizantina como máximo, al menos una de la intersección es honesta. Si las reglas honestas prohíben votar valores incompatibles en el historial pertinente de altura y ronda, no pueden formarse dos certificados de compromiso incompatibles.

Si dos réplicas están desconectadas, solo quedan 2 votos y no se forma un certificado q=3. Es un fallo de vivacidad, no automáticamente de seguridad: un protocolo seguro espera en vez de reducir localmente el umbral.

2. Siete réplicas con igual peso

Sean n=7, f=2 y q=5. Dos cuórums se solapan en al menos 5+5-7=3=f+1 réplicas. Como como máximo 2 son bizantinas, hay una honesta en la intersección. Dos réplicas bizantinas no pueden crear solas un certificado de cinco votos, pero tres ausentes o que retengan votos dejan solo 4 y pueden detener el progreso.

La aritmética del umbral es necesaria, pero no suficiente. Si implementaciones honestas aceptan votos de otra altura, reutilizan una membresía, infringen un bloqueo o firman con claves comprometidas, los supuestos de la prueba ya no describen el sistema desplegado.

3. Poder de voto ponderado

Supongamos pesos 40, 30, 20 y 10, total 100, y que un certificado exige estrictamente más de 2/3, implementado aquí como al menos 67. La coalición 40+30=70 puede certificar; 30+20+10=60 no, aunque reúna tres de cuatro validadores. Si el validador de peso 40 queda fuera de línea, solo queda 60 y se detiene la finalidad.

Dos conjuntos de al menos 67 se solapan en al menos 67+67-100=34. Por tanto, certificados incompatibles implican que al menos 34 de peso participó en ambos o falló otro supuesto. En ciertos protocolos basta algo más de un tercio de equivocación para violar seguridad; «hacen falta dos tercios para atacar» no es un mínimo universal.

4. Sincronía parcial y plazos

Supongamos plazos de ronda de 1 s, 2 s, 4 s y 8 s. Antes del momento desconocido de estabilización, los mensajes pueden llegar después de cada plazo y provocar cambios de ronda sin decisión. Si después la demora queda por debajo de 3 s, una ronda de 4 s o posterior puede dar tiempo suficiente a un proponente honesto y un cuórum, siempre que se cumplan los demás supuestos.

Las cifras ilustran progreso eventual, no una fórmula universal. Plazos cortos causan cambios innecesarios; largos, una recuperación lenta. La seguridad no debe depender de adivinar el límite de demora antes de la estabilización.

Riesgos y fallos de revisión

Modelo y prueba

  • Decir «BFT» sin nombrar protocolo, versión, decisión, modelo de fallos, red, membresía y umbral.
  • Aplicar n=3f+1 o un tercio a todo registro distribuido aunque su prueba use otros supuestos.
  • Confundir seguridad, vivacidad, validez, disponibilidad, consistencia, finalidad, elección de bifurcación y corrección de transacciones.
  • Afirmar que FLP hace imposible el consenso sin conservar sus condiciones determinista, totalmente asíncrona y de terminación garantizada.
  • Contar nodos o direcciones cuando el protocolo cuenta participación, delegación, comités, épocas u otro recurso.
  • Redondear ambiguamente «dos tercios» o ignorar >, >=, pesos enteros y la instantánea del denominador.
  • Revisar tamaño de cuórum sin revisar intersección, bloqueos, certificados, cambios de vista, reconfiguración y transferencia de estado.
  • Suponer que una prueba cubre corrupción adaptativa, robo de claves, fallos correlacionados, denegación de servicio o historias de largo alcance.

Implementación y operación

  • Aceptar firmas sin vincular cadena, dominio, altura, ronda, valor, padre, época de membresía y tipo de mensaje.
  • Repetir votos o certificados antiguos entre rondas, alturas, bifurcaciones, redes, actualizaciones o cambios de validadores.
  • Permitir doble firma, regresión de bloqueo, conmutación insegura o dos réplicas activas con una identidad de validador.
  • Tratar el vencimiento de un plazo como prueba de malicia y decidir sobre seguridad solo con relojes locales.
  • Ignorar fallos correlacionados por cliente, nube, región, red, hardware, claves u operador común.
  • Suponer que las penalizaciones impiden fallos, recuperan vivacidad, revierten acciones finalizadas o compensan a todos.
  • Probar solo el caso normal y no particiones, demoras, reordenamientos, equivocación, fallos del proponente, reinicios y cambios de miembros.

Aplicación y gobernanza

  • Tratar un valor comprometido como estado válido sin ejecución determinista ni validación de transición.
  • Acreditar depósitos, emitir activos puente o liquidar operaciones antes de la condición exacta de finalidad exigida.
  • Equiparar finalidad del protocolo con irreversibilidad social tras claves comprometidas, fallos de software o intervención de gobernanza.
  • Ignorar censura y demora de inclusión porque los bloques de otros usuarios continúan finalizándose.
  • Inferir descentralización, seguridad de activos, valor del token o exigibilidad jurídica de la etiqueta BFT o del número anunciado de validadores.

Errores comunes

  • BFT significa que la red nunca se detiene. Muchos protocolos sacrifican deliberadamente vivacidad durante fallos excesivos o particiones para preservar seguridad.
  • Siempre basta con más del 51% de participantes honestos. El umbral depende del protocolo; el BFT parcialmente síncrono clásico suele exigir más de dos tercios del poder relevante para progresar.
  • Un atacante siempre necesita dos tercios para romper seguridad. Dos tercios pueden certificar solos, pero dos certificados incompatibles pueden revelar apenas más de un tercio de equivocación.
  • Más direcciones de validadores mejoran automáticamente la tolerancia. Propiedad común, delegaciones, clientes, infraestructura, claves y dominios de fallo determinan la independencia.
  • La penalización es la prueba BFT. Es una respuesta económica de algunos sistemas PoS; la seguridad procede de reglas y supuestos y la sanción no deshace consecuencias externas.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...