Leaks de inactividad (Inactivity Leaks): Recuperar el consenso tras catástrofes

En Safety, liveness y responsiveness vimos que un protocolo BFT con $n = 3f + 1$ réplicas avanza solo si reúne certificados de $n - f$ votos. Si más de $f$ réplicas se apagan, ningún certificado puede formarse.

La pregunta de este artículo es incómoda: ¿qué debería hacer un sistema cuando la falla ya no es "hasta $f$" sino un apagón o una partición que deja fuera a más de un tercio del stake? HotStuff responde "esperar". Ethereum responde reduciendo, época tras época, el stake de quienes no votan. Ese mecanismo es el inactivity leak, se activó por primera vez en Ethereum en mayo de 2023, y tiene un precio que Pavloff, Amoussou-Guenou y Tucci-Piergiovanni midieron con cuidado. [1]

Por qué la finalidad se detiene con más de un tercio ausente

Empecemos por la familia BFT clásica. En HotStuff, un QC es un conjunto de $n - f$ votos firmados sobre la misma propuesta y la misma vista; safety no depende de la red, y el progreso depende de que, después de GST, un líder correcto reúna esos votos. [4] Si $f + 1$ réplicas no votan, llegan como máximo $n - f - 1$ votos, uno menos de lo necesario. El pacemaker puede rotar líderes indefinidamente: ninguno certifica. La red queda detenida y, a la vez, intacta.

Ethereum hereda la misma aritmética en su capa de finalidad. Casper FFG define un enlace de supermayoría como un par de checkpoints $(a, b)$ respaldado por votos de al menos dos tercios de los validadores, ponderados por depósito; un checkpoint se justifica con un enlace desde otro justificado y se finaliza cuando su hijo directo también queda justificado. [2] Gasper, el protocolo de la beacon chain, combina ese gadget con la regla de bifurcación LMD GHOST y mantiene la condición de dos tercios del stake para justificar. [3]

En la descripción de Pavloff et al., el tiempo se divide en slots de 12 segundos y épocas de 32 slots; cada validador emite una atestación por época, con un voto de checkpoint. Un checkpoint queda justificado cuando validadores con más de dos tercios del stake emiten el mismo voto, y la finalización requiere dos checkpoints justificados consecutivos. [1]

De ahí sale el problema. Buterin y Griffith lo llaman catastrophic crash: si más de un tercio de los validadores deja de participar, sea por una partición de red, una falla de máquinas o por malicia, ya no pueden crearse enlaces de supermayoría y ningún checkpoint futuro se finaliza. [2] Hasta aquí, Ethereum se comporta como HotStuff. La diferencia es lo que hace a continuación.

Una aclaración de diseño: la cadena de Ethereum no se congela por completo. Pavloff et al. subrayan que la parte no finalizada sigue creciendo aunque la finalización se detenga, una propiedad que llaman availability. [1] Lo que se detiene es la finalidad, no la producción de bloques.

El mecanismo: puntaje de inactividad y drenaje de stake

La idea aparece ya en el paper de Casper FFG como defensa contra caídas catastróficas: un "leak" que drena lentamente el depósito de todo validador que no vota, hasta que los que sí votan vuelven a ser supermayoría. [2] Los autores dejaban la fórmula exacta fuera del alcance del paper, como una cuestión de incentivos económicos, y sugerían que una tasa creciente con la duración del estancamiento podía resolver antes la crisis. [2] Pavloff et al. notan además que la descripción de Gasper no menciona el mecanismo, y aportan la primera descripción formal. [1]

Según esa formalización, el leak empieza cuando la cadena pasa cuatro épocas consecutivas sin finalizar. Un validador cuenta como inactivo en una época si no envía atestación o si su voto de checkpoint apunta a un objetivo que no pertenece a la cadena que se evalúa. Durante el leak desaparecen las recompensas de atestación y aparecen penalizaciones de inactividad. [1]

Cada validador $i$ lleva un puntaje de inactividad $I_i$. En cada época de leak sube 4 si el validador estuvo inactivo y baja 1 (sin pasar de cero) si estuvo activo. La penalización por época es proporcional al puntaje y al stake: [1]

