sdk_common/doc/Silent-Payment-Specs.md

• 1. Objectif
• 2. Portée
• 3. Documents de référence
• 4. Fontion
• 5. Structure des outputs
• 6. Envoi de la transaction SP
  • 6.1. Dans un RequestPrdMessage
  • 6.2. Dans un Message du RequestPrdMessage

1. Objectif

2. Portée

3. Documents de référence

Voir _Doc_references.md.

4.  Fontion

La transaction SP à plusieurs objectifs :

1. Permettre l'horodatage de l'empreinte des RequestPrd sur la side chain (RequestPrdKeyMessage sans message confidentiel).
2. Permettre le partage de la keyConfidential pour les RequestPrd afin de déchiffrer les données confidentielles, sur d'autres relais que ceux qui ont reçu le RequestPrd.

La clé KeyConfidential d'unetransaction SP est utilisée pour chiffrer les RequestPrd.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. Specs-Security.md) dans la transaction.

Cette information est parrallèle aux RequestPrd et permet une meilleur sécurité et confidentialité des échanges.

Latransaction SP a aussi une fonction d'horodate et de preuve de publication des RequestPrd donc de la validation des données des RequestPcd.Les outputs de latransaction SP contiennent les empreintes cryptographiques des messages et RequestPrd et des RequestPcd.Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication.

Les RequestPrdConfirm qui sont des accusés automatiques de réception des RequestPrd sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non).

Il y a une transactions SP pour tous les types de RequestPrd.

5.  Structure des outputs

Une fois le RequestPrd finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur un outputs aux index suivants:

0. L'output 0 est toujours un paiment au destinataire
1. L'output 1 c'est toujours l'op_return avec un tableau de hashs en clair selon un tableau de hashs en JSON avec les index suivants : 1.1. Le hash du message de type Message correspondant 1.2. Le hash du RequestPrd 1.3. Le hash du process 1.4. Le hash de la valeur de la signature (attribut sig_value du RequestPrd) 1.5. Le hash de l'item_name de l'Item concerné (le cas échéant) 1.6. Le hash du RequestPrd d'origine associé au RequestPrd (le cas échéant) 1.7. Le hash du RequestPcd d'origine associé au RequestPrd (le cas échéant) 1.8. Le hash du RequestPcd de référence associé au RequestPrd (le cas échéant) 1.9. Le hash d'un Amount de paiement (le cas échéant) 1.10. Le hash d'un Amountde dépôt (le cas échéant) 1.11. Un hash d'un engagement externe ou d'un Number (le cas échéant)

Pour des raison de confidentialité, le Role associé à l'item_name du RequestPrd peut définir (option) un salt pour la génération des hashs dans l'attribut sp_output_salt_enc.

6. Envoi de la transaction SP

Afin d'améliorer la rélisience du broadcast des transactions, la transaction est envoyée à la fois :

1. Dans un RequestPrdMessage à un membre du rôle member du ItemProcess concerné et
2. Dans le Message du RequestPrdMessage sur les relais

6.1. Dans un RequestPrdMessage

Dans l'attribut raw_transaction_list du RequestPrdMessage associé à la transaction SP. La transaction sera broadcastée par les noeuds de signet du membre du Role member du ItemProcess concerné qui a reçu ce message, il devra alors avoir un noeud de signet pour le broadcast.

6.2. Dans un Message du RequestPrdMessage

Dans l'attribut raw_transaction_list du Message associé à la transaction SP. La transaction sera broadcastée par les noeuds de signet des relais.