From e7c2c3fd06a03e37cc9e77cc926e264548e08a66 Mon Sep 17 00:00:00 2001 From: NicolasCantu Date: Fri, 16 Feb 2024 13:26:39 +0100 Subject: [PATCH] A RequestPrdMessage is required for sending the raw transaction (doc). We don't want to use the same relay for both messages and sp tx --- doc/PRD-PCD-Specs.md | 44 ++++++++++++++++++++++-------------------- doc/Specs-Datamodel.md | 2 +- 2 files changed, 24 insertions(+), 22 deletions(-) diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index bbd4c4b..2fd690f 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -77,7 +77,7 @@ Les RequestPrd et RequestPcd sont au format JSON. Voir [Specs-Datamodel.md](Spec Les types RequestPrd et RequestPcd sont distingués par l'attribut `request_type` dans le `message`. -En cas de RequestPcd ou RequestPrd en relation via `RequestPcd_reference_hash` ou `RequestPrd_reference_hash` ou `RequestPcd_origin_hash` ou `RequestPrd_origin_hash` ou `item_reference_hash` (dans des RequestPcd), il avoir reçu ou attendre ces documents pour traiter le message. +En cas de RequestPcd ou RequestPrd en relation via `RequestPcd_reference_hash` ou `request_prd_reference_hash` ou `RequestPcd_origin_hash` ou `request_prd_origin_hash` ou `item_reference_hash` (dans des RequestPcd), il avoir reçu ou attendre ces documents pour traiter le message. **Réception du message**: voir [Message-SP-Specs.md](Message-SP-Specs.md). @@ -122,9 +122,9 @@ Les RequestPrd sont de plusieurs types tels que `RequestPrdList`, `RequestPrdMes L'attribut `sig_value` permet de donner une valeur aux signatures. Les valeurs des signatures sont définies par rôles dans les `ItemProcess` avec des valeurs valant pour `OK` ou `KO` pour `none` pour les validations des `RequestPrd`. -Lorsque que la réponse fait référence à un RequestPcd il est précisé dans `RequestPcd_reference_hash`, idem pour les RequestPrd avec `RequestPrd_reference_hash`. +Lorsque que la réponse fait référence à un RequestPcd il est précisé dans `RequestPcd_reference_hash`, idem pour les RequestPrd avec `request_prd_reference_hash`. -Lorsque que la réponse fait suite directement à un RequestPcd il est précisé dans `RequestPcd_origin_hash`, idem pour les RequestPrd avec `RequestPrd_origin_hash`. +Lorsque que la réponse fait suite directement à un RequestPcd il est précisé dans `RequestPcd_origin_hash`, idem pour les RequestPrd avec `request_prd_origin_hash`. Les `RequestPrdResponse` signalent de façon confidentielle : @@ -157,11 +157,12 @@ La création d'un RequestPrd suit plusieurs étapes : 1. **Chargement des clés de chiffrement confidentiel'**: Récupération des clés de chiffrement confidentiel des attributs des items d'un RequestPcd. 2. **Chiffrement du RequestPrd**: Chiffrement du RequestPrd avec la clé `ProcessKey` du `process` concerné. -3. **Création de l'adresse SP**: Création d'une adresse Silent Payment SP pour le paiement des frais de transaction depuis l'adresse signet de l'utilisateur décrit dans un objet `ItemMember` (cf. [Specs-Datamodel.md](Specs-Datamodel.md)) avec les outupts de la transaction Silent Payment SP correspondants au RequestPrd et aux éventuels RequestPcd associés. +3. **Création de l'adresse SP**: (Sauf `RequestPRDKeyBackup`) Création d'une adresse Silent Payment SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du RequestPrd dans la side chain. 4. **Création du message**: Création du `message` contenant le RequestPrd chiffré, la preuve de travail, l'adresse de faucet 5. **Sélection des relais pour le message**: Sélection de 4 relais pour le message selon l'historique des pings et des réponses retournées. -6. **Sélection des noeuds de signet pour la transaction silent Payment (SP)**: Sélection de 4 noeuds de signet pour l'envoi de la transaction Silent Payment SP. -7. **Envoi du message**: Envoi du message aux relais et des transactions aux noeuds de signet. +6. **Sélection des noeuds de signet pour la transaction silent Payment (SP)**: (Sauf `RequestPRDKeyBackup`) Sélection de 4 noeuds de signet pour l'envoi de la transaction Silent Payment SP. +7. **Envoi du message**: Envoi du message aux relais +8. **Envoi de la transaction**: (Sauf `RequestPRDKeyBackup`) envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la transaction Silent Payment SP avec le hash du RequestPrd dans l'attribut `request_prd_reference_hash`. ### 6.4. Réception @@ -170,10 +171,10 @@ La réception d'un RequestPcd suit plusieurs étapes : 1. Traitements communs aux RequestPcd et RequestPrd 2. Recherche des RequestPcd en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` et attente si nécessaire et traitement de ceux ci. 3. Vérification de la conformité des RequestPcd en relation. -4. Recherche des RequestPrd en relation via `RequestPrd_reference_hash` et `RequestPrd_origin_hash` et attente si nécessaire et traitement de ceux ci. +4. Recherche des RequestPrd en relation via `request_prd_reference_hash` et `request_prd_origin_hash` et attente si nécessaire et traitement de ceux ci. 5. Vérification de la conformité des RequestPrd en relation. 6. Recherche de l'`Item` associé via `item_reference_hash` et attente si nécessaire et traitement de celui ci. -7. Déchiffrage des attributs confidentiels notés `_enc_by_shared_secret` depuis la `KeyConfidential` de la transaction silent payment SP correspondante via hash du RequestPrd dans l'output `2` de la transaction. +7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `_enc_by_shared_secret` depuis la `KeyConfidential` de la transaction silent payment SP correspondante via hash du RequestPrd dans l'output `2` de la transaction. 8. Mise à jour du cache pour les traitement des RequestPrd. 9. Traitements spécifiques au type de RequestPrd. @@ -185,20 +186,19 @@ Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de L'envoi d'un `RequestPrdList` suit plusieurs étapes : -1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdList`. -2. Envoi de la transaction Silent Payment SP. +Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdList` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. ### 7.2. Réception La réception d'un `RequestPrdList` suit plusieurs étapes : 1. Traitements des RequestPrd -2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList`. +2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList` et envoie de la transaction Silent Payment SP associée avec 3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné. 4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné. 5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdRResponse` avec : 5.1. le hash du `RequestPcd` envoyé dans l'attribut `RequestPcd_reference_hash` - 5.2. le hash du `RequestPrdList` reçu dans l'attribut `RequestPrd_origin_hash` + 5.2. le hash du `RequestPrdList` reçu dans l'attribut `request_prd_origin_hash` 6. Mise à jour du cache avec les nouveaux `RequestPcd` et `RequestPrdResponse` et `RequestPrdConfirm` envoyés. ## 8. RequestPrdMessage - Envoi de Messages @@ -207,11 +207,13 @@ Le RequestPrdMessage facilite l'envoi de messages sécurisés entre utilisateurs Permet la communication directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties. -Les `RequestPrdMessage` répondent aux `RequestPrdMessage`. +Permet la communication des transactions Silent Payment SP au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain. + +Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi de `raw_transaction_list`. ### 8.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdMessage`. +Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdMessage` incluant l'envoi de la transaction Silent Payment SP via un autre `RequestPrdMessage` pour la publication de la transaction dans la side chain. ### 8.2. Réception @@ -221,9 +223,9 @@ La réception d'un `RequestPrdMessage` suit plusieurs étapes : 2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList`. 3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné. 4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné. -5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdRResponse` avec : +5. Création et envoi à l'émetteur du `RequestPrdList` d'un `RequestPrdResponse` avec : 5.1. le hash du `RequestPcd` envoyé dans l'attribut `RequestPcd_reference_hash` - 5.2. le hash du `RequestPrdList` reçu dans l'attribut `RequestPrd_origin_hash` + 5.2. le hash du `RequestPrdList` reçu dans l'attribut `request_prd_origin_hash` ## 9. RequestPrdUpdate - Mises à Jour de RequestPcd @@ -239,7 +241,7 @@ Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_versi ### 9.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate`. +Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpdate` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. ### 9.2. Réception @@ -255,7 +257,7 @@ Crucial pour les processus qui nécessitent une confirmation explicite de récep ### 10.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm`. +Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. ### 10.2. Réception @@ -271,7 +273,7 @@ Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, pui ### 11.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse`. +Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. ### 11.2. Réception @@ -281,7 +283,7 @@ Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards as ### 12.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse`. +Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdRRequestPrdKeyHelloBakcupesponse` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. ### 12.2. Réception @@ -293,7 +295,7 @@ Important pour les processus d'onboarding de nouveaux membres, de réinitialisat ### 13.1. Création et envoi -Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello`. +Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain. ### 13.2. Réception diff --git a/doc/Specs-Datamodel.md b/doc/Specs-Datamodel.md index f3b3c22..675c989 100644 --- a/doc/Specs-Datamodel.md +++ b/doc/Specs-Datamodel.md @@ -509,7 +509,7 @@ Message provides a general structure for messages, including shared peers and pr | shared_process_list | Vec | | A list of shared processes, assuming `SharedProcess` is a predefined struct. | | faucet_sp_address | ```String``` | | The service provider address for a faucet. | | pow | Pow | | Represents a Proof of Work (PoW) challenge, assuming `Pow` is a predefined struct. | -| raw_transaction_list | ```Vec``` | | Transaction to broadcast | +| raw_transaction_list | ```Vec``` | Yes | Transaction to broadcast | ### 6.4. Pow