Qstamp / Matemáticas
Construcción formal

Las matemáticas que respaldan cada recibo.

Esta página especifica con precisión la construcción de Qstamp, expone la seguridad que alcanza frente a adversarios clásicos y cuánticos, y explica por qué los contratos inteligentes Quanta ejecutados en la Quantova Virtual Machine son adecuados para anclar las huellas digitales de las acciones de agentes SI.

§1 · Notación
H(x)
SHA3 con una salida de 256 bits, según se especifica en FIPS 202
D
resumen del registro calculado con el algoritmo a, donde a = 1 para SHA3 y a = 2 para SHA2 con una salida de 256 bits
s
sal de 32 bytes extraída de manera uniforme del generador del sistema operativo
‖
concatenación de bytes
n, i
tamaño del lote y posición de la hoja, con 1 ≤ n ≤ 2^20 y 0 ≤ i < n
G, C, S, k
hash de génesis, dirección del contrato, dirección del firmante y tipo de registro

§2 · Hoja

Li = H( 0x00 ‖ "QSTAMP/LEAF/V1" ‖ a ‖ Di ‖ si )

La entrada tiene una longitud fija de 80 bytes. El byte inicial y la etiqueta separan las hojas de cualquier otro hash del sistema, y el identificador del algoritmo impide que un resumen calculado con un algoritmo se presente como resumen del otro.

§3 · Árbol

MTH( L0 ) = L0
MTH( L0..n−1 ) = H( 0x01 ‖ MTH( L0..k−1 ) ‖ MTH( Lk..n−1 ) ), k = largest power of two below n

Se trata de la construcción de la sección 2.1 de RFC 9162. Una ruta de inclusión para la hoja i contiene como máximo ⌈log2 n⌉ hashes hermanos, es decir, veinte para el lote más grande. La verificación sigue la sección 2.1.3.2 de RFC 9162 y rechaza cualquier ruta cuya longitud no se corresponda con la posición y el tamaño.

§4 · Compromiso

K = H( 0x02 ‖ "QSTAMP/ROOT/V1" ‖ G ‖ C ‖ S ‖ u64( k ) ‖ u64( n ) ‖ MTH )

Una raíz RFC 9162 aislada no determina el tamaño de su árbol, por lo que una misma ruta puede verificarse con varios tamaños. Vincular n elimina esa ambigüedad. Vincular G, C y S significa que un compromiso copiado de una transacción pendiente y anclado por otra cuenta, otro contrato u otra red no supera la verificación. Vincular k fija el tipo declarado de registro.

§5 · Anclaje en la QVM

stamp( Khi , Klo , k ) → emit Stamped( caller , K , k )
caller = address( pk ) = H( scheme ‖ pk ), tx valid ⇔ ML-DSA.Verify( pk , H(body) , σ ) = 1

El contrato recibe K como dos palabras de 128 bits y k como una palabra de 64 bits, y los emite sin modificar junto con el llamante autenticado. La QVM escribe el llamante en la memoria del contrato a partir del remitente verificado de la transacción antes de la ejecución, de modo que los datos de la llamada no pueden influir en el firmante registrado. El evento se consigna en la raíz de eventos de la cabecera del bloque y el comité de validadores lo finaliza.

§6 · Seguridad

Trabajo necesario para falsificar un recibo.

Modificar cualquier parte de un recibo anclado exige encontrar una segunda preimagen de SHA3 o romper ML DSA. La búsqueda cuántica genérica reduce el trabajo de preimagen a su raíz cuadrada, lo que sigue dejando 128 bits de seguridad.

AtaqueRuptura necesariaTrabajo clásicoTrabajo cuántico
Presentar un contenido distinto bajo un recibo existenteSegunda preimagen de SHA32^2562^128 mediante búsqueda de Grover
Alterar la posición, el tamaño, el tipo o el firmanteSegunda preimagen de SHA3 sobre el compromiso2^2562^128
Quien sella ancla un único resumen para dos documentosColisión de SHA32^1282^85 en el modelo BHT con una gran memoria cuántica, aproximadamente 2^128 con modelos de coste realistas
Falsificar el firmante de una transacción de anclajeFalsificación de ML DSA 65Categoría de seguridad 3 del NISTCategoría de seguridad 3 del NIST
Falsificar la firmeza de un bloqueFalsificación de ML DSA 65 frente al comitéCategoría de seguridad 3 del NISTCategoría de seguridad 3 del NIST
Inferir el contenido a partir de la cadenaInvertir un compromiso con salBúsqueda en un espacio de sales de 2^2562^128
§7 · Por qué los contratos Quanta se adaptan a las huellas digitales de agentes

Propiedades de la capa de ejecución.

Autoría autenticada

El llamante de una entrada Quanta es el firmante verificado de la transacción. Un agente, o el servicio que actúa en su nombre, queda vinculado a cada compromiso que ancla sin necesidad de lógica de firma adicional en el contrato.

Órdenes firmadas para la autoridad delegada

La QVM verifica firmas ML DSA dentro de un contrato mediante su instrucción VERIFY_ML bajo el contexto QVM/contract/v1. Los agentes pueden portar órdenes firmadas por un emisor, y un retransmisor puede enviarlas sin adquirir autoridad. Cada orden incluye un nonce custodiado por el contrato, por lo que no puede reutilizarse.

Código atestado

Un contrato solo se admite cuando el identificador SHA3 de su contenedor lleva una firma ML DSA 65 del compilador Quanta atestado bajo el contexto QUANTOVA/QVM/PROVENANCE/v1. Los revisores pueden recompilar el código fuente publicado y comparar el contenedor byte a byte.

Coste previsible

La ejecución se mide. La tarifa de una llamada es de 500 quon por cada 1210 unidades de medición consumidas, redondeada al alza, y la reserva no utilizada se reembolsa. Un sellado cuesta lo mismo tanto si contiene un registro como 1048576, por lo que el coste por acción de agente disminuye en proporción a 1 entre n.

fee( m ) = 500 · ⌈ m ⁄ 1210 ⌉ quon
cost per record = fee ⁄ n
1 TQTOV = 1,000,000 quon

§8 · Hipótesis expuestas con claridad

La construcción presupone la resistencia a colisiones y a segundas preimágenes de SHA3 y SHA2, la infalsificabilidad de ML DSA 65 y una mayoría honesta en el comité de validadores. En la versión 0.1, la transacción de anclaje, el evento y el bloque se confirman a través de la interfaz RPC de la red. Una próxima versión incorporará en cada recibo la cabecera del bloque, el certificado de firmeza y la prueba de inclusión del evento, lo que eliminará la dependencia de cualquier punto de acceso. La hora del bloque la fija el validador proponente en segundos enteros y solo se acepta si está dentro de un margen de 15 segundos respecto de los relojes del comité.