Evidencia poscuántica para agentes autónomos en la Quantova Virtual Machine

Resumen

Los agentes autónomos y los agentes de superinteligencia realizan ya pagos, adoptan decisiones y presentan documentación en nombre de empresas de los sectores bancario, público, sanitario y financiero. Los registros de lo que hicieron esos agentes los custodian los mismos operadores cuya conducta describen dichos registros. Tales registros pueden ser reescritos por su custodio y, cuando llegan a firmarse, se firman con ECDSA, EdDSA o RSA, que el algoritmo de Shor permite falsificar a un ordenador cuántico en tiempo polinómico.

Qstamp es un SDK abierto y un conjunto de contratos inteligentes Quanta en la Quantova Virtual Machine (QVM) que convierten los registros de los agentes en evidencia duradera que cualquier persona puede verificar, mientras los propios registros permanecen privados en poder del operador. Cada registro se reduce a un resumen SHA3 256 y se vincula a una sal nueva de 256 bits. Las hojas resultantes se combinan en un árbol de hashes RFC 9162 de hasta 2²⁰ hojas, y el árbol queda comprometido mediante un único valor de 32 bytes con separación de dominios que vincula la cadena, el contrato, el firmante, el tipo de registro y el tamaño del lote. El compromiso se ancla mediante un contrato inteligente Quanta atestado en una transacción firmada con ML DSA 65 y finalizada por un comité de validadores que ha firmado cada bloque con ML DSA 65 desde el bloque génesis.

Definimos un juego de falsificación de evidencia y demostramos que la ventaja de cualquier adversario clásico o cuántico está acotada por las ventajas de colisión y de segunda preimagen frente a SHA3 256, una ventaja EUF-CMA multiplicada por q frente a ML DSA 65 y la probabilidad de un fallo del consenso. Enunciamos con exactitud lo que un recibo demuestra y lo que no demuestra, describimos cómo se compilan, se atestan y se despliegan los contratos, proporcionamos un procedimiento de verificación adecuado a las órdenes de tribunales y reguladores con un ejemplo desarrollado en la red de pruebas de Quantova, y relacionamos la construcción con las obligaciones de conservación de registros en la Unión Europea, el Reino Unido, Estados Unidos, Japón, Corea y Hong Kong.

Palabras clave

1. Introducción y resumen de las contribuciones

Los agentes de software construidos sobre grandes modelos invocan ya herramientas, mueven fondos, aprueban créditos y producen contenido en nombre de personas e instituciones. Cuando posteriormente se impugna una de estas acciones, la cuestión que se plantea ante un tribunal, un supervisor o una aseguradora es fáctica. ¿Qué hizo el agente, bajo qué modelo y política, y cuándo? La respuesta se extrae casi siempre de registros llevados por el operador del agente, que es también la parte cuya conducta está en cuestión.

De ello se derivan dos debilidades. La primera es la custodia. Un registro conservado en una base de datos bajo el control administrativo del operador puede ser modificado por este, y nada en el propio registro revela el cambio. La segunda es la durabilidad. Cuando los registros se protegen criptográficamente, la protección consiste en una firma digital basada en ECDSA, EdDSA o RSA, y las estimaciones de recursos publicadas indican que un ordenador cuántico tolerante a fallos de tamaño suficiente falsificaría tales firmas en horas o días [10, 11, 8]. Muchos registros deben conservarse entre seis y diez años [37, 35], un plazo largo en comparación con la incertidumbre sobre cuándo podría existir una máquina así [13].

Qstamp aborda ambas debilidades con una única construcción. Cada registro se reduce, dentro del perímetro del operador, a un compromiso SHA3 256 con sal. Un lote de hasta 2²⁰ compromisos se agrega en un árbol de hashes, y un único valor de 32 bytes que vincula el árbol a su cadena, contrato, firmante, tipo y tamaño se ancla mediante un contrato inteligente Quanta en la Quantova Virtual Machine. Toda firma de la que depende ese anclaje, desde la cuenta que lo envía hasta el comité que lo finaliza, es una firma ML DSA 65 [24], y así ha sido desde el bloque génesis de la red. El registro nunca sale del ámbito del operador, y cualquier parte que posea el registro y su recibo puede verificarlo posteriormente sin confiar en el operador ni en Quantova Inc.

Este artículo realiza las siguientes contribuciones.

1. Un modelo formal del operador como adversario interno y del adversario cuántico frente a las firmas clásicas, y un predicado que recoge los requisitos de conservación de registros de la normativa vigente (Sección 2 y Sección 3).
2. Una especificación completa de la construcción de Qstamp exactamente tal como está implementada en la versión 0.1.4 del SDK, incluidas las codificaciones, los algoritmos de sellado y de verificación y el resultado de verificación trivalente (Sección 5).
3. Una reducción que demuestra que la falsificación de evidencia contra Qstamp está acotada por la resistencia a colisiones y a segundas preimágenes de SHA3 256, la infalsificabilidad de ML DSA 65 y la seguridad del consenso, junto con propiedades de vinculación, ocultación y vivacidad y cotas concretas clásicas y cuánticas (Sección 6).
4. Un enunciado preciso de lo que un recibo demuestra y no demuestra para agentes autónomos (Sección 7), y un procedimiento de verificación para órdenes de tribunales y reguladores ilustrado con una ejecución real en la red de pruebas (Sección 8).
5. Una correspondencia entre las obligaciones legales y las propiedades formales proporcionadas y sus límites (Sección 9), un análisis de por qué dichas propiedades requieren una capa 1 poscuántica con código de contratos atestado (Sección 10), y el coste y la latencia medidos (Sección 11).

Este artículo describe únicamente lo que está en funcionamiento en la fecha de la Versión 1.0. La construcción se ejecuta en la red de pruebas de Quantova, cuyos recibos carecen de valor probatorio. El uso en producción tendrá lugar en la red principal de Quantova una vez que entre en funcionamiento. Las funcionalidades previstas se identifican como tales en la Sección 6.7 y en la Sección 12.

2. El problema, enunciado matemáticamente

En todo el artículo, H denota SHA3 256 [22], ‖ denota la concatenación de bytes, λ denota el parámetro de seguridad, y un algoritmo es eficiente si se ejecuta en tiempo polinómico en λ en un ordenador clásico (PPT) o en un ordenador cuántico (QPT).

2.1 Registros controlados por el operador y el adversario interno

Las firmas calculadas por O no modifican esta conclusión. Si cada entrada lleva σ_j = Sign(sk_O, e_j), entonces O, que posee sk_O, calcula una σ′ válida para cualquier sustituto e′. La firma de un custodio autentica el origen frente a terceros, pero no dice nada sobre la integridad frente al propio custodio. La integridad frente a O requiere un testigo W, una parte o un sistema cuyo estado O no puede alterar, que fije un valor derivado de Λ antes de t_a. En la práctica actual, la confianza de V en el estado de W descansa en firmas de W, casi siempre ECDSA sobre secp256k1 o P 256 [26, 29], Ed25519 [30] o RSA, o en ninguna firma cuando el testigo es un sistema interno del operador.

2.2 El algoritmo de Shor y su coste publicado

2.2.1 La reducción al cálculo del orden

Sea N un entero compuesto impar que no es potencia de un primo, y sea a elegido uniformemente entre las unidades módulo N. El orden de a es

