Preuves post-quantiques pour les agents autonomes sur la machine virtuelle Quantova

Résumé

Les agents autonomes et les agents de superintelligence effectuent désormais des paiements, prennent des décisions et procèdent à des dépôts réglementaires pour le compte d’entreprises des secteurs bancaire, public, de la santé et de la finance. Les enregistrements de ce qu’ont fait ces agents sont détenus par les opérateurs dont ils décrivent la conduite. De tels enregistrements peuvent être réécrits par leur dépositaire, et lorsqu’ils sont signés, ils le sont avec ECDSA, EdDSA ou RSA, que l’algorithme de Shor permet à un ordinateur quantique de falsifier en temps polynomial.

Qstamp est un SDK ouvert et un ensemble de contrats intelligents Quanta sur la machine virtuelle Quantova (QVM) qui transforment les enregistrements d’agents en preuves durables que chacun peut vérifier, tandis que les enregistrements eux-mêmes restent confidentiels chez l’opérateur. Chaque enregistrement est réduit à un condensat SHA3 256 et lié à un sel neuf de 256 bits. Les feuilles qui en résultent sont combinées dans un arbre de hachage RFC 9162 comportant jusqu’à 2²⁰ feuilles, et l’arbre fait l’objet d’un engagement cryptographique au moyen d’une valeur unique de 32 octets à séparation de domaine, qui lie la chaîne, le contrat, le signataire, le type d’enregistrement et la taille du lot. L’engagement est ancré par un contrat intelligent Quanta attesté, dans une transaction signée avec ML DSA 65 et finalisée par un comité de validateurs qui signe chaque bloc avec ML DSA 65 depuis la genèse.

Nous définissons un jeu de falsification de preuve et démontrons que l’avantage de tout adversaire classique ou quantique est borné par les avantages en collision et en seconde préimage contre SHA3 256, par un avantage EUF-CMA à q clés contre ML DSA 65 et par la probabilité d’une défaillance du consensus. Nous énonçons précisément ce qu’un reçu prouve et ce qu’il ne prouve pas, décrivons la manière dont les contrats sont compilés, attestés et déployés, présentons une procédure de vérification adaptée aux injonctions des tribunaux et des régulateurs, illustrée par un exemple détaillé issu du réseau de test Quantova, et rattachons la construction aux obligations de tenue des enregistrements de l’Union européenne, du Royaume-Uni, des États-Unis, du Japon, de la Corée et de Hong Kong.

Mots-clés

1. Introduction et synthèse des contributions

Des agents logiciels fondés sur de grands modèles appellent désormais des outils, transfèrent des fonds, accordent des crédits et produisent des contenus pour le compte de personnes et d’institutions. Lorsqu’une telle action est ultérieurement contestée, la question posée à une juridiction, à une autorité de surveillance ou à un assureur est d’ordre factuel. Qu’a fait l’agent, sous quel modèle et quelle politique, et à quel moment ? La réponse est presque toujours tirée d’enregistrements tenus par l’opérateur de l’agent, c’est-à-dire par la partie même dont la conduite est en cause.

Il en résulte deux faiblesses. La première tient à la garde des enregistrements. Un enregistrement conservé dans une base de données placée sous le contrôle administratif de l’opérateur peut être modifié par celui-ci, et rien dans l’enregistrement lui-même ne révèle la modification. La seconde tient à la durabilité. Lorsque les enregistrements sont protégés cryptographiquement, la protection consiste en une signature numérique ECDSA, EdDSA ou RSA, et les estimations de ressources publiées indiquent qu’un ordinateur quantique tolérant aux fautes de taille suffisante falsifierait de telles signatures en quelques heures ou quelques jours [10, 11, 8]. De nombreux enregistrements doivent être conservés pendant six à dix ans [37, 35], durée longue au regard de l’incertitude qui entoure la date à laquelle une telle machine pourrait exister [13].

Qstamp remédie à ces deux faiblesses au moyen d’une construction unique. Chaque enregistrement est réduit, à l’intérieur du périmètre de l’opérateur, à un engagement cryptographique SHA3 256 salé. Un lot comportant jusqu’à 2²⁰ engagements est agrégé dans un arbre de hachage, et une valeur unique de 32 octets, qui lie l’arbre à sa chaîne, à son contrat, à son signataire, à son type et à sa taille, est ancrée au moyen d’un contrat intelligent Quanta sur la machine virtuelle Quantova. Toute signature dont dépend cet ancrage, depuis le compte qui le soumet jusqu’au comité qui le finalise, est une signature ML DSA 65 [24], et il en est ainsi depuis le bloc de genèse du réseau. L’enregistrement ne quitte jamais l’opérateur, et toute partie détenant l’enregistrement et son reçu peut ultérieurement le vérifier sans faire confiance à l’opérateur ni à Quantova Inc.

Le présent article apporte les contributions suivantes.

1. Un modèle formel de l’opérateur en tant qu’adversaire interne et de l’adversaire quantique face aux signatures classiques, ainsi qu’un prédicat qui rend compte des exigences de tenue des enregistrements de la réglementation actuelle (section 2 et section 3).
2. Une spécification complète de la construction Qstamp, exactement telle qu’implémentée dans la version 0.1.4 du SDK, comprenant les encodages, les algorithmes d’horodatage et de vérification ainsi que le résultat de vérification à trois valeurs (section 5).
3. Une réduction démontrant que la falsification de preuve contre Qstamp est bornée par la résistance aux collisions et aux secondes préimages de SHA3 256, par l’infalsifiabilité de ML DSA 65 et par la sûreté du consensus, accompagnée de propriétés de liaison, de masquage et de vivacité ainsi que de bornes concrètes classiques et quantiques (section 6).
4. Un énoncé précis de ce qu’un reçu prouve et ne prouve pas pour les agents autonomes (section 7), et une procédure de vérification destinée aux injonctions des juridictions et des régulateurs, illustrée par une exécution réelle sur le réseau de test (section 8).
5. Une mise en correspondance des obligations légales avec les propriétés formelles fournies et leurs limites (section 9), une analyse des raisons pour lesquelles ces propriétés exigent une couche 1 post-quantique dotée d’un code de contrat attesté (section 10), ainsi que le coût et la latence mesurés (section 11).

Le présent article ne décrit que ce qui est en service à la date de la version 1.0. La construction fonctionne sur le réseau de test Quantova, dont les reçus n’ont aucune valeur probante. L’utilisation en production se fera sur le réseau principal Quantova dès son lancement. Les fonctionnalités prévues sont identifiées comme telles à la section 6.7 et à la section 12.

