Vectores de ataque en BFT modernos: Equivocation, Sybil, Long-Range y Censura

Un protocolo BFT no promete resistir a cualquier adversario. Promete resistir a uno que controla como mucho $f$ de $n = 3f + 1$ participantes, que no falsifica firmas y que, tarde o temprano, deja que la red entregue mensajes. [1] Cada ataque de este artículo empuja contra uno de esos supuestos: la equivocación pone a prueba la regla de votación, el ataque Sybil el conteo de $f$, el largo alcance la idea de que una clave retirada ya no importa, y la censura el progreso.

La estructura es la misma en las cuatro secciones: qué hace el atacante, qué supuesto toca y qué mecanismo documentado lo contiene. Sin cifras de marketing: donde la literatura dice que una defensa es parcial, lo decimos.

Equivocación: dos firmas incompatibles para el mismo lugar

Equivocar es enviar mensajes contradictorios para el mismo punto del protocolo: un líder que propone el bloque A a una parte de la red y el B a otra, o un votante que firma ambos. Es el comportamiento bizantino por excelencia, y es exactamente lo que la intersección de quórums neutraliza.

En HotStuff, una réplica correcta vota a lo sumo una vez por fase en cada vista $v$, y un QC agrega $n - f$ votos. Dos QCs del mismo tipo y la misma vista para bloques en conflicto necesitarían que sus quórums compartieran una réplica correcta que votó dos veces, lo que el protocolo prohíbe; de ahí que no puedan coexistir. [1] El líder bizantino puede enviar A a unos y B a otros, pero a lo sumo una de las dos propuestas reúne un QC. La aritmética del cruce está desarrollada en Quórums en acción.

Eso protege safety, pero no castiga a nadie. Aquí entra la segunda mitad de la defensa: los votos son mensajes firmados, y dos firmas del mismo autor sobre mensajes incompatibles son una prueba que cualquiera puede verificar. Casper FFG convierte esa observación en reglas explícitas. Sus dos "mandamientos" prohíben a un validador publicar dos votos distintos con la misma altura de destino, y votar dentro del intervalo de otro voto propio. [2]

Si un validador viola cualquiera de las dos condiciones, la evidencia puede incluirse en la cadena como transacción; en el diseño del paper, el validador pierde todo su depósito y quien envía la prueba recibe una pequeña recompensa. [2] El resultado formal es la accountable safety: dos checkpoints en conflicto solo pueden finalizarse si validadores con al menos un tercio del depósito violan una condición de slashing. [2]

La lectura práctica: la intersección de quórums garantiza que la equivocación de hasta $f$ participantes no rompa safety, y las firmas garantizan que, si safety se rompe, haya culpables identificables con evidencia criptográfica. Son dos propiedades distintas y conviene no fundirlas. Una salvedad de calendario: la evidencia tiene que llegar a la cadena para que haya sanción, y un proponente corrupto puede retrasarla. El propio paper reconoce que un mecanismo de propuesta corrupto puede impedir la finalidad. [2]

Sybil: por qué el umbral f necesita identidades caras

Toda la sección anterior supone algo que nunca escribimos: que $f$ cuenta entidades independientes. Si crear una identidad es gratis, un único adversario puede fabricar las que necesite y superar cualquier umbral. Douceur bautizó este problema como ataque Sybil: en sistemas que se defienden con redundancia, una entidad defectuosa que presenta varias identidades puede controlar una fracción sustancial del sistema y anular esa redundancia. [3]

Su resultado es tajante. Una forma de evitarlo es que una agencia de confianza certifique las identidades; sin una autoridad lógicamente centralizada, los ataques Sybil son siempre posibles salvo bajo supuestos extremos y poco realistas de paridad de recursos y coordinación entre entidades. [3]

Eso explica las dos formas que adopta el BFT en la práctica. En la variante permisionada, el conjunto de réplicas está fijado y cada una tiene una clave pública conocida; HotStuff parte de un conjunto fijo de $n$ réplicas autenticadas. [1] Esa es, en términos de Douceur, la autoridad que certifica identidades.

En la variante abierta, la identidad deja de ser la unidad de voto. El survey de Deirmentzoglou et al. lo resume así: en proof of stake, la elección de validadores y el poder de voto se ponderan por stake, de modo que un atacante tiene el mismo peso si concentra su stake en una identidad o lo reparte entre muchas. [4] Casper FFG mide sus supermayorías por depósito, no por número de validadores, por la misma razón. [2] El umbral deja de ser "un tercio de los nodos" y pasa a ser "un tercio del stake".

Largo alcance: reescribir el pasado con claves retiradas

El stake resuelve Sybil hoy, pero introduce un problema temporal. Las claves que firmaron el pasado siguen existiendo cuando su stake ya no está en juego. Casper FFG lo describe como long range revision: una coalición que hace mucho tiempo tuvo más de dos tercios de los depósitos y ya los retiró puede usar esa supermayoría histórica para finalizar checkpoints en conflicto sin miedo al slashing, porque ya no queda dinero que quitarle. [2]

