BEEFY: finalidad compacta para puentes

Un contrato en Ethereum custodia activos que representan saldos en Polkadot. Para liberar fondos necesita creer una sola afirmación: "el bloque 1 000 000 de la relay chain es final y su estado contiene este mensaje". En el capítulo de GRANDPA vimos que esa afirmación se demuestra con una justificación: firmas de más de dos tercios de los validadores. El problema es que verificar esa justificación dentro de la EVM es caro y, con las firmas que usa GRANDPA, poco práctico.

BEEFY (Bridge Efficiency Enabling Finality Yielder) existe para ese contrato. Al terminar este capítulo deberías poder explicar qué firma un validador BEEFY, por qué esa firma es más barata de verificar fuera de Polkadot, qué retraso añade frente a GRANDPA y qué confianza queda depositada en quien transporta las pruebas.

Preguntas guía

• ¿Qué hace caro verificar una justificación GRANDPA fuera de Polkadot?
• ¿Qué contiene un compromiso BEEFY y por qué se firma con ECDSA sobre secp256k1?
• ¿Por qué BEEFY siempre va por detrás de GRANDPA, y cuánto?
• ¿Qué supuestos añade el relayer y cómo los reduce el muestreo aleatorio?

Conexiones dentro de la serie

• Antes: GRANDPA explica la finalidad que BEEFY reutiliza. Sincronización y light clients explica por qué un cliente ligero necesita pruebas de finalidad. Sassafras cerró la producción de bloques.
• Investigación relacionada: Firmas umbral y agregadas y costes de BLS frente a Ed25519 explican por qué el esquema de firma decide el tamaño y el coste de un certificado.
• Después: Anatomía del consenso en un nodo muestra dónde se enchufan GRANDPA y BEEFY dentro del nodo.

Por qué no basta con GRANDPA

La especificación de Polkadot define BEEFY como "a secondary protocol to GRANDPA to support efficient bridging between the Polkadot network (relay chain) and remote, segregated blockchains, such as Ethereum". [1] La palabra clave es secundario: BEEFY no decide qué es final. Solo vuelve a atestiguar, en un formato más barato, lo que GRANDPA ya decidió.

La misma especificación explica el problema: "GRANDPA justifications are large and are expensive to verify on other chains like Ethereum that do not support some cryptographic signature schemes." [1] Son dos costes distintos, y el README del crate sc-consensus-beefy los separa.

El primero es estructural. En GRANDPA cada votante vota por el bloque que cree más reciente y el protocolo finaliza el ancestro común con apoyo suficiente. El README lo dice así: "voters are voting on different things". [2] Como cada voto puede apuntar a un bloque distinto, la prueba necesita los datos de cada voto y, a veces, cabeceras adicionales para comprobar las ascendencias.

El segundo es criptográfico. GRANDPA firma con ed25519, que según el mismo README "we can't efficiently verify in the EVM". [2] Un contrato que quiera verificar cientos de firmas ed25519 paga un gas que hace inviable el puente.

Una nota sobre el umbral. El artículo de GRANDPA asume que, de n votantes, como mucho f son bizantinos, con f menor que n/3, y exige n − f votos para finalizar. [3] BEEFY hereda ese modelo: sus rondas concluyen con "2/3rd + 1" votos válidos. [2]

Qué firma un validador BEEFY

El README propone un modelo mental útil: BEEFY "should be considered as an extra voting round done by GRANDPA validators for the current best finalized block." [2] Como el bloque ya es final, no hay bifurcaciones que resolver: todos votan exactamente lo mismo. Ese es el atajo que GRANDPA no puede tomar.

Lo que se firma es un compromiso. La especificación lo define como la tupla (payload, Block Number, ValidatorSetID); un compromiso firmado añade la lista de firmas. [1] Un compromiso firmado válido es lo que el README llama justificación BEEFY o prueba de finalidad BEEFY.

El payload es, según la especificación, "the Merkle root of the MMR generated where the leaf data contains the following fields for each block". Cada hoja guarda la versión del formato, información del próximo conjunto de autoridades BEEFY, el número y hash del bloque padre y una raíz de las cabeceras de parachains. [1]

Un Merkle Mountain Range (MMR) es un árbol de Merkle de solo inserción: una lista de subárboles perfectos que se fusionan a medida que crecen. La especificación lo elige porque añadir hojas no obliga a reconstruir el árbol. Para el puente, la consecuencia es concreta: con una sola raíz firmada, el contrato puede verificar después la inclusión de cualquier bloque anterior mediante una prueba de Merkle, sin haber visto cada cabecera.

La información del próximo conjunto de autoridades dentro de la hoja también importa. Es la forma en que el contrato aprende, de manera verificable, qué claves deberá aceptar en la sesión siguiente. Un puente que no siguiera esos cambios acabaría aceptando firmas de un conjunto viejo.

Claves ECDSA, rondas y retraso

Las claves cambian respecto de GRANDPA. La especificación: "Validators use an ECDSA key scheme for signing Beefy messages." El par de claves es secp256k1, y la clave pública ocupa 33 bytes en lugar de 32. [1] El README explica la elección sin rodeos: la primera versión se pensó para un light client escrito en Solidity, "Hence the choice of the initial cryptography for BEEFY: secp256k1 and usage of keccak256 hashing function." [2]

El conjunto de validadores es el mismo que el de GRANDPA, aunque con otras claves de sesión. Y el retraso es inherente: "BEEFY finalized block lags behind the best GRANDPA (finalized) block." [1]

Figura 1

BEEFY: de la finalidad de GRANDPA al light client del puente

Fuentes:

[1][2][4]

Cómo leer esta figura

Fila superior con siete bloques B1 a B7 encadenados. Una flecha verde rotulada BEEFY apunta a B2, una azul rotulada GRANDPA apunta a B5 y una gris rotulada mejor producido apunta a B7; una nota dice que BEEFY solo vota bloques ya finalizados por GRANDPA y por eso va por detrás. En la segunda fila, una caja verde con el compromiso (payload raíz del MMR, número de bloque e id del conjunto de validadores) apunta a otra caja verde de firmas ECDSA secp256k1 de al menos dos tercios más uno del conjunto. Desde ahí, una flecha va a la caja del relayer, fuera de cadena, y otra al light client, un contrato en Ethereum. Una nota inferior explica el muestreo aleatorio de Snowbridge: el relayer se compromete, el contrato elige al azar unas pocas firmas y el relayer debe presentarlas; si no las presenta o no son válidas, el compromiso no se acepta.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

¿Cuánto retraso? Depende de cómo se eligen las rondas. El README define bloques obligatorios: el primero de cada sesión debe tener justificación BEEFY. [2] Tras finalizar el obligatorio, la siguiente ronda apunta a un bloque cuya distancia al mejor BEEFY es una potencia de dos, según la mitad de la brecha con GRANDPA. Si BEEFY se atrasa, las rondas cambian con menos frecuencia para darles tiempo de concluir.

La regla tiene una lectura operativa: el retraso no es constante. Con buena red, BEEFY puede llegar a finalizar cada bloque que finaliza GRANDPA, aunque el README advierte que con bloques cortos será raro y sugiere un min_delta entre rondas; con validadores lentos, el salto entre bloques BEEFY crece. Un puente que promete tiempos de liberación tiene que medir esa distribución, no suponerla.

El relayer y el muestreo aleatorio

Los votos BEEFY viajan por gossip entre nodos de Polkadot. Ningún contrato de Ethereum escucha ese gossip: alguien tiene que llevarle las pruebas. La especificación llama a ese actor relayer: "an abstract entity that takes finality proofs from the Polkadot network and makes those available to the light clients." [1]

El relayer no puede inventar finalidad: no tiene las claves de los validadores. Lo que sí puede hacer es no entregar, entregar tarde o intentar convencer al contrato con menos firmas de las necesarias. La seguridad del puente depende de que el contrato verifique lo suficiente, y la disponibilidad depende de que haya al menos un relayer honesto y activo. Esa es la pregunta de confianza que hay que documentar.

Aun con ECDSA, verificar todas las firmas es caro. La Web3 Foundation lo cuantifica: verificar 401 firmas por actualización, con unos 600 validadores en Polkadot, "remains expensive". [4] La respuesta es un protocolo interactivo en tres fases: el relayer se compromete y afirma tener una supermayoría, aportando una firma que puede ser penalizada si es fraudulenta; el contrato usa RANDAO para elegir al azar unas 25 firmas; el relayer presenta exactamente esas.