2. Formulation mathématique du problème

Dans tout ce qui suit, H désigne SHA3 256 [22], ‖ désigne la concaténation d’octets, λ désigne le paramètre de sécurité, et un algorithme est dit efficace s’il s’exécute en temps polynomial en λ sur un ordinateur classique (PPT) ou sur un ordinateur quantique (QPT).

2.1 Enregistrements contrôlés par l’opérateur et adversaire interne

Les signatures calculées par O n’y changent rien. Si chaque entrée porte σ_j = Sign(sk_O, e_j), alors O, qui détient sk_O, calcule une signature σ′ valide pour tout remplacement e′. La signature d’un dépositaire authentifie l’origine à l’égard des tiers mais n’apporte rien quant à l’intégrité face au dépositaire. L’intégrité face à O requiert un témoin W, c’est-à-dire une partie ou un système dont O ne peut altérer l’état, qui fixe une valeur dérivée de Λ avant t_a. Dans la pratique actuelle, la confiance de V dans l’état de W repose sur des signatures de W, presque toujours ECDSA sur secp256k1 ou P 256 [26, 29], Ed25519 [30] ou RSA, voire sur aucune signature lorsque le témoin est un système interne de l’opérateur.

2.2 L’algorithme de Shor et son coût publié

2.2.1 La réduction à la recherche d’ordre

Soit N un entier composé impair qui n’est pas une puissance d’un nombre premier, et soit a tiré uniformément parmi les unités modulo N. L’ordre de a est

Si r est pair et a^r/2 ≢ −1 (mod N), alors N divise (a^r/2 − 1)(a^r/2 + 1) mais ne divise aucun des deux facteurs, de sorte que

est un facteur non trivial. Pour N possédant au moins deux facteurs premiers impairs distincts, cet événement a une probabilité au moins égale à un demi sur le choix de a [2, 12]. La factorisation se réduit donc en temps polynomial classique au calcul d’ordres, et la contribution de Shor est un algorithme quantique pour ce dernier [1, 2].

2.2.2 La transformée de Fourier quantique

Choisissons Q = 2^ℓ avec N² ≤ Q < 2N². Un registre de ℓ qubits est placé en superposition uniforme et l’application x ↦ a^x mod N est calculée de manière réversible dans un second registre,

La transformée de Fourier quantique sur ℤ_Q agit sur le premier registre selon

et s’implémente exactement avec O(ℓ²) portes à un et deux qubits. Le second registre étant périodique en x de période r, une mesure du premier registre après la transformée renvoie, avec une probabilité Ω(1/log log N), une valeur y telle que

pour un certain entier s premier avec r. D’après le théorème de Legendre, s/r est alors une réduite du développement en fraction continue de y/Q, ce qui fournit r de manière classique. L’exponentiation modulaire domine le coût, avec O(ℓ³) portes pour l’arithmétique scolaire.

2.2.3 Logarithmes discrets et courbes elliptiques

Soit ⟨P⟩ un groupe cyclique d’ordre premier q et soit Q′ = dP une clé publique. La fonction

est constante exactement sur les classes du sous-groupe L. Une transformée de Fourier à deux registres sur ℤ_q² suivie d’une mesure fournit (u, v) avec v ≡ ud (mod q), de sorte que d = v·u⁻¹ mod q dès que u ≠ 0 [2]. Pour un groupe de courbe elliptique, la loi de groupe est évaluée de manière réversible au moyen d’une arithmétique sur le corps de base [9]. Roetteler, Naehrig, Svore et Lauter donnent un circuit concret pour les courbes sur corps premier de longueur n bits [8], qui utilise

et un nombre de portes de Toffoli de l’ordre de 10¹¹ pour n = 256. L’estimation s’applique à secp256k1 et à P 256, qui sous-tendent la plupart des déploiements d’ECDSA, et, à une différence négligeable près, à la courbe de 255 bits d’Ed25519. Il s’agit de qubits logiques. L’implémentation tolérante aux fautes multiplie le nombre de qubits physiques par le surcoût du code correcteur d’erreurs.

2.2.4 Estimations de ressources pour RSA 2048

Pour RSA, Gidney et Ekerå ont estimé en 2019 qu’un module de 2048 bits peut être factorisé en 8 heures environ avec 20 millions de qubits bruités, en supposant un taux d’erreur physique par porte de 10⁻³, une durée de cycle du code de surface d’une microseconde et un temps de réaction du système de contrôle de dix microsecondes [10]. Gidney a révisé cette estimation en 2025 à moins d’un million de qubits bruités et moins d’une semaine d’exécution, sous les mêmes hypothèses matérielles [11].

2.3 Conséquences pour les signatures, les registres et les journaux

La conséquence probatoire est rétroactive. Soit une entrée e signée à l’instant t_c sous pk, et soit t_q le premier instant auquel l’adversaire peut exécuter A_Shor. À tout instant T ≥ t_q, l’adversaire produit (e′, σ′) avec Verify(pk, e′, σ′) = 1. Un vérificateur à l’instant T détient deux couples qui sont tous deux vérifiés, et la vérification de signature ne fournit aucune information sur celui qui existait à l’instant t_c. L’adversaire n’a besoin que de pk, qui est public et qui, dans les registres, est publié avec la première transaction du compte. Les clés publiques et les enregistrements signés peuvent donc être collectés dès maintenant et falsifiés plus tard. En notant x la durée pendant laquelle les preuves doivent demeurer valables, y le temps nécessaire à leur migration et z le temps restant jusqu’à t_q, la condition de Mosca [13]

détermine à partir de quand les preuves sont exposées. Les durées de conservation sont longues. Les enregistrements des courtiers-négociants relevant de la Rule 17a 4 sont conservés jusqu’à six ans [37], et la documentation technique des systèmes d’IA à haut risque pendant dix ans après la mise sur le marché du système [35].

Les plateformes de contrats intelligents en production aujourd’hui autorisent les transactions au moyen d’ECDSA ou d’EdDSA. Sur une telle plateforme, l’affirmation selon laquelle un compte a autorisé une transaction n’est étayée que par une signature classique, et après t_q tout compte dont la clé publique est connue peut être amené à signer n’importe quoi. La fiabilité de l’ordre des blocs passés dépend de la manière dont un vérificateur prend connaissance de l’historique canonique. Un participant qui a suivi la chaîne de façon continue conserve sa connaissance. Lorsque le consensus est lui-même authentifié par des signatures classiques, un vérificateur qui reconstitue l’historique après t_q à partir des seules signatures, comme le ferait une juridiction ou un auditeur, ne peut pas distinguer l’historique canonique d’un historique alternatif signé avec des clés recouvrées. Lorsque l’ordre est garanti par une preuve de travail, l’ordonnancement conserve une sécurité fondée sur le hachage, mais l’autorisation de chaque transaction reste classique. C’est la couche de signature qui cède.

