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

Ce qui circule, où, et ce qui ne sort jamais de vos systèmes.

Chaque produit de la famille Qstamp suit les trois mêmes flux. Un enregistrement est scellé au sein des systèmes de son propriétaire, un engagement cryptographique salé est ancré sur le réseau Quantova, et toute partie peut ensuite vérifier l’enregistrement par rapport à son reçu. Cette page retrace chaque flux étape par étape et indique précisément quelles données franchissent quelle limite.

Live flow

The three flows in motion.

Each step lights in turn as a record moves through it. Steps inside your systems never send content out. Only the anchor reaches the Quantova network, and only chain facts are public on QVMScan.

Live flowQstamp, from your application to the explorer
  1. Your systemsYour applicationCreates a record, a decision, a model or a document
  2. Your systemsQstamp SDKSHA3 256 fingerprint bound to a fresh random salt
  3. Your systemsBatch treeUp to 1,048,576 records in one RFC 9162 tree
  4. Quantova networkQstamp contractCommitment anchored in a transaction signed with ML DSA 65
  5. Quantova networkFinalityValidator committee finalises the block in about 0.2 seconds
  6. PublicQVMScanAnchor public, record content private
  7. PublicAny verifierProves the record existed unchanged at that time
Inside your systemsQuantova networkPublic and verifiable
Limites

Trois zones, et les données autorisées dans chacune.

La règle de conception de la famille est que le contenu des enregistrements ne sort jamais de la zone de son propriétaire. Seuls des engagements cryptographiques de longueur fixe franchissent la frontière vers le réseau, et seuls les faits inscrits sur la chaîne sont publics.

Zone 1

Au sein de vos systèmes

  • L’enregistrement et ses documents
  • Clés de signature et sels
  • Données personnelles et commerciales
  • Enveloppes signées et reçus
Zone 2

Envoyé au réseau

  • Un engagement cryptographique salé de 32 octets par lot
  • Le type d’enregistrement, par exemple QTax
  • Une transaction signée avec ML DSA 65
  • Rien qui puisse être inversé pour retrouver le contenu
Zone 3

Public sur QVMScan

  • L’engagement cryptographique et l’adresse du signataire
  • Le bloc, son horodatage et sa finalité
  • Le type d’enregistrement et la taille du lot
  • Aucun enregistrement, document ni identité
Flux 1

Scellement d’un enregistrement, au sein de vos systèmes.

Le scellement a lieu là où l’enregistrement est créé, sans qu’un accès au réseau soit nécessaire.

  1. 01Capture

    L’application crée l’enregistrement au moment où l’événement se produit, par exemple une action d’un agent, une déclaration ou un paiement.

  2. 02Codage canonique

    L’enregistrement est codé dans une forme binaire fixe, de sorte que le même enregistrement produit toujours les mêmes octets et qu’aucun champ ne peut être réinterprété.

  3. 03Signature

    L’enregistrement est signé avec ML DSA sous une chaîne de contexte propre au produit, à l’aide d’une clé détenue uniquement par son propriétaire.

  4. 04Empreinte

    Une empreinte SHA3 256 est calculée sur l’enregistrement codé et sa signature, avec une étiquette de domaine propre au produit.

  5. 05Feuille salée

    L’empreinte est combinée à un sel aléatoire nouvellement généré, de sorte que rien de ce qui est publié ne puisse servir à confirmer une hypothèse sur l’enregistrement.

  6. 06Arbre du lot

    Les feuilles sont regroupées dans un arbre de Merkle conformément à la RFC 9162, de sorte qu’un seul engagement cryptographique puisse couvrir des milliers d’enregistrements.

Flux 2

Ancrage d’un engagement cryptographique sur le réseau Quantova.

