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