Les fonctions de hachage sont affaiblies mais non cassées. L’algorithme de Grover trouve une préimage d’une fonction de n bits en O(2^n/2) évaluations [3], ce qui est optimal pour la recherche générique [4]. L’algorithme de Brassard, Høyer et Tapp trouve des collisions en O(2^n/3) évaluations, à condition de disposer d’une mémoire accessible quantiquement de même taille [5], ce qui est là encore optimal pour les fonctions génériques [6]. Bernstein montre qu’une fois le coût de cette mémoire pris en compte, la recherche quantique de collisions n’est pas moins coûteuse que la recherche classique parallèle de collisions, soit environ 2^n/2 [7]. Pour n = 256, les marges restent d’au moins 2⁸⁵ dans le modèle le plus favorable à l’attaquant et d’environ 2¹²⁸ sous un coût réaliste. Cette asymétrie entre signatures et fonctions de hachage constitue le fondement de la conception exposée à la section 5.

2.3.1 Primitives classiques dans l’infrastructure des agents

L’infrastructure au moyen de laquelle les agents sont aujourd’hui identifiés, autorisés et audités repose sur un petit ensemble de primitives à clé publique. Le tableau indique, pour chacune d’elles, le problème sur lequel elle repose et l’effet de l’algorithme de Shor.

Les primitives symétriques se comportent différemment. HMAC et la famille SHA2 ne sont pas affectés par l’algorithme de Shor et ne sont qu’affaiblis par celui de Grover, de sorte que HMAC avec une clé de 256 bits conserve environ 128 bits de sécurité face à la recherche de clé. Un code d’authentification de message ne prouve toutefois rien à un tiers. Quiconque détient la clé peut recalculer une étiquette valide pour toute entrée altérée, et dans un journal d’audit le détenteur de la clé est l’opérateur, de sorte que l’observation 1 s’applique sans changement. Il en va de même d’une chaîne de hachage tenue par l’opérateur sans ancrage externe, que l’opérateur peut recalculer à partir de tout point altéré.

2.4 Le vide réglementaire

Dans l’ensemble des juridictions, les règles exigent que certains enregistrements soient générés, conservés pendant des durées définies et protégés contre l’altération, ou tenus de manière que toute altération soit détectable. L’AI Act de l’UE exige que les systèmes d’IA à haut risque permettent l’enregistrement automatique des événements tout au long de leur cycle de vie (article 12), et impose aux fournisseurs et aux déployeurs de conserver ces journaux pendant une durée adaptée à la destination prévue, d’au moins six mois (article 19 et article 26, paragraphe 6) [35]. La modification eIDAS 2 confère une reconnaissance juridique aux registres électroniques et attache une présomption d’intégrité et d’ordre chronologique aux registres électroniques qualifiés (articles 45 nonies et 45 decies) [36]. La SEC Rule 17a 4 impose aux courtiers-négociants de conserver les enregistrements électroniques soit avec une piste d’audit complète et horodatée, soit sous une forme non réinscriptible et non effaçable [37]. L’article 5, paragraphe 1, point f), du RGPD britannique exige une sécurité appropriée des données à caractère personnel, y compris la protection contre le traitement non autorisé et contre la perte ou les dommages d’origine accidentelle [38]. La loi japonaise sur la conservation électronique des livres exige des mesures garantissant l’authenticité des enregistrements électroniques, telles que des horodatages ou des systèmes qui consignent les corrections et les suppressions [39]. Les mesures de sécurité exigées par l’article 29 de la loi coréenne sur la protection des informations personnelles comprennent la conservation des registres d’accès et leur protection contre la falsification et l’altération [40]. Le principe de protection des données 4 de la Personal Data (Privacy) Ordinance de Hong Kong impose aux utilisateurs de données de prendre toutes les mesures raisonnablement possibles pour protéger les données à caractère personnel contre tout accès, traitement, effacement, perte ou utilisation non autorisés ou accidentels [41].

Le même horizon est désormais régi par des obligations de migration post-quantique. Le NIST IR 8547, dans son projet initial soumis à consultation publique, propose que les algorithmes à clé publique vulnérables au quantique au niveau de sécurité de 112 bits soient dépréciés après 2030 et que tous les algorithmes à clé publique vulnérables au quantique soient interdits après 2035 [27]. Le décret présidentiel (Executive Order) 14412 enjoint aux systèmes fédéraux des États-Unis d’adopter l’établissement de clés post-quantique au plus tard le 31 décembre 2030 et les signatures numériques post-quantiques au plus tard le 31 décembre 2031 [28]. Les enregistrements créés aujourd’hui seront donc examinés, au cours de leur durée de conservation, à une époque où les signatures qui les protègent seront formellement interdites.

Les textes énoncent Ret explicitement au travers des durées de conservation et énoncent Int en des termes tels que la protection contre l’altération ou la falsification, le stockage non réinscriptible ou les pistes d’audit. Ver et Time découlent de la finalité de la surveillance et de la preuve. Le vide tient à ce que tout mécanisme dont la propriété Int repose sur une signature classique ne satisfait Int que pour 𝒜 restreinte aux adversaires actifs avant t_q. Dès que t₀ + R > t_q, le prédicat est faux pour le reste de la période. Qstamp est conçu pour fournir Int, Ver et Time pour tout t de la période face aux adversaires classiques et quantiques, sous les hypothèses de la section 3. Ret demeure l’obligation du dépositaire. Aucune loi citée ici n’impose Qstamp. Les lois exigent des propriétés, et la section 9 expose celles que Qstamp fournit.

3. Modèle du système et modèle de menace

3.1 Parties

• Opérateur O. Exploite un ou plusieurs agents, détient leurs enregistrements et contrôle une clé de signature sk_S dont la clé publique ML DSA 65 détermine l’adresse S sur la chaîne. O exécute le SDK Qstamp.
• Vérificateur V. Une juridiction, un régulateur, un auditeur, un assureur ou une contrepartie. V ne détient que des paramètres publics, à savoir le hachage de genèse G de la chaîne, l’adresse C du contrat Qstamp officiel et l’ensemble de validateurs publié, ainsi que tout ce que O produit.
• Réseau. La chaîne Quantova, constituée de la QVM, d’un comité de validateurs 𝒱 qui finalise les blocs, ainsi que de points de terminaison RPC et d’un explorateur qui servent les données de la chaîne.
• Adversaire A. Toute partie qui cherche à faire accepter par V une affirmation fausse concernant un enregistrement.

