17 KiB
-
- 5.1. Relais
- 5.2. Process
- 5.3. Liste des hashs des messages reçus
- 5.4. Liste des sockets ouverts
-
- 6.1. SharedPeerList
- 6.2. SharedProcessList
- 6.3. Taille des données
- 6.4. Preuve de travail
- 6.5. Adresse SP de faucet
-
- 10.1. Protocole de Découverte des Pairs
- 10.2. Protocole de Transmission des Transactions
- 10.3. Protocole de Partage des Blocs
- 10.4. Validation et relais
- 10.5. Gestion des Forks
- 10.6. Connexion au réseau de nœuds de side chain
- 10.7. Connexion au réseau de nœuds de layer 1
- 10.8. Horodatage et ancrage des
RequestPrdvia les transactions Silent Payment (SP)
1. 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.
2. 2. Portée
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.
4. 4. Variable SharedPeerList du SDK (Wasm)
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. 6. Caractéristiques générales des messages de type Message et MessageConnect
5.1. 6.1. SharedPeerList
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.
5.2. 6.2. SharedProcessList
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.3. 6.3. Taille des données
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.
5.4. 6.4. Preuve de travail
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.5. 6.5. Adresse SP de faucet
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é.
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.
6. 7. Traitements par les clients
6.1. 7.1. Connexion d'un client à sa liste de relais via les messages de type MessageConnect
6.1.1. 7.1.1. Récupération et choix des relais
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.
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.
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.
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.
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).
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.
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.1.2. 7.1.2. Envoi du message de type MessageConnect à chaque relais
L'utilisateur parcourt sa liste de relais et envoie un message de type MessageConnect au format JSON (voir 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.2. 7.2. Envoi de RequestPcd sur les relais via les messages de type Message
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.3. 7.3. Envoi de RequestPrd sur les relais via les messages de type Message
Une fois le RequestPrd finalisé, une transaction SP est effectuée incluant plusieurs hashs (voir Silent-Payment-Specs.md) :
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.
6.4. 7.4. Traitement des messages de type Message par les clients
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. 8. Traitements par les relais
7.1. 8.1. Traitement des messages de type MessageConnect par les relais
À 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.
7.2. 8.2. Connexion au réseau de relais via les messages de type MessageConnect par 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.
8. 9. Traitement des messages de type Message par les relais
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.
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.
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.
9.1. 10.1. Protocole de Découverte des Pairs
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.
9.2. 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, etblock.
9.3. 10.3. Protocole de Partage des Blocs
- 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.
9.4. 10.4. Validation et relais
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.
9.5. 10.5. Gestion des Forks
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é.
9.6. 10.6. Connexion au réseau de nœuds de side chain
9.6.1. 10.6.1. Clients
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.
9.6.2. 10.6.2. Relais
Les relais fonctionnent comme des nœuds complets de la side chain, facilitant la communication et la validation des transactions.
9.7. 10.7. Connexion au réseau de nœuds de layer 1
Les relais maintiennent également une connexion au réseau principal (mainnet) pour des opérations d'ancrage et d'horodatage.
9.8. 10.8. Horodatage et ancrage des RequestPrd via les transactions Silent Payment (SP)
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é.
10. 11. Transactions mainnet Bitcoin
10.1. 11.1. Horodatage et ancrage des blocs de la side chain sur 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é.
10.2. 11.2. Remboursement des frais d'horodatage et ancrage
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.
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.
11. Exemples de Code
12. Todo
- Extraits de code illustrant l'utilisation des
RequestPcdetRequestPrddans des scénarios réels. - Diagrammes de séquences