4nk/sdk_common
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
sdk_common/doc/Messages-SP-Specs.md

10 KiB
Raw Blame History

# Auth - Specs

1. Objectif

2. Portée

3. 3. Documents de référence

Voir 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).

Les relais sont ainsi partagés sous forme d'objets SharedPeer (décris dans 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 desMessage à 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.