Finality, slashing e inactivity leak

Imagina que tu equipo levanta dos instancias del mismo validador "por alta disponibilidad". Las dos tienen la misma clave. Durante un corte de red, cada una cree que la otra murió y ambas firman una attestation para la misma época, pero sobre bloques distintos. Ese pequeño error de despliegue es exactamente lo que el protocolo está diseñado para detectar y castigar.

Este capítulo explica tres mecanismos que sostienen la finalidad de Ethereum: qué firmas son slashables (castigables con pérdida de stake y expulsión), cuánto cuesta un slashing según las especificaciones actuales, y qué hace el protocolo cuando el problema no es la mentira sino la ausencia: el inactivity leak. [1]

Preguntas guía

• ¿Qué par de firmas convierte a un validador en slashable y por qué esas dos reglas bastan para proteger la finalidad?
• ¿Cuánto pierde un validador aislado y cuánto pierde si cae junto con muchos otros?
• ¿Qué pasa con la finalidad si más de un tercio del stake se desconecta?
• ¿Qué decisiones de infraestructura convierten un fallo de red en un slashing?

Conexiones dentro de la serie

• Antes: Validadores, attestations y BLS explica qué firma un validador en cada época, y Gasper: Casper FFG + LMD-GHOST explica cómo esos votos justifican y finalizan checkpoints.
• Después: Shapella: retirar stake sin romper el consenso muestra cómo sale el ETH de un validador que terminó su ciclo, incluido uno slasheado.
• Investigación relacionada: Casper FFG como gadget de finalidad, castigo financiero y slashing en BFT e inactivity leaks y particiones masivas desarrollan la teoría que aquí aplicamos al protocolo real.

Estado de votos: qué hace slashable a una attestation

Cada attestation contiene un voto FFG: un enlace desde un checkpoint fuente (el último justificado que conoce el validador) hasta un checkpoint objetivo (el de la época actual). Un checkpoint es el bloque al inicio de una época; una época son 32 slots de 12 segundos. Casper FFG, el componente de finalidad de Gasper, prueba que dos checkpoints en conflicto no pueden finalizarse a menos que al menos un tercio del stake viole una de dos reglas. [2] [3]

La especificación de consenso codifica esas dos reglas en una función de pocas líneas. Es el contrato exacto que verifica cualquier cliente:

# consensus-specs, phase0/beacon-chain.md (extracto literal)
def is_slashable_attestation_data(data_1: AttestationData, data_2: AttestationData) -> bool:
    return (
        # Double vote
        (data_1 != data_2 and data_1.target.epoch == data_2.target.epoch)
        or
        # Surround vote
        (data_1.source.epoch < data_2.source.epoch and data_2.target.epoch < data_1.target.epoch)
    )

El doble voto es firmar dos attestations distintas con la misma época objetivo. El voto envolvente (surround vote) es firmar un enlace cuyo intervalo fuente–objetivo contiene estrictamente a otro enlace firmado antes o después. La figura muestra ambos casos y una secuencia legal para contrastar.

Figura 1

Doble voto, voto envolvente y una secuencia legal

Fuentes:

[4]

Cómo leer esta figura

Tres ejes horizontales de épocas numeradas de 0 a 6. En el primero, dos arcos parten de la época 2 y llegan a la época 3, uno sólido hacia el bloque X y otro punteado hacia el bloque Y: es un doble voto y está marcado como slashable. En el segundo, un arco grande va de la época 1 a la 5 y otro más pequeño de la 2 a la 4, contenido dentro del primero: es un voto envolvente, con s1 menor que s2 y t2 menor que t1, marcado como slashable. En el tercero, tres arcos consecutivos van de 1 a 2, de 2 a 3 y de 3 a 4: es la secuencia normal de un validador honesto y está marcada como válida.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Hay una tercera falta, para quien propone bloques: firmar dos cabeceras distintas para el mismo slot. process_proposer_slashing exige que ambas cabeceras tengan el mismo slot y el mismo proponente, que sean distintas y que las dos firmas sean válidas. [4]

Fíjate en lo que no es slashable: estar desconectado, votar tarde o votar por una cabeza equivocada. Eso cuesta recompensas y penalizaciones pequeñas, pero no expulsa a nadie. El protocolo solo castiga con slashing lo que deja una prueba criptográfica de contradicción.

Traza de ejecución de un slashing: de la evidencia al balance

La evidencia no se envía sola. Cualquier nodo que vea dos mensajes contradictorios puede empaquetarlos en un AttesterSlashing o un ProposerSlashing, y un proponente los incluye en un bloque. A partir de ahí, slash_validator ejecuta una secuencia fija. Los números de abajo son los vigentes desde Electra, la mitad de consenso de la actualización Pectra (mayo de 2025). [5]

El paso más importante es la penalización por correlación. En process_slashings, el protocolo suma el balance efectivo de todos los validadores slasheados en las últimas 8192 épocas, lo multiplica por PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX = 3 y lo compara con el stake activo total. Cada validador slasheado pierde esa fracción de su balance efectivo. [5]

La consecuencia se deduce con aritmética simple: un error aislado cuesta poco, pero si un tercio del stake firma contradicciones dentro de la misma ventana, el factor llega a 1 y cada uno pierde todo su balance efectivo. Un tercio no es un número arbitrario: es la cantidad mínima de stake que necesita un ataque contra la seguridad de Casper FFG. El castigo apunta justo a ese umbral. [1]

Riesgo operativo: el validador que se duplica a sí mismo