3.2 Hypothèses

3.3 Classes d’adversaires

Un adversaire classique est PPT. Un adversaire quantique est QPT, peut exécuter hors ligne les algorithmes de Shor et de Grover, et dispose d’un accès quantique à H lorsqu’un modèle de l’oracle aléatoire est utilisé [16]. Les deux classes peuvent corrompre l’opérateur après un instant t*, ce qui modélise un initié qui souhaite ultérieurement réécrire l’historique ou une compromission ultérieure de sk_S. Toutes deux peuvent contrôler n’importe quels autres comptes, corrompre des membres du comité dans la limite fixée par T3, retarder, réordonner ou supprimer des messages réseau, et exploiter leurs propres points de terminaison RPC. L’opérateur honnête est supposé horodater correctement avant t*.

Trois questions se situent hors du modèle et sont énoncées afin qu’elles ne soient pas prises pour des garanties. Un enregistrement qui était faux au moment de son horodatage demeure faux, puisque Qstamp fige le contenu sans le juger. Un adversaire détenant sk_S avant l’horodatage d’un enregistrement peut horodater au nom de S, ce qui relève de la garde des clés. La disponibilité de l’enregistrement et de son reçu relève de la responsabilité du dépositaire, puisqu’un sel perdu rend l’inclusion correspondante impossible à prouver.

4. Le cadre Quantova

La présente section décrit les composants sur lesquels Qstamp s’appuie, tels qu’ils sont en service à la date du présent article.

4.1 Quanta, le langage de contrats intelligents

Quanta est le langage de contrats de la chaîne Quantova. Un contrat Quanta se compile en un conteneur QVM. Au sein d’un contrat, l’autorité découle uniquement de signatures vérifiées. L’appelant d’un point d’entrée est le signataire vérifié de la transaction, et un contrat peut vérifier d’autres signatures ML DSA portant sur des ordres signés au moyen de l’instruction QVM VERIFY_ML. Chacune de ces vérifications utilise la chaîne de contexte FIPS 204 QVM/contract/v1, que FIPS 204 lie au message signé sous la forme

de sorte qu’une signature produite pour un ordre de contrat ne peut pas être présentée comme signature dans un autre contexte [24]. Le contrat Qstamp ouvert est le code source Quanta suivant, qui ne détient ni état, ni fonds, ni propriétaire.

Les modèles émetteur et conseil ajoutent des ordres signés qui portent un nonce détenu par le contrat, une échéance et une valeur de domaine propre à chaque déploiement, de sorte qu’un ordre ne peut être ni rejoué, ni utilisé tardivement, ni utilisé sur un autre déploiement.

4.2 Le compilateur attesté

Un conteneur c est identifié par id(c) = H(c). La chaîne n’admet un déploiement que si l’identifiant porte une signature ML DSA 65 de la clé de provenance du compilateur,

La signature établit que le conteneur déployé a été produit par le compilateur attesté. L’identité avec le code source examiné est ensuite établie par reproduction. Un examinateur compile le code source publié, compare octet par octet le conteneur obtenu au conteneur déployé, et confirme ainsi que le code situé en C est bien le code qui a été examiné. Le code source publié du contrat Qstamp ouvert se compile octet par octet en le contrat déployé sur le réseau de test. Cette garantie suppose la garde sécurisée de la clé de provenance par Quantova Inc. Pour la seule propriété d’identité du code, il s’agit d’une hypothèse de confiance qui s’ajoute à T1 à T5.

4.3 La machine virtuelle Quantova et la couche d’exécution

La QVM est une machine à registres à consommation mesurée, dotée d’instructions natives pour la vérification ML DSA et SLH DSA [25], le hachage et les arbres de hachage. Avant l’exécution, la QVM inscrit l’émetteur vérifié de la transaction dans la mémoire du contrat sous le nom caller, de sorte que le signataire consigné ne peut pas être influencé par les données d’appel. L’exécution est atomique. En notant S l’état, tx une transaction et m sa limite de mesure,

où E est la liste des événements émis. Les événements et les changements d’état ne sont consignés qu’en cas de succès, et les événements font l’objet d’un engagement dans la racine des événements de l’en-tête du bloc. Une transaction finalisée dépourvue de son événement ne prouve donc rien quant à un horodatage, et la vérification de la section 5 exige l’événement.

4.4 Consensus et finalité

Chaque compte, chaque transaction et chaque certificat de finalité de la chaîne Quantova sont signés avec ML DSA 65 depuis le bloc de genèse, SLH DSA étant disponible comme schéma de compte alternatif ainsi qu’il a été décrit ci-dessus. Une adresse est une valeur de 32 octets dérivée d’une clé publique ML DSA 65. Les blocs sont finalisés par un comité tiré au sort dont le certificat porte des signatures ML DSA 65 atteignant le seuil de finalité, et la finalité est atteinte en 0.2 seconde environ. L’heure du bloc est proposée en secondes entières. Sous T4, un bloc accepté B de parent P satisfait

de sorte que l’heure des blocs ne décroît jamais et ne peut pas devancer de plus de 15 secondes les horloges honnêtes.

4.5 Frais

L’exécution est mesurée, et les frais d’un appel qui consomme m unités de mesure sont

la réserve inutilisée étant remboursée. L’appel d’horodatage comporte des données d’appel de longueur fixe et émet un unique événement de longueur fixe, de sorte que ses frais ne dépendent pas de la taille de lot N. Sur le réseau de test, un horodatage coûte 0.005 TQTOV, soit 5000 quon, quel que soit N. Les TQTOV sont des unités du réseau de test dépourvues de valeur monétaire.

5. La construction Qstamp

5.1 Notations

5.2 Feuilles, arbre et engagement

Pour l’enregistrement r_i de condensé d_i = D_alg(r_i), la feuille est

soit une évaluation de H sur exactement 1 + 14 + 1 + 32 + 32 = 80 octets. Les feuilles forment l’arbre de la section 2.1 du RFC 9162 [31], dont les nœuds internes sont

soit une évaluation de H sur exactement 65 octets.

L’engagement cryptographique est

