diff --git a/doc/Messages-Specs.md b/doc/Messages-Specs.md index d87cbf1..ebf02e1 100644 --- a/doc/Messages-Specs.md +++ b/doc/Messages-Specs.md @@ -1,4 +1,8 @@ - + + * 1. [Objectif](#Objectif) * 2. [Portée](#Porte) * 3. [3. Documents de référence](#Documentsderfrence) @@ -27,7 +31,7 @@ * 9. [Traitement des messages de type `Message` par les relais](#TraitementdesmessagesdetypeMessageparlesrelais) * 9.1. [Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais) * 9.2. [Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects) -* 10. [Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet](#Connexionsauxrseauxdenoeudsdebitcoinderseauxsidechainoumainnet) +* 10. [Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet](#ConnexionsauxrseauxdenoeudsdeBitcoinderseauxsidechainoumainnet) * 10.1. [Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs) * 10.2. [Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions) * 10.3. [Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs) @@ -44,353 +48,165 @@ * 12. [Exemples de Code](#ExemplesdeCode) * 13. [Todo](#Todo) - -# Auth - Specs +## 1. 1. Objectif -## 1. Objectif +L'objectif de ce document est de décrire les spécifications techniques des messages de type `Message` et `MessageConnect` pour le réseau de relais et les clients. -L'objectif de ce document est de décrire les spécifications techniques des messages de type `Message` et de type `MessageConnect` pour le réseau de relais et les clients. +## 2. 2. Portée -## 2. Portée - -Ce document concerne les messages de type `Message` et de type `MessageConnect` pour le réseau de relais et les clients. +Ce document concerne les messages de type `Message` et `MessageConnect` pour le réseau de relais et les clients. ## 3. 3. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -## 4. ## Variable `SharedPeerList` du SDK (Wasm) +## 4. 4. Variable `SharedPeerList` du SDK (Wasm) -La variable `SharedPeerList` du SDK (Wasm) est une liste de relais partagée avec les relais, c'est la première liste disponible, en dur fournie par le relais sur lequel on est connecté. +La variable `SharedPeerList` du SDK (Wasm) est une liste de relais partagée avec les relais, constituant la première liste disponible, fournie en dur par le relais auquel on est connecté. -## 5. Structure du stockage en cache +## 5. 6. Caractéristiques générales des messages de type `Message` et `MessageConnect` -### 5.1. Relais +### 5.1. 6.1. SharedPeerList -Le cache est constitué de 2 parties : +`SharedPeerList` est une liste de relais partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux relais. -1. `public` : - * Liste partagée des relais avec les relais (agrégée au fil des relais découverts par le partage des listes de relais dans les messages). - * L'historique des pings des relais (timestamp, valeur du ping, relais concerné). - * L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné). - * L'historique de message envoyés sans retour d'une transaction Silent Payment (SP). -2. `private` : - * Liste non partagée des relais (agrégée à partir de relais communiqués de façon confidentielle). - * L'historique des pings des relais (timestamp, valeur du ping, relais concerné). - * L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné). - * L'historique de message envoyés sans retour d'une transaction Silent Payment (SP). +### 5.2. 6.2. SharedProcessList -Voir [ClientDataModel.md](ClientDataModel.md). +`SharedProcessList` est une liste de `ItemProcess` partagée entre les relais et les clients, complétée au fur et à mesure de leur découverte de nouveaux `ItemProcess`. -### 5.2. Process +### 5.3. 6.3. Taille des données -Le cache est constitué de 2 parties : +Les objets `SharedPeer` spécifient la taille maximale des données pour les messages de type `Message` et `MessageConnect` dans l'attribut `data_max_size` du sous-attribut `relay`. Les messages excédant cette taille sont rejetés. -1. `public` : - * Liste partagée des `ItemProcess` avec les relais (agrégée au fil des relais découverts par le partage des listes de `ItemProcess` dans les messages). - * Liste partagée des `ItemProcess` complets reçus depuis les mises à jour des parties prenantes. -2. `private` : - * Liste non partagée des `ItemProcess` (agrégée à partir de `ItemProcess` communiqués de façon confidentielle). - * Liste non partagée des `ItemProcess` complets reçus depuis les mises à jour des parties prenantes. +### 5.4. 6.4. Preuve de travail -Voir [ClientDataModel.md](ClientDataModel.md). +Les objets `SharedPeer` définissent les caractéristiques de la preuve de travail pour les messages de type `Message` et `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, `pow_prefix`, `pow_nonce`, `pow_timeout` du sous-attribut `relay`. Les messages ne respectant pas la preuve de travail sont rejetés. -### 5.3. Liste des hashs des messages reçus +### 5.5. 6.5. Adresse SP de faucet -Le cache contient une liste des hashs des messages de type `Message` et de type `MessageConnect` reçus, répartie en plusieurs parties : +L'utilisateur fournit aux relais une adresse SP (Silent Payment) dite de faucet `faucet_sp_address`. Un portefeuille est généré en mémoire pour chaque relais à la réception des fonds, les fonds sont ensuite transférés vers l'adresse SP de l'utilisateur et le portefeuille est supprimé. -* Hashs des objets `Message`. -* Hashs des objets `MessageConnect` (vide pour les clients). -* Hashs de la donnée encryptée dans les objets `Message`. -* Hashs des `RequestPcd` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant (vide pour les relais) et état actuel de la collecte des `RequestPrd` correspondants. -* Hashs des `RequestPrd` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant et l'id de la transaction Silent Payment (SP) correspondante (vide pour les relais). -* Liste des `transaction SP` du faucet. -* Liste des `transaction SP` reçues. +L'utilisateur reçoit en retour une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction inclut un output supplémentaire avec le hash du message de type `MessageConnect` ou `Message` correspondant. -Voir [ClientDataModel.md](ClientDataModel.md). +## 6. 7. Traitements par les clients -### 5.4. Liste des sockets ouverts +### 6.1. 7.1. Connexion d'un client à sa liste de relais via les messages de type `MessageConnect` -Le cache contient une liste des sockets ouverts, répartie en 2 parties : +#### 6.1.1. 7.1.1. Récupération et choix des relais -* SocketClientList: liste des sockets ouverts en tant que clients. -* SocketServerList: liste des sockets ouverts parles clients. +Pour discuter avec les relais du réseau et faire relayer des `RequestPcd` et des `RequestPrd` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, quatre par défaut. -Voir [ClientDataModel.md](ClientDataModel.md). +L'utilisateur envoie un message de type `MessageConnect` à chaque relais pour se connecter. Ensuite, il peut envoyer des `Message` à chacun des quatre relais connectés et recevoir des `Message` de leur part. -## 6. Caractéristiques générales des messages de type `Message` et de type `MessageConnect` +Il y a des doublons de messages pour chaque relais, à la fois envoyés et reçus. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable de manière autonome en rapport à sa propre expérience. L'arbitrage repose sur une réponse devant satisfaire au moins 80% de la même réponse que celle des relais connectés pour le même message. Les valeurs des arbitrages sont stockées dans le cache. -### 6.1. SharedPeerList +Pour se connecter, l'utilisateur récupère leurs caractéristiques depuis la liste de relais partagée `SharedPeerList` du SDK (Wasm) et depuis les listes de relais non partagées `private` et `public` du cache. -`SharedPeerList` est une liste de relais. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de relais. +Un ping (incluant la Preuve de Travail dans le délai) est réalisé sur chaque relais pour vérifier leur disponibilité, et les quatre premiers relais disponibles sont choisis. Les valeurs des pings sont stockées dans le cache pour chaque relais (historique des pings). -### 6.2. SharedProcessList +Les relais "browsers" possèdent un nom de domaine et un certificat SSL pour satisfaire aux exigences de sécurité des navigateurs. Les autres relais, qui n'ont pas de nom spécifique, peuvent ne pas avoir de nom de domaine ni de certificat SSL et sont utilisés pour relayer les messages entre les relais. -`SharedProcessList` est une liste de `ItemProcess`. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de `ItemProcess`. +Les connexions utilisent le protocole WebSocket avec ou sans SSL (URL commençant par `ws://` ou `wss://`), et les messages sont au format JSON. -### 6.3. Taille des données +#### 6.1.2. 7.1.2. Envoi du message de type `MessageConnect` à chaque relais -Les objets `SharedPeer` indiquent la taille maximale des données pour les messages de type `Message` et de type `MessageConnect` dans l'attribut `data_max_size` du sous attribut `relay`. Les messages plus gros que cette taille sont rejetés. +L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` au format JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter. Il partage ainsi sa liste de relais et sa liste de `ItemProcess`. Il n'y a pas de retour attendu pour ce message. -### 6.4. Preuve de travail +### 6.2. 7.2. Envoi de `RequestPcd` sur les relais via les messages de type `Message` -Les objets `SharedPeer` indiquent les caractéristiques de la preuve de travail pour les messages de type `Message` et de type `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, `pow_prefix`, `pow_nonce`, `pow_timeout` du sous attribut `relay`. Les messages ne satisfaisant pas à la preuve de travail sont rejetés. +Après finalisation du `RequestPcd`, celui-ci est chiffré avec la `ProcessKey` du `ItemProcess`. Cette partie chiffrée constitue la valeur de l'attribut `request_enc` du `Message`. L'utilisateur parcourt sa liste de relais et envoie à chacun un message de type `Message` au format JSON pour se connecter, partageant ainsi sa liste de relais et sa liste de `ItemProcess`. -### 6.5. Adresse SP de faucet +### 6.3. 7.3. Envoi de `RequestPrd` sur les relais via les messages de type `Message` -L'utilisateur fournit aux relais une`adresse SP` (SP) dite de faucet `faucet_sp_address`. Un wallet est généré en mémoire pour chaque relais, à la réception des fonds les fonds sont transférés vers l'addresse SP de l'utilisateur et le wallet est supprimé. +Une fois le `RequestPrd` finalisé, une transaction SP est effectuée incluant plusieurs hashs (voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md)) : -L'utilisateur reçoit en retour une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address`, cette transaction contient un output supplémentaire avec le hash du message de type `MessageConnect` ou de type `Message` correspondant. +La clé `KeyConfidential` de cette transaction est utilisée pour chiffrer divers champs. Le `RequestPrd` est ensuite chiffré avec la `ProcessKey` du `ItemProcess`, et cette partie chiffrée devient la valeur de l'attribut `request_enc` du `Message`. L'utilisateur envoie un message de type `Message` au format JSON à chaque relais pour se connecter, partageant ainsi sa liste de relais et sa liste de `ItemProcess`. -## 7. Traitements par les clients +### 6.4. 7.4. Traitement des messages de type `Message` par les clients -### 7.1. Connexion d'un client à sa liste relais via les messages de type `MessageConnect` +Le client reçoit un nouveau message via le socket ouvert avec le relais et effectue divers contrôles, notamment le calcul du hash du message et sa vérification dans le cache. Les listes de relais (`SharedPeerList`) et de `ItemProcess` (`SharedProcessList`) sont mises à jour en conséquence. Le message est ensuite déchiffré avec la `ProcessKey` du `ItemProcess`, et d'autres contrôles sont réalisés. Les données pertinentes sont mises à jour dans le cache. -#### 7.1.1. Récupération et choix des relais +## 7. 8. Traitements par les relais -Afin de pouvoir discuter avec les relais du réseau et faire relayer des `RequestPcd` et des `RequestPrd` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, 4 par défaut. +![RelayMessageReceived](diagrams/RelayMessageReceived.png "RelayMessageReceived") -L'utilisateur enverra un message de type `MessageConnect` à chaque relais pour se connecter. Puis, il pourra envoyer des `Message` à chacun des 4 relais connectés et recevoir des `Message` de chacun d'eux. +### 7.1. 8.1. Traitement des messages de type `MessageConnect` par les relais -Ainsi, il y a des doublons des messages pour chaque relais à la fois envoyés et reçus. Un arbitrage est possible pour confronter les données dans le temps et par origines. Les résultats permettent d'améliorer les listes de membres par un système de réputation calculable par chacun de façon autonome en rapport à sa propre expérience. À ce stade, l'arbitrage repose sur une réponse devant satisfaire au moins 80% de même réponse que des relais connectés pour le même message. Les valeurs des arbitrages sont stockées dans le cache. +![RelayMessageConnectReceived](diagrams/RelayMessageConnectReceived.png "RelayMessageConnectReceived") -Pour s'y connecter, l'utilisateur récupère leurs caractéristiques depuis la liste de relais partagée `SharedPeerList` du SDK (Wasm) et depuis la liste de relais non partagée `private` du cache et depuis la liste de relais non partagée `public` du cache. +À la réception d'un message de type `MessageConnect`, le relais enregistre le socket du client et réalise divers contrôles, y compris la vérification de la preuve de travail et la taille des données. Les listes de relais (`SharedPeerList`) et de `ItemProcess` (`SharedProcessList`) sont mises à jour. En retour, le relais envoie quelques jetons à l'adresse SP de faucet communiquée par le client et met à jour les données dans le cache. -Un ping (PoW incluse dans le délai) est réalisé sur chaque relais pour vérifier leur disponibilité et l'on choisit les 4 premiers relais disponibles. Les valeurs des pings sont stockées dans le cache pour chaque relais (historique des pings). +### 7.2. 8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais -Les relais dits "navigators" ont un nom de domaine et un certificat SSL afin de satisfaire aux exigences de sécurité des navigateurs. Les autres relais n'ont pas de nom spécifique et n'ont pas nécessairement de nom de domaine et de certificat SSL, ils sont utilisés pour relayer les messages entre les relais. +Les relais se connectent à de nouveaux relais en utilisant `MessageConnect`, partageant à leur tour leur liste de relais et de `ItemProcess`. Aucun retour n'est attendu pour ce message. -Les connexions sont en websocket avec ou sans SSL (url commençant par `ws://` ou `wss://`) et les messages sont en JSON. +## 8. 9. Traitement des messages de type `Message` par les relais -#### 7.1.2. Envoi du message de type `MessageConnect` à chaque relais +![RelayMessageMessageReceived](diagrams/RelayMessageMessageReceived.png "RelayMessageMessageReceived") -L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageConnect` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`. +Le relais reçoit un nouveau message de type `Message` du client, effectue les contrôles nécessaires, et met à jour ses listes. En retour, le relais envoie quelques jetons à l'adresse SP de faucet du client. Le message est ensuite relayé aux autres relais et clients connectés, favorisant ainsi sa propagation. -Il n'y a pas de retour attendu pour ce message. - -### 7.2. Envoi de `RequestPcd` sur les relais via les messages de type `Message` - -Une fois le `RequestPcd` finalisé, il est chiffré par la `ProcessKey` du `ItemProcess`. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`. - -L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`. - -### 7.3. Envoi de `RequestPrd` sur les relais via les messages de type `Message` - -Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés (voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md)). : - -La clé `KeyConfidential` de cette transaction est utilisée pour chiffrer les champs suivants : - -* `RequestPcd_keys_role_confidential_list_enc_by_shared_secret` - -Pour les `RequestPrd` de type `RequestPrdResponse` : - -* `payment_method_enc_by_shared_secret` -* `deposit_method_enc_by_shared_secret` -* `commitment_method_enc_by_shared_secret` -* `certif_key_enc_by_shared_secret` -* `device_footprint_enc_by_sp_shared_secret` -* `pre_id_enc_by_sp_shared_secret` -* `shard_enc_by_sp_shared_secret` - -Pour les `RequestPrd` de type `RequestPrdConfirm` : - -* `code_confirm_enc_by_shared_secret` - -Pour les `RequestPrd` de type `RequestPrdList` : - -* `item_member_enc_by_sp_shared_secret` -* `pre_id_enc_by_sp_shared_secret` - -Puis le `RequestPrd` est chiffré par la `ProcessKey` du `ItemProcess`. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`. - -L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de `ItemProcess`. - -### 7.4. Traitement des messages de type `Message` par les clients - -Le client reçoit un nouveau message dans le socket ouvert avec le relais. - -Le client réalise les contrôles suivants : - -* Calcul du hash du message et vérification de la non-existence du hash dans le cache. - -Le client met à jour ses propres listes suivantes : - -* Liste des relais depuis la liste partagée par le relais `SharedPeerList`. -* Liste des `ItemProcess` depuis la liste partagée par le relais `SharedProcessList`. - -Déchiffrement du message avec la `ProcessKey` du `ItemProcess` et contrôles suivants : - -* Calcul du hash du `RequestPcd` ou `RequestPrd` et vérification de la non-existence du hash dans le cache. -* Voir [ RequestPrd- RequestPcd-Specs.md]( RequestPrd- RequestPcd-Specs.md) pour les détails des contrôles. - -Mises à jour des données du cache. - -## 8. Traitements par les relais - -### 8.1. Traitement des messages de type `MessageConnect` par les relais - -Le relais enregistre le socket du client et lui attribue un index dans l'ordre de création des sockets. - -Le relais réalise les contrôles suivants : - -* Calcul du hash du message et vérification de la non-existence du hash dans le cache. -* Vérification de la preuve de travail. -* Vérification de la taille des données. - -Le relais met à jour ses propres listes suivantes : - -* Liste des relais depuis la liste partagée par le client `SharedPeerList`. -* Liste des `ItemProcess` depuis la liste partagée par le client `SharedProcessList`. - -Voir [ClientDataModel.md](ClientDataModel.md). - -Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client. - -Mises à jour des données du cache. - -Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant. - -### 8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais - -Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de `ItemProcess`. - -Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant. - -Il n'y a pas de retour attendu pour ce message. - -## 9. Traitement des messages de type `Message` par les relais - -Le relais reçoit un nouveau message dans le socket ouvert avec le client. - -Le relais réalise les contrôles suivants : - -* Calcul du hash du message et vérification de la non-existence du hash dans le cache. -* Vérification de la preuve de travail. -* Vérification de la taille des données. - -Le relais met à jour ses propres listes suivantes : - -* Liste des relais depuis la liste partagée par le client `SharedPeerList`. -* Liste des `ItemProcess` depuis la liste partagée par le client `SharedProcessList`. - -Voir [ClientDataModel.md](ClientDataModel.md). - -Le relais envoie en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client. - -Mises à jour des données du cache. - -Envoi de la transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant. - -### 9.1. Broadcast des messages de type `Message` vers les relais - -Le relais parcourt la liste de relais mise à jour et se connecte à chacun des nouveaux relais via un `MessageConnect` en partageant à son tour sa liste de relais et sa liste de `ItemProcess`. - -Envoi vers chaque nouveau relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `MessageConnect` correspondant. - -Envoi vers chaque relai d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant. - -Le relais parcourt la liste de relais mise à jour et envoie le `Message` reçu à chaque relai connecté en partageant à son tour sa liste de relais et sa liste de `ItemProcess` (sans modifier la Preuve de Travail mais en contrôlant la taille du message et les caractéristiques de la preuve de travail avant d'envoyer au relai). - -Il n'y a pas de retour attendu pour ce message. - -### 9.2. Broadcast des messages de type `Message` vers les clients connectés - -Le relais parcourt la liste des sockets ouverts et envoie le `Message` reçu à chaque client connecté en partageant à son tour sa liste de relais et sa liste de `ItemProcess`. - -Envoi vers chaque client d'une transaction Silent Payment (SP) contenant des jetons sur l'adresse dite de faucet `faucet_sp_address` avec un output supplémentaire avec le hash du message de type `Message` correspondant. - -Il n'y a pas de retour attendu pour ce message. - -## 10. Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet +## 9. 10. Connexions aux réseaux de noeuds de Bitcoin, de réseaux side chain ou mainnet Pour plus de détails, voir : [Specs-References.md](Specs-References.md). -### 10.1. Protocole de Découverte des Pairs +Bitcoin et les side chains utilisent divers protocoles pour la découverte de pairs, la transmission des transactions, et le partage des blocs, adaptés aux besoins spécifiques de 4NK. -Bitcoin utilise un mécanisme de découverte de pairs pour que les nouveaux nœuds puissent trouver d'autres nœuds du réseau. Cela peut être réalisé via des "DNS seeds" (des serveurs DNS qui retournent une liste d'adresses IP de nœuds Bitcoin actifs) ou via une liste de nœuds connus codée en dur dans le logiciel. +### 9.1. 10.1. Protocole de Découverte des Pairs -* **Gossip Protocol** : Bitcoin utilise un protocole de type "gossip" pour la propagation des transactions. Lorsqu'un nœud reçoit une transaction valide qu'il n'a pas encore vue, il la valide puis la retransmet à tous ses pairs, ce qui permet une propagation rapide et efficace à travers le réseau. +Bitcoin facilite la découverte de nouveaux nœuds via des DNS seeds et une liste de nœuds codée en dur. 4NK utilise la `SharedPeerList` comme équivalent pour faciliter la découverte de relais dans le réseau. -Dans le cas de 4NK, l'équivalent des DNS est la liste de relais partagée `SharedPeerList`. +### 9.2. 10.2. Protocole de Transmission des Transactions -### 10.2. Protocole de Transmission des Transactions +* **Mempool et Transactions Orphelines** : Les transactions sont ajoutées au mempool en attente de confirmation. Les transactions dépendantes d'autres transactions non confirmées sont considérées comme orphelines jusqu'à résolution. +* **Protocole P2P de Bitcoin** : Définit la communication entre nœuds pour échanger informations sur les transactions et blocs, incluant les messages `version`, `verack`, `inv`, `getdata`, `tx`, et `block`. -* **Mempool et Transactions Orphelines** : Lorsqu'un nœud reçoit une nouvelle transaction, il l'ajoute à son pool de transactions en attente (mempool) avant de la transmettre à ses pairs. Si une transaction fait référence à des entrées inexistantes (par exemple, si elle dépend de transactions non confirmées), elle peut être traitée comme orpheline jusqu'à ce que ses dépendances soient résolues. +### 9.3. 10.3. Protocole de Partage des Blocs -Le protocole P2P de Bitcoin définit la manière dont les nœuds communiquent entre eux pour partager les informations sur les transactions et les blocs. Il inclut plusieurs types de messages : +* **Propagation des Blocs** : Les nouveaux blocs sont rapidement transmis à travers le réseau via un mécanisme de propagation. +* **Compact Blocks** : Optimise la transmission des blocs en utilisant les données déjà présentes dans le mempool des nœuds récepteurs. -* **version / verack** : Utilisés lors de l'établissement de la connexion entre deux nœuds pour échanger les informations de version et confirmer la connexion. +### 9.4. 10.4. Validation et relais -* **Protocole inv (inventaire)** : Un nœud annonce de nouvelles transactions à ses pairs en utilisant des messages inv, qui contiennent des identifiants de transaction. Les nœuds qui n'ont pas ces transactions peuvent alors les demander en utilisant des messages getdata. +Les transactions et les blocs sont validés selon les règles de consensus avant d'être relayés aux autres pairs, assurant l'intégrité et la sécurité du réseau. -* **getdata** : Utilisé par un nœud pour demander les données spécifiques (transactions ou blocs) annoncées via un message inv. +### 9.5. 10.5. Gestion des Forks -* **tx** : Utilisé pour transmettre les détails d'une transaction. +Bitcoin gère les bifurcations temporaires de la blockchain, permettant une réorganisation basée sur la chaîne avec le plus de travail cumulé. -* **block** : Utilisé pour transmettre les détails d'un bloc. +### 9.6. 10.6. Connexion au réseau de nœuds de side chain -* **getblocks / getheaders** : Utilisés pour récupérer des blocs ou des en-têtes de blocs depuis un nœud, généralement dans le processus de synchronisation de la blockchain. +#### 9.6.1. 10.6.1. Clients -* **headers** : Utilisé pour transmettre des en-têtes de blocs en réponse à un message getheaders, facilitant la vérification et la synchronisation de la blockchain sans télécharger tous les blocs complets. +Les clients se connectent au réseau de nœuds de side chain pour recevoir les blocs et les transactions, y compris les transactions Silent Payment (SP) liées aux `RequestPrd`. -### 10.3. Protocole de Partage des Blocs +#### 9.6.2. 10.6.2. Relais -* **Propagation des Blocs** : Lorsqu'un nœud mine un nouveau bloc, il le transmet immédiatement à ses pairs. Comme pour les transactions, la propagation utilise un mécanisme similaire au protocole "gossip" pour assurer une distribution rapide du bloc à travers le réseau. +Les relais fonctionnent comme des nœuds complets de la side chain, facilitant la communication et la validation des transactions. -* **Compact Blocks** : Introduit par BIP 152, ce mécanisme permet de transmettre des blocs de manière plus efficace en utilisant les informations déjà disponibles dans le mempool des nœuds récepteurs. Cela réduit la quantité de données nécessaires pour transmettre un nouveau bloc, accélérant ainsi sa propagation. +### 9.7. 10.7. Connexion au réseau de nœuds de layer 1 -* **Protocole inv pour les blocs** : Similaire aux transactions, un nœud utilise des messages inv pour annoncer de nouveaux blocs à ses pairs. Les nœuds qui ne connaissent pas ce bloc peuvent demander le bloc complet en utilisant getdata. +Les relais maintiennent également une connexion au réseau principal (mainnet) pour des opérations d'ancrage et d'horodatage. -* **Transaction Relay Protocol** : Bitcoin Core a implémenté des améliorations telles que le "Transaction Relay Protocol" pour optimiser la manière dont les transactions sont relayées entre les nœuds, réduisant la bande passante nécessaire et améliorant la confidentialité. +### 9.8. 10.8. Horodatage et ancrage des `RequestPrd` via les transactions Silent Payment (SP) -* **Compact Block Relay** : Ce protocole permet une propagation plus efficace des nouveaux blocs en utilisant les informationsque les nœuds ont probablement déjà en leur possession, réduisant ainsi la quantité de données nécessaires à transmettre pour relayer un bloc complet. +Les `RequestPrd` sont ancrés dans la side chain à travers des transactions SP, offrant une preuve immuable de leur existence et de leur intégrité. -Dans le cas de 4NK, les block relay, compact blocks, et les blocs filters permettent de travailler rapidement et côté client directement sur les données des blocs et transactions du réseau. +## 10. 11. Transactions mainnet Bitcoin -### 10.4. Validation et relais +### 10.1. 11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin -* **Validation** : Les nœuds valident les transactions et les blocs selon les règles de consensus de Bitcoin et les règles de filtrage local avant de les relayer à d'autres nœuds. Cela inclut la vérification des signatures, la conformité des structures de données, et d'autres critères spécifiques à Bitcoin. +Les blocs de la side chain sont ancrés sur le mainnet de Bitcoin à intervalles réguliers, fournissant une preuve temporelle et augmentant la sécurité. -* **Relais** : Après validation, les transactions et les blocs sont relayés aux autres pairs, favorisant ainsi la propagation rapide et la redondance des données à travers le réseau. +### 10.2. 11.2. Remboursement des frais d'horodatage et ancrage -### 10.5. Gestion des Forks +Le processus de minage "vert" de 4NK génère les jetons nécessaires pour couvrir les frais d'horodatage et d'ancrage sur le réseau Bitcoin, assurant ainsi la viabilité financière de ces opérations. -Lorsque deux blocs sont minés presque simultanément, cela peut créer une bifurcation temporaire dans la blockchain. Les nœuds choisissent le premier bloc qu'ils reçoivent et continuent à construire dessus, mais ils gardent aussi une trace de la branche alternative. Si la branche alternative devient plus longue (c'est-à-dire qu'elle devient la chaîne avec le plus de travail cumulé), les nœuds basculent sur cette chaîne, réorganisant ainsi leur blockchain locale. +Ces spécifications techniques fournissent une vue d'ensemble de la façon dont 4NK s'intègre avec les réseaux Bitcoin et side chain, utilisant des protocoles éprouvés tout en introduisant de nouvelles méthodes pour améliorer la sécurité, la transparence, et l'efficacité des transactions et des communications au sein du réseau. -### 10.6. Connexion au réseau de nœuds de side chain +## 11. Exemples de Code -#### 10.6.1. Clients - -Les clients se connectent comme un nœud depuis le SDK au réseau de nœuds de side chain via les protocoles p2p de Bitcoin. Ils reçoivent les blocs et les transactions (mempool) de la side chain et scannent les transactions de la side chain pour trouver les transactions Silent Payment (SP) correspondantes aux RequestPrd, puis les `RequestPcd` correspondant aux RequestPrd. - -#### 10.6.2. Relais - -Les relais hébergent un nœud complet de la side chain, connecté aux autres membres de ce réseau. Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement. - -### 10.7. Connexion au réseau de nœuds de layer 1 - -Les relais hébergent un nœud complet du mainnet, connecté aux autres membres de ce réseau. Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement. - -### 10.8. Horodatage et ancrage des `RequestPrd` via les transactions Silent Payment (SP) - -Les `RequestPrd` sont horodatés et ancrés sur la side chain via des transactions Silent Payment (SP) contenant les hashs des messages et des signatures associées ( RequestPrd). Ces transactions sont ajoutées aux blocs, eux-mêmes signés par les nœuds "certificator" de la side chain pour être ajoutés à cette timechain. La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la possession de la clé privée associée). Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement. - -## 11. Transactions mainnet Bitcoin - -### 11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin - -Le temps de référence est en blocs. Tous les hashs de blocs de la side chain sont historisés par lots de 6 * 24 blocs. À toutes les hauteurs de blocs multiples de 144, chaque lot de hashs de blocs est l'objet lui-même d'un hash qui est inscrit dans un output de transaction sur Bitcoin (mainnet). - -### 11.2. Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin - -Le minage "vert" de 4NK permet de produire les jetons nécessaires au remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin. La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la possession de la clé privée associée). - -## 12. Exemples de Code - -## 13. Todo +## 12. Todo * [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels. * [ ] Diagrammes de séquences diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index ba202f7..cda2e41 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -92,17 +92,17 @@ Les `RequestPrd` sont des demandes d'actions ou des réponses à ces demandes, i * `RequestPrdConfirm` : Répond à tous les autres types de `RequestPrd` (à l'exception des `RequestPrdConfirm` eux-mêmes). * `RequestPrdResponse` : Répond à tous les autres types de `RequestPrd` (à l'exception des `RequestPrdConfirm`, `RequestPrdMessage` et `RequestPrdResponse` eux-mêmes). Dans le cas d'une réponse à un `RequestPrdList` ou d'un `RequestPrdUpdate`, le `RequestPrdResponse` doit obligatoirement être accompagné d'un `RequestPcd`. -On fonction des `RequestPrd` les demandes vont d'adresser à tous les membres de l'`ItemProcess`, ou aux gestionnaires du type d'`Item` concerné ou simplement à l'émetteur, selon : +Selon le type de `RequestPrd`, les demandes peuvent s'adresser à tous les membres de l'`ItemProcess`, aux gestionnaires du type d'`Item` concerné ou simplement à l'émetteur, selon : -* `RequestPrdList` : Envoyé aux gestionnaires du type d'`Item` concerné +* `RequestPrdList` : Envoyé aux gestionnaires du type d'`Item` concerné. * `RequestPrdMessage`, avec 2 cas de figure : - * Demande de relais d'une `transaction SP`, dans ce cas, le destinaire du `RequestPrd`assiocié. - * Envoi de message au destinaire du message. -* `RequestPrdUpdate` : Envoyé aux gestionnaires du type d'`Item` concerné -* `RequestPrdConfirm` : Envoyé à l'emetteur du `RequestPrd`assiocié. + * Demande de relais d'une `transaction SP`, dans ce cas, destinée au destinataire du `RequestPrd` associé. + * Envoi de message au destinataire du message. +* `RequestPrdUpdate` : Envoyé aux gestionnaires du type d'`Item` concerné. +* `RequestPrdConfirm` : Envoyé à l'émetteur du `RequestPrd` associé. * `RequestPrdResponse`, avec 2 cas de figure : - * Réponse à un `RequestPrdList`: envoie à l'emetteur du `RequestPrdList` - * Réponse à un `RequestPrdUpdate`: envoue à tous les membres et à l'émetteur du `RequestPrdUpdate` + * Réponse à un `RequestPrdList` : envoyée à l'émetteur du `RequestPrdList`. + * Réponse à un `RequestPrdUpdate` : envoyée à tous les membres et à l'émetteur du `RequestPrdUpdate`. Les traitements des `RequestPrd` varient selon leur type, principalement autour des aspects suivants : @@ -413,7 +413,6 @@ Pour simplifier, les `RequestPrdConfirm` n'ont pas été représentés dans le s ## 15. Todo -[ ] Définition claire de ‘request-type’ [ ] Description détaillée de tous les éléments (attributs) qui composent le ‘request-type’: [ ] Qu’y a-t-il dans le ‘request-type’? [ ] A quoi sert l’attribut X du ‘request-type’? diff --git a/doc/diagrams/.$AES-GCM-256.drawio.bkp b/doc/diagrams/.$AES-GCM-256.drawio.bkp deleted file mode 100644 index 4ceffd7..0000000 --- a/doc/diagrams/.$AES-GCM-256.drawio.bkp +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$KeyGen.drawio.bkp b/doc/diagrams/.$KeyGen.drawio.bkp deleted file mode 100644 index 2a3e3b5..0000000 --- a/doc/diagrams/.$KeyGen.drawio.bkp +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$Login-Wireframes.drawio.bkp b/doc/diagrams/.$Login-Wireframes.drawio.bkp deleted file mode 100644 index 34d1869..0000000 --- a/doc/diagrams/.$Login-Wireframes.drawio.bkp +++ /dev/null @@ -1,1018 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$PBKDF2.drawio.bkp b/doc/diagrams/.$PBKDF2.drawio.bkp deleted file mode 100644 index 3a54a49..0000000 --- a/doc/diagrams/.$PBKDF2.drawio.bkp +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$PCD_PRD_encryption.drawio.bkp b/doc/diagrams/.$PCD_PRD_encryption.drawio.bkp deleted file mode 100644 index da975f8..0000000 --- a/doc/diagrams/.$PCD_PRD_encryption.drawio.bkp +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$RelayMessageConnectReceived.drawio.bkp b/doc/diagrams/.$RelayMessageConnectReceived.drawio.bkp new file mode 100644 index 0000000..ccb3d9b --- /dev/null +++ b/doc/diagrams/.$RelayMessageConnectReceived.drawio.bkp @@ -0,0 +1,34 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/.$RelayMessageReceived.drawio.bkp b/doc/diagrams/.$RelayMessageReceived.drawio.bkp new file mode 100644 index 0000000..449be85 --- /dev/null +++ b/doc/diagrams/.$RelayMessageReceived.drawio.bkp @@ -0,0 +1,175 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/.$RelayMessageReceived.png.bkp b/doc/diagrams/.$RelayMessageReceived.png.bkp new file mode 100644 index 0000000..110a98c Binary files /dev/null and b/doc/diagrams/.$RelayMessageReceived.png.bkp differ diff --git a/doc/diagrams/.$WalletCreate.drawio.bkp b/doc/diagrams/.$WalletCreate.drawio.bkp deleted file mode 100644 index 64569e7..0000000 --- a/doc/diagrams/.$WalletCreate.drawio.bkp +++ /dev/null @@ -1,677 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$WalletOnboard.drawio.bkp b/doc/diagrams/.$WalletOnboard.drawio.bkp deleted file mode 100644 index 6bcd784..0000000 --- a/doc/diagrams/.$WalletOnboard.drawio.bkp +++ /dev/null @@ -1,561 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$WalletRecover.drawio.bkp b/doc/diagrams/.$WalletRecover.drawio.bkp deleted file mode 100644 index 673e99a..0000000 --- a/doc/diagrams/.$WalletRecover.drawio.bkp +++ /dev/null @@ -1,702 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/diagrams/.$WalletRecover.png.bkp b/doc/diagrams/.$WalletRecover.png.bkp deleted file mode 100644 index f414c35..0000000 Binary files a/doc/diagrams/.$WalletRecover.png.bkp and /dev/null differ diff --git a/doc/diagrams/.$relay_message_receive.drawio.bkp b/doc/diagrams/.$relay_message_receive.drawio.bkp new file mode 100644 index 0000000..b42f273 --- /dev/null +++ b/doc/diagrams/.$relay_message_receive.drawio.bkp @@ -0,0 +1,137 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/.$relay_message_received.drawio.bkp b/doc/diagrams/.$relay_message_received.drawio.bkp new file mode 100644 index 0000000..6962d80 --- /dev/null +++ b/doc/diagrams/.$relay_message_received.drawio.bkp @@ -0,0 +1,244 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/RelayMessageConnectReceived.drawio b/doc/diagrams/RelayMessageConnectReceived.drawio new file mode 100644 index 0000000..aeaa533 --- /dev/null +++ b/doc/diagrams/RelayMessageConnectReceived.drawio @@ -0,0 +1,34 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/RelayMessageConnectReceived.png b/doc/diagrams/RelayMessageConnectReceived.png new file mode 100644 index 0000000..928d205 Binary files /dev/null and b/doc/diagrams/RelayMessageConnectReceived.png differ diff --git a/doc/diagrams/RelayMessageMessageReceived.png b/doc/diagrams/RelayMessageMessageReceived.png new file mode 100644 index 0000000..8c95d19 Binary files /dev/null and b/doc/diagrams/RelayMessageMessageReceived.png differ diff --git a/doc/diagrams/RelayMessageReceived.drawio b/doc/diagrams/RelayMessageReceived.drawio new file mode 100644 index 0000000..eb85cec --- /dev/null +++ b/doc/diagrams/RelayMessageReceived.drawio @@ -0,0 +1,175 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/RelayMessageReceived.png b/doc/diagrams/RelayMessageReceived.png new file mode 100644 index 0000000..6dd4313 Binary files /dev/null and b/doc/diagrams/RelayMessageReceived.png differ diff --git a/doc/diagrams/relayMessageMessageReceived.drawio b/doc/diagrams/relayMessageMessageReceived.drawio new file mode 100644 index 0000000..77fd42b --- /dev/null +++ b/doc/diagrams/relayMessageMessageReceived.drawio @@ -0,0 +1,61 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +