Construire un système de transactions post-quantiques : guide complet du développeur

Les transactions en crypto-monnaie constituent l’épine dorsale des réseaux blockchain. La transition vers la cryptographie post-quantique nécessite de repenser la structure, la sérialisation et la validation des transactions. Ce guide couvre la mise en œuvre complète des transactions quantiques résistantes telles qu'utilisées dans le Portefeuille résistant aux quantiques SynX.

Présentation de l'architecture des transactions

Structure d'entrée de transaction

Chaque entrée fait référence à une sortie précédente non dépensée et prouve l'autorisation de dépenser :

Structure de sortie de transaction

Les résultats définissent où vont les fonds, en utilisant les adresses de brûleur tournantes dérivées par transaction :

Le modèle de confidentialité à deux niveaux

Avant d’aller plus loin, soyez précis sur ce que ce format de transaction fait et ne cache pas. SynX est transparent par défaut, ombre à la demande.

A transparent transaction is fully visible on the block explorer — amount, sender, recipient — exactly like Bitcoin. A shadow transaction is Kyber-768 encrypted (NIST FIPS 203) and routed through a rotating burner address; the explorer shows it as “Private”.

Pour une divulgation sélective, SynX émet un clé de vue éphémère: scoped to a single transaction, alive for thirty minutes, revealing the montant seulement, never the graph. Contrast Zcash, whose view keys are permanent and transferable: SynX issues expiring capabilities, not permanent identity grants.

Ce que fait SynX pas mettre en œuvre, et ce sur quoi vous ne devriez pas construire : des preuves sans connaissance, des signatures en anneau, RingCT, des engagements de Pedersen, des preuves de plage ou toute couche de mélange. Les brûlures sont l'exception délibérée au masquage : elles sont publiques et vérifiables par toute personne sur la page Pyre Altar de l'explorateur, prouvant qu'une brûlure s'est produite sans révéler qui l'a provoquée.

Structure complète de la transaction

Générateur de transactions

Le Portefeuille résistant aux quantiques SynX fournit un constructeur de haut niveau pour construire des transactions :

Validation des transactions

Les nœuds valident les transactions entrantes avant relais et inclusion :

Comparaison de la taille des transactions

Foire aux questions

Quelle est l’ampleur des transactions post-quantiques ?

Un minimum Portefeuille résistant aux quantiques SynX transaction with one input and one output is approximately 9-10KB due to SPHINCS+-SHAKE-128s signatures (7,856 bytes). Multi-input transactions scale linearly. Signatures are pseudorandom hash outputs, so compression does not meaningfully reduce wire size.

En quoi les transactions post-quantiques diffèrent-elles de Bitcoin ?

Les principales différences structurelles sont des signatures plus grandes (7 856 octets contre ~72 octets), des adresses de graveur rotatives dérivées de nouvelles pour chaque sortie et un texte chiffré Kyber-768 en option sur les sorties de niveau fantôme. La validation des transactions utilise la vérification de signature SPHINCS+ au lieu de ECDSA. Notez que SynX n’a aucun frais de gaz – il n’y a pas de marché de frais à ajuster, et donc pas de métadonnées de frais permettant aux sociétés d’analyse de chaîne d’empreintes digitales des utilisateurs.

Les montants des transactions sont-ils masqués sur SynX ?

Not on the transparent tier — they appear on the block explorer in the clear, like Bitcoin. SynX implements no confidential-transaction layer, no Pedersen commitments, and no range proofs. Amount privacy comes from using the shadow tier, where the explorer returns "Private" for shadow balances and transaction lists. Any implementation guide claiming otherwise is describing a different chain.

Comment mettre en œuvre la divulgation sélective ?

Through the ephemeral view key. It is scoped to one transaction and expires after thirty minutes. Verification requires the transaction hash and the view key together, and returns the amount only. Do not design any system that assumes the key can be stored, re-presented later, or delegated onward; that is the Zcash model, and it is precisely what SynX refuses to build.