Questions et réponses sur Qstamp.

Qstamp est une boîte à outils de preuve post-quantique destinée aux agents de superintelligence (SI), qui préserve la confidentialité de chaque enregistrement. SI, abréviation de superintelligence, est le terme que Quantova utilise pour désigner les systèmes communément appelés IA. Son SDK calcule l’empreinte de chaque action et de chaque décision d’un agent sur les propres systèmes de l’entreprise et n’ancre sur le réseau Quantova qu’un engagement cryptographique salé. Les organisations des secteurs bancaire, public, de la santé et de la finance peuvent ainsi démontrer aux juridictions, aux auditeurs et aux régulateurs exactement ce que leurs agents ont fait et à quel moment, sans divulguer les enregistrements eux-mêmes. Ces preuves ne peuvent pas être falsifiées par un ordinateur quantique.

Les enregistrements d’agents reposent aujourd’hui sur des signatures classiques, à savoir ECDSA sur secp256k1 ou P 256, EdDSA sur Ed25519 ou RSA, qui sont toutes cassées par l’algorithme de Shor. Quantova signe les comptes, les transactions, le code des contrats et la finalité avec ML DSA et n’accepte aucune signature classique dans son protocole.

Pour chaque enregistrement, Qstamp calcule une empreinte sur vos propres systèmes, regroupe de nombreuses empreintes en un seul engagement cryptographique de 32 octets et ancre cet engagement au moyen d’un contrat intelligent Quanta sur la machine virtuelle Quantova (QVM).

Chaque enregistrement reçoit ensuite un reçu. Avec l’enregistrement et son reçu, toute personne peut prouver ultérieurement que l’enregistrement existait exactement sous cette forme au plus tard à l’heure de l’ancrage, sans devoir faire confiance à Quantova Inc ni au détenteur de l’enregistrement.

Un reçu valide prouve trois faits.

1. L’enregistrement est identique, octet par octet, à l’enregistrement qui a été horodaté.
2. L’enregistrement existait au plus tard à l’heure du bloc qui l’a ancré.
3. L’ancrage a été signé par un compte indiqué, sous un type d’enregistrement indiqué.

Un reçu ne prouve pas que le contenu est véridique, licite ou approuvé, et il n’identifie aucune personne. Il ne constitue pas un horodatage électronique qualifié au sens d’eIDAS 2, sauf s’il est délivré par un prestataire de services de confiance qualifié certifié.

Non. Un registre public signifie une preuve publique, et non des données publiques. Chacun peut vérifier qu’un enregistrement a existé et n’a pas été modifié, mais personne ne peut le lire.

Les prompts, les entrées et sorties des agents, leur raisonnement, les appels d’outils, les données personnelles, les données de paiement, les fichiers et les poids des modèles ne quittent jamais vos systèmes. L’empreinte de chaque enregistrement est calculée localement en SHA3 256 avec un sel aléatoire neuf de 256 bits, et seul un engagement cryptographique de 32 octets calculé à partir de ces empreintes est publié, accompagné du bloc, de l’heure, du compte signataire, du contrat et du type d’enregistrement.

L’empreinte ne permet pas de reconstituer l’enregistrement, et le sel empêche quiconque de confirmer une hypothèse, même pour un prompt court ou prévisible. Un enregistrement n’est divulgué que lorsque vous choisissez de le produire, par exemple devant un tribunal ou auprès d’un régulateur, accompagné de son reçu.

Très peu. Le SDK s’exécute sur les serveurs qu’une entreprise exploite déjà et ne nécessite ni GPU, ni entraînement de modèle, ni stockage distinct, car les enregistrements ne sont jamais copiés vers Quantova. L’empreinte d’un enregistrement est calculée en SHA3 256 en quelques microsecondes sur un processeur ordinaire et, lors de notre banc d’essai, les empreintes de 65536 enregistrements ont été calculées et combinées en un seul arbre de hachage en moins d’une seconde.

Jusqu’à 1048576 enregistrements partagent une même transaction d’ancrage, et le réseau Quantova finalise les blocs au moyen de signatures de comité en ML DSA 65 plutôt que par preuve de travail, de sorte que l’ancrage ne consomme aucune énergie de minage.

Qstamp est publié sur npm et sur GitHub, sous licence Apache 2.0 ou sous licence MIT. Node 20 ou une version ultérieure est requis.

npm install @quantovainc/qstamp

Pour examiner le code source ou le compiler vous-même, clonez le dépôt.

git clone https://github.com/Quantova/QStamp.git
cd QStamp
npm ci

Code source sur GitHub · Paquet sur npm

1. Créez une clé de signature que vous seul pouvez lire.

openssl rand -hex 32 > signer.key
chmod 600 signer.key

2. Enregistrez le script suivant sous le nom account.js dans le même dossier et exécutez-le avec node account.js. Il affiche l’adresse de votre compte.

const fs = require('fs');
const { Client, core } = require('@quantovainc/qcore');

const seed = Uint8Array.from(Buffer.from(fs.readFileSync('signer.key', 'utf8').trim(), 'hex'));
const client = new Client('https://rpc-testnet.quantova.org', { expectedChainId: 'Q-test-net-1' });
const address = core.address(seed, 0);

