* 1. [Objectif](#Objectif) * 2. [Portée](#Porte) * 3. [Documents de référence](#Documentsderfrence) * 4. [Fonction](#Fonction) * 5. [Structure des outputs](#Structuredesoutputs) * 6. [Envoi de la transaction SP](#EnvoidelatransactionSP) * 6.1. [Dans un `RequestPrdMessage`](#DansunRequestPrdMessage) * 6.2. [Dans un `Message` du `RequestPrdMessage`](#DansunMessageduRequestPrdMessage) ## 1. Objectif ## 2. Portée ## 3. Documents de référence Voir [_Doc_references.md](_Doc_references.md). ## 4.  Fonction 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'une`transaction SP` est utilisée pour chiffrer les `RequestPrd`.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction. Cette information est parrallèle aux `RequestPrd` et permet une meilleur sécurité et confidentialité des échanges. La`transaction 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 la`transaction 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 `Amount`de 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.