Si r es par y a^r/2 ≢ −1 (mod N), entonces N divide a (a^r/2 − 1)(a^r/2 + 1) pero a ninguno de los factores, por lo que

es un factor no trivial. Para N con al menos dos factores primos impares distintos, este suceso tiene probabilidad al menos un medio sobre la elección de a [2, 12]. Por tanto, la factorización se reduce en tiempo polinómico clásico al cálculo de órdenes, y la contribución de Shor es un algoritmo cuántico para esto último [1, 2].

2.2.2 La transformada cuántica de Fourier

Se elige Q = 2^ℓ con N² ≤ Q < 2N². Un registro de ℓ cúbits se coloca en superposición uniforme y la aplicación x ↦ a^x mod N se calcula de forma reversible en un segundo registro,

La transformada cuántica de Fourier sobre ℤ_Q actúa sobre el primer registro como

y se implementa de forma exacta con O(ℓ²) puertas de uno y dos cúbits. Como el segundo registro es periódico en x con período r, una medición del primer registro tras la transformada devuelve, con probabilidad Ω(1/log log N), un valor y tal que

para algún entero s coprimo con r. Por el teorema de Legendre, s/r es entonces una reducida del desarrollo en fracción continua de y/Q, lo que proporciona r de forma clásica. La exponenciación modular domina el coste, con O(ℓ³) puertas para la aritmética escolar.

2.2.3 Logaritmos discretos y curvas elípticas

Sea ⟨P⟩ un grupo cíclico de orden primo q y sea Q′ = dP una clave pública. La función

es constante exactamente sobre las clases laterales del subgrupo L. Una transformada de Fourier de dos registros sobre ℤ_q² seguida de una medición proporciona (u, v) con v ≡ ud (mod q), de modo que d = v·u⁻¹ mod q siempre que u ≠ 0 [2]. Para el grupo de una curva elíptica, la ley de grupo se evalúa de forma reversible con aritmética sobre el cuerpo base [9]. Roetteler, Naehrig, Svore y Lauter presentan un circuito concreto para curvas sobre cuerpos primos de longitud en bits n [8] que utiliza

y un número de puertas Toffoli del orden de 10¹¹ para n = 256. La estimación se aplica a secp256k1 y P 256, que subyacen a la mayoría de los despliegues de ECDSA, y, con cambios despreciables, a la curva de 255 bits de Ed25519. Se trata de cúbits lógicos. La implementación tolerante a fallos multiplica el número físico por la sobrecarga del código corrector de errores.

2.2.4 Estimaciones de recursos para RSA 2048

Para RSA, Gidney y Ekerå estimaron en 2019 que un módulo de 2048 bits puede factorizarse en unas 8 horas con 20 millones de cúbits ruidosos, suponiendo una tasa de error de puerta física de 10⁻³, un tiempo de ciclo del código de superficie de un microsegundo y un tiempo de reacción del sistema de control de diez microsegundos [10]. Gidney revisó la estimación en 2025 a menos de un millón de cúbits ruidosos y menos de una semana de tiempo de ejecución bajo los mismos supuestos de hardware [11].

2.3 Consecuencias para firmas, libros contables y registros

La consecuencia probatoria es retroactiva. Sea una entrada e firmada en el instante t_c bajo pk, y sea t_q el primer instante en que el adversario puede ejecutar A_Shor. En cualquier instante T ≥ t_q, el adversario produce (e′, σ′) con Verify(pk, e′, σ′) = 1. Un verificador en T dispone de dos pares que verifican ambos, y la verificación de firmas no aporta información sobre cuál existía en t_c. El adversario solo necesita pk, que es pública y que, en los libros contables distribuidos, se publica con la primera transacción de la cuenta. Por tanto, las claves públicas y los registros firmados pueden recopilarse ahora y falsificarse después. Siendo x el período durante el cual la evidencia debe seguir siendo sólida, y el tiempo necesario para migrarla y z el tiempo hasta t_q, la condición de Mosca [13]

identifica cuándo queda expuesta la evidencia. Los períodos de conservación son largos. Los registros de los intermediarios financieros (broker dealers) sujetos a la Rule 17a 4 se conservan hasta seis años [37], y la documentación técnica de los sistemas de IA de alto riesgo, durante diez años después de la introducción del sistema en el mercado [35].

Las plataformas de contratos inteligentes en producción hoy autorizan las transacciones con ECDSA o EdDSA. En una plataforma así, la afirmación de que una cuenta autorizó una transacción solo está respaldada por una firma clásica, y después de t_q puede hacerse que cualquier cuenta cuya clave pública se conozca firme cualquier cosa. Que el orden de los bloques pasados siga siendo fiable depende de cómo conoce un verificador la historia canónica. Un participante que ha seguido la cadena de forma continua conserva su conocimiento. Cuando el propio consenso se autentica mediante firmas clásicas, un verificador que reconstruye la historia después de t_q únicamente a partir de firmas, como lo haría un tribunal o un auditor, no puede distinguir la historia canónica de una alternativa firmada con claves recuperadas. Cuando el orden está asegurado por prueba de trabajo, el orden conserva una seguridad basada en hashes, pero la autorización de cada transacción sigue siendo clásica. Es la capa de firmas la que se rompe.

Las funciones hash se debilitan, pero no se rompen. El algoritmo de Grover encuentra una preimagen de una función de n bits con O(2^n/2) evaluaciones [3], y esto es óptimo para la búsqueda genérica [4]. El algoritmo de Brassard, Høyer y Tapp encuentra colisiones con O(2^n/3) evaluaciones si se dispone de memoria accesible cuánticamente del mismo tamaño [5], de nuevo óptimo para funciones genéricas [6]. Bernstein muestra que, una vez contabilizado el coste de esa memoria, la búsqueda cuántica de colisiones no es más barata que la búsqueda clásica paralela de colisiones, en torno a 2^n/2 [7]. Para n = 256, los márgenes siguen siendo de al menos 2⁸⁵ en el modelo más favorable para el atacante y de unos 2¹²⁸ con un coste realista. Esta asimetría entre firmas y hashes es el fundamento del diseño de la Sección 5.

2.3.1 Primitivas clásicas en la infraestructura de agentes

La infraestructura mediante la cual se identifica, autoriza y audita hoy a los agentes descansa en un pequeño conjunto de primitivas de clave pública. La tabla indica, para cada una, el problema en el que se basa y el efecto del algoritmo de Shor.

Las primitivas simétricas se comportan de otro modo. HMAC y la familia SHA2 no se ven afectados por el algoritmo de Shor y solo los debilita el de Grover, de modo que HMAC con una clave de 256 bits conserva unos 128 bits de seguridad frente a la búsqueda de claves. Sin embargo, un código de autenticación de mensajes no demuestra nada a un tercero. Quien posee la clave puede volver a calcular una etiqueta válida para cualquier entrada alterada, y en un registro de auditoría quien posee la clave es el operador, por lo que la Observación 1 se aplica sin cambios. Lo mismo ocurre con una cadena de hashes llevada por el operador sin un anclaje externo, que el operador puede volver a calcular a partir de cualquier punto alterado.

2.4 La laguna normativa

