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

This commit is contained in:
NicolasCantu 2024-02-16 13:26:39 +01:00
parent 51976fdb93
commit e7c2c3fd06
2 changed files with 24 additions and 22 deletions

View File

@ -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`. 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). **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`. 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 : 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. 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é. 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 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. 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. 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 et des transactions aux noeuds de signet. 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. <a name='Rception-1'></a>Réception ### 6.4. <a name='Rception-1'></a>Réception
@ -170,10 +171,10 @@ La réception d'un RequestPcd suit plusieurs étapes :
1. Traitements communs aux RequestPcd et RequestPrd 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. 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. 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. 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. 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 `<attribut>_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 `<attribut>_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. 8. Mise à jour du cache pour les traitement des RequestPrd.
9. Traitements spécifiques au type de 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 : L'envoi d'un `RequestPrdList` suit plusieurs étapes :
1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdList`. 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.
2. Envoi de la transaction Silent Payment SP.
### 7.2. <a name='Rception-1'></a>Réception ### 7.2. <a name='Rception-1'></a>Réception
La réception d'un `RequestPrdList` suit plusieurs étapes : La réception d'un `RequestPrdList` suit plusieurs étapes :
1. Traitements des RequestPrd 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é. 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é. 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 `RequestPrdRResponse` avec :
5.1. le hash du `RequestPcd` envoyé dans l'attribut `RequestPcd_reference_hash` 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. 6. Mise à jour du cache avec les nouveaux `RequestPcd` et `RequestPrdResponse` et `RequestPrdConfirm` envoyés.
## 8. <a name='RequestPrdMessage-EnvoideMessages'></a>RequestPrdMessage - Envoi de Messages ## 8. <a name='RequestPrdMessage-EnvoideMessages'></a>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. 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. <a name='Crationetenvoi-1'></a>Création et envoi ### 8.1. <a name='Crationetenvoi-1'></a>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. <a name='Rception-1'></a>Réception ### 8.2. <a name='Rception-1'></a>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`. 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é. 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é. 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.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. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd ## 9. <a name='RequestPrdUpdate-MisesJourdeRequestPcd'></a>RequestPrdUpdate - Mises à Jour de RequestPcd
@ -239,7 +241,7 @@ Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_versi
### 9.1. <a name='Crationetenvoi-1'></a>Création et envoi ### 9.1. <a name='Crationetenvoi-1'></a>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. <a name='Rception-1'></a>Réception ### 9.2. <a name='Rception-1'></a>Réception
@ -255,7 +257,7 @@ Crucial pour les processus qui nécessitent une confirmation explicite de récep
### 10.1. <a name='Crationetenvoi-1'></a>Création et envoi ### 10.1. <a name='Crationetenvoi-1'></a>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. <a name='Rception-1'></a>Réception ### 10.2. <a name='Rception-1'></a>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. <a name='Crationetenvoi-1'></a>Création et envoi ### 11.1. <a name='Crationetenvoi-1'></a>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. <a name='Rception-1'></a>Réception ### 11.2. <a name='Rception-1'></a>Réception
@ -281,7 +283,7 @@ Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards as
### 12.1. <a name='Crationetenvoi-1'></a>Création et envoi ### 12.1. <a name='Crationetenvoi-1'></a>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. <a name='Rception-1'></a>Réception ### 12.2. <a name='Rception-1'></a>Réception
@ -293,7 +295,7 @@ Important pour les processus d'onboarding de nouveaux membres, de réinitialisat
### 13.1. <a name='Crationetenvoi-1'></a>Création et envoi ### 13.1. <a name='Crationetenvoi-1'></a>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. <a name='Rception-1'></a>Réception ### 13.2. <a name='Rception-1'></a>Réception

View File

@ -509,7 +509,7 @@ Message provides a general structure for messages, including shared peers and pr
| shared_process_list | Vec<SharedProcess> | | A list of shared processes, assuming `SharedProcess` is a predefined struct. | | shared_process_list | Vec<SharedProcess> | | A list of shared processes, assuming `SharedProcess` is a predefined struct. |
| faucet_sp_address | ```String``` | | The service provider address for a faucet. | | 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. | | pow | Pow | | Represents a Proof of Work (PoW) challenge, assuming `Pow` is a predefined struct. |
| raw_transaction_list | ```Vec<String>``` | | Transaction to broadcast | | raw_transaction_list | ```Vec<String>``` | Yes | Transaction to broadcast |
### 6.4. <a name='Pow'></a>Pow ### 6.4. <a name='Pow'></a>Pow