El survey de Deirmentzoglou et al. generaliza el ataque: el adversario bifurca la cadena desde un punto antiguo, incluso desde el bloque génesis, y lo consigue si su rama termina superando a la principal. [4] La raíz está en lo que el survey llama costless simulation o nothing at stake: producir bloques en proof of stake no cuesta trabajo computacional, así que fabricar una rama alternativa no tiene coste para el atacante. [4]

El survey distingue tres variantes. [4]

• Simple: en implementaciones que no verifican marcas de tiempo, el atacante forja timestamps para producir bloques por adelantado.
• Corrupción posterior: el atacante roba o compra las claves de validadores retirados, que ya no tienen incentivos para protegerlas, y firma con ellas bloques antiguos de su rama.
• Stake bleeding: el atacante deja de producir bloques en la cadena principal para frenarla mientras, en su rama privada, acumula recompensas y stake hasta dominarla.

El problema que hace peligrosos estos ataques tiene nombre: weak subjectivity. Un nodo nuevo, o uno que vuelve tras mucho tiempo desconectado, ve varias ramas válidas y no tiene forma de saber cuál es la principal; los nodos que siguen la cadena en tiempo real no pueden ser engañados así. [4]

Figura 1

Un ataque de largo alcance reescribe la historia desde un bloque antiguo

Fuentes:

[4]

Cómo leer esta figura

Arriba, la cadena canónica de B0 a B5. Desde B1 sale una historia alternativa en rojo, de B2 prima a B5 prima. Una nota indica que la historia alternativa está firmada con claves de validadores que ya retiraron su depósito; otra nota indica la mitigación: partir de un checkpoint reciente de confianza, la subjetividad débil.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Mitigaciones contra el largo alcance y sus límites

La respuesta de Casper FFG combina dos piezas: una regla de elección de bifurcación que nunca revierte un bloque finalizado, y la expectativa de que cada cliente se conecte y obtenga una vista completa de la cadena con cierta frecuencia, del orden de una vez cada uno o dos meses. Una rama que finaliza bloques más antiguos que eso se ignora, porque todos los clientes ya vieron un bloque finalizado a esa altura. [2] El retraso de retiro de los depósitos es lo que da margen: mientras el depósito sigue bloqueado, una equivocación aún puede castigarse. [2]

El survey cataloga un abanico más amplio. [4]

• Checkpoints móviles: solo los últimos bloques pueden reorganizarse, lo que degrada un ataque de largo alcance a uno de corto alcance.
• Firmas con claves que evolucionan (key-evolving signatures): la clave privada cambia en cada época y no se puede recuperar la anterior, de modo que una clave filtrada no sirve para volver a firmar mensajes viejos. Es la respuesta directa a la corrupción posterior.
• Transacciones conscientes del contexto: incluir el hash de un bloque previo en cada transacción impide copiarla a otra rama.
• Regla de plenitud: comparar la densidad de bloques de las ramas, porque la del atacante empieza escasa.
• Finalidad económica: el slashing hace que los validadores tengan algo que perder, aunque no elimina el ataque.

La conclusión del survey es la parte que conviene recordar: ninguna de estas contramedidas protege por completo contra todas las variantes, y hace falta combinarlas. [4] Como razonamiento propio: en un BFT permisionado con conjunto fijo no hay retiro de stake, pero en cuanto el conjunto se reconfigura vuelve a importar qué pasa con las claves de quienes salen; el tema de la reconfiguración está en reorganización dinámica de validadores.

Censura y negación de liveness

Los tres ataques anteriores apuntan a safety. La censura apunta a otra cosa: quien produce bloques decide qué transacciones entran y puede omitir algunas a propósito. El survey señala que un solo validador censurando puede retrasar transacciones, y que el riesgo crece con el número de validadores que se suman. [4] Entre las respuestas que recoge están los requisitos de liveness que garantizan el procesamiento eventual de las transacciones y la penalización de nodos que no crean bloques en el orden definido por el protocolo. [4]

Su forma extrema es la negación de liveness: validadores que simplemente dejan de producir bloques para detener la cadena. Para ese caso el survey remite al requisito de liveness de Casper FFG, que drena lentamente el stake de los inactivos. [4] En el paper original, ese inactivity leak se presenta como defensa contra la caída simultánea de más de un tercio de los validadores, y se reconoce su efecto secundario: puede permitir que se finalicen dos checkpoints en conflicto sin que nadie sea sancionado. [2]

En la familia HotStuff, la defensa estructural es la rotación de líder: el pacemaker reemplaza a un líder que no hace progreso, y después de GST un líder correcto termina proponiendo. [1] Eso garantiza que la cadena avance, no que un líder concreto incluya una transacción concreta. Separar la difusión de datos del ordenamiento, como hace Narwhal, es una línea de diseño relacionada que conviene estudiar aparte.

Siguiente lectura

Para repasar la aritmética del cruce de quórums que sostiene la defensa contra la equivocación, vuelve a Quórums en acción. Si te interesa cómo se buscan sistemáticamente estos fallos en implementaciones reales, continúa con Twins y la detección de errores de estado.