BB84, un rollup de OP Stack activo en la mainnet de Ethereum bajo el chain ID 42069000, ha eliminado por completo las firmas de transacciones de su red, reemplazándolas por cadenas de hash estilo Lamport en un diseño destinado a mitigar la amenaza cuántica a largo plazo para la criptografía convencional. La red opera en la mainnet desde el 30 de septiembre. Su fundador, que publica bajo el seudónimo de Hadamard, describió el sistema en una publicación del 24 de octubre en Ethereum Research y solicitó retroalimentación crítica.

Las cuentas ordinarias de Ethereum autorizan transacciones con firmas ECDSA, que una computadora cuántica lo suficientemente grande ejecutando el algoritmo de Shor podría romper. Hoy no existe ninguna máquina capaz de hacerlo, pero las advertencias sobre claves de billeteras expuestas han impulsado a los desarrolladores a buscar alternativas: una clave se vuelve visible públicamente una vez que una cuenta ha enviado una transacción. Las construcciones basadas en hash también se encuentran entre los candidatos post-cuánticos más antiguos: Leslie Lamport propuso un esquema de firmas basado en hash en 1979, y los estándares post-cuánticos de NIST de 2024 incluyen un esquema basado en hash, SLH-DSA.

Cuentas de cadena de hash, un paso a la vez

Cada cuenta de BB84 se construye a partir de un secreto que se hashea una y otra vez con keccak-256 —la misma función hash que usa el propio Ethereum— creando una cadena de valores en la que solo el último valor es público. Para pagar, la billetera revela el valor anterior a la posición actual, que cualquiera puede verificar hasheándolo una vez. La red luego registra ese valor y mueve la cuenta un paso abajo en la cadena.

El valor predeterminado del protocolo es de 1,000 pagos por cadena de hash, mientras que la CLI de desarrolladores de BB84 crea cadenas de 10 pasos para cada dirección de un solo uso. Un paso se consume incluso si el pago en sí falla, y la cadena rechaza cualquier transacción firmada de manera convencional.

Los pagos se liquidan únicamente en USDC y EURC puenteados. Tanto las transacciones de commit como las de reveal son gratuitas para los usuarios, y los pagadores crean una dirección nueva de un solo uso para cada destinatario.

El compromiso de seguridad

La publicación detalla los límites del diseño. Dentro de la red, todo descansa en que keccak-256 sea difícil de revertir, y el algoritmo de búsqueda cuántica de Grover lo reduciría solo a unas 2^128 operaciones. Las direcciones, sin embargo, se acortan a 160 bits, lo que deja alrededor de 2^80 de resistencia cuántica en la propia dirección. La documentación de BB84 anuncia seguridad post-cuántica de 128 bits sin esa advertencia. La mainnet de Ethereum también sigue siendo ECDSA: los depósitos provienen de billeteras ordinarias de Ethereum, y los retiros se pagan en ellas.

Una falla de front-running descubierta mientras se redactaba la publicación

Revelar un secreto lo hace público, por lo que cualquier observador podría copiarlo en una transacción que se pague a sí mismo. Para evitarlo, la billetera primero envía una trans de commit que bloquea el secreto a un pago exacto sin mostrarlo. El reveal debe seguir dentro de cinco bloques de forma predeterminada.

El punto débil era que los commits no llevan firma, porque no hay nada con qué firmar. En la primera versión, un nuevo commit simplemente reemplazaba al pendiente. Un atacante que detectara un secreto en un reveal pendiente podía insertar un commit que vinculase ese secreto a su propio pago. Hadamard dice que el equipo descubrió la falla mientras redactaba la publicación y la corrigió con una nueva regla que entró en vigor el 21 de octubre. Según la regla revisada, gana el primer commit, el espacio se libera solo tras el reveal correspondiente o su expiración, la billetera espera a que su commit quede en un bloque antes de revelar, y el RPC público no expone las transacciones pendientes.

Lo que la corrección deja abierto

El griefing sigue siendo posible: cualquiera puede publicar un commit basura y bloquear una dirección por hasta cinco bloques, aunque no puede mover sus fondos. Un sequencer deshonesto es otro riesgo residual: si un commit honesto expira o es reorganizado fuera mientras su reveal está pendiente, el secreto deja de estar bloqueado. Hoy solo el sequencer propio de BB84 ve las transacciones pendientes.

Hadamard sugiere una regla "Guy Fawkes" más estricta, en la que los commits se agregan en lugar de reemplazarse, pero dice que no ha sido implementada. La documentación va más allá de la publicación, afirmando que el commit y el reveal implican que un sequencer no puede robar un retiro.

Una billetera que no debe perder la cuenta

Como cada cadena tiene un número fijo de pasos, la billetera debe renovarla en el último de ellos incluyendo un nuevo compromiso en ese pago final. Si omite ese paso, la dirección queda muerta. Mantener la cuenta es igual de importante: Hadamard dice que la aplicación y la cadena perdieron la sincronización en producción, por lo que las billeteras deben poder resincronizarse a partir de los datos de la cadena.

Los secretos todavía deben protegerse como claves. La CLI advierte que su archivo de billetera almacena las claves de gasto sin cifrar y lista el cifrado como un elemento del roadmap. Eliminar las firmas cambia cómo se autoriza el gasto, no la necesidad de mantener los secretos a salvo.

Los retiros dependen de un operador de confianza

BB84 no tiene fault proofs. Un proposer con permisos publica el estado de la red en Ethereum a través de un juego de disputas personalizado que se resuelve de inmediato, y sin un sistema de pruebas, Hadamard escribe que, según el marco de L2BEAT, la cadena "ni siquiera sería Stage 0". El marco califica los rollups de Stage 0 a Stage 2 según cuánto deben confiar los usuarios en un operador en lugar de en un sistema de pruebas. Por lo tanto, los retiros confían en el proposer. La documentación todavía describe los retiros como un flujo de fault proofs de OP Stack con un retraso de maduración de siete días, pero como señala la explicación de Optimism, los fault proofs existen para que el estado incorrecto pueda ser impugnado —y aquí nada puede ser impugnado durante esa espera. El sequencer también es operado por BB84.

Qué cambiaría el panorama

La publicación cierra con preguntas que van más allá de una sola cadena. La mayor es si las cuentas de cadena de hash podrían convertirse en un modo de validación estilo EIP-7702 o de abstracción de cuentas nativa en redes de capa 2 de propósito general, lo que haría la idea accesible sin necesidad de migrar a una cadena dedicada. EIP-7702, activo desde la actualización Pectra de Ethereum en mayo de 2025, permite que las cuentas ordinarias adopten código de contratos inteligentes. Hadamard añade que las verificaciones adicionales son lo suficientemente simples de probar con la herramienta Cannon existente de Optimism, que una regla de commit de solo agregación cerraría tanto la brecha de griefing como la del sequencer, y que se está preparando un documento más extenso con las reglas completas para arXiv. El esfuerzo de migración más amplio de Ethereum, expuesto en su roadmap cuántico, también cubre las firmas de validadores, los compromisos de datos y los sistemas de pruebas.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión. Las redes experimentales conllevan riesgos técnicos y de custodia.

Fuente: Coindoo