Las firmas BLS están en todas partes, desde el consenso de Ethereum hasta EigenLayer. Pero es fácil usarlas de manera incorrecta. ¿Qué son las firmas BLS? Hablemos de la forma correcta y la incorrecta de usarlas:

Pero primero, ¿qué son las firmas BLS? Las firmas BLS son un primitivo criptográfico utilizado para firmar mensajes, como ECDSA. Así es como funciona la matemática. Se basa en emparejamientos de curvas elípticas. Pero, ¿qué las hace tan especiales? ¿Por qué usar estos emparejamientos tan sofisticados?

La característica destacada de BLS: agregación de firmas. Puedes combinar muchas firmas BLS en una sola firma. ¡Esto te permite transmitir y verificar N firmas a la vez, siendo más eficiente en espacio y tiempo! Y en la cadena, las optimizaciones son enormemente importantes para el ahorro de gas.

Para una mirada en profundidad sobre cómo funcionan las firmas BLS, junto con el proceso de construcción de agregaciones y multi-firmas, ¡consulta la publicación completa del blog enlazada al final de este hilo! Ahora, veamos cómo pueden fallar las firmas BLS y cómo EigenLayer las utiliza (correctamente, evitando estas trampas)!

EigenLayer es una capa de restaking para Ethereum. En EigenLayer AVSes, los validadores firman los resultados de sus cálculos de validación. El agregador recopila todas estas firmas y las envía a la cadena. Las firmas agregadas se verifican en la cadena.

La tarea contiene el número de bloque cuando se creó la tarea y un umbral que indica el porcentaje de validación del operador, que es necesario para validar la tarea. Los operadores que optaron por el AVS pueden obtener esas tareas para calcular la respuesta de la tarea y luego el operador puede enviar la respuesta con su firma BLS de la tarea al agregador. Tan pronto como se alcanza el umbral de respuestas idénticas, el agregador fusiona todas las firmas BLS en una única firma agregada y la envía de vuelta al contrato AVS. El contrato verifica que la firma es correcta y abre un período de desafío cuando un retador puede demostrar que la validación fue incorrecta, y si es así, los operadores que se comportaron mal son penalizados.

En el contrato, la verificación ocurre en la función `trySignatureAndApkVerification`:

Sin embargo, las multi-firmas, si se utilizan incorrectamente, presentan un problema serio llamado ataques de clave rebelde. Supongamos que un usuario honesto tiene una clave pública, `pk_0`. Un atacante que ha visto previamente `pk_0` puede elegir su clave pública como pk_1 = sk_1⋅G_1—pk_0. El atacante no conocería la clave privada asociada con la clave pública. Sin embargo, la verificación de la multi-firma daría lo siguiente:

Solo se necesita `sk_1` para firmar un mensaje que resulte en una firma múltiple válida, aunque el primer usuario puede no haberlo firmado. Esto se generaliza fácilmente a cualquier número `r` de usuarios honestos eligiendo la clave rebelde, que es:

Esta es una amenaza peligrosa ya que, en nuestro ejemplo anterior de AVS, un agregador malicioso que anteriormente hubiera registrado una clave fraudulenta podría enviar firmas agregadas no firmadas por los validadores, pero aún así ser aceptadas por el contrato. Esto llevaría a que los validadores fueran sancionados incluso si no se comportaron mal.

Entonces, para prevenir un ataque de clave maliciosa, el método común es solicitar a los usuarios que demuestren que conocen la clave privada que coincide con su clave pública, conocido como prueba de posesión. Así, en el primer paso de registro, se solicita al usuario que registre su clave pública junto con la prueba de posesión π de tal manera que:

Básicamente, se le solicita al usuario que firme su clave pública o cualquier otro mensaje de identificación. En AVS, el mensaje es la dirección del operador. En el contrato de EigenLayer, la prueba de posesión se verifica mediante la función `registerBLSPublicKey`:

La función `pubkeyRegistrationMessageHash` se utiliza para hashear el separador de dominio personalizado `PUBKEY_REGISTRATION_TYPEHASH` y la dirección del operador.

Después de registrarse, la clave pública se añade al contrato. Podemos verificar su valor llamando a la función `getRegisteredPubkey`. Aquí hay un ejemplo de una clave pública BLS registrada para EigenDA AVS:

La prueba de posesión es básicamente una firma BLS. Sin embargo, tampoco es recomendable usar múltiples firmas durante el paso de prueba de posesión, por ejemplo, para registrar múltiples claves públicas para un solo participante. Si es así, el participante lograría un ataque de cero dividido. En este caso, el participante podría registrar claves que se cancelarían al sumarse y podría eludir la prueba de posesión.

Hemos visto que las multi-firmas BLS ofrecen una oportunidad de optimización significativa. La implementación de EigenLayer demuestra el poder de las firmas BLS y también destaca las complejidades involucradas en su implementación práctica. Sin embargo, las multi-firmas introducen riesgos de seguridad como ataques de clave maliciosa, lo que requiere salvaguardias como la prueba de posesión. Pero con la actualización de Pectra que soporta BLS12-381, podríamos ver una mayor implementación y mejoras en Solidity, y por lo tanto esperamos que esta publicación ayude a evitar errores de implementación y vulnerabilidades conocidas.

Para una inmersión más profunda en las firmas BLS, la construcción de agregaciones y las multi-firmas, consulta nuestra publicación de blog recientemente publicada a continuación: