Validadores, attestations y BLS

Piensa en un comité de cien validadores que vota lo mismo en el mismo slot. Si cada voto viajara y se guardara con su propia firma, un bloque cargaría cien firmas por comité y cada nodo tendría que verificarlas una a una. Ethereum hace otra cosa: junta esas firmas en una sola y verifica el grupo de una vez.

Este capítulo abre ese mecanismo en cuatro capas: qué contiene exactamente un voto, por dónde viaja hasta entrar en un bloque, por qué la criptografía BLS permite comprimirlo y qué riesgos operativos tiene la clave que lo firma. El voto se llama attestation: una declaración firmada de cómo ve la cadena un validador. [1]

Preguntas guía

• ¿Qué campos firma un validador y cuál de ellos es el voto de finalidad?
• ¿Por qué solo se pueden agregar firmas sobre exactamente los mismos datos?
• ¿Quién decide qué validador agrega y cómo lo demuestra?
• ¿Qué pasa si la misma clave de validador corre en dos máquinas a la vez?

Conexiones dentro de la serie

• Antes: Gasper: Casper FFG + LMD-GHOST explica para qué sirven los dos votos que lleva cada attestation.
• Criptografía: Firmas en BFT: threshold, aggregate y AggQC explica por qué BLS agrega tan bien y en qué se diferencia de una firma umbral.
• Después: Finality, slashing e inactivity leak cubre las penalizaciones cuando el voto se usa mal.
• Reloj: Beacon Chain desde cero explica slots, epochs y comités.

Anatomía de una attestation: qué firma un validador

Una attestation tiene tres partes: aggregation_bits, un mapa de bits que dice qué miembros del comité firmaron; data, el contenido del voto; y signature, la firma BLS que agrega las firmas individuales. [1] El contenido es este contenedor de la especificación:

# Extracto de consensus-specs, phase0/beacon-chain.md
class AttestationData(Container):
    slot: Slot
    index: CommitteeIndex
    beacon_block_root: Root      # voto de cabeza (LMD-GHOST)
    source: Checkpoint           # voto FFG: último checkpoint justificado
    target: Checkpoint           # voto FFG: checkpoint de la epoch actual

beacon_block_root es la raíz del bloque que el validador ve como cabeza tras correr el fork choice; source y target forman el voto de finalidad. [1] Un solo mensaje firmado lleva los dos votos de Gasper.

El validador no firma los datos a secas. Firma un signing root: el hash de los datos junto con un dominio. [2] El dominio mezcla el tipo de mensaje (DOMAIN_BEACON_ATTESTER, distinto del de propuesta o del de RANDAO) con la versión del fork y la raíz de validadores de génesis, y la especificación lo justifica para evitar colisiones entre forks y cadenas. [2] Así, una firma de attestation no puede reutilizarse como firma de bloque ni en otra red.

Desde Electra el campo index ya no distingue comités. EIP-7549 sacó el índice de comité del mensaje firmado para poder agregar votos iguales de comités distintos. [3] La especificación de Electra exige data.index == 0 y añade a la attestation un campo committee_bits que indica qué comités participan. [4]

Traza de ejecución: del voto individual al bloque

Sigue un voto desde la clave hasta el bloque. El validador conoce su comité y su slot con antelación. En ese slot espera el bloque del proponente; atestigua en cuanto recibe un bloque válido o, si no llega, cuando ha pasado get_attestation_due_ms() desde el inicio del slot, lo que ocurra primero. [5] En mainnet ese plazo es ATTESTATION_DUE_BPS = 3333 puntos básicos, cerca de un tercio del slot. [5]

El voto se publica en una subred de attestations, no en toda la red. Dentro de cada comité, algunos validadores son agregadores. La selección es local y verificable: el validador firma el número de slot y, si el hash de esa firma módulo len(committee) // 16 da cero, es agregador. [5] El 16 es TARGET_AGGREGATORS_PER_COMMITTEE, así que se esperan unos 16 agregadores por comité. [5]

