* 1. [Objectif](#Objectif) * 2. [Portée](#Porte) * 3. [3. Documents de référence](#Documentsderfrence) * 4. [Taille des données](#Tailledesdonnes) * 5. [Preuve de travail](#Preuvedetravail) * 6. [Récupération et choix des relais](#Rcuprationetchoixdesrelais) * 7. [Récupération des UTXO pour les adresses Silent Payment (SP) depuis le faucet des wallets des relais](#RcuprationdesUTXOpourlesadressesSilentPaymentSPdepuislefaucetdeswalletsdesrelais) * 8. [Connexion au réseau de relais via les messages de type `MessageConnect`](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnect) * 9. [Broadcast des messages de type `MessageConnect` vers les relais](#BroadcastdesmessagesdetypeMessageConnectverslesrelais) * 10. [Envoi de PCD sur les relais via les messages de type `Message`](#EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage) * 11. [Envoi de PRD sur les relais via les messages de type `Message`](#EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage) * 12. [Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais) * 13. [Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects) * 14. [Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin) * 15. [Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin) * 16. [Génération des adresses SP](#GnrationdesadressesSP) * 17. [Exemples de Code](#ExemplesdeCode) # Auth - Specs ## 1. Objectif ## 2. Portée ## 3. 3. Documents de référence # Voir [Doc_references.md](Doc_references.md). # 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é. # Structure du stockage en cache des relais Le cache est constitué de 2 parties : 1. `public` : 1.1. Liste des relais partagée avec les relais (aggrée au fil des relais découverts par le partage des listes de relais dans les messages). 2.2. L'historique des pings des relais (timestamp, valeur du ping, relais concerné) 2.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné). 2. `private` : 2.1. Liste des relais non partagés (aggrégée à partir de relais communiqués de façon confidentielle). 2.2. L'historique des pings des relais (timestamp, valeur du ping, relais concerné) 2.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné). Dans chaque partie, les relais sont stockés sous forme d'objets `SharedPeer` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)). Les relais sont ainsi partagés sous forme d'objets `SharedPeer` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)). # Caractéristiques générales des messages de type `Message` et de type `MessageConnect` ## 4. Taille des données ## 5. Preuve de travail ## Partage de la liste de relais ## Parage de la liste de process # Connexion d'un client à sa liste relais via les messages de type `MessageConnect` ## 6. Récupération et choix des relais Afin de pouvoir discuter avec les relais du réseau et faire relayer des `PCD` et des `PRD` sous forme de `Message`, l'utilisateur doit se connecter à un ou plusieurs relais, 4 par défaut. 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 des 4 relais connectés. Ainsi il y a des doubles 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. A 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. 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. Un ping 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). Les relais dits "navigators" ont un nom de domaine et un certificat SSL afin de satisfaires 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 connexions sont en websocket avec ou sans SSL (url commençant par `ws://` ou `wss://`) et les messages sont en JSON. ## 7. Récupération des UTXO pour les adresses Silent Payment (SP) depuis le faucet des wallets des relais Afin d'obtenir les premiers `UTXO` indispensables pour créer les adresses SP, lors de la réception d'un message de type `MessageConnect` ou de type `Message` par un relais, ce relais envoit en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis ces clés privées et transmise via un message de type `MessageConnect` ou de type `Message`). # Traitement des messages de type `MessageConnect` par les relais ## 8. Connexion au réseau de relais via les messages de type `MessageConnect` ## 9. Broadcast des messages de type `MessageConnect` vers les relais # Traitement des messages de type `Message` par les relais ## 10. Envoi de PCD sur les relais via les messages de type `Message` ## 11. Envoi de PRD sur les relais via les messages de type `Message` ## 12. Broadcast des messages de type `Message` vers les relais ## 13. Broadcast des messages de type `Message` vers les clients connectés # Connexion au réseau de nodes de side chain # Connexion au réseau de nodes de layer 1 # Horodatage et ancrage des PRD via les transactions Silent Payment (SP) # Transactions mainnet Bitcoin ## 14. Horodatage et ancrage des blocs de la side chain sur Bitcoin ## 15. Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin ## 16. Génération des adresses SP Le relais partage leur liste de relais au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedPeer`. Afin d'obtenir les premiers `UTXO` indispensables pour créer les adresses SP, l'utilisateur parcourt la liste de relais `SharedPeer` et se connecte à chacun via un `MessageConnect`. Ces relais envoient en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis ces clés privées). Avec ces `UTXO` et les clés de dépense et de scan, on génère 1 `adresse SP` pour le réseau signet et 1 pour le réseau mainnet et chacun pour leurs clés de login et de révocation. Dans l'ordre on génère donc : 1. Adresse `faucet_sp_address` de login du signet. 2. Adresse `faucet_sp_address` de révocation du signet. 3. Adresse `faucet_sp_address` du mainnet. Puis on se connecte aux relais selon (on se connecte à plusieurs relais afin de pallier aux indisponibilités éventuelles ou au manque de jetons éventuel sur le relai) : 1. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de login du signet. 2. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de révocation du signet. 3. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` du mainnet. 4. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de login du signet. 5. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de révocation du signet. 6. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` du mainnet. 7. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de login du signet. 8. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de révocation du signet. 9. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` du mainnet. 10. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de login du signet. 11. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de révocation du signet. 12. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` du mainnet. Puis on génère les adresses SP : 1. Adresse `id_SP` de login du signet depuis `spend_recover` et `scan_recover` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de login du signet. 2. Adresse `id_SP` de révocation du signet depuis `spend_revoke` et `scan_revoke` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de révocation du signet. 3. Adresse `id_SP` du mainnet depuis `spend_mainnet` et `scan_mainnet` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` du mainnet. ## 17. Exemples de Code Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.