En las distintas jurisdicciones, las normas exigen que determinados registros se generen, se conserven durante períodos definidos y se protejan frente a la alteración, o se lleven de modo que cualquier alteración sea detectable. El Reglamento europeo de inteligencia artificial (AI Act) exige que los sistemas de IA de alto riesgo permitan el registro automático de eventos a lo largo de su ciclo de vida (artículo 12), y exige a los proveedores y a los responsables del despliegue que conserven esos registros de eventos durante un período, adecuado a la finalidad prevista, de al menos seis meses (artículo 19 y artículo 26, apartado 6) [35]. La modificación eIDAS 2 otorga reconocimiento jurídico a los libros mayores electrónicos y atribuye a los libros mayores electrónicos cualificados una presunción de integridad y de orden cronológico (artículos 45 nonies y 45 decies) [36]. La SEC Rule 17a 4 exige a los intermediarios financieros (broker dealers) conservar los registros electrónicos con una pista de auditoría completa con sellado de tiempo o en un formato no reescribible y no borrable [37]. El artículo 5, apartado 1, letra f), del RGPD del Reino Unido exige una seguridad adecuada de los datos personales, incluida la protección frente al tratamiento no autorizado y frente a su pérdida o daño accidentales [38]. La Ley japonesa de conservación de libros electrónicos exige medidas que garanticen la autenticidad de los registros electrónicos, como sellos de tiempo o sistemas que registren correcciones y supresiones [39]. Las medidas de seguridad exigidas por el artículo 29 de la Ley coreana de protección de información personal incluyen la conservación de registros de acceso y su protección frente a la falsificación y la alteración [40]. El principio 4 de protección de datos de la Personal Data (Privacy) Ordinance de Hong Kong exige a los usuarios de datos adoptar todas las medidas viables para proteger los datos personales frente al acceso, el tratamiento, la supresión, la pérdida o el uso no autorizados o accidentales [41].

El mismo horizonte está regido ahora por mandatos de migración poscuántica. NIST IR 8547, en su borrador público inicial, propone que los algoritmos de clave pública vulnerables a la computación cuántica con un nivel de seguridad de 112 bits queden obsoletos después de 2030 y que todos los algoritmos de clave pública vulnerables a la computación cuántica queden prohibidos después de 2035 [27]. La Executive Order 14412 ordena a los sistemas federales de Estados Unidos adoptar el establecimiento de claves poscuántico a más tardar el 31 de diciembre de 2030 y las firmas digitales poscuánticas a más tardar el 31 de diciembre de 2031 [28]. Por tanto, los registros creados hoy se inspeccionarán dentro de sus períodos de conservación en un momento en que las firmas que los protegen estarán formalmente prohibidas.

Las leyes enuncian Ret de forma explícita mediante períodos de conservación y enuncian Int en términos como la protección frente a la alteración o la falsificación, el almacenamiento no reescribible o las pistas de auditoría. Ver y Time se derivan de la finalidad de la supervisión y de la prueba. La laguna consiste en que todo mecanismo cuya Int descansa en una firma clásica satisface Int solo para 𝒜 restringida a adversarios activos antes de t_q. Siempre que t₀ + R > t_q, el predicado falla durante el resto del período. Qstamp está diseñado para proporcionar Int, Ver y Time para todo t del período frente a adversarios clásicos y cuánticos, bajo los supuestos de la Sección 3. Ret sigue siendo obligación del custodio. Ninguna ley aquí citada exige Qstamp. Las leyes exigen propiedades, y la Sección 9 expone cuáles de ellas proporciona Qstamp.

3. Modelo del sistema y modelo de amenazas

3.1 Partes

• Operador O. Ejecuta uno o varios agentes, conserva sus registros y controla una clave de firma sk_S cuya clave pública ML DSA 65 determina la dirección en la cadena S. O ejecuta el SDK de Qstamp.
• Verificador V. Un tribunal, regulador, auditor, aseguradora o contraparte. V solo dispone de parámetros públicos, que son el hash de génesis G de la cadena, la dirección C del contrato oficial de Qstamp y el conjunto de validadores publicado, junto con lo que O presente.
• Red. La cadena de Quantova, formada por la QVM, un comité de validadores 𝒱 que finaliza los bloques, y puntos de acceso RPC y un explorador que sirven los datos de la cadena.
• Adversario A. Cualquier parte que pretenda que V acepte una afirmación falsa sobre un registro.

3.2 Supuestos

3.3 Clases de adversarios

Un adversario clásico es PPT. Un adversario cuántico es QPT, puede ejecutar los algoritmos de Shor y de Grover sin conexión y tiene acceso cuántico a H cuando se utiliza un modelo de oráculo aleatorio [16]. Ambas clases pueden corromper al operador después de un instante t*, lo que modela a un interno que posteriormente desea reescribir la historia o un compromiso posterior de sk_S. Ambas pueden controlar cualesquiera otras cuentas, corromper miembros del comité hasta la cota de T3, retrasar, reordenar o descartar mensajes de la red y operar puntos de acceso RPC propios. Se supone que el operador honesto sella correctamente antes de t*.

Tres cuestiones quedan fuera del modelo y se enuncian para que no se confundan con garantías. Un registro que era falso cuando se selló sigue siendo falso, ya que Qstamp fija el contenido y no lo juzga. Un adversario que posea sk_S antes de que se selle un registro puede sellar en nombre de S, lo cual es una cuestión de custodia de claves. La disponibilidad del registro y de su recibo es responsabilidad del custodio, ya que una sal perdida hace que la inclusión correspondiente no pueda demostrarse.

4. El marco de Quantova

Esta sección describe los componentes en los que se apoya Qstamp, tal como están en funcionamiento en la fecha de este artículo.

4.1 Quanta, el lenguaje de contratos inteligentes

Quanta es el lenguaje de contratos de la cadena de Quantova. Un contrato Quanta se compila en un contenedor de la QVM. La autoridad dentro de un contrato deriva únicamente de firmas verificadas. El invocante de un punto de entrada es el firmante verificado de la transacción, y un contrato puede verificar otras firmas ML DSA sobre órdenes firmadas mediante la instrucción VERIFY_ML de la QVM. Cada una de estas verificaciones utiliza la cadena de contexto de FIPS 204 QVM/contract/v1, que FIPS 204 vincula al mensaje firmado como

de modo que una firma producida para una orden de contrato no puede presentarse como firma en ningún otro contexto [24]. El contrato abierto de Qstamp es el siguiente código fuente Quanta, que no mantiene estado, ni fondos, ni propietario.

Las plantillas de emisor y de consejo añaden órdenes firmadas que llevan un nonce mantenido por el contrato, un plazo límite y un valor de dominio propio de cada despliegue, de modo que una orden no puede reproducirse, utilizarse fuera de plazo ni utilizarse en otro despliegue.

4.2 El compilador atestado

Un contenedor c se identifica mediante id(c) = H(c). La cadena solo admite un despliegue si el identificador lleva una firma ML DSA 65 de la clave de procedencia del compilador,

La firma establece que el contenedor desplegado fue producido por el compilador atestado. La igualdad con el código fuente revisado se establece después por reproducción. Un revisor compila el código fuente publicado, compara byte a byte el contenedor resultante con el desplegado y confirma así que el código en C es el código que se revisó. El código fuente publicado del contrato abierto de Qstamp se compila byte a byte en el contrato desplegado en la red de pruebas. La garantía presupone la custodia segura de la clave de procedencia por parte de Quantova Inc. Únicamente para la propiedad de identidad del código, este es un supuesto de confianza adicional a T1 a T5.