$s_i(t) = s_i(t-1) - \frac{I_i(t-1)\, s_i(t-1)}{2^{26}}$

El término importante es $I_i$: como crece con cada época de ausencia, la pérdida se acelera. Modelando el stake como función continua, los autores obtienen que un validador siempre inactivo, con $I(t) = 4t$, conserva $s(t) = s_0\, e^{-t^2/2^{25}}$. Un validador siempre activo no pierde nada. Un validador semiactivo, activo una época sí y otra no, decae más lento, como $s_0\, e^{-3t^2/2^{28}}$. [1]

Hay un segundo efecto discreto: los validadores cuyo stake cae a 16,75 ETH o menos son expulsados. Partiendo de 32 ETH, un validador siempre inactivo llega a ese límite en la época 4685 del leak, y uno semiactivo en la 7652; como referencia, los autores indican que 5000 épocas son unas tres semanas. [1]

Aritmética del retorno a dos tercios

El efecto buscado no es castigar por castigar. Al drenar el stake de los ausentes se encoge el denominador contra el que se miden los dos tercios. Los activos no ganan votos nuevos: pasan a representar una fracción mayor de un total más pequeño.

Un ejemplo hipotético con números redondos lo muestra. Supongamos un stake total de $100$ unidades, de las cuales $60$ siguen votando y $40$ quedan aisladas. Los activos tienen $0{,}6$ del total, por debajo de $2/3$. Llamemos $s$ al stake restante de los inactivos. Los activos recuperan la supermayoría cuando

$\frac{60}{60 + s} \ge \frac{2}{3} \quad \Longleftrightarrow \quad s \le 30.$

Basta con que los inactivos pierdan una cuarta parte de su stake. Pavloff et al. hacen la misma cuenta con su curva de penalización: si $p_0$ es la fracción del stake que sigue activa en una rama, la fracción activa en la época $t$ del leak es [1]

$\frac{p_0}{p_0 + (1 - p_0)\, e^{-t^2/2^{25}}}$

y el umbral de dos tercios se alcanza en

$t = \min\left( \sqrt{2^{25}\left[\log\big(2(1-p_0)\big) - \log p_0\right]},\; 4685 \right).$

El mínimo con $4685$ refleja la expulsión: en su simulación, con $p_0 \le 0{,}5$ la fracción activa salta a 1 cuando los inactivos son expulsados, mientras que con $p_0 = 0{,}6$ los dos tercios se recuperan antes de esa expulsión. [1] Cuantos más validadores activos tiene una rama, antes vuelve a finalizar.

Fíjate en lo que cambió. La supermayoría recuperada no se cruza necesariamente con una supermayoría medida sobre el stake original, porque ambas se calculan contra denominadores distintos. El invariante del bloque anterior presupone un conjunto y un stake fijos. [3] El leak altera el stake sin que nadie haya votado esa alteración, y con eso suspende la premisa de la prueba.

Figura 1

El inactivity leak devuelve los dos tercios a los activos

Fuentes:

[1]

Cómo leer esta figura

Curva cualitativa de la fracción de stake activo frente a las épocas sin finalidad. Empieza en 0,6, por debajo de la línea de dos tercios, y sube a medida que el stake inactivo se reduce; cruza los dos tercios en el punto donde la finalidad se reanuda, cuando el stake inactivo restante es como mucho 30 de 100.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

El precio: dos ramas finalizadas tras una partición

Mientras los ausentes estén realmente apagados, el cambio de denominador es inofensivo. El problema aparece cuando la "caída" es una partición y ambos lados siguen activos. Casper FFG ya lo advertía: si los validadores se dividen en $V_A$, que vota en la cadena A, y $V_B$, que vota en la B, en la cadena A se drena el depósito de $V_B$ y viceversa, hasta que cada subconjunto tiene supermayoría en su cadena y se finalizan dos checkpoints en conflicto sin que nadie viole una condición de slashing. [2] La recomendación del paper era que cada validador favoreciera el checkpoint finalizado que vio primero, y dejaba la recuperación como problema abierto. [2]