L’ancrage fixe l’engagement cryptographique dans le temps. Il peut s’exécuter selon un calendrier, par l’intermédiaire d’une passerelle contrôlée, depuis un seul compte approvisionné.

  1. 01Engagement

    La racine de l’arbre du lot est liée au réseau, au contrat, au signataire, au type d’enregistrement et à la taille du lot.

  2. 02Transaction

    L’engagement cryptographique est envoyé au contrat officiel de Qstamp dans une transaction signée avec ML DSA 65.

  3. 03Finalité

    Un comité de validateurs signant avec ML DSA 65 finalise le bloc, généralement en 0,2 seconde environ.

  4. 04Événement

    Le contrat émet un événement portant le signataire, l’engagement cryptographique et le type d’enregistrement, visible sur QVMScan.

  5. 05Reçu

    Chaque enregistrement reçoit son propre reçu, avec son chemin d’inclusion, son sel et la transaction, stocké avec l’enregistrement.

  6. 06Récupération

    Si la connexion échoue après l’envoi, un horodatage en attente est conservé et l’ancrage est achevé ultérieurement, de sorte qu’aucun enregistrement n’est ancré deux fois.

Flux 3

Vérification d’un enregistrement, par quiconque, à tout moment.

La vérification nécessite l’enregistrement, son enveloppe, son reçu et la clé publique du signataire. Elle ne nécessite ni le logiciel de Quantova ni les systèmes du producteur.

  1. 01Signature

    Le vérificateur contrôle la signature ML DSA par rapport à la clé publique indiquée dans l’enregistrement et par rapport aux clés de confiance qu’il attend.

  2. 02Liens

    Lorsque l’enregistrement dépend d’enregistrements antérieurs, chaque enregistrement lié est vérifié pour s’assurer qu’il s’agit exactement de celui indiqué et qu’il est valablement signé.

  3. 03Règles

    Les règles propres au produit sont appliquées, telles que la séparation des tâches, les totaux cumulés, l’ordre chronologique et les limites du délai d’ancrage.

  4. 04Inclusion

    La feuille est recalculée et son chemin est vérifié jusqu’à la racine engagée.

  5. 05Chaîne

    Le vérificateur confirme sur le réseau que la transaction est finale et que le contrat a émis l’engagement cryptographique.

  6. 06Résultat

    Le résultat est valide, non valide ou indéterminé, avec la liste de toutes les vérifications effectuées. L’absence de preuve ne produit jamais un résultat valide.

Par cas d’usage

Les mêmes flux, appliqués à des enregistrements réels.

Cas d’usageEnregistrement scelléLié àCe qu’un vérificateur peut prouver
Agents d’IAChaque appel d’outil, changement de modèle et décisionL’entrée de journal précédente et le mandat de l’agentL’agent a agi dans les limites de son mandat et aucune action n’a été supprimée
Paiements d’agentsChaque intention de paiement et son reçuLe mandat et ses limites de dépenseLes paiements sont restés dans les limites autorisées
FiscalitéDéclarations, factures, avis d’imposition et remboursementsLa déclaration, l’avis d’imposition et les remboursements antérieursAucun remboursement ne dépasse le montant dû et aucun enregistrement n’a été antidaté
Marchés publicsEngagements cryptographiques des offres, notations et attributionsL’avis de marché et les notations signéesAucune offre n’a été ajoutée ou remplacée après la date limite
ÉlectionsProcès-verbaux des bureaux de vote et opérations de dépouillementAgents enregistrés et logicielsLe résultat déclaré correspond aux procès-verbaux certifiés
Contenu d’IAContenu, modèles et jeux de donnéesLes éléments constitutifs et le propriétaire du modèleL’origine et l’historique du contenu sont conformes à ce qui est déclaré
Clés

Garde des clés dans chaque flux.

Générées localement

Les clés sont générées à partir de la source aléatoire sécurisée du système propre de l’opérateur et ne sont jamais transmises à Quantova.

Détenues par rôle

Des clés distinctes sont détenues pour des rôles distincts, de sorte qu’une même personne ou un même système ne puisse créer et approuver le même enregistrement.

Effacées après usage

Les SDK effacent le matériel de clés de la mémoire après chaque opération, et les fichiers de clés en ligne de commande doivent être lisibles uniquement par leur propriétaire.