4.3 La Quantova Virtual Machine y la capa de ejecución

La QVM es una máquina de registros con medición de consumo e instrucciones nativas para la verificación ML DSA y SLH DSA [25], el hashing y los árboles de hashes. Antes de la ejecución, la QVM escribe el remitente verificado de la transacción en la memoria del contrato como caller, de modo que el firmante registrado no puede verse influido por los datos de la llamada. La ejecución es atómica. Siendo S el estado, tx una transacción y m su límite de medición,

donde E es la lista de eventos emitidos. Los eventos y los cambios de estado solo se registran en caso de éxito, y los eventos se comprometen en la raíz de eventos de la cabecera del bloque. Por tanto, una transacción finalizada sin su evento no demuestra nada sobre un sellado, y la verificación de la Sección 5 requiere el evento.

4.4 Consenso y firmeza

Cada cuenta, cada transacción y cada certificado de firmeza de la cadena de Quantova se han firmado con ML DSA 65 desde el bloque génesis, con SLH DSA disponible como esquema alternativo de cuenta descrito anteriormente. Una dirección es un valor de 32 bytes derivado de una clave pública ML DSA 65. Los bloques los finaliza un comité muestreado cuyo certificado lleva firmas ML DSA 65 que alcanzan el umbral de firmeza, y la firmeza se alcanza en unos 0,2 segundos. La hora del bloque se propone en segundos enteros. Bajo T4, un bloque aceptado B con padre P satisface

de modo que la hora del bloque nunca disminuye y no puede adelantarse más de 15 segundos a los relojes honestos.

4.5 Tarifas

La ejecución se mide, y la tarifa de una llamada que consume m unidades de medición es

con reembolso de la reserva no utilizada. La llamada de sellado tiene datos de llamada de longitud fija y emite un único evento de longitud fija, por lo que su tarifa no depende del tamaño del lote N. En la red de pruebas, un sellado cuesta 0,005 TQTOV, es decir, 5000 quon, con independencia de N. Los TQTOV son unidades de la red de pruebas sin valor monetario.

5. La construcción de Qstamp

5.1 Notación

5.2 Hojas, árbol y compromiso

Para el registro r_i con resumen d_i = D_alg(r_i), la hoja es

una evaluación de H sobre exactamente 1 + 14 + 1 + 32 + 32 = 80 bytes. Las hojas forman el árbol de la Sección 2.1 de RFC 9162 [31], cuyos nodos interiores son

una evaluación de H sobre exactamente 65 bytes.

El compromiso es

una evaluación de H sobre exactamente 1 + 14 + 32 + 32 + 32 + 8 + 8 + 32 = 159 bytes. Las tres funciones se separan por su primer byte y por sus longitudes, propiedad que se utiliza en el Lema 1. La construcción sigue el árbol de hashes de Merkle [18] y la idea de encadenamiento de Haber y Stornetta [19], con la separación de dominio de RFC 9162 y una vinculación explícita del tamaño y del contexto.

5.3 Anclaje

K se divide en dos mitades de 16 bytes (hi, lo) y se envía desde S en una llamada al contrato oficial C,

Los datos de la llamada tienen longitud fija y constan del selector de 4 bytes, 120 bytes de contexto del host, el compromiso de 32 bytes y el tipo de 8 bytes. Los datos del evento tienen 72 bytes. Como el contrato no mantiene estado, pueden coexistir cualquier número de sellados de cualquier compromiso, y ningún sellado puede impedir que otro se registre.

5.4 Recibo

Cada registro recibe su propio recibo, la tupla

con fmt = qstamp-receipt/1, el nombre de la cadena id y el génesis G, el contrato C, el tipo k como cadena decimal, el algoritmo de resumen, el resumen y la sal, la posición, el tamaño del lote y la ruta de inclusión, la raíz del árbol, y la transacción de anclaje, la altura del bloque h, el identificador del bloque B, la hora del bloque t en segundos desde 1970 y el firmante S. Un recibo no contiene ninguna parte del registro. Sí contiene el resumen y la sal, lo cual es relevante para la Sección 6.5.

5.5 Algoritmos

La verificación devuelve uno de tres resultados. Válido significa que todas las comprobaciones se superaron. Inválido significa que al menos una comprobación sustantiva falló, incluido el caso en que no se aportó ningún registro ni resumen. Indeterminado significa que toda comprobación fallida fue un fallo de transporte, como un punto de acceso inalcanzable o una lista de eventos truncada. Indeterminado nunca se notifica como válido. Las comprobaciones se denominan formato, contrato, contenido, inclusión, cadena, transacción, evento y bloque, ocho en total.

$ npm install @quantovainc/qstamp
added 2 packages

$ npx @quantovainc/qstamp --version
0.1.4

$ openssl rand -hex 32 > signer.key && chmod 600 signer.key
$ node account.js
address  Q1NUR6ETECQXEVE77TJ9YPZ6WAWYMT45WCJANV5J43X93SF79DWE0S0D572X
status   registered, ready to stamp

{
  "evaluation": {"approved_by": "Model Risk Committee", "auc": 0.871},
  "model": "risk-model 3.2.1",
  "time": "2026-10-09T09:39:27.273Z",
  "training_data": "dataset manifest 2026-09-30",
  "weights_sha3": "f01483b8e6269760c5c2e2025875b6e5d1b16402443e9a98d73e0a43156bf17b"
}

const qstamp = require('@quantovainc/qstamp');
const batch = [];

agent.on('action', (action) => {
  const bytes = Buffer.from(canonicalJson(action));
  log.write(bytes);
  batch.push({ digest: qstamp.digestBytes(bytes) });
});

setInterval(async () => {
  const records = batch.splice(0);
  if (records.length === 0) return;
  const receipts = await qstamp.stamp({
    seed, index: 0, kind: 'ai_agent_action', records,
    onPending: savePending,
  });
  receipts.forEach(storeBesideAction);
}, 60000);

{
  "agent": "credit-decision-agent-07",
  "amount_usd": 125000,
  "applicant": "APP-54a49c823275",
  "decision": "approve",
  "human_review": false,
  "model": "risk-model 3.2.1",
  "operator": "Example Bank plc",
  "policy": "retail-lending-policy 2026-10",
  "reasons": ["score_above_threshold"],
  "risk_score": 645,
  "time": "2026-10-09T09:39:25.132Z",
  "tool": "credit_bureau.lookup"
}

$ npx @quantovainc/qstamp hash action-04.json
  action-04.json

$ npx @quantovainc/qstamp verify action-04.json.qstamp.json --file action-04.json
pass format · pass contract · pass content · pass inclusion
pass chain · pass transaction · pass event · pass block
VALID  stamped no later than 2026-10-09T09:39:25Z in block 2011753

$ npx @quantovainc/qstamp verify action-04.json.qstamp.json --file altered.json
FAIL content  the content does not match the fingerprint in the receipt
INVALID

6. Análisis de seguridad

6.1 El juego de falsificación de evidencia