soit une évaluation de H sur exactement 1 + 14 + 32 + 32 + 32 + 8 + 8 + 32 = 159 octets. Les trois rôles sont distingués par leur premier octet et par leur longueur, propriété utilisée dans le lemme 1. La construction reprend l’arbre de hachage de Merkle [18] et l’idée de chaînage de Haber et Stornetta [19], avec la séparation de domaine du RFC 9162 et une liaison explicite de la taille et du contexte.

5.3 Ancrage

K est scindé en deux moitiés de 16 octets (hi, lo) et soumis depuis S dans un appel au contrat officiel C,

Les données d’appel ont une longueur fixe et se composent du sélecteur de 4 octets, de 120 octets de contexte hôte, de l’engagement de 32 octets et du type sur 8 octets. Les données de l’événement comportent 72 octets. Le contrat ne conservant aucun état, un nombre quelconque d’horodatages de tout engagement peuvent coexister, et aucun horodatage ne peut empêcher qu’un autre soit consigné.

5.4 Reçu

Chaque enregistrement reçoit son propre reçu, à savoir le n-uplet

avec fmt = qstamp-receipt/1, le nom de chaîne id et la genèse G, le contrat C, le type k sous forme de chaîne décimale, l’algorithme de condensé, le condensé et le sel, la position, la taille du lot et le chemin d’inclusion, la racine de l’arbre, ainsi que la transaction d’ancrage, la hauteur de bloc h, l’identifiant de bloc B, l’heure du bloc t en secondes depuis 1970 et le signataire S. Un reçu ne contient aucune partie de l’enregistrement. Il contient en revanche le condensé et le sel, ce qui importe pour la section 6.5.

5.5 Algorithmes

La vérification renvoie l’un de trois résultats. Valide signifie que toutes les vérifications ont réussi. Invalide signifie qu’au moins une vérification de fond a échoué, y compris lorsque aucun enregistrement ni condensé n’a été fourni. Indéterminé signifie que toutes les vérifications en échec étaient des défaillances de transport, telles qu’un point de terminaison injoignable ou une liste d’événements tronquée. Un résultat indéterminé n’est jamais rapporté comme valide. Les vérifications, au nombre de huit, sont nommées format, contract, content, inclusion, chain, transaction, event et block.

$ 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. Analyse de sécurité

6.1 Le jeu de falsification de preuve

Le jeu rend compte de l’initié qui réécrit l’historique après coup, puisque A obtient sk_S et doit néanmoins rattacher r′ à un ancrage antérieur à t*. Il rend compte de l’intrus extérieur qui substitue un contenu, ainsi que du tiers qui tente d’imputer à S un enregistrement que S n’a jamais horodaté. Un nouvel horodatage de r′ après t* ne constitue pas une falsification, puisque son reçu indique une heure postérieure.

6.2 Séparation de domaine

Sans les préfixes de rôle, un nœud interne pourrait être présenté comme une feuille, ce qui est l’ambiguïté classique de seconde préimage des arbres de Merkle sans préfixe que le RFC 9162 supprime [31]. Sans u64(N), une racine ne déterminerait pas la forme de son arbre, et un même chemin pourrait être vérifié sous plusieurs tailles.

6.3 Théorème principal

Esquisse de preuve. Supposons que A gagne avec la sortie (r′, ρ′), où ρ′ désigne alg′, d′, s′, la position i, la taille N′, le chemin π′, root′, le type k′, la transaction tx, la hauteur h, l’heure t ≤ t* et le signataire S. La validité des huit vérifications fournit les faits suivants. G et C sont les valeurs officielles. D(r′) = d′. RootFromPath(L′, i, N′, π′) = root′, où L′ est la feuille de (alg′, d′, s′). Sous T5, le bloc finalisé à la hauteur h contient tx de S vers C ainsi qu’un événement de C de données S ‖ K′ ‖ u64(k′), où K′ = Commit(G, C, S, k′, N′, root′). Nous partitionnons l’événement de victoire.

1. Défaillance du consensus. Le bloc rapporté à la hauteur h n’est pas l’unique bloc finalisé à cette hauteur. Cela contredit T3, sauf avec probabilité Adv_consensus, une fois exclues les signatures de comité falsifiées, qui relèvent du cas suivant.
2. Falsification de signature. Le bloc canonique à la hauteur h porte une transaction de S que le challengeur n’a pas signée avant t*, ou une signature de comité qu’aucun membre honnête n’a produite. Avant t*, les horodatages honnêtes sont exactement les requêtes de signature, de sorte que B₃ devine laquelle des q clés est falsifiée, y place sa clé de défi et produit la falsification en sortie. Cela coûte au plus q · Adv^EUF-CMA.
3. Ancrage honnête. Dans le cas contraire, l’événement a été émis par un horodatage honnête portant sur le lot (r₀, …, r_N−1), avec les sels s_i, le type k et l’engagement K, puisque toute transaction de S antérieure à t* est honnête et que les données de l’événement désignent S. La concordance de l’événement donne K′ = K et k′ = k. D’après le lemme 1, soit (N′, root′) = (N, root), soit B₁ ou B₂ produit une collision entre deux chaînes de 159 octets.
4. Même arbre. À taille et racine égales, l’algorithme 3 recalcule root à partir de L′ le long d’un chemin dont la forme ne dépend que de (i, N). Parcourons le chemin de la racine vers la feuille. Au premier niveau où les entrées du nœud honnête et du nœud présenté diffèrent, les deux entrées ont la même image par hachage, ce qui, d’après le lemme 1, constitue une collision entre deux chaînes de 65 octets. Si aucun niveau ne diffère, alors L′ = L_i.
5. Même feuille. D’après le lemme 1, soit (alg′, d′, s′) = (alg, d_i, s_i), soit les deux entrées de 80 octets entrent en collision.
6. Même condensé. Alors D(r′) = d_i = D(r_i) avec r′ ≠ r_i, puisque A gagne, ce qui constitue une collision de D = SHA3 256.

Il reste à attribuer chaque collision obtenue dans les cas 3 à 6 à B₁ ou à B₂. Si l’entrée honnête de la paire en collision est une fonction de valeurs choisies par A seul, comme lorsque A a choisi le lot et que l’entrée en collision ne contient aucun sel frais, la paire est une collision et elle est produite en sortie par B₁. Si l’entrée honnête contient une valeur non choisie par A, à savoir un sel s_i ou un enregistrement fourni par une partie honnête, alors l’entrée honnête est une cible fixée avant que A n’entame sa recherche, et A a trouvé une seconde entrée ayant la même image. Il s’agit d’une seconde préimage au sens de Rogaway et Shrimpton pour des cibles tirées selon la distribution honnête [17], produite en sortie par B₂. Les deux attributions sont disjointes, de sorte qu’une borne de l’union sur les cas 1 à 6 donne (22). ∎

