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

Pero primero, ¿qué son las firmas BLS? Las firmas BLS son una primitiva criptográfica que se utiliza para firmar mensajes, como ECDSA. Así es como funcionan las matemáticas. Está construido sobre pares de curvas elípticas. Pero, ¿qué los hace tan especiales? ¿Por qué usar estos maridajes elegantes?

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

Para obtener una visión en profundidad de cómo funcionan las firmas BLS, junto con el proceso de creación de agregación y firmas múltiples, consulte la publicación de blog completa vinculada al final de este hilo. Ahora, veamos cómo las firmas BLS pueden salir mal y cómo EigenLayer las usa (correctamente, evitando estas trampas).

EigenLayer es una capa de replanteamiento para Ethereum. En los AVS de EigenLayer, los validadores firman los resultados de sus cálculos de validación. El agregador recoge 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 hacer que esas tareas calculen la respuesta a la tarea y, a continuación, 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 firma agregada única y la envía de vuelta al contrato AVS. El contrato verifica que la firma es correcta y abre un período de impugnación en el que un impugnador puede dar pruebas de que la validación fue incorrecta y, de ser así, los operadores que se comportan mal son eliminados.

En el contrato, la verificación se realiza en la función 'trySignatureAndApkVerification':

Sin embargo, las firmas múltiples, si se usan incorrectamente, conllevan un problema grave llamado ataques de clave no autorizada. Digamos que un usuario honesto tiene una clave pública, 'pk_0'. Un atacante que haya 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 a la clave pública. Sin embargo, la verificación de múltiples firmas daría lo siguiente:

Solo se necesita "sk_1" para firmar un mensaje que dé como resultado una firma múltiple válida, aunque es posible que el primer usuario no lo haya firmado. Esto se generaliza fácilmente a cualquier número 'r' de usuarios honestos eligiendo la clave maliciosa, siendo:

Se trata de una amenaza peligrosa ya que, en nuestro ejemplo anterior de AVS, un agregador malicioso que habría registrado previamente una clave maliciosa podría enviar firmas agregadas no firmadas por los validadores, pero que aún así serían aceptadas por el contrato. Esto llevaría a que los validadores fueran recortados incluso si no se comportaron mal.

Por lo tanto, para evitar un ataque de clave no autorizada, el método común es solicitar a los usuarios que demuestren que saben que la clave privada coincide con su clave pública, lo que se conoce como prueba de posesión. Por lo tanto, en el primer paso de registro, se solicita al usuario que registre su clave pública junto con una prueba de posesión π tal que:

Básicamente, se 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 del registro, la clave pública se agrega al contrato. Podemos verificar su valor llamando a la función 'getRegisteredPubkey'. A continuación, se muestra 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 aconsejable utilizar firmas múltiples durante el paso de prueba de posesión, por ejemplo, para registrar varias claves públicas para un solo participante. Si es así, el participante lograría un ataque de división cero. En este caso, el participante podría registrar claves que se cancelarían cuando se sumaran y podría omitir la prueba de posesión.

Hemos visto que las firmas múltiples de BLS ofrecen una importante oportunidad de optimización. 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 firmas múltiples introducen riesgos de seguridad, como los ataques de clave no autorizadas, que requieren salvaguardas como la prueba de posesión. Pero con la actualización de Pectra compatible con BLS12-381, es posible que veamos más implementaciones y mejoras en Solidity, por lo que esperamos que esta publicación ayude a evitar errores y vulnerabilidades de implementación conocidos.

Para obtener una inmersión más profunda en las firmas BLS, la agregación de edificios y las firmas múltiples, consulte nuestra publicación de blog publicada recientemente a continuación: