Liviu Hrenaru, fundador de Aere Network, explica a Territorio Bitcoin qué significa realmente preparar una blockchain frente a un futuro ataque cuántico.
Su red ya utiliza identidades, transacciones y certificados post-cuánticos, pero la finalidad por bloque continúa dependiendo de ECDSA, los diez validadores tienen un único operador y todavía no existe una auditoría externa.
¿Cuándo puede una blockchain afirmar realmente que está preparada para resistir un ordenador cuántico?
La respuesta aparentemente sencilla sería cuando sustituye la criptografía vulnerable por algoritmos post-cuánticos. En la práctica, el problema es mucho más complejo.
Una red puede proteger determinados tipos de transacciones y seguir utilizando criptografía clásica en otras cuentas. Puede autenticar mensajes de consenso mediante firmas post-cuánticas y continuar dependiendo de ECDSA para demostrar qué bloque fue finalmente decidido. Incluso puede disponer de dos implementaciones distintas de su protocolo y mantener todos sus validadores bajo el control de una única organización.
Aere Network reúne actualmente varias de esas contradicciones.
Y su fundador y CEO, Liviu Hrenaru, no intenta ocultarlas.
Aere se presenta hoy como una infraestructura criptográfica construida alrededor de una Layer 1 pública compatible con EVM. El proyecto está desarrollando herramientas relacionadas con claves, certificados, identidad, comunicaciones y pruebas verificables preparadas para un escenario en el que parte de la criptografía actual pueda dejar de ser segura.
En su blockchain ya existen transacciones autorizadas mediante ML-DSA, identidades de validadores derivadas de claves Falcon-512 y certificados post-cuánticos incorporados periódicamente a la cadena.
Pero Aere todavía no dispone de finalidad post-cuántica por bloque.
La evidencia persistente que determina actualmente la finalidad de cada bloque continúa dependiendo de firmas clásicas ECDSA. La propia Aere distingue ahora entre esa finalidad clásica y los certificados post-cuánticos que protegen periódicamente la historia de la cadena.
La precisión no es menor.
Durante la preparación de esta entrevista, Territorio Bitcoin contrastó las respuestas de Hrenaru con la documentación técnica del proyecto y solicitó una segunda ronda de aclaraciones. Encontramos, entre otras cuestiones, una página que seguía indicando que el segundo cliente de Aere funcionaba únicamente en testnet cuando, según Hrenaru y los datos aportados para su comprobación, ya participaba en mainnet.
Aere reconoció que la página estaba desactualizada y la corrigió el 5 de octubre.
Esa revisión terminó llevando la conversación hacia una pregunta mucho más interesante que qué blockchain puede colocar antes la etiqueta post-cuántica.
¿Qué puede demostrarse realmente detrás de ella?
Empecemos poniendo una línea roja. ¿Cuándo podrá Aere afirmar legítimamente que tiene finalidad completamente post-cuántica?
Liviu Hrenaru: Solo utilizaremos la expresión full post-quantum finality para mainnet cuando se cumplan cuatro condiciones.
Primero, el commit seal debe estar vinculado a la ronda de consenso y un certificado debe representar un quorum de sellos pertenecientes a una misma ronda.
Después llegará la etapa 4 de AIP-22: la cadena de certificados pasará a convertirse en el criterio para determinar la cadena canónica, y los commit seals y firmas clásicas dejarán de ser criterios de validez.
En la etapa 5, los commit seals clásicos desaparecerán de las cabeceras, que incorporarán en su lugar el sello Falcon-512 del proponente.
Y ambas implementaciones del cliente deberán aplicar las mismas reglas, mientras el verificador público deberá poder reproducirlas a partir de las cabeceras y los vectores publicados.
En ese momento ninguna firma ECDSA formará parte de la definición de finalidad.
Incluso entonces quedarían tres cuestiones antes de poder hablar de toda la cadena de confianza como post-cuántica y creíblemente neutral: el transporte entre nodos, la migración de las cuentas convencionales y disponer tanto de validadores independientes como de una auditoría externa.
Entonces, ¿qué partes de Aere son realmente post-cuánticas hoy?
Hay varias capas.
Desde el bloque 19.900.000 existe el tipo de transacción 0x50, definido en AIP-20. Se autoriza mediante una firma ML-DSA y la dirección del remitente deriva de su clave pública post-cuántica. No interviene secp256k1 en la validación de esas transacciones.
Las transacciones clásicas continúan siendo válidas por compatibilidad.
También existen cinco contratos precompilados que permiten verificar Falcon-512, Falcon-1024, ML-DSA-44 y SLH-DSA-SHA2-128s, además de SHAKE256.
Desde el bloque 20.836.228 las identidades de los validadores derivan de claves Falcon-512.
Y los mensajes del consenso —propuesta, preparación, commit y cambio de ronda— incorporan un sello Falcon-512 vinculado al autor.
Además están los certificados de anclaje: cada 32 bloques se incorpora un certificado de al menos siete de los diez validadores mediante Falcon-512 y cada 128 bloques se exige también SLH-DSA.
Pero, insisto, la finalidad individual de cada bloque sigue siendo clásica.
¿Por qué es tan importante distinguir entre autenticar un mensaje mediante criptografía post-cuántica y tener finalidad post-cuántica?
Porque responden a dos preguntas diferentes.
La autenticación pregunta: ¿quién envió este voto?
La finalidad plantea algo más difícil: ¿qué decidió realmente la red y puede alguien que no estaba presente comprobar esa decisión posteriormente utilizando únicamente la cadena?
Desde el bloque 17.700.000, nueve de los diez validadores rechazan un voto que no lleve un sello Falcon-512 válido de su autor. Una decisión necesita siete validadores.
Pero la evidencia permanente incluida actualmente en cada cabecera continúa siendo clásica: los commit seals ECDSA correspondientes a un quorum de una misma ronda.
Los sellos post-cuánticos son comprobados cuando llegan los mensajes y quedan posteriormente incorporados a la cadena mediante los certificados periódicos.
Por eso hablamos de bloques post-quantum certified y no afirmamos que exista todavía finalidad post-cuántica por bloque.
Precisamente Aere tuvo que corregir su especificación el 1 de octubre. ¿Qué ocurrió?
Lo encontramos nosotros mismos durante una revisión adversarial del protocolo antes de activar la siguiente etapa en mainnet y lo publicamos ese mismo día.
El sello post-cuántico de commit firmaba la cadena, la altura y el hash del bloque, pero no incorporaba la ronda de consenso.
En QBFT, un validador honesto puede comprometerse con un bloque en una ronda que no llega a completarse y posteriormente decidirse un bloque diferente durante otra ronda.
Eso significaba que disponer de siete sellos válidos sobre un bloque demostraba que siete validadores lo habían sellado, pero no demostraba por sí mismo que aquel fuera el bloque finalmente decidido.
Reproducimos el problema en el cliente de referencia y publicamos una errata en AIP-21 y AIP-22.
El verificador también dejó de utilizar una etiqueta de finalidad y pasó a mostrar post-quantum certified, indicando además que esos sellos no contienen la ronda de consenso.
La finalidad actual de mainnet no se vio afectada porque cada cabecera continúa conteniendo el quorum clásico correspondiente a una misma ronda.
Prefiero corregir públicamente mi propia especificación en un día que defender una frase que afirma más de lo que permiten demostrar las matemáticas.
¿Y qué hace falta para solucionar esa limitación?
El commit seal tiene que incorporar la ronda.
El validador debe firmar la cadena, la altura, la ronda y el hash del bloque, y un certificado solo podrá considerarse un quorum cuando los sellos correspondan a la misma ronda.
La misma regla debe existir en ambos clientes, en el verificador público y en los vectores de prueba.
El round-bound seal ya está implementado en los dos clientes y se encuentra en pruebas de conformidad entre ellos.
Pero quiero ser preciso: todavía no está desplegado en ninguna red y no existe una altura programada para activarlo en mainnet.
Supongamos el peor escenario: mañana aparece un ordenador cuántico capaz de comprometer ECDSA. ¿Qué sobreviviría?
La historia situada por debajo del anclaje post-cuántico más reciente permanecería protegida porque reescribirla obligaría a reproducir sus certificados.
También se mantendrían protegidas las identidades de los validadores, las cuentas creadas bajo AIP-20 y aquellos contratos que exijan una firma post-cuántica antes de mover sus activos.
Y la red en vivo continuaría exigiendo los sellos post-cuánticos en los mensajes del consenso.
Pero otras partes serían vulnerables.
La mayoría de las cuentas de Aere, como ocurre en las cadenas EVM, siguen utilizando secp256k1. Una vez que una cuenta convencional ha realizado una transacción, su clave pública es conocida y un adversario cuántico suficientemente capaz podría llegar a firmar en su nombre.
También estarían expuestos los contratos administrados mediante claves clásicas, el transporte entre nodos y la finalidad de la parte más reciente de la cadena antes de quedar cubierta por el siguiente anclaje.
La posibilidad de migrar a una cuenta AIP-20 ya existe. La adopción, sin embargo, acaba de comenzar.
¿Cuánto podría reescribirse de esa parte reciente de la cadena?
En el modelo de amenaza que hemos publicado, como máximo 32 bloques, con una excepción que puede ampliar el límite a 33, aproximadamente veinte segundos.
Estamos hablando de un escenario extremo en el que el atacante posee todas las claves clásicas ECDSA de los validadores pero ninguna de sus claves post-cuánticas.
Sin siete claves Falcon-512 no puede producir arbitrariamente un nuevo certificado válido.
El bloque adicional procede precisamente de la limitación que encontramos en el sello que todavía no está vinculado a una ronda.
Publicamos el argumento, un modelo basado en Z3 y un verificador para que esa afirmación pueda comprobarse sin confiar en nosotros.
Nota de Territorio Bitcoin: este límite procede del modelo de amenaza y de las herramientas publicadas por Aere. Todavía no ha sido validado mediante una auditoría externa independiente.
Hablemos precisamente de verificación. ¿Puede un investigador comprobar todo esto sin depender de servidores de Aere?
El endpoint que proporcionamos es una opción predeterminada, no una dependencia.
La criptografía se ejecuta en la máquina del investigador. El endpoint RPC puede sustituirse por localhost y el mismo verificador puede utilizarse contra un nodo operado por esa persona.
Los manifiestos de claves también pueden descargarse y comprobarse contra la información anclada en la cadena.
Publicamos además el código necesario para ejecutar un nodo compatible.
Hay limitaciones y debemos decirlas.
Actualmente los peers iniciales a los que se conecta un nodo nuevo están operados por la Foundation porque todavía no existe un operador independiente.
Y aunque el código de validación del segundo cliente es público, su motor de consenso encargado de producir bloques todavía no lo es. Publicarlo es una condición que nosotros mismos hemos establecido antes de incorporar el primer puesto externo que utilice ese cliente.
Ese segundo cliente nos llevó precisamente a pediros una aclaración. ¿Está produciendo realmente bloques en mainnet?
Sí.
La página que encontrasteis estaba desactualizada y la corregimos el 5 de octubre.
Desde el bloque 18.083.404, el décimo validador utiliza una segunda implementación basada en Nethermind, mientras los otros nueve ejecutan nuestro cliente derivado de Hyperledger Besu.
Ese validador propone su parte de los bloques. En una ventana de 1.000 bloques que comprobamos, produjo exactamente 100, la misma proporción que cada uno de los otros nueve.
Cada bloque es, por tanto, validado por dos bases de código desarrolladas separadamente.
Pero tampoco quiero exagerar lo que significa: con nueve de los diez puestos ejecutando el primer cliente, el segundo proporciona una comprobación independiente, no tolerancia frente al fallo del cliente mayoritario.
Existe otra concentración todavía mayor: los diez validadores están operados por Aere Foundation. ¿Puede considerarse descentralizada la red actualmente?
Una organización, Aere Foundation, opera los diez validadores.
No reclamamos diversidad de infraestructura como mitigación. La evaluación correcta hoy es considerar la red como un único operador y un único punto de fallo, independientemente de dónde estén alojadas físicamente las máquinas.
Eso genera riesgos de integridad, operación, infraestructura, gobernanza y censura.
Una sola organización controla actualmente las claves de los diez validadores, establece las alturas de activación y controla las votaciones para modificar el conjunto de validadores.
El objetivo es llegar hasta 21 puestos con operadores independientes.
Para un nuevo validador exigimos una entidad diferente, un proveedor de infraestructura diferente y un país diferente. Las claves deben generarse en la máquina del propio operador y la Foundation nunca recibe las claves privadas.
Pero a día de hoy ningún operador independiente tiene un puesto.
La criptografía podíamos construirla nosotros, así que la construimos.
La descentralización no puede construirse solo. Hay que entregársela a otros.
Y tampoco existe todavía una auditoría externa. ¿Qué tendría que revisar?
No. Actualmente no existe ninguna firma de auditoría contratada.
El consenso necesita un equipo con experiencia demostrable en protocolos BFT y código de clientes. Las implementaciones de firmas requieren especialistas capaces de revisar codificaciones, casos límite y canales laterales en Falcon, ML-DSA y SLH-DSA. Y los contratos necesitan una auditoría especializada en smart contracts.
Probablemente serán al menos dos trabajos diferentes.
Queremos auditar un protocolo congelado y no uno que siga cambiando. El round-bound seal modifica una parte central de aquello que debería revisar un auditor, así que tiene que terminar primero.
Hasta entonces tenemos dos implementaciones, pruebas diferenciales, un tercer verificador independiente de determinadas reglas, vectores publicados y una testnet en la que se despliegan primero los cambios.
Nada de eso sustituye una auditoría externa y no lo presentamos como tal.
Si las firmas post-cuánticas existen, ¿por qué no sustituir directamente ECDSA en todos los bloques?
Porque las firmas post-cuánticas tienen un coste que no puede ignorarse.
Una firma clásica ocupa 65 bytes. Una Falcon-512 ocupa aproximadamente 663 bytes. Una firma SLH-DSA-SHA2-128s llega a 7.861 bytes.
Un certificado Falcon completo en cada cabecera supondría entre 259 y 370 GB adicionales por nodo cada año.
Con SLH-DSA superaríamos los 3 TB por nodo y año.
Además existe un coste de rendimiento. Cuando probamos en testnet un sello SLH-DSA en cada commit, el tiempo de bloque pasó aproximadamente de 0,5 a 4 segundos.
Por eso optamos por un certificado Falcon cada 32 bloques y SLH-DSA cada 128.
La consecuencia es un compromiso: un bloque queda cubierto por Falcon aproximadamente dentro de los siguientes 32 bloques —unos veinte segundos— y por ambos esquemas dentro de 128 bloques, alrededor de 75 segundos.
El problema de ingeniería no consiste simplemente en preguntar qué algoritmo utilizar.
La verdadera pregunta es dónde colocar las firmas y con qué frecuencia.
Aere ya utiliza Falcon, ML-DSA y SLH-DSA. ¿Por qué combinar algoritmos diferentes?
Porque no queremos que toda la seguridad dependa de una única familia matemática.
Falcon y ML-DSA pertenecen al ámbito de la criptografía basada en retículas, mientras SLH-DSA utiliza firmas basadas en funciones hash.
En los anclajes correspondientes al intervalo de 128 bloques exigimos ambos tipos.
Eso introduce un coste, especialmente porque SLH-DSA tiene firmas mucho mayores y es más lento, pero proporciona diversidad criptográfica.
No se trata simplemente de añadir más criptografía. Hay que decidir dónde aporta seguridad suficiente para justificar su coste.
Gran parte de la preocupación cuántica suele resumirse con la expresión harvest now, decrypt later. ¿Es ese el principal problema para una blockchain?
No.
Harvest now, decrypt later es fundamentalmente una amenaza contra datos cifrados: capturar hoy información cifrada para descifrarla en el futuro cuando exista la capacidad necesaria.
Las firmas son públicas desde el momento en que se realizan.
En una blockchain, el riesgo cuántico es diferente: la falsificación de firmas y la posibilidad de reconstruir o reescribir la historia utilizando claves de validadores recuperadas.
Ese es precisamente el escenario para el que diseñamos los anclajes.
Has dicho que la adopción de las cuentas post-cuánticas apenas comienza. ¿No existe el riesgo de construir una infraestructura preparada para una amenaza futura mientras los usuarios continúan utilizando cuentas vulnerables?
Sí.
Una infraestructura puede ofrecer una ruta de migración, pero no puede obligar automáticamente a todos los usuarios a utilizarla.
Las cuentas AIP-20 no utilizan una clave clásica en su autorización, pero las cuentas EVM convencionales continúan funcionando por compatibilidad.
Por eso tampoco sería correcto afirmar que toda Aere Network es hoy post-cuántica.
La transición tiene diferentes capas y diferentes ritmos.
Nuestro trabajo consiste en conseguir que la ruta exista antes de que sea necesaria, hacerla verificable y explicar con precisión qué parte ya está protegida y cuál no.
Después de todo este trabajo, ¿crees que la industria está llegando tarde al riesgo cuántico?
La industria continúa describiendo el ordenador cuántico como un problema para después.
Nosotros no estamos de acuerdo.
Y tampoco creemos que una blockchain sea un producto en sí mismo. La vemos como una capa de liquidación sobre la que pueden construirse las claves, certificados, identidad, pruebas y auditoría que las organizaciones necesitarán si la criptografía clásica deja de ser segura.
Hemos trasladado las identidades de los validadores y los certificados de una red activa a claves post-cuánticas y hemos introducido un tipo de transacción nativamente post-cuántico mientras la cadena seguía funcionando.
Pero también publicamos aquello que todavía no está terminado.
El día que aparezca un ordenador cuántico suficientemente capaz, a todos los sistemas se les preguntará qué tenían preparado.
Queremos poder responder con números de bloque para lo que ya funciona y con una lista pública para aquello que todavía no.
Después de revisar vuestra documentación para esta entrevista encontramos información desactualizada y vosotros mismos habéis corregido una especificación del protocolo. ¿Por qué debería un lector confiar ahora en las afirmaciones de Aere?
No debería.
No confíes en nuestra palabra. Verifícalo.
Todo lo que he explicado puede contrastarse sin nosotros.
Ese es el estándar que pediría a vuestros lectores que aplicaran a cualquier red que haga una afirmación post-cuántica.
A la nuestra, la primera.