QuantovaQstampby Quantova
FR
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub Commencer le développement →
Qstamp / Mathématiques
Construction formelle

Les mathématiques derrière chaque reçu.

Cette page spécifie avec précision la construction Qstamp, énonce la sécurité qu’elle atteint face à des adversaires classiques et quantiques, et explique pourquoi les contrats intelligents Quanta exécutés sur la machine virtuelle Quantova (QVM) sont adaptés à l’ancrage des empreintes des actions d’agents SI.

§1 · Notation
H(x)
SHA3 avec une sortie de 256 bits, tel que spécifié dans FIPS 202
D
condensat de l’enregistrement calculé avec l’algorithme a, où a = 1 pour SHA3 et a = 2 pour SHA2 avec une sortie de 256 bits
s
sel de 32 octets tiré uniformément du générateur du système d’exploitation
‖
concaténation d’octets
n, i
taille du lot et position de la feuille, avec 1 ≤ n ≤ 2^20 et 0 ≤ i < n
G, C, S, k
hachage de genèse, adresse du contrat, adresse du signataire et type d’enregistrement

§2 · Feuille

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

L’entrée a une longueur fixe de 80 octets. L’octet initial et l’étiquette distinguent les feuilles de tout autre hachage du système, et l’identifiant d’algorithme empêche qu’un condensat calculé avec un algorithme soit présenté comme un condensat de l’autre.

§3 · Arbre

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

Il s’agit de la construction de la section 2.1 du RFC 9162. Un chemin d’inclusion pour la feuille i contient au plus ⌈log2 n⌉ hachages frères, soit vingt pour le lot le plus grand. La vérification suit la section 2.1.3.2 du RFC 9162 et rejette tout chemin dont la longueur ne correspond pas à la position et à la taille.

§4 · Engagement cryptographique

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

Une racine RFC 9162 seule ne détermine pas la taille de son arbre, de sorte qu’un même chemin peut être vérifié pour plusieurs tailles. La liaison de n supprime cette ambiguïté. La liaison de G, C et S signifie qu’un engagement cryptographique copié depuis une transaction en attente et ancré par un autre compte, un autre contrat ou un autre réseau échoue à la vérification. La liaison de k fixe le type d’enregistrement déclaré.

§5 · Ancrage sur 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

Le contrat reçoit K sous la forme de deux mots de 128 bits et k sous la forme d’un mot de 64 bits, et les émet inchangés, conjointement avec l’appelant authentifié. Avant l’exécution, la QVM inscrit l’appelant dans la mémoire du contrat à partir de l’émetteur vérifié de la transaction, de sorte que le signataire enregistré ne peut pas être influencé par les données d’appel. L’événement est engagé dans la racine d’événements de l’en-tête de bloc et finalisé par le comité de validateurs.

§6 · Sécurité

Le travail nécessaire pour falsifier un reçu.

Modifier une partie quelconque d’un reçu ancré exige de trouver une seconde préimage de SHA3 ou de casser ML DSA. La recherche quantique générique réduit le travail de recherche de préimage à sa racine carrée, ce qui laisse encore 128 bits de sécurité.

AttaqueCassage requisTravail classiqueTravail quantique
Présenter un contenu différent sous un reçu existantSeconde préimage SHA32^2562^128 par recherche de Grover
Modifier la position, la taille, le type ou le signataireSeconde préimage SHA3 sur l’engagement cryptographique2^2562^128
L’horodateur ancre un même condensat pour deux documentsCollision SHA32^1282^85 dans le modèle BHT avec une grande mémoire quantique, environ 2^128 selon des modèles de coût réalistes
Falsifier le signataire d’une transaction d’ancrageContrefaçon ML DSA 65Catégorie de sécurité 3 du NISTCatégorie de sécurité 3 du NIST
Falsifier la finalité d’un blocContrefaçon ML DSA 65 visant le comitéCatégorie de sécurité 3 du NISTCatégorie de sécurité 3 du NIST
Déduire le contenu à partir de la chaîneInverser un engagement cryptographique saléRecherche dans un espace de sels de 2^2562^128
§7 · Pourquoi les contrats Quanta conviennent aux empreintes d’agents

Propriétés de la couche d’exécution.

Paternité authentifiée

L’appelant d’un point d’entrée Quanta est le signataire vérifié de la transaction. Un agent, ou le service qui agit pour son compte, est lié à chaque engagement cryptographique qu’il ancre, sans logique de signature supplémentaire dans le contrat.

Ordres signés pour l’autorité déléguée

La QVM vérifie les signatures ML DSA à l’intérieur d’un contrat au moyen de son instruction VERIFY_ML sous le contexte QVM/contract/v1. Les agents peuvent porter des ordres signés par un émetteur, et un relais peut les soumettre sans acquérir d’autorité. Chaque ordre porte un nonce conservé par le contrat, de sorte qu’il ne peut pas être rejoué.

Code attesté

Un contrat n’est admis que si l’identifiant SHA3 de son conteneur porte une signature ML DSA 65 du compilateur Quanta attesté sous le contexte QUANTOVA/QVM/PROVENANCE/v1. Les examinateurs peuvent recompiler le code source publié et comparer le conteneur octet par octet.

Coût prévisible

L’exécution fait l’objet d’un comptage de consommation. Les frais d’un appel s’élèvent à 500 quon pour chaque tranche de 1210 unités de consommation, arrondis à l’unité supérieure, la réserve non utilisée étant remboursée. Un horodatage coûte le même prix qu’il porte un enregistrement ou 1048576, de sorte que le coût par action d’agent décroît proportionnellement à 1 sur n.

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

§8 · Hypothèses énoncées clairement

La construction suppose la résistance aux collisions et aux secondes préimages de SHA3 et de SHA2, l’infalsifiabilité de ML DSA 65 et une majorité honnête au sein du comité de validateurs. Dans la version 0.1, la transaction d’ancrage, l’événement et le bloc sont confirmés au moyen de l’interface RPC du réseau. Une prochaine version intégrera dans chaque reçu l’en-tête de bloc, le certificat de finalité et la preuve d’inclusion de l’événement, ce qui supprimera toute dépendance à un point d’accès. L’horodatage du bloc est fixé par le validateur proposant, en secondes entières, et n’est accepté que s’il concorde, à 15 secondes près, avec les horloges du comité.