El juego recoge al interno que reescribe la historia a posteriori, ya que A obtiene sk_S y aun así debe vincular r′ a un anclaje anterior a t*. Recoge al externo que sustituye el contenido, y al tercero que intenta incriminar a S con un registro que S nunca selló. Un sellado nuevo de r′ después de t* no es una falsificación, ya que su recibo indica una hora posterior.

6.2 Separación de dominio

Sin los prefijos de función, un nodo interior podría presentarse como hoja, la clásica ambigüedad de segunda preimagen de los árboles de Merkle sin prefijos que RFC 9162 elimina [31]. Sin u64(N), una raíz no determinaría la forma de su árbol, y una misma ruta podría verificarse bajo varios tamaños.

6.3 Teorema principal

Esbozo de demostración. Supóngase que A gana con salida (r′, ρ′), donde ρ′ indica alg′, d′, s′, la posición i, el tamaño N′, la ruta π′, root′, el tipo k′, la transacción tx, la altura h, la hora t ≤ t* y el firmante S. La validez de las ocho comprobaciones proporciona los hechos siguientes. G y C son los valores oficiales. D(r′) = d′. RootFromPath(L′, i, N′, π′) = root′ con L′ la hoja de (alg′, d′, s′). Bajo T5, el bloque finalizado a la altura h contiene tx de S a C y un evento de C con datos S ‖ K′ ‖ u64(k′), donde K′ = Commit(G, C, S, k′, N′, root′). Particionamos el suceso ganador.

1. Fallo de consenso. El bloque comunicado a la altura h no es el único bloque finalizado a esa altura. Esto contradice T3 salvo con probabilidad Adv_consensus, una vez excluidas las firmas del comité falsificadas, que corresponden al caso siguiente.
2. Falsificación de firma. El bloque canónico a la altura h lleva una transacción de S que el retador no firmó antes de t*, o una firma del comité que ningún miembro honesto produjo. Antes de t*, los sellados honestos son exactamente las consultas de firma, por lo que B₃ adivina cuál de las q claves se falsifica, inserta allí su clave de desafío y produce la falsificación. Esto cuesta a lo sumo q · Adv^EUF-CMA.
3. Anclaje honesto. En otro caso, el evento fue emitido por un sellado honesto con lote (r₀, …, r_N−1), sales s_i, tipo k y compromiso K, ya que toda transacción de S anterior a t* es honesta y los datos del evento indican S. La correspondencia de eventos da K′ = K y k′ = k. Por el Lema 1, o bien (N′, root′) = (N, root), o bien B₁ o B₂ produce una colisión de dos cadenas de 159 bytes.
4. Mismo árbol. Con igual tamaño y raíz, el Algoritmo 3 vuelve a calcular root a partir de L′ a lo largo de una ruta cuya forma depende únicamente de (i, N). Se recorre desde la raíz hacia la hoja. En el primer nivel en que las entradas del nodo honesto y del presentado difieren, ambas entradas producen el mismo hash, lo que por el Lema 1 es una colisión de dos cadenas de 65 bytes. Si ningún nivel difiere, entonces L′ = L_i.
5. Misma hoja. Por el Lema 1, o bien (alg′, d′, s′) = (alg, d_i, s_i), o bien las dos entradas de 80 bytes colisionan.
6. Mismo resumen. Entonces D(r′) = d_i = D(r_i) con r′ ≠ r_i, ya que A gana, lo que constituye una colisión de D = SHA3 256.

Queda por atribuir cada colisión encontrada en los casos 3 a 6 a B₁ o a B₂. Si la entrada honesta del par en colisión es función de valores elegidos únicamente por A, como cuando A eligió el lote y la entrada en colisión no contiene ninguna sal nueva, el par es una colisión y lo produce B₁. Si la entrada honesta contiene un valor no elegido por A, a saber, una sal s_i o un registro aportado por una parte honesta, entonces la entrada honesta es un objetivo fijado antes de que A busque, y A ha encontrado una segunda entrada con la misma imagen. Esto es una segunda preimagen en el sentido de Rogaway y Shrimpton para objetivos extraídos de la distribución honesta [17], y la produce B₂. Ambas atribuciones son disjuntas, por lo que una cota de la unión sobre los casos 1 a 6 da (22). ∎

Para alg = 2, el paso de resumen del caso 6 se basa en SHA 256 y la cota incorpora los términos correspondientes de SHA 256. La vinculación solo requiere T1 a T3 en el modelo estándar. La ocultación de la Sección 6.5 utiliza el modelo de oráculo aleatorio [15, 16].

6.4 Vinculación del contexto, reproducción y adelantamiento

Esto se deriva del Lema 1 y tiene cinco consecuencias. Un compromiso anclado en una cadena no se verifica frente a otra, porque G difiere, y una red relanzada con un génesis nuevo no puede verificar recibos antiguos. Un recibo no se verifica frente a un contrato distinto, porque C difiere. Un adelantador F que copia K de una transacción pendiente y envía stamp(K, k) desde su propia cuenta obtiene un evento que indica F, y un recibo que indica F solo se verifica si K = Commit(G, C, F, k, N, root), una colisión. Como el contrato abierto no tiene estado, la copia no impide que se registre la transacción original de S, de modo que el adelantamiento ni sustrae ni bloquea un sellado. El tipo declarado no puede reetiquetarse después del anclaje. El tamaño del lote es fijo, lo que elimina la ambigüedad de tamaño de las raíces RFC 9162 sin más.

6.5 Ocultación

La salvedad es esencial. El titular de un recibo conoce s_i y d_i. Como d_i = D(r_i) no lleva sal, el titular de un recibo puede comprobar una conjetura sobre un registro de baja entropía, como un importe o un código corto, con una sola evaluación de hash. Por tanto, los recibos deben protegerse como los registros que describen. La ocultación protege el contenido frente a los observadores de la cadena, no frente a los titulares de recibos.

6.6 Cotas concretas

La categoría 3 del NIST significa que romper el esquema requiere recursos comparables o superiores a los de una búsqueda de claves en un cifrado por bloques con una clave de 192 bits [24]. FIPS 202 establece para SHA3 256, frente a ataques clásicos, una resistencia a colisiones de 128 bits y una resistencia a preimágenes y a segundas preimágenes de 256 bits [22].

6.7 Vivacidad, indeterminación y el punto de acceso de confianza

Vivacidad del sellado. Un sellado se completa cuando el comité finaliza su transacción. Si no se observa la firmeza dentro del tiempo de espera, el Algoritmo 1 devuelve el lote pendiente conservado, que contiene las sales, el compromiso y el identificador de la transacción. Los recibos se completan más tarde a partir de ese lote sin un segundo pago. Un error producido mientras se enviaba la transacción también lleva consigo el lote pendiente, de modo que las sales nunca se pierden por un fallo de la red.