Pavloff et al. cuantifican este caso con validadores solo honestos separados en dos particiones. La configuración más rápida para finalizar ambas ramas es el reparto parejo, $p_0 = 0{,}5$, y aun así ninguna rama puede finalizar antes de la expulsión en la época 4685. Contando una época más para finalizar el checkpoint justificado, ambas ramas finalizan 4686 épocas después del inicio del leak, unas tres semanas. Su conclusión: cualquier partición más larga que eso produce finalización en conflicto y pérdida de safety. [1]

Contrasta con HotStuff. Allí, dos QCs en conflicto en la misma vista exigen que alguna réplica correcta vote dos veces, lo que sus reglas de votación impiden. [4] Con el leak no hace falta ningún doble voto: cada lado forma su supermayoría sobre un denominador distinto.

Cómo los validadores bizantinos aceleran el riesgo

El análisis se vuelve más serio cuando se añade un adversario con menos de un tercio del stake inicial, $\beta_0 < 1/3$, capaz de coordinarse entre particiones. [1] Los autores estudian cuatro estrategias.

Activos en ambas ramas, con slashing. Si los bizantinos atestan en las dos ramas a la vez, cuentan como activos en ambas y aceleran la recuperación de dos tercios en cada una. Es una falta sancionable, pero solo cuando la prueba de atestaciones conflictivas se incluye en un bloque, y antes de GST eso puede no ocurrir. Con $p_0 = 0{,}5$, la finalización en conflicto baja de 4685 épocas con $\beta_0 = 0$ a 3107 con $\beta_0 = 0{,}2$ y a unas 500 con $\beta_0 = 0{,}33$, unos dos días. [1] El slashing llega tarde: las dos ramas finalizadas ya son irreconciliables con el protocolo actual.

Semiactivos, sin slashing. Alternando actividad entre ramas, los bizantinos nunca firman dos atestaciones conflictivas en la misma época, pierden stake más despacio que los honestos inactivos y, en el momento oportuno, permanecen activos dos épocas seguidas en cada rama. Con $\beta_0 = 0{,}33$, eso produce finalización en conflicto en unas 556 épocas sin ninguna acción sancionable. [1]

Superar el umbral de un tercio. La misma estrategia semiactiva, pero sin finalizar, persigue otro objetivo: que la proporción de stake bizantino supere $1/3$ en cada rama mientras los honestos de la otra partición se desangran. Con $p_0 = 0{,}5$, esto es posible en ambas ramas a la vez si $\beta_0 \ge 0{,}2421$. [1]

Probabilistic bouncing. Por último, revisan un ataque conocido para retrasar la finalidad durante periodos síncronos y muestran que, con el leak, puede llevar el stake bizantino por encima de un tercio de forma probabilística si $\beta_0$ está suficientemente cerca de $1/3$. [1]

Los autores son explícitos sobre el alcance: las condiciones para que estos ataques persistan hasta amenazar safety son poco probables en la práctica, sobre todo por las escalas de tiempo, aunque los bizantinos pueden hacer perder stake a otros validadores mucho antes. [1]

Esperar o reponderar: qué significa "finalizado"

La comparación honesta no es "Ethereum se cura y HotStuff no". Es una elección sobre qué propiedad conservar cuando el modelo de fallas se rompe. HotStuff mantiene safety sin suposiciones de red y acepta que, con más de $f$ réplicas ausentes, el progreso se detenga. [4] Recuperar servicio exige que las réplicas vuelvan o una reconfiguración explícita del conjunto, como la que se discute en reorganización dinámica de validadores.

Ethereum elige lo contrario para su finalidad. Pavloff et al. lo leen a través del teorema CAP: el leak restaura liveness durante particiones y, por eso mismo, pone en riesgo safety. [1] Para quien diseña sistemas, la consecuencia práctica es leer con cuidado qué garantiza "finalizado". En un BFT con conjunto fijo, significa respaldado por un quórum que se cruza con cualquier otro. Con leak, significa respaldado por dos tercios del stake vigente en esa rama, y ese stake puede haberlo redefinido el propio apagón.

Siguiente lectura

Para repasar por qué la intersección de quórums es el corazón de safety, vuelve a Quórums en acción. Si quieres ver cómo un protocolo de conjunto fijo recupera liveness después de GST sin tocar los pesos, continúa con el pacemaker y el cambio de vista de HotStuff.