Pour alg = 2, l’étape de condensé du cas 6 repose sur SHA 256 et la borne s’enrichit des termes SHA 256 correspondants. La liaison ne requiert que T1 à T3 dans le modèle standard. Le masquage, à la section 6.5, utilise le modèle de l’oracle aléatoire [15, 16].

6.4 Liaison du contexte, rejeu et front running

Ce résultat découle du lemme 1 et emporte cinq conséquences. Un engagement ancré sur une chaîne n’est pas vérifié sur une autre, car G diffère, et un réseau relancé avec une nouvelle genèse ne peut pas vérifier les anciens reçus. Un reçu n’est pas vérifié au regard d’un autre contrat, car C diffère. Un acteur de front running F qui copie K à partir d’une transaction en attente et soumet stamp(K, k) depuis son propre compte obtient un événement désignant F, et un reçu désignant F n’est vérifié que si K = Commit(G, C, F, k, N, root), ce qui constitue une collision. Le contrat ouvert étant sans état, la copie n’empêche pas la consignation de la transaction d’origine de S, de sorte que le front running ne permet ni de dérober ni de bloquer un horodatage. Le type déclaré ne peut pas être réétiqueté après l’ancrage. La taille du lot est fixée, ce qui supprime l’ambiguïté de taille des racines RFC 9162 nues.

6.5 Masquage

La réserve est essentielle. Le détenteur d’un reçu connaît s_i et d_i. Comme d_i = D(r_i) n’est pas salé, le détenteur d’un reçu peut tester, au prix d’une seule évaluation de hachage, une conjecture portant sur un enregistrement de faible entropie, tel qu’un montant ou un code court. Les reçus doivent donc être protégés au même titre que les enregistrements qu’ils décrivent. Le masquage protège le contenu contre les observateurs de la chaîne, non contre les détenteurs de reçus.

6.6 Bornes concrètes

La catégorie 3 du NIST signifie que casser le schéma requiert des ressources comparables ou supérieures à celles d’une recherche de clé sur un chiffrement par blocs à clé de 192 bits [24]. FIPS 202 indique pour SHA3 256 une résistance aux collisions de 128 bits et une résistance aux préimages et aux secondes préimages de 256 bits face aux attaques classiques [22].

6.7 Vivacité, indétermination et point de terminaison de confiance

Vivacité de l’horodatage. Un horodatage s’achève lorsque le comité finalise sa transaction. Si la finalité n’est pas observée avant l’expiration du délai, l’algorithme 1 renvoie le lot en attente enregistré de manière persistante, qui contient les sels, l’engagement cryptographique et l’identifiant de transaction. Les reçus sont complétés ultérieurement à partir de ce lot, sans second paiement. Une erreur survenue pendant la soumission de la transaction porte également le lot en attente, de sorte que les sels ne sont jamais perdus du fait d’une défaillance du réseau.

Le point de terminaison de confiance de la version 0.1. Les vérifications 1 à 4 s’exécutent sur la machine du vérificateur et ne dépendent d’aucune partie extérieure. Les vérifications de chaîne, de transaction, d’événement et de bloc reçoivent leur réponse de points de terminaison RPC, de sorte que T5 est requise. Un point de terminaison exploité de manière malhonnête pourrait signaler un ancrage inexistant. La version 0.1 atténue ce risque en utilisant par défaut le point de terminaison officiel, en vérifiant que chaque point de terminaison sert la chaîne désignée dans le reçu, en exigeant que tous les points de terminaison consultés concordent et en indiquant quels points de terminaison ont été consultés. Sans T5, (22) s’enrichit d’un terme Adv_endpoint égal à la probabilité que tous les points de terminaison consultés mentent de manière cohérente. T5 couvre également le canal vers chaque point de terminaison. Les réponses transitent par TLS, qui assure une sécurité de transport extérieure au protocole Quantova et peut recourir à un échange de clés et à des certificats classiques, de sorte qu’un adversaire capable d’usurper un point de terminaison au niveau de la couche de transport est pris en compte dans ce même terme.

Preuves de finalité hors ligne prévues. Une version à venir inclura dans chaque reçu l’en-tête du bloc de hauteur h, le certificat de finalité du comité et une preuve d’inclusion de l’événement Stamped par rapport à la racine des événements de l’en-tête. La vérification ne nécessitera alors que le reçu, l’enregistrement et l’ensemble de validateurs publié. Le terme lié au point de terminaison disparaît et les vérifications de chaîne se réduisent à la vérification ML DSA 65 sous T2 et T3, de sorte que (22) vaut sans T5.

7. Application aux agents autonomes et aux agents de superintelligence

7.1 Enregistrements canoniques des actions

Une action a d’un agent ne constitue une preuve qu’au travers d’un encodage en octets canon(a), et le condensé est d = D(canon(a)). L’encodage doit être fixé et versionné par l’opérateur, puisque deux sérialisations d’un même contenu donnent des condensés différents. Un changement de sérialisation produit un faux verdict d’invalidité, jamais un faux verdict de validité. Une forme JSON canonique à clés triées lexicographiquement et sans espace non significatif, telle que le schéma du RFC 8785 [32], répond à ce besoin. Le SDK hache exactement les octets qui lui sont fournis et n’impose aucune sérialisation. Un enregistrement d’action utile désigne l’agent, l’opérateur, le modèle et sa version, la politique en vigueur, l’outil invoqué, les entrées sur lesquelles l’agent s’est appuyé, la décision ou la sortie, l’existence ou non d’un examen humain, ainsi que l’heure affirmée par l’agent.

7.2 Regroupement en lots

Un opérateur collecte les actions sur une fenêtre Δ, ou jusqu’à un certain nombre, et les horodate en un seul lot. Une action effectuée à l’instant τ dispose alors d’un ancrage dont le bloc a été finalisé au plus tard à τ + Δ + t_fin, où t_fin est la latence d’horodatage. Le coût par action est fee / N. Les actions significatives, telles que les paiements supérieurs à un seuil, peuvent être horodatées individuellement avant ou après leur exécution, de sorte que l’enregistrement soit final avant que l’action ne s’achève. Le hook onPending permet à l’opérateur d’enregistrer de manière persistante chaque lot soumis avant d’attendre la finalité.

7.3 Types d’enregistrement

Le type est une valeur de 64 bits liée à K et émise dans l’événement. Il indique ce que S a déclaré comme contenu du lot. Il ne constitue pas une classification vérifiée du contenu.