client.account(address).then(async (account) => {
  console.log('address  ' + address);
  console.log('balance  ' + account.balance + ' quon');
  if (account.has_key) return console.log('status   registered, ready to stamp');
  if (account.balance === '0') return console.log('status   claim test TQTOV at the faucet');
  const { outcome } = await client.register(seed, 0, '100000');
  console.log('status   registration ' + outcome.verdict);
});

3. Obtenez gratuitement des unités de test TQTOV pour cette adresse auprès du distributeur (faucet) du réseau de test.
4. Exécutez de nouveau node account.js. Une fois les unités reçues, le script inscrit votre compte sur le réseau. L’inscription n’est nécessaire qu’une seule fois par compte.
5. Horodatez un fichier et vérifiez son reçu.

npx qstamp stamp report.pdf --seed-file ./signer.key --index 0 --kind record
npx qstamp verify report.pdf.qstamp.json --file report.pdf

Chaque transaction d’ancrage coûte 0.005 TQTOV sur le réseau de test, quel que soit le nombre de fichiers. Gardez signer.key secret et sauvegardé. Toute personne qui le détient peut signer au nom de votre compte.

Consignez chaque action effectuée par l’agent, puis ancrez les actions par lots.

1. Après chaque appel d’outil ou chaque décision, écrivez l’action au format JSON avec un ordre de clés fixe. Indiquez l’identité de l’agent, l’outil, les condensats des entrées et des sorties, ainsi que l’heure.
2. Calculez l’empreinte de ce JSON et ajoutez-la au lot en cours.
3. À intervalle fixe, par exemple chaque minute, ancrez le lot en une seule transaction avec le type d’enregistrement ai_agent_action. Un lot peut contenir jusqu’à 1048576 actions.
4. Conservez chaque reçu à côté de l’action correspondante dans votre journal. Sauvegardez les lots en attente au moyen de l’option onPending, afin qu’aucun reçu ne soit perdu si le processus s’interrompt.

const qstamp = require('@quantovainc/qstamp');

const batch = [];

function recordAction(action) {
  const bytes = Buffer.from(JSON.stringify(action));
  batch.push({ digest: qstamp.digestBytes(bytes) });
}

async function anchorBatch(seed) {
  if (batch.length === 0) return [];
  const records = batch.splice(0);
  return qstamp.stamp({
    seed,
    index: 0,
    kind: 'ai_agent_action',
    records,
    onPending: (pending) => savePending(pending),
  });
}

La graine est transmise sous la forme d’un Uint8Array de 32 octets et le SDK l’efface après la signature. Les fichiers de modèle et les jeux de données peuvent être horodatés de la même manière avec les types ai_model et ai_dataset.

Le type d’enregistrement est stocké sur la chaîne avec chaque engagement cryptographique, de sorte qu’un vérificateur peut voir quelle catégorie d’enregistrement a été ancrée. Les types nommés sont énumérés ci-dessous. D’autres valeurs sont disponibles pour des schémas privés.

0  record
1  file
2  document
3  software_release
4  ai_model
5  ai_dataset
6  ai_agent_action
7  ai_output
8  wallet_binding
9  financial_record
10 public_record

La plupart des utilisateurs n’ont jamais à déployer de contrat. Le contrat Qstamp ouvert est déjà en service et le SDK l’utilise par défaut. Une institution ne déploie son propre contrat que si elle a besoin d’un émetteur autorisé ou d’une approbation à plusieurs parties.

1. Installez l’extension de portefeuille QMask dans Chrome depuis qmask.io et créez un compte.
2. Obtenez des TQTOV de test pour ce compte auprès du distributeur (faucet) du réseau de test.
3. Ouvrez QIDE sur qdock.io. Aucune autre installation n’est nécessaire. QIDE compile sur son serveur avec le compilateur Quanta attesté et ajoute la signature du compilateur exigée par le réseau.
4. Copiez un modèle, par exemple QStampIssuer.qs, depuis le dépôt des modèles de contrat dans un nouveau fichier de QIDE, puis compilez-le.
5. Connectez QMask, choisissez Deploy et approuvez la transaction dans QMask. QMask affiche les frais maximaux avant votre approbation. Un déploiement sur le réseau de test coûte normalement moins de 1 TQTOV.
6. Notez l’adresse du contrat et communiquez-la à chaque partie qui vérifiera vos reçus.

Les modèles sont des exemples. Un audit de sécurité indépendant réalisé par un tiers est requis avant tout déploiement en production. Les reçus émis par votre propre contrat se vérifient en transmettant son adresse avec l’option trustCustomContract définie sur true.

1. Règlement européen sur l’intelligence artificielle (AI Act). Preuves pour l’obligation de journalisation automatique prévue à l’article 12, les obligations de conservation des journaux et de la documentation prévues aux articles 18, 19 et 26, et l’obligation de marquage des contenus prévue à l’article 50.
2. eIDAS 2. Preuves d’intégrité et d’horodatage pour les enregistrements électroniques. Le statut qualifié exige une délivrance par un prestataire de services de confiance qualifié certifié.
3. SEC Rule 17a 4. Preuves d’intégrité révélant toute altération pour les enregistrements des courtiers-négociants conservés de trois à six ans.
4. RGPD et RGPD britannique. Les enregistrements ne quittent jamais leur propriétaire et seuls des engagements cryptographiques salés sont publiés, ce qui soutient le principe de minimisation des données.
5. NIST AI RMF et ISO IEC 42001. Preuves de traçabilité pour les contrôles de gouvernance SI.
6. Obligations de migration post-quantique. Les preuves sont signées en ML DSA 65 et hachées en SHA3, de sorte qu’elles restent vérifiables même après que les signatures classiques seront devenues falsifiables.

Qstamp fournit des preuves. Chaque organisation reste responsable du respect des autres exigences des lois qui lui sont applicables.

Correspondance réglementaire complète par juridiction

1. Les échéances sont fixées. Les obligations de marquage du règlement européen sur l’intelligence artificielle (AI Act) s’appliquent à partir du 2 décembre 2026 et les obligations relatives au haut risque à partir du 2 décembre 2027. Le California AI Transparency Act s’applique aux fournisseurs à partir du 2 août 2026 et la loi du Colorado sur l’IA à partir du 1er janvier 2027.
2. Les preuves ne peuvent pas être créées après coup. Un enregistrement horodaté aujourd’hui prouve son intégrité à partir d’aujourd’hui. Pour un enregistrement conservé sans ancrage, il sera impossible de démontrer plus tard qu’il n’a pas été modifié.
3. La conservation dure plus longtemps que la cryptographie classique. Les enregistrements réglementés doivent rester vérifiables pendant une durée pouvant atteindre dix ans, ce qui va au-delà des dates auxquelles le NIST retire les signatures classiques (dépréciation en 2030 et interdiction en 2035).
4. L’effort d’intégration est léger. Un agent a besoin d’un seul appel de fonction par lot et d’un emplacement pour stocker ses reçus.

Oui. Qstamp consigne ce qu’un agent a fait, quelles que soient ses capacités. Le même SDK, les mêmes types d’enregistrement et les mêmes reçus s’appliquent aussi bien à un assistant aux capacités limitées qu’aux systèmes autonomes les plus performants.

Les systèmes SI contribuent de plus en plus aux recherches qui améliorent la SI elle-même, avec une intervention humaine moindre à chaque étape. Qstamp inscrit sur la chaîne, au moment où elles se produisent, une empreinte de chaque action, de chaque modification de modèle et de chaque décision, sur un réseau post-quantique depuis son premier bloc, afin que chaque étape puisse ultérieurement être retrouvée et comparée à ce que l’agent était autorisé à faire. Chaque transaction d’ancrage est visible sur QVMScan, l’explorateur de Quantova.

À mesure que les agents gagnent en capacités et agissent avec moins de contrôle humain, des preuves indépendantes de chaque action deviennent plus importantes. Un reçu permet à un opérateur, à un auditeur ou à un régulateur de confirmer ce qui a été enregistré sans devoir faire confiance à l’agent ni à son opérateur.

Non. Les empreintes sont calculées sur vos propres systèmes. La seule valeur publiée pour chaque lot est un engagement cryptographique salé de 32 octets, dont aucun contenu ne peut être déduit.

Un reçu ne contient aucune partie de l’enregistrement, mais il contient le condensat et le sel de l’enregistrement. Traitez les reçus avec le même soin que les enregistrements qu’ils décrivent.

Sur le réseau de test, chaque transaction d’ancrage coûte 0.005 TQTOV quelle que soit la taille du lot, jusqu’à 1048576 enregistrements. Les unités de test TQTOV n’ont aucune valeur monétaire et sont gratuites auprès du distributeur (faucet).

L’utilisation en production se fera sur le réseau principal Quantova, selon son barème de frais publié, dès son lancement.

Non. Les reçus émis sur le réseau de test n’ont aucune valeur probante. Utilisez le réseau de test pour développer et tester votre intégration. L’utilisation en production se fera sur le réseau principal Quantova dès son lancement.

Le vérificateur a besoin de l’enregistrement et de son reçu.

npx qstamp verify receipt.qstamp.json --file record.pdf

Le résultat est valide, invalide ou indéterminé. Indéterminé signifie que le réseau n’a pas pu être consulté. Un résultat indéterminé n’est jamais présenté comme valide. Les quatre premiers contrôles s’exécutent entièrement sur la propre machine du vérificateur. Un vérificateur indépendant peut aussi reconstruire chaque contrôle à partir de la construction publiée sur la page Mathématiques.

Les empreintes et les arbres de hachage utilisent SHA3 avec une sortie de 256 bits, tel que spécifié dans FIPS 202, ce qui offre une sécurité de 128 bits face à la recherche quantique de préimage. Chaque transaction et chaque certificat de finalité du réseau Quantova sont signés en ML DSA 65, tel que spécifié dans FIPS 204.

Écrivez à [email protected]. Pour signaler une vulnérabilité de sécurité, suivez la politique Sécurité et divulgation.