El punto de acceso de confianza de la versión 0.1. Las comprobaciones 1 a 4 se ejecutan en el equipo del verificador y no dependen de ninguna parte externa. Las comprobaciones de cadena, transacción, evento y bloque las responden puntos de acceso RPC, por lo que se requiere T5. Un punto de acceso operado de forma deshonesta podría comunicar un anclaje inexistente. La versión 0.1 mitiga este riesgo utilizando por defecto el punto de acceso oficial, comprobando que cada punto de acceso sirve la cadena indicada en el recibo, exigiendo que todos los puntos de acceso consultados coincidan e informando de qué puntos de acceso se consultaron. Sin T5, (22) incorpora un término Adv_endpoint igual a la probabilidad de que todos los puntos de acceso consultados mientan de forma coherente. T5 abarca también el canal hacia cada punto de acceso. Las respuestas viajan sobre TLS, que es seguridad de transporte ajena al protocolo de Quantova y puede utilizar intercambio de claves y certificados clásicos, por lo que un adversario capaz de suplantar un punto de acceso en la capa de transporte se contabiliza en el mismo término.

Pruebas de firmeza sin conexión previstas. Una versión próxima incluirá en cada recibo la cabecera del bloque de altura h, el certificado de firmeza del comité y una prueba de inclusión del evento Stamped respecto de la raíz de eventos de la cabecera. La verificación necesitará entonces únicamente el recibo, el registro y el conjunto de validadores publicado. El término del punto de acceso desaparece y las comprobaciones de la cadena se reducen a la verificación ML DSA 65 bajo T2 y T3, de modo que (22) se cumple sin T5.

7. Aplicación a agentes autónomos y agentes de superinteligencia

7.1 Registros canónicos de acciones

Una acción a de un agente solo constituye evidencia a través de una codificación en bytes canon(a), y el resumen es d = D(canon(a)). La codificación debe ser fijada y versionada por el operador, ya que dos serializaciones del mismo contenido dan resúmenes distintos. Un cambio de serialización produce un falso veredicto de inválido, nunca uno falso de válido. Una forma JSON canónica con claves ordenadas lexicográficamente y sin espacios en blanco no significativos, como el esquema de RFC 8785 [32], satisface esta necesidad. El SDK aplica el hash exactamente a los bytes que recibe y no impone una serialización. Un registro de acción útil indica el agente, el operador, el modelo y su versión, la política vigente, la herramienta invocada, las entradas en las que se basó, la decisión o el resultado, si un ser humano lo revisó y la hora declarada por el agente.

7.2 Agrupación en lotes

Un operador reúne acciones durante una ventana Δ, o hasta un número determinado, y las sella como un único lote. Una acción realizada en el instante τ tiene entonces un anclaje cuyo bloque se finalizó a más tardar en τ + Δ + t_fin, donde t_fin es la latencia del sellado. El coste por acción es fee / N. Las acciones relevantes, como los pagos por encima de un umbral, pueden sellarse individualmente antes o después de su ejecución, de modo que el registro sea firme antes de que la acción concluya. El hook onPending permite al operador conservar cada lote enviado antes de esperar a la firmeza.

7.3 Tipos de registro

El tipo es un valor de 64 bits vinculado en K y emitido en el evento. Indica lo que S declaró que contenía el lote. No es una clasificación verificada del contenido.

7.4 Pasaportes de modelos

Un pasaporte de modelo es un patrón de uso, no un mecanismo independiente. En el momento de la publicación, el operador sella, con el tipo ai_model, un registro que enumera los resúmenes de los artefactos del modelo, el resumen del manifiesto del conjunto de datos sellado con el tipo ai_dataset y los resúmenes de los informes de evaluación. Cada registro de acción posterior indica la versión del modelo y el resumen de su pasaporte, de modo que el recibo de una acción conduce al recibo que fijó el modelo del que dependía la acción.

7.5 Qué demuestra un recibo y qué no demuestra

8. Procedimiento probatorio ante una orden judicial

Supóngase que un tribunal o un regulador ordena a una empresa SI que muestre lo que hizo su agente en un asunto determinado. El procedimiento siguiente no exige de la empresa nada más que la aportación de documentos, ni del verificador nada más que parámetros públicos y cálculo.

1. Aportación. La empresa aporta el registro r y su recibo ρ. La orden también puede exigir la regla de canonicalización utilizada para los registros de ese tipo.
2. Nuevo cálculo. El verificador vuelve a calcular d = H(r), la hoja L a partir de (alg, d, s), la raíz a partir de (L, i, N, π) con el Algoritmo 3, y K a partir de (G, C, S, k, N, root). Este paso no requiere acceso a la red y puede realizarse con el SDK, con la orden qstamp verify o con una implementación independiente de la Sección 5.
3. Anclaje. Utilizando la cadena pública, a través de uno o varios puntos de acceso RPC independientes y en el explorador, el verificador comprueba que la transacción indicada en ρ fue enviada por S al contrato oficial C y que el bloque h contiene el evento Stamped de C con los datos S ‖ K ‖ u64(k). El explorador es una vista de los datos de la cadena que permite a un lector sin conocimientos técnicos confirmar los mismos hechos. No es un ancla de confianza independiente.
4. Firmeza. El verificador comprueba que la transacción es firme y que el bloque a la altura h tiene el identificador B y la hora t.
5. Resultado. Si se superan todas las comprobaciones, el resultado es válido, y la Proposición 5 enuncia lo que ha quedado establecido. Si falla una comprobación sustantiva, el resultado es inválido, y la comprobación fallida identifica qué eslabón no se sostiene. Si no se pudo consultar la red, el resultado es indeterminado y el procedimiento se repite.

8.1 Ejemplo práctico de la red de pruebas de Quantova

Un agente de decisiones crediticias produjo el siguiente registro, serializado como JSON canónico con claves ordenadas y sin espacios en blanco no significativos.

El registro se selló en un lote de seis registros. Los valores siguientes se han tomado de esa ejecución.

La transacción de anclaje puede consultarse en https://qvmscan.io/tx/QTX1V53JW528S64SZYD6EDZ563N0PUUA2ARGNQHV4LTJMNH24PQS5VPQTAH8RQ.

La verificación del recibo frente al registro dio como resultado válido, con las ocho comprobaciones superadas.

A continuación, el importe del registro se modificó en 1000 y la verificación se repitió con el mismo recibo. La comprobación de contenido falló y el resultado fue inválido. Las demás comprobaciones no se ven afectadas por el cambio, que es el comportamiento previsto, ya que el veredicto indica el eslabón exacto que se rompió. A título ilustrativo, sustituir 125000 por 126000 da el resumen

Dos aspectos del ejemplo merecen comentario. En primer lugar, el campo de hora dentro del registro, 09:39:25.132, es una afirmación del agente y no está certificado. La hora del bloque es un segundo entero, 09:39:25, y coincide con el registro a esa resolución. En segundo lugar, el tiempo medido desde el envío hasta la firmeza observada fue de unos 0,7 segundos, lo que incluye el intervalo de sondeo del SDK.

9. Correspondencia normativa

La tabla relaciona cada obligación con la propiedad formal que proporciona Qstamp y con los límites de dicha propiedad. Las paráfrasis son resúmenes orientativos y no sustituyen a los textos legales [35, 36, 37, 38, 39, 40, 41, 27]. Ninguna ley citada exige Qstamp. Cada una exige propiedades de los registros, y Qstamp proporciona algunas de ellas.

Cada organización sigue siendo responsable de cumplir íntegramente los requisitos de las leyes que le sean aplicables y debe obtener su propio asesoramiento jurídico.

10. Qué distingue a esta construcción

Sostenemos que una evidencia duradera para agentes requiere cuatro propiedades conjuntamente, y que una cadena clásica no puede adquirir la primera de ellas para su historia existente únicamente mediante una migración.

