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`.
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. <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
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 `<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.
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. <a name='Rception-1'></a>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. <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.
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
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
@ -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. <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
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
@ -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
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
@ -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
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
@ -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
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
@ -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
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

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. |
| 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<String>``` | | Transaction to broadcast |
| raw_transaction_list | ```Vec<String>``` | Yes | Transaction to broadcast |
### 6.4. <a name='Pow'></a>Pow