7.4 Passeports de modèle

Un passeport de modèle est un mode d’utilisation, non un mécanisme distinct. Lors de la publication, l’opérateur horodate, avec le type ai_model, un enregistrement qui énumère les condensés des artefacts du modèle, le condensé du manifeste du jeu de données horodaté avec le type ai_dataset, ainsi que les condensés des rapports d’évaluation. Chaque enregistrement d’action ultérieur désigne la version du modèle et le condensé de son passeport, de sorte que le reçu d’une action mène au reçu qui a figé le modèle dont l’action dépendait.

7.5 Ce qu’un reçu prouve et ce qu’il ne prouve pas

8. Procédure probatoire en exécution d’une décision de justice

Supposons qu’une juridiction ou un régulateur enjoigne à une entreprise SI de démontrer ce que son agent a fait dans une affaire donnée. La procédure ci-dessous n’exige de l’entreprise rien d’autre que la production de documents, et du vérificateur rien d’autre que des paramètres publics et des calculs.

1. Production. L’entreprise produit l’enregistrement r et son reçu ρ. L’injonction peut également exiger la règle de canonicalisation utilisée pour les enregistrements de ce type.
2. Recalcul. Le vérificateur recalcule d = H(r), la feuille L à partir de (alg, d, s), la racine à partir de (L, i, N, π) au moyen de l’algorithme 3, et K à partir de (G, C, S, k, N, root). Cette étape ne nécessite aucun accès au réseau et peut être effectuée avec le SDK, avec la commande qstamp verify ou avec une implémentation indépendante de la section 5.
3. Ancrage. Au moyen de la chaîne publique, par l’intermédiaire d’un ou de plusieurs points de terminaison RPC indépendants et dans l’explorateur, le vérificateur contrôle que la transaction désignée dans ρ a été envoyée par S au contrat officiel C et que le bloc h contient l’événement Stamped de C avec les données S ‖ K ‖ u64(k). L’explorateur est une vue des données de la chaîne qui permet à un lecteur non technicien de confirmer les mêmes faits. Il ne constitue pas une ancre de confiance distincte.
4. Finalité. Le vérificateur contrôle que la transaction est finale et que le bloc à la hauteur h a pour identifiant B et pour heure t.
5. Résultat. Si toutes les vérifications réussissent, le résultat est valide, et la proposition 5 énonce ce qui a été établi. Si une vérification de fond échoue, le résultat est invalide, et la vérification en échec identifie le maillon défaillant. Si le réseau n’a pas pu être consulté, le résultat est indéterminé et la procédure est répétée.

8.1 Exemple détaillé issu du réseau de test Quantova

Un agent de décision de crédit a produit l’enregistrement suivant, sérialisé en JSON canonique avec des clés triées et sans espace non significatif.

L’enregistrement a été horodaté dans un lot de six enregistrements. Les valeurs ci-dessous sont tirées de cette exécution.

La transaction d’ancrage peut être consultée à l’adresse https://qvmscan.io/tx/QTX1V53JW528S64SZYD6EDZ563N0PUUA2ARGNQHV4LTJMNH24PQS5VPQTAH8RQ.

La vérification du reçu au regard de l’enregistrement a renvoyé un résultat valide, les huit vérifications ayant réussi.

Le montant figurant dans l’enregistrement a ensuite été modifié de 1000 et la vérification répétée avec le même reçu. La vérification du contenu a échoué et le résultat a été invalide. Les autres vérifications ne sont pas affectées par la modification, ce qui est le comportement attendu, puisque le verdict désigne précisément le maillon rompu. À titre d’illustration, le remplacement de 125000 par 126000 donne le condensé

Deux caractéristiques de l’exemple appellent un commentaire. Premièrement, le champ horaire à l’intérieur de l’enregistrement, 09:39:25.132, est une assertion de l’agent et n’est pas certifié. L’heure du bloc est exprimée en secondes entières, 09:39:25, et concorde avec l’enregistrement à cette résolution. Deuxièmement, le temps mesuré entre la soumission et l’observation de la finalité a été d’environ 0.7 seconde, ce qui inclut l’intervalle d’interrogation du SDK.

9. Correspondance réglementaire

Le tableau met en relation chaque obligation avec la propriété formelle que fournit Qstamp et avec les limites de cette propriété. Les paraphrases sont des résumés destinés à l’orientation du lecteur et ne remplacent pas les textes juridiques [35, 36, 37, 38, 39, 40, 41, 27]. Aucune loi citée n’impose Qstamp. Chacune exige certaines propriétés des enregistrements, et Qstamp en fournit une partie.

Chaque organisation reste responsable du respect de l’ensemble des exigences des lois qui lui sont applicables et devrait recueillir son propre conseil juridique.

10. Ce qui distingue cette construction

Nous soutenons que des preuves durables pour les agents exigent la réunion de quatre propriétés, et qu’une chaîne classique ne peut acquérir la première d’entre elles pour son historique existant par la seule migration.

1. R1. Authentification post-quantique de l’ensemble de l’historique. Toute signature dont dépend un ancrage, du compte qui le soumet jusqu’à la finalité, est post-quantique, et ce depuis la genèse, et le protocole n’accepte aucune signature classique susceptible d’établir un fait concurrent.
2. R2. Témoin indépendant. L’ancrage est figé par un comité indépendant du dépositaire, et non par le dépositaire ou par une autorité unique.
3. R3. Code attesté. Le code qui consigne un ancrage est, de manière démontrable, le code examiné, et il ne peut pas être remplacé à la même adresse.
4. R4. Autorité programmable. Les politiques institutionnelles, telles que les émetteurs autorisés, l’approbation multipartite et la révocation, s’exécutent sous authentification post-quantique.

La condition énoncée dans la proposition 6 décrit un véritable remède, qui doit être présenté loyalement. Les preuves peuvent être préservées par renouvellement, procédé par lequel les anciennes preuves font l’objet d’un engagement sous des primitives plus robustes avant que les anciennes ne cèdent, comme dans le renouvellement de Haber et Stornetta [19] et dans l’Evidence Record Syntax du RFC 4998 [34]. Le renouvellement doit intervenir avant t_q, doit lui-même être vérifiable et ne protège que ce qui a été renouvelé. Un réseau post-quantique depuis la genèse n’a rien à renouveler pour son propre historique. C’est en ce sens que l’adaptation a posteriori d’une chaîne classique laisse son historique antérieur falsifiable, à moins qu’il ne soit renouvelé à temps.