1. R1. Autenticación poscuántica de toda la historia. Toda firma de la que depende un anclaje, desde la cuenta que lo envía hasta la firmeza, es poscuántica, hasta el génesis, y el protocolo no acepta ninguna firma clásica que pudiera establecer un hecho en competencia.
2. R2. Testigo independiente. El anclaje lo fija un comité independiente del custodio, no el custodio ni una única autoridad.
3. R3. Código atestado. El código que registra un anclaje es, de forma demostrable, el código revisado, y no puede sustituirse en la misma dirección.
4. R4. Autoridad programable. Las políticas institucionales, como los emisores autorizados, la aprobación multipartita y la revocación, se ejecutan bajo autenticación poscuántica.

La condición de la Proposición 6 describe un remedio real, que debe exponerse con equidad. La evidencia puede preservarse mediante renovación, en la que la evidencia antigua se compromete bajo primitivas más robustas antes de que fallen las antiguas, como en la renovación de Haber y Stornetta [19] y en la Evidence Record Syntax de RFC 4998 [34]. La renovación debe producirse antes de t_q, debe ser a su vez verificable y solo protege lo que se renovó. Una red que es poscuántica desde el génesis no tiene nada que renovar respecto de su propia historia. Es en este sentido en el que la adaptación a posteriori de una cadena clásica deja su historia anterior expuesta a la falsificación, salvo que se renueve a tiempo.

Una autoridad de sellado de tiempo poscuántica satisface R1, pero descansa en una única autoridad y no ofrece ninguna política programable. Un libro contable sin código atestado satisface R2 y R4, pero un verificador debe auditar de forma independiente el bytecode en la dirección del contrato. La tabla resume los despliegues habituales de cada categoría en 2026. Describe categorías, no productos concretos.

Hasta donde sabemos, en la fecha de este artículo pocas redes en producción combinaban R1 a R4 desde el génesis. No afirmamos que la combinación sea exclusiva de Quantova, y el argumento de esta sección depende únicamente de las propiedades, no de la identidad de ninguna red.

11. Economía y rendimiento

Por (15), la tarifa de un sellado depende únicamente de la medición consumida por la llamada de longitud fija, por lo que un sellado cuesta 0,005 TQTOV, 5000 quon, en la red de pruebas para cualquier N. El coste amortizado por registro es

En la cadena, cada sellado añade 164 bytes de datos de llamada y un evento de 72 bytes, con independencia de N. La verificación local cuesta un resumen del registro y como máximo ⌈log₂N⌉ + 2 evaluaciones adicionales de SHA3 256 sobre entradas de longitud fija. La verificación en la cadena cuesta cuatro consultas por punto de acceso, para la identidad de la cadena, la transacción, los eventos y el bloque.

En la ejecución en la red de pruebas que produjo el ejemplo de la Sección 8, el tiempo desde el envío de un sellado hasta la firmeza observada fue de unos 0,7 segundos, frente a una firmeza de la cadena de unos 0,2 segundos. La diferencia es atribuible al envío y al intervalo de sondeo de 400 milisegundos con el que el SDK observa la firmeza. Cuatro sellados costaron 0,02 TQTOV en total, es decir, 0,005 TQTOV cada uno. Estas cifras son mediciones en la red de pruebas y no constituyen garantías del rendimiento ni del precio en la red principal.

12. Limitaciones y trabajo futuro

1. Pruebas de firmeza sin conexión. La versión 0.1 confirma los hechos de la cadena a través de puntos de acceso RPC y, por tanto, depende de T5. Está prevista la inclusión en cada recibo de la cabecera del bloque, el certificado de firmeza y la prueba de inclusión del evento, tal como se describe en la Sección 6.7, lo que eliminará esa dependencia.
2. Dominio por despliegue en las plantillas. Las plantillas de emisor y de consejo rechazan las órdenes cuyo valor de dominio difiere del del despliegue. El valor es un número de 64 bits elegido por quien realiza el despliegue, y su novedad es una obligación operativa. La dirección de un contrato depende únicamente de la cuenta que lo despliega y de su número de transacciones, por lo que, tras un relanzamiento o en una bifurcación, un nuevo despliegue puede recibir la dirección de uno anterior, y solo un valor de dominio nuevo impide entonces que se acepten órdenes firmadas para el despliegue anterior.
3. El SDK aún no comprueba la revocación. La plantilla de emisor registra la retirada de un compromiso con un código de motivo, pero Verify no consulta ese estado. Un recibo de un compromiso retirado sigue verificándose como válido, y un verificador que se base en las retiradas debe consultar por separado el contrato del emisor.
4. Auditoría por terceros. El SDK y los contratos se revisaron internamente antes de su publicación. Las plantillas de contratos se publican como ejemplos, y se requiere una auditoría independiente realizada por un tercero cualificado antes de cualquier despliegue de las mismas en producción, que también se recomienda antes de confiar en el SDK en producción.
5. Resolución temporal. La hora del bloque tiene una resolución de un segundo, está acotada superiormente por T4 e inferiormente solo por la hora del bloque padre. Los recibos establecen la existencia a más tardar en el momento de la firmeza, no un momento más temprano.
6. Completitud. Un recibo demuestra la inclusión, no la completitud. La numeración consecutiva y el encadenamiento de lotes, tal como se sugiere en la Sección 7.5, son prácticas del operador y el contrato no las impone.
7. Estado de la red. Todos los resultados de este artículo se refieren a la red de pruebas. Los recibos producidos en ella carecen de valor probatorio, y el uso en producción tendrá lugar en la red principal de Quantova una vez que entre en funcionamiento.

13. Estatus jurídico de este artículo

El presente artículo constituye una especificación técnica y una descripción de Qstamp facilitadas por Quantova Inc con fines informativos. Por sí mismo no genera obligación contractual, garantía, declaración ni compromiso alguno, y no constituye asesoramiento jurídico, regulatorio, fiscal ni de inversión. El uso de Qstamp, del SDK de Qstamp y de las plantillas de contratos Quanta se rige por las Condiciones de Uso, por las licencias con arreglo a las cuales se publica el software y por cualquier acuerdo suscrito con Quantova Inc, que prevalecerán sobre el presente artículo en caso de conflicto. Las afirmaciones sobre leyes y reglamentos son resúmenes orientativos. Las afirmaciones sobre funcionalidades futuras describen intenciones actuales y pueden cambiar.

Letra pequeña. Toda afirmación del presente artículo según la cual Quantova o Qstamp es poscuántico, o no depende de firmas clásicas, se refiere al protocolo de Quantova, es decir, a las firmas de cuentas, transacciones y certificados de firmeza, a la atestación del código de los contratos y al consenso. No se extiende a la seguridad de transporte ajena al protocolo, como las conexiones TLS, los certificados y el intercambio de claves utilizados por los sitios web, el explorador, las pasarelas RPC y otros servicios de alojamiento web, que pueden utilizar algoritmos clásicos. En la versión 0.1, las comprobaciones de la cadena en la verificación dependen de la integridad de las respuestas recibidas de los puntos de acceso RPC, que están protegidas en tránsito por dicha seguridad de transporte (supuesto T5 y Sección 6.7). Mientras los recibos no incluyan pruebas de firmeza sin conexión, el verificador que requiera garantías poscuánticas para dichas comprobaciones deberá obtener los datos de la cadena a través de un canal de su confianza o de varios puntos de acceso operados de forma independiente.

