91 lines
4.8 KiB
Markdown
91 lines
4.8 KiB
Markdown
<!-- vscode-markdown-toc -->
|
||
* 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 `PrdMessage`](#DansunPrdMessage)
|
||
* 6.2. [Dans un `Message` du `PrdMessage`](#DansunMessageduPrdMessage)
|
||
|
||
<!-- vscode-markdown-toc-config
|
||
numbering=true
|
||
autoSave=true
|
||
/vscode-markdown-toc-config -->
|
||
<!-- /vscode-markdown-toc -->
|
||
## 1. <a name='Objectif'></a>Objectif
|
||
|
||
## 2. <a name='Porte'></a>Portée
|
||
|
||
## 3. <a name='Documentsderfrence'></a>Documents de référence
|
||
|
||
Voir [_Doc_references.md](_Doc_references.md).
|
||
|
||
## 4. <a name='Fonction'></a> Fonction
|
||
|
||
La transaction SP à plusieurs objectifs :
|
||
|
||
1. Permettre l'horodatage de l'empreinte des `Prd` sur la side chain (`PrdKeyMessage` sans message confidentiel).
|
||
2. Permettre le partage de la `keyConfidential` pour les `Prd` afin de déchiffrer les données confidentielles, sur d'autres relais que ceux qui ont reçu le `Prd`.
|
||
|
||
La clé `KeyConfidential` d'une`transaction SP` est utilisée pour chiffrer les `Prd`.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 `Prd` 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 `Prd` donc de la validation des données des `Pcd`.Les outputs de la`transaction SP` contiennent les empreintes cryptographiques des `messages` et `Prd` et des `Pcd`.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 `PrdConfirm` qui sont des accusés automatiques de réception des `Prd` sont aussi associés à une transaction Silent Payments 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 `Prd`.
|
||
|
||
## 5. <a name='Structuredesoutputs'></a> Structure des outputs
|
||
|
||
Une fois le `Prd` 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 `Prd`
|
||
1.3. Le hash du process
|
||
1.4. Le hash de la valeur de la signature (attribut `sig_value` du Prd)
|
||
1.5. Le hash de l'`item_name` de l'`Item` concerné (le cas échéant)
|
||
1.6. Le hash du `Prd` d'origine associé au `Prd` (le cas échéant)
|
||
1.7. Le hash du `Pcd` d'origine associé au `Prd` (le cas échéant)
|
||
1.8. Le hash du `Pcd` de référence associé au `Prd` (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 `Prd` peut définir (option) un salt pour la génération des hashs dans l'attribut `sp_output_salt_enc`.
|
||
|
||
## 6. <a name='EnvoidelatransactionSP'></a>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 `PrdMessage` à un membre du rôle `member` du `ItemProcess` concerné et
|
||
2. Dans le `Message` du `PrdMessage` sur les relais
|
||
|
||
### 6.1. <a name='DansunPrdMessage'></a>Dans un `PrdMessage`
|
||
|
||
Dans l'attribut `raw_transaction_list` du `PrdMessage` 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. <a name='DansunMessageduPrdMessage'></a>Dans un `Message` du `PrdMessage`
|
||
|
||
Dans l'attribut `raw_transaction_list` du `Message` associé à la transaction SP.
|
||
La transaction sera broadcastée par les noeuds de signet des relais.
|
||
|
||
## En réception les transactions silent Payments SP sont relayées par les relais en temps réel
|
||
|
||
Le relais récupère les transactions depuis l'interface ZMQ du noeud Bitcoin : https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md.
|
||
Puis il ajoute le tweak data de la transaction Silent Payments, puis il envoie la transaction à tous les connectés.
|
||
|
||
Puis le relais relaient les transactions dans le format suivant :
|
||
|
||
* **raw_tx**: La transaction en hexadécimal
|
||
* **pubkey**: La clé publique du membre qui a envoyé la transaction
|
||
|
||
Le même procédé existe pour les blocs :
|
||
|
||
* **raw_block**: Le bloc en hexadécimal
|