El agregador junta las attestations con datos idénticos a los suyos, enciende los bits correspondientes y suma las firmas. [1] Luego publica el agregado en el canal global beacon_aggregate_and_proof hacia los dos tercios del slot, con su prueba de selección para que la red pueda comprobar que tenía derecho a agregar. [5] El proponente del bloque siguiente recoge esos agregados y los incluye. [1]

Figura 1

Agregación de attestations: muchas firmas, una comprobación

Fuentes:

[1][2]

Cómo leer esta figura

A la izquierda, bajo el título comité del slot, cuatro validadores: V1, V2 y V3 con firmas sigma 1, sigma 2 y sigma 3, y V4 en línea discontinua con la etiqueta no vota. Las tres firmas llegan con flechas a la caja Agregador, que suma firmas con la misma data; la flecha de V4 es discontinua y lleva la etiqueta bit 0. Del agregador sale una flecha a la caja attestation agregada, que contiene data con slot, head, source y target, bits 1110 y firma sigma igual a sigma 1 más sigma 2 más sigma 3. De ahí sale una flecha a Bloque y verificación: una comprobación con pk1, pk2 y pk3, con la etiqueta FastAggregateVerify.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

BLS12-381: una firma que vale por muchas

Ethereum usa firmas BLS sobre la curva BLS12-381. En la especificación, una clave pública es un punto comprimido del grupo G1 de 48 bytes y una firma es un punto comprimido del grupo G2 de 96 bytes. [2] La interfaz sigue el borrador IETF de firmas BLS, versión 4, con el ciphersuite BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_. [2]

Las funciones que importan aquí son tres. Aggregate combina varias firmas en una. FastAggregateVerify comprueba una firma agregada contra varias claves públicas que firmaron el mismo mensaje. AggregateVerify acepta mensajes distintos, a un coste mayor. [2] La validación de una attestation usa la versión rápida: un solo mensaje, el signing root de la data. [2]

Esa es la razón técnica de la regla "solo se agregan votos con data idéntica". Si dos validadores ven cabezas distintas, sus signing roots difieren y sus firmas ya no caben en la misma comprobación rápida. La agregación no mezcla opiniones: comprime acuerdo exacto.

El sufijo POP del ciphersuite significa proof of possession, prueba de posesión. Sin ella, un atacante podría registrar una clave pública fabricada a partir de las de otros y falsificar un agregado (el ataque de clave maliciosa o rogue key). La Beacon Chain exige esa prueba al registrar al validador: el depósito lleva una firma sobre los propios datos del depósito, que el contrato no comprueba pero el procesamiento de depósitos sí. [2] Para la comparación con firmas umbral y certificados agregados, ver el capítulo de firmas en BFT.

Riesgo operativo del validador: claves, doble firma y protección local

Un validador maneja dos tipos de credencial. La clave de firma firma bloques y attestations y por eso vive en caliente, en una máquina conectada. Las credenciales de retiro indican a dónde va el saldo: el prefijo 0x00 es el formato BLS original, 0x01 apunta a una dirección de ejecución y 0x02 es el tipo moderno con capitalización. [6]

Si alguien roba la clave de firma, ethereum.org enumera lo que puede hacer: proponer dos bloques distintos para el mismo slot, firmar una attestation que envuelve a otra, firmar dos attestations distintas con el mismo target, o forzar una salida voluntaria. [6] Las tres primeras son faltas penalizables por slashing.

El fallo más común no es un robo. Es la propia operación: un equipo migra el validador a otra máquina, el proceso viejo sigue vivo, y la misma clave firma dos votos para la misma epoch. Para el protocolo eso es un doble voto, sin importar la intención.

Esa lista resume la sección de buenas prácticas de la especificación. [5] Para el punto del validador recuperado existe un formato estándar, EIP-3076, que permite mover el historial de firmas de una clave entre clientes sin firmar mensajes en conflicto. [7] Al momento de esta revisión su estado en eips.ethereum.org es Last Call.

La regla operativa queda así: una clave, un proceso firmante, una base anti-slashing que viaja con la clave. Si tu runbook de migración no apaga el firmante viejo y exporta su historial antes de arrancar el nuevo, el slashing está a un despliegue de distancia.