© 2026 Quantova Inc. Qstamp y Quantova son marcas de Quantova Inc.

14. Referencias

1. [1]P. W. Shor. Algorithms for quantum computation: discrete logarithms and factoring. In Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), IEEE, 1994, pp. 124 to 134.
2. [2]P. W. Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM Journal on Computing 26(5), 1997, pp. 1484 to 1509.
3. [3]L. K. Grover. A fast quantum mechanical algorithm for database search. In Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC), 1996, pp. 212 to 219.
4. [4]C. H. Bennett, E. Bernstein, G. Brassard and U. Vazirani. Strengths and weaknesses of quantum computing. SIAM Journal on Computing 26(5), 1997, pp. 1510 to 1523.
5. [5]G. Brassard, P. Høyer and A. Tapp. Quantum cryptanalysis of hash and claw-free functions. In LATIN '98: Theoretical Informatics, Lecture Notes in Computer Science 1380, Springer, 1998, pp. 163 to 169.
6. [6]S. Aaronson and Y. Shi. Quantum lower bounds for the collision and the element distinctness problems. Journal of the ACM 51(4), 2004, pp. 595 to 605.
7. [7]D. J. Bernstein. Cost analysis of hash collisions. Will quantum computers make SHARCS obsolete? In Workshop Record of SHARCS 2009, Special-purpose Hardware for Attacking Cryptographic Systems, 2009.
8. [8]M. Roetteler, M. Naehrig, K. M. Svore and K. Lauter. Quantum resource estimates for computing elliptic curve discrete logarithms. In Advances in Cryptology, ASIACRYPT 2017, Lecture Notes in Computer Science 10625, Springer, 2017, pp. 241 to 270.
9. [9]J. Proos and C. Zalka. Shor's discrete logarithm quantum algorithm for elliptic curves. Quantum Information and Computation 3(4), 2003, pp. 317 to 344.
10. [10]C. Gidney and M. Ekerå. How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits. Quantum 5, 433, 2021. First circulated as arXiv:1905.09749, 2019.
11. [11]C. Gidney. How to factor 2048 bit RSA integers with less than a million noisy qubits. arXiv:2505.15917, 2025.
12. [12]M. A. Nielsen and I. L. Chuang. Quantum Computation and Quantum Information. Cambridge University Press, 2000.
13. [13]M. Mosca. Cybersecurity in an era with quantum computers. Will we be ready? IEEE Security and Privacy 16(5), 2018, pp. 38 to 41.
14. [14]S. Goldwasser, S. Micali and R. L. Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing 17(2), 1988, pp. 281 to 308.
15. [15]M. Bellare and P. Rogaway. Random oracles are practical. A paradigm for designing efficient protocols. In Proceedings of the 1st ACM Conference on Computer and Communications Security (CCS), 1993, pp. 62 to 73.
16. [16]D. Boneh, Ö. Dagdelen, M. Fischlin, A. Lehmann, C. Schaffner and M. Zhandry. Random oracles in a quantum world. In Advances in Cryptology, ASIACRYPT 2011, Lecture Notes in Computer Science 7073, Springer, 2011, pp. 41 to 69.
17. [17]P. Rogaway and T. Shrimpton. Cryptographic hash-function basics. Definitions, implications, and separations for preimage resistance, second-preimage resistance, and collision resistance. In Fast Software Encryption, FSE 2004, Lecture Notes in Computer Science 3017, Springer, 2004, pp. 371 to 388.
18. [18]R. C. Merkle. A digital signature based on a conventional encryption function. In Advances in Cryptology, CRYPTO '87, Lecture Notes in Computer Science 293, Springer, 1988, pp. 369 to 378.
19. [19]S. Haber and W. S. Stornetta. How to time-stamp a digital document. Journal of Cryptology 3(2), 1991, pp. 99 to 111.
20. [20]L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler and D. Stehlé. CRYSTALS-Dilithium. A lattice-based digital signature scheme. IACR Transactions on Cryptographic Hardware and Embedded Systems 2018(1), pp. 238 to 268.
21. [21]E. Kiltz, V. Lyubashevsky and C. Schaffner. A concrete treatment of Fiat-Shamir signatures in the quantum random-oracle model. In Advances in Cryptology, EUROCRYPT 2018, Lecture Notes in Computer Science 10822, Springer, 2018.
22. [22]National Institute of Standards and Technology. SHA-3 Standard. Permutation-Based Hash and Extendable-Output Functions. FIPS PUB 202, August 2015.
23. [23]National Institute of Standards and Technology. Secure Hash Standard (SHS). FIPS PUB 180-4, August 2015.
24. [24]National Institute of Standards and Technology. Module-Lattice-Based Digital Signature Standard. FIPS 204, August 2024.
25. [25]National Institute of Standards and Technology. Stateless Hash-Based Digital Signature Standard. FIPS 205, August 2024.
26. [26]National Institute of Standards and Technology. Digital Signature Standard (DSS). FIPS 186-5, February 2023.
27. [27]D. Moody, R. Perlner, A. Regenscheid, A. Robinson and D. Cooper. Transition to Post-Quantum Cryptography Standards. NIST Internal Report 8547, Initial Public Draft, National Institute of Standards and Technology, November 2024.
28. [28]Executive Order 14412. Securing the Nation Against Advanced Cryptographic Attacks. The White House, Washington, signed 22 June 2026.
29. [29]Certicom Research. SEC 2. Recommended Elliptic Curve Domain Parameters. Standards for Efficient Cryptography, Version 2.0, 2010.
30. [30]S. Josefsson and I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032, Internet Engineering Task Force, January 2017.
31. [31]B. Laurie, E. Messeri and R. Stradling. Certificate Transparency Version 2.0. RFC 9162, Internet Engineering Task Force, December 2021.
32. [32]A. Rundgren, B. Jordan and S. Erdtman. JSON Canonicalization Scheme (JCS). RFC 8785, Internet Engineering Task Force, June 2020.
33. [33]C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161, Internet Engineering Task Force, August 2001.
34. [34]T. Gondrom, R. Brandner and U. Pordesch. Evidence Record Syntax (ERS). RFC 4998, Internet Engineering Task Force, August 2007.
35. [35]Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L series, 12 July 2024.
36. [36]Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Official Journal of the European Union, L series, 30 April 2024.
37. [37]United States Securities and Exchange Commission. Rule 17a-4, Records to be preserved by certain exchange members, brokers and dealers. 17 CFR 240.17a-4.
38. [38]Regulation (EU) 2016/679 as it forms part of the law of the United Kingdom (UK GDPR), Article 5(1)(f).
39. [39]Japan. Act on Special Provisions concerning Preservation Methods for Books and Documents Related to National Tax Prepared by Means of Computers (Act No. 25 of 1998), and its Enforcement Regulation.
40. [40]Republic of Korea. Personal Information Protection Act, Article 29, and the standards on safety measures for personal information issued under it by the Personal Information Protection Commission.
41. [41]Hong Kong Special Administrative Region. Personal Data (Privacy) Ordinance (Cap. 486), Schedule 1, Data Protection Principle 4.