La especificación recoge la misma idea con sus términos: el relayer guarda en la cadena remota unos datos testigo que indican qué validadores votaron, sin las firmas, y el light client pide después las firmas que quiere comprobar. [1] La seguridad pasa a ser probabilística y criptoeconómica: el tamaño de la muestra se calcula para que atacar no compense.

Según la Web3 Foundation, ese diseño, Random Sampling BEEFY, protege Snowbridge, un puente entre Polkadot y Ethereum lanzado en junio de 2024. [4] Las cifras de uso y valor bloqueado de esa fuente son de su fecha de publicación y no se repiten aquí.

Dónde vive BEEFY en un nodo y en un runtime

En el Polkadot SDK, el nodo kitchensink es el ejemplo que conecta todas las piezas. Su runtime incluye pallet_beefy, pallet_mmr y pallet_beefy_mmr; este último configura el MMR para que cada nueva raíz se deposite como digest BEEFY (OnNewRoot = pallet_beefy_mmr::DepositBeefyDigest<Runtime>) y convierte las claves ECDSA de las autoridades al formato de Ethereum (BeefyEcdsaToEthereum). [5]

En el servicio del nodo, BEEFY se monta como un envoltorio más en la cadena de importación: FullBeefyBlockImport envuelve al BlockImport de GRANDPA, y el servicio registra un protocolo de gossip propio y un manejador de justificaciones bajo demanda. [6] Es el mismo patrón que veremos en el capítulo siguiente: cada motor de finalidad entra al nodo por la cadena de BlockImport y por la red.

Para observarlo, el nodo expone suscripciones RPC paralelas: grandpa_subscribeJustifications y beefy_subscribeJustifications, además de beefy_getFinalizedHead. [7] Son la base del laboratorio de este capítulo.

Qué cambia respecto de Ethereum

Quien viene de validadores, attestations y BLS conoce otra solución al mismo problema de tamaño: Ethereum agrega firmas BLS para que muchos votos quepan en poco espacio. BEEFY, en su versión actual, no agrega: usa ECDSA porque es lo que la EVM verifica barato, y compensa con un compromiso único y con muestreo. El README deja abierta la puerta a otros esquemas, incluidas firmas umbral, en el futuro.

La segunda diferencia es la dirección del puente. El capítulo Puentes y riesgo cross-chain clasifica los verificadores por tipo: multisig, comité, light client o pruebas de validez. Un puente con BEEFY es un light client de la finalidad de Polkadot dentro de Ethereum. Su riesgo no está en un multisig, sino en la corrección del contrato verificador, en la aleatoriedad usada para el muestreo y en la disponibilidad de relayers.

La tercera es el retraso. En Ethereum, la finalidad de Casper FFG avanza por épocas; en Polkadot, GRANDPA finaliza cadenas enteras y BEEFY va detrás. Un puente hacia Ethereum desde Polkadot hereda la suma de ambos: el retraso de GRANDPA, el de BEEFY y el tiempo que tarde el relayer en completar el protocolo de muestreo.

Laboratorio propuesto

Estado: propuesta. Este laboratorio todavía no está publicado en lab.trautslab.dev; describe lo que se construirá, en local, sin red pública ni fondos reales.

Objetivo. Ver con datos que BEEFY va por detrás de GRANDPA y comparar el tamaño de las dos justificaciones del mismo tramo.

Pasos propuestos.

1. Levantar una red local con el nodo kitchensink, cuyo runtime incluye BEEFY, MMR y BEEFY-MMR, con al menos tres validadores.
2. Suscribirse por RPC a grandpa_subscribeJustifications y beefy_subscribeJustifications y registrar, para cada justificación, el número de bloque y la hora de llegada.
3. Para un mismo bloque con ambas justificaciones, comparar el tamaño en bytes de la codificación de cada una.

Evidencia esperada. Una serie de números de bloque BEEFY siempre menores o iguales que los de GRANDPA en el mismo instante, con saltos que crecen si se ralentiza la red. Una justificación BEEFY de tamaño fijo por firma frente a una GRANDPA que incluye datos por voto. Que el chain spec de desarrollo del kitchensink active BEEFY sin configuración extra, y los tamaños concretos, quedan a validar al construir el laboratorio.