Une autorité d’horodatage post-quantique satisfait R1 mais repose sur une autorité unique et n’offre aucune politique programmable. Un registre dépourvu de code attesté satisfait R2 et R4, mais un vérificateur doit auditer de manière indépendante le bytecode situé à l’adresse du contrat. Le tableau résume les déploiements typiques de chaque catégorie en 2026. Il décrit des catégories, et non des produits nommément désignés.

À notre connaissance, peu de réseaux en production réunissaient R1 à R4 depuis la genèse à la date du présent article. Nous ne prétendons pas que cette combinaison soit exclusive à Quantova, et l’argumentation de la présente section ne dépend que des propriétés, non de l’identité d’un quelconque réseau.

11. Économie et performances

D’après (15), les frais d’un horodatage ne dépendent que de la mesure consommée par l’appel de longueur fixe, de sorte qu’un horodatage coûte 0.005 TQTOV, soit 5000 quon, sur le réseau de test, quel que soit N. Le coût amorti par enregistrement est

Sur la chaîne, chaque horodatage ajoute 164 octets de données d’appel et un événement de 72 octets, indépendamment de N. La vérification locale coûte un condensé de l’enregistrement et au plus ⌈log₂N⌉ + 2 évaluations supplémentaires de SHA3 256 sur des entrées de longueur fixe. La vérification sur la chaîne coûte quatre requêtes par point de terminaison, portant sur l’identité de la chaîne, la transaction, les événements et le bloc.

Lors de l’exécution sur le réseau de test qui a produit l’exemple de la section 8, le temps écoulé entre la soumission d’un horodatage et l’observation de la finalité a été d’environ 0.7 seconde, pour une finalité de la chaîne d’environ 0.2 seconde. La différence est imputable à la soumission et à l’intervalle d’interrogation de 400 millisecondes avec lequel le SDK observe la finalité. Quatre horodatages ont coûté 0.02 TQTOV au total, soit 0.005 TQTOV chacun. Ces chiffres sont des mesures effectuées sur le réseau de test et ne constituent pas des garanties quant aux performances ou au prix sur le réseau principal.

12. Limites et travaux futurs

1. Preuves de finalité hors ligne. La version 0.1 confirme les faits de la chaîne au moyen de points de terminaison RPC et repose donc sur T5. L’intégration dans chaque reçu de l’en-tête du bloc, du certificat de finalité et de la preuve d’inclusion de l’événement, telle que décrite à la section 6.7, est prévue et supprimera cette dépendance.
2. Domaine propre à chaque déploiement dans les modèles. Les modèles émetteur et conseil rejettent les ordres dont la valeur de domaine diffère de celle du déploiement. Cette valeur est un nombre de 64 bits choisi par le déployeur, et sa fraîcheur constitue une obligation opérationnelle. L’adresse d’un contrat ne dépend que du compte qui le déploie et du nombre de transactions de ce compte, de sorte qu’après une relance ou sur une bifurcation, un nouveau déploiement peut recevoir l’adresse d’un déploiement antérieur, et seule une valeur de domaine fraîche empêche alors que des ordres signés pour le déploiement antérieur soient acceptés.
3. La révocation n’est pas encore vérifiée par le SDK. Le modèle émetteur consigne le retrait d’un engagement avec un code de motif, mais Verify ne consulte pas cet état. Un reçu portant sur un engagement retiré est encore vérifié comme valide, et un vérificateur qui se fonde sur les retraits doit interroger séparément le contrat émetteur.
4. Audit par un tiers. Le SDK et les contrats ont fait l’objet d’un examen interne avant leur publication. Les modèles de contrat sont publiés à titre d’exemples, et un audit indépendant par un tiers qualifié est requis avant tout déploiement en production de ceux-ci et recommandé avant de s’appuyer sur le SDK en production.
5. Résolution temporelle. L’heure du bloc a une résolution d’une seconde, est bornée supérieurement par T4 et inférieurement par la seule heure du bloc parent. Les reçus établissent l’existence au plus tard à la finalité, et non un instant au plus tôt.
6. Exhaustivité. Un reçu prouve l’inclusion, non l’exhaustivité. La numérotation consécutive et le chaînage des lots, tels que suggérés à la section 7.5, sont des pratiques de l’opérateur et ne sont pas imposés par le contrat.
7. Statut du réseau. Tous les résultats du présent article concernent le réseau de test. Les reçus qui y sont produits n’ont aucune valeur probante, et l’utilisation en production se fera sur le réseau principal Quantova dès son lancement.

13. Statut juridique du présent document

Le présent document constitue une spécification et une description techniques de Qstamp fournies par Quantova Inc à titre informatif. Il ne crée par lui-même aucune obligation contractuelle, garantie, déclaration ou engagement, et ne constitue pas un conseil juridique, réglementaire, fiscal ou en investissement. L’utilisation de Qstamp, du SDK Qstamp et des modèles de contrat Quanta est régie par les Conditions d’utilisation, par les licences sous lesquelles le logiciel est publié et par tout accord signé avec Quantova Inc, lesquels prévalent sur le présent document en cas de contradiction. Les énoncés relatifs aux lois et aux règlements sont des résumés destinés à l’orientation du lecteur. Les énoncés relatifs aux fonctionnalités futures décrivent des intentions actuelles et sont susceptibles d’évoluer.

Précisions. Toute affirmation du présent document selon laquelle Quantova ou Qstamp est post-quantique, ou ne repose pas sur des signatures classiques, concerne le protocole Quantova, c’est-à-dire les signatures portant sur les comptes, les transactions et les certificats de finalité, l’attestation du code des contrats, ainsi que le consensus. Elle ne s’étend pas à la sécurité de transport extérieure au protocole, telle que les connexions TLS, les certificats et l’échange de clés utilisés par les sites web, l’explorateur, les passerelles RPC et tout autre hébergement web, qui peuvent recourir à des algorithmes classiques. Dans la version 0.1, les vérifications de chaîne effectuées lors de la vérification reposent sur l’intégrité des réponses reçues des points de terminaison RPC, laquelle est protégée en transit par cette sécurité de transport (hypothèse T5 et section 6.7). Tant que les reçus ne comportent pas de preuves de finalité hors ligne, un vérificateur qui exige une assurance post-quantique pour ces vérifications devrait obtenir les données de la chaîne par un canal auquel il fait confiance ou auprès de plusieurs points de terminaison exploités de manière indépendante.

© 2026 Quantova Inc. Qstamp et Quantova sont des marques de Quantova Inc.

14. Références

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.