Volvamos al ejemplo inicial. Desde el punto de vista del protocolo, dos procesos con la misma clave son un único validador que firma cosas contradictorias. No existe una excepción para "fue el failover". Por eso la práctica sana para validadores es la contraria a la de un servicio web: una sola instancia activa por clave, con un failover manual o con una base de datos de firmas compartida y consultada antes de firmar.

Esa base de datos tiene un estándar. EIP-3076 define un formato JSON de slashing protection para mover el historial de firmas de un cliente a otro. Un fragmento del ejemplo de la EIP: [6]

{
  "metadata": {
    "interchange_format_version": "5",
    "genesis_validators_root": "0x04700007fabc8282644aed6d1c7c9e21d38a03a0c4ba193f3afe428824b3a673"
  },
  "data": [
    {
      "pubkey": "0xb845089a1457f811bfc000588fbb4e713669be8ce060ea6be3c6ece09afc3794106c91ca73acda5e5457122d58723bed",
      "signed_blocks": [{ "slot": "81952" }],
      "signed_attestations": [{ "source_epoch": "2290", "target_epoch": "3007" }]
    }
  ]
}

Tras importar el archivo, el firmante debe negarse a firmar cualquier attestation slashable respecto de las registradas y cualquier attestation con época objetivo menor o igual que la mínima del historial. La EIP pone un ejemplo concreto: si el reloj del cliente anterior se adelantó, migrar las claves sin ese historial deja al validador expuesto a firmar en conflicto durante las épocas que el reloj se había adelantado. [6]

Hay un equilibrio incómodo aquí: estar caído unas horas cuesta muy poco comparado con un slashing. Si dudas entre arrancar una segunda instancia o esperar, esperar suele ser la decisión más barata.

Estado de votos sin quórum: cuándo empieza el inactivity leak

Ahora cambia el escenario. Nadie miente, pero un 40 % del stake queda aislado por un fallo de cliente o de red. Para finalizar hace falta que dos tercios del stake voten el mismo enlace fuente–objetivo. Con un 60 % activo, ningún checkpoint puede justificarse y la finalidad se detiene. La cadena sigue produciendo bloques, pero ninguno se vuelve irreversible. [1]

El protocolo detecta la situación con una sola resta: la distancia entre la época anterior y el último checkpoint finalizado. Si supera MIN_EPOCHS_TO_INACTIVITY_PENALTY = 4, la red entra en inactivity leak. [4]

# consensus-specs, phase0/beacon-chain.md (extracto literal)
def get_finality_delay(state: BeaconState) -> Epoch:
    return get_previous_epoch(state) - state.finalized_checkpoint.epoch
 
def is_in_inactivity_leak(state: BeaconState) -> bool:
    return get_finality_delay(state) > MIN_EPOCHS_TO_INACTIVITY_PENALTY

Desde Altair, cada validador tiene un inactivity score. Si en una época no logra un voto objetivo puntual, su score sube INACTIVITY_SCORE_BIAS = 4; si lo logra, baja 1. Mientras no hay leak, todos los scores bajan además INACTIVITY_SCORE_RECOVERY_RATE = 16 por época. La penalización de cada época es effective_balance × score / (4 × INACTIVITY_PENALTY_QUOTIENT), con el cociente fijado en 2²⁴ desde Bellatrix. [7] [8]

Como el score de un ausente crece linealmente con el tiempo y la penalización por época es proporcional al score, la pérdida acumulada crece de forma aproximadamente cuadrática. Las primeras horas cuestan poco; días de ausencia cuestan mucho. Durante el leak, además, los validadores activos no cobran las recompensas de sus votos de fuente y objetivo: la regla castiga al ausente sin premiar al presente. [7]

Invariante de recuperación: por qué la fuga siempre devuelve los dos tercios

El invariante es simple: el stake de quien no vota baja y el de quien vota no. Por grande que sea el grupo ausente, en algún momento su fracción cae por debajo de un tercio, los activos superan los dos tercios y pueden volver a justificar y finalizar checkpoints. ethereum.org recuerda que esto ya ocurrió en la testnet Medalla, cuando menos del 66 % de los validadores activos coincidía en la cabeza de la cadena y la finalidad se recuperó gracias al leak. [1]

Este invariante tiene un precio conceptual. Si la red se parte en dos mitades que no se ven, cada mitad ve a la otra como ausente y su propio leak la drena. Tras suficiente tiempo, ambas podrían finalizar historias distintas. Ethereum elige recuperar la vida (liveness) de cada lado antes que quedar congelado para siempre; la reconciliación entre las dos historias queda fuera del protocolo. Ese compromiso se analiza en detalle en el capítulo de investigación sobre inactivity leaks y particiones masivas.

La lectura para tu equipo es operativa. Un leak es una señal de incidente de red o de cliente, no un evento de cada día. Si tus validadores están del lado activo, siguen votando y no cobran recompensas por un tiempo. Si están del lado ausente, cada hora cuenta más que la anterior. Por eso las alertas sobre "época finalizada que no avanza" pertenecen al mismo tablero que las alertas de proceso caído.

Laboratorio mínimo: detectar slashing antes de firmar

Puedes reproducir la lógica sin tocar mainnet. Toma la función de la especificación, genera pares de AttestationData sintéticos con épocas fuente y objetivo, y comprueba que tu detector marca exactamente los casos de la figura. Después importa un historial EIP-3076 y verifica que el firmante rechaza una attestation con objetivo menor o igual al mínimo registrado.

Quédate con esta frase: Ethereum castiga con slashing lo que deja prueba de contradicción y castiga con el leak lo que impide finalizar. Las dos reglas apuntan al mismo umbral de un tercio, una desde la seguridad y otra desde la vida de la red.