Doc update
This commit is contained in:
parent
20bb9817cf
commit
c6816044c3
@ -2,20 +2,46 @@
|
|||||||
* 1. [Objectif](#Objectif)
|
* 1. [Objectif](#Objectif)
|
||||||
* 2. [Portée](#Porte)
|
* 2. [Portée](#Porte)
|
||||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||||
* 4. [Taille des données](#Tailledesdonnes)
|
* 4. [Variable `SharedPeerList` du SDK (Wasm)](#VariableSharedPeerListduSDKWasm)
|
||||||
* 5. [Preuve de travail](#Preuvedetravail)
|
* 5. [Structure du stockage en cache](#Structuredustockageencache)
|
||||||
* 6. [Récupération et choix des relais](#Rcuprationetchoixdesrelais)
|
* 5.1. [Relais](#Relais)
|
||||||
* 7. [Récupération des UTXO pour les adresses Silent Payment (SP) depuis le faucet des wallets des relais](#RcuprationdesUTXOpourlesadressesSilentPaymentSPdepuislefaucetdeswalletsdesrelais)
|
* 5.2. [5. Process](#Process)
|
||||||
* 8. [Connexion au réseau de relais via les messages de type `MessageConnect`](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnect)
|
* 5.3. [Liste des hashs des messages reçus](#Listedeshashsdesmessagesreus)
|
||||||
* 9. [Broadcast des messages de type `MessageConnect` vers les relais](#BroadcastdesmessagesdetypeMessageConnectverslesrelais)
|
* 5.4. [Liste des sockets ouverts](#Listedessocketsouverts)
|
||||||
* 10. [Envoi de PCD sur les relais via les messages de type `Message`](#EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage)
|
* 6. [Caractéristiques générales des messages de type `Message` et de type `MessageConnect`](#CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect)
|
||||||
* 11. [Envoi de PRD sur les relais via les messages de type `Message`](#EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage)
|
* 6.1. [SharedPeerList](#SharedPeerList)
|
||||||
* 12. [Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais)
|
* 6.2. [SharedProcessList](#SharedProcessList)
|
||||||
* 13. [Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects)
|
* 6.3. [Taille des données](#Tailledesdonnes)
|
||||||
* 14. [Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
|
* 6.4. [Preuve de travail](#Preuvedetravail)
|
||||||
* 15. [Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
|
* 6.5. [Adresse SP de faucet](#AdresseSPdefaucet)
|
||||||
* 16. [Génération des adresses SP](#GnrationdesadressesSP)
|
* 7. [Traitments par les clients](#Traitmentsparlesclients)
|
||||||
* 17. [Exemples de Code](#ExemplesdeCode)
|
* 7.1. [Connexion d'un client à sa liste relais via les messages de type `MessageConnect`](#ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect)
|
||||||
|
* 7.1.1. [Récupération et choix des relais](#Rcuprationetchoixdesrelais)
|
||||||
|
* 7.1.2. [Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais)
|
||||||
|
* 7.2. [Envoi de PCD sur les relais via les messages de type `Message`](#EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage)
|
||||||
|
* 7.3. [Envoi de PRD sur les relais via les messages de type `Message`](#EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage)
|
||||||
|
* 7.4. [Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients)
|
||||||
|
* 8. [Traitements par les relais](#Traitementsparlesrelais)
|
||||||
|
* 8.1. [Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais)
|
||||||
|
* 8.2. [Connexion au réseau de relais via les messages de type `MessageConnect` par les relais](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais)
|
||||||
|
* 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.1. [Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs)
|
||||||
|
* 10.2. [Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions)
|
||||||
|
* 10.3. [Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs)
|
||||||
|
* 10.4. [Validation et relais](#Validationetrelais)
|
||||||
|
* 10.5. [Gestion des Forks](#GestiondesForks)
|
||||||
|
* 10.6. [Connexion au réseau de nodes de side chain](#Connexionaurseaudenodesdesidechain)
|
||||||
|
* 10.6.1. [Clients](#Clients)
|
||||||
|
* 10.6.2. [Relais](#Relais-1)
|
||||||
|
* 10.7. [Connexion au réseau de nodes de layer 1](#Connexionaurseaudenodesdelayer1)
|
||||||
|
* 10.8. [Horodatage et ancrage des PRD via les transactions Silent Payment (SP)](#HorodatageetancragedesPRDvialestransactionsSilentPaymentSP)
|
||||||
|
* 11. [Transactions mainnet Bitcoin](#TransactionsmainnetBitcoin)
|
||||||
|
* 11.1. [Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||||
|
* 11.2. [Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||||
|
* 12. [Exemples de Code](#ExemplesdeCode)
|
||||||
|
|
||||||
<!-- vscode-markdown-toc-config
|
<!-- vscode-markdown-toc-config
|
||||||
numbering=true
|
numbering=true
|
||||||
@ -29,46 +55,96 @@
|
|||||||
|
|
||||||
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
|
||||||
|
|
||||||
# Voir [Doc_references.md](Doc_references.md).
|
Voir [Doc_references.md](Doc_references.md).
|
||||||
|
|
||||||
# Variable `SharedPeerList` du SDK (Wasm)
|
## 4. <a name='VariableSharedPeerListduSDKWasm'></a>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, 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
|
## 5. <a name='Structuredustockageencache'></a>Structure du stockage en cache
|
||||||
|
|
||||||
|
### 5.1. <a name='Relais'></a> Relais
|
||||||
|
|
||||||
Le cache est constitué de 2 parties :
|
Le cache est constitué de 2 parties :
|
||||||
|
|
||||||
1. `public` :
|
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).
|
1.1. Liste partagée des relais 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.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.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
|
||||||
|
2.4. L'historique de message envoyés sans retour d'une transaction Silent Payment (SP)
|
||||||
2. `private` :
|
2. `private` :
|
||||||
2.1. Liste des relais non partagés (aggrégée à partir de relais communiqués de façon confidentielle).
|
2.1. Liste non partagée des relais (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.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.3. L'historique de message reçus ne satisfaisant pas à l'arbitrage (timestamp, hash du message, relais concerné).
|
||||||
|
2.4. L'historique de message envoyés sans retour d'une transaction Silent Payment (SP)
|
||||||
|
|
||||||
Dans chaque partie, les relais sont stockés sous forme d'objets `SharedPeer` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
|
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)).
|
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`
|
### 5.2. <a name='Process'></a>5. Process
|
||||||
|
|
||||||
## 4. <a name='Tailledesdonnes'></a>Taille des données
|
Le cache est constitué de 2 parties :
|
||||||
|
|
||||||
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`. Les messages plus gros que cette taille sont rejetés.
|
1. `public` :
|
||||||
|
1.1. Liste partagée des process avec les relais (aggrée au fil des relais découverts par le partage des listes de process dans les messages).
|
||||||
|
1.2. Liste partagée des process complets reçues depuis les mises à jour des parties prenantes
|
||||||
|
2. `private` :
|
||||||
|
2.1. Listenon partagée des process (aggrégée à partir de process communiqués de façon confidentielle).
|
||||||
|
1.2. Liste non partagée des process complets reçues depuis les mises à jour des parties prenantes
|
||||||
|
|
||||||
## 5. <a name='Preuvedetravail'></a>Preuve de travail
|
Dans chaque partie, les process sont stockés sous forme d'objets `SharedProcess` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
|
||||||
|
|
||||||
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`, timestamp. Les messages ne satisfaisant pas à la preuve de travail sont rejetés.
|
Les process sont ainsi partagés sous forme d'objets `SharedProcess` (décris dans [Specs-Datamodel.md](Specs-Datamodel.md)).
|
||||||
|
|
||||||
## Partage de la liste de relais
|
### 5.3. <a name='Listedeshashsdesmessagesreus'></a>Liste des hashs des messages reçus
|
||||||
|
|
||||||
## Parage de la liste de process
|
Le cache contient une liste des hashs des messages de type `Message` et de type `MessageConnect` reçus, répartie en 3 parties :
|
||||||
|
|
||||||
# Connexion d'un client à sa liste relais via les messages de type `MessageConnect`
|
* MessageHashList: Hashs des objets `Message`.
|
||||||
|
* MessageConnectHashList: Hashs des objets `MessageConnect` (vide pour les clients).
|
||||||
|
* MessageDataEncHashList: Hashs de la donnée encryptée dans les objets `Message`.
|
||||||
|
* PCDHashList: Hashs des `PCD` 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 PRD correspondants.
|
||||||
|
* PRDHashList: Hashs des `PRD` 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).
|
||||||
|
* TxFaucetIdList: Liste des transactions classiques du faucet.
|
||||||
|
* TxSpIdList: Liste des transactions silent payment (SP) reçues.
|
||||||
|
|
||||||
## 6. <a name='Rcuprationetchoixdesrelais'></a>Récupération et choix des relais
|
### 5.4. <a name='Listedessocketsouverts'></a>Liste des sockets ouverts
|
||||||
|
|
||||||
|
Le cache contient une liste des sockets ouverts, répartie en 2 parties :
|
||||||
|
|
||||||
|
* SocketClientList : liste des sockets ouverts en tant que clients.
|
||||||
|
* SocketServerList : liste des sockets ouverts par les clients.
|
||||||
|
|
||||||
|
## 6. <a name='CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect'></a>Caractéristiques générales des messages de type `Message` et de type `MessageConnect`
|
||||||
|
|
||||||
|
### 6.1. <a name='SharedPeerList'></a>SharedPeerList
|
||||||
|
|
||||||
|
`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.
|
||||||
|
|
||||||
|
### 6.2. <a name='SharedProcessList'></a>SharedProcessList
|
||||||
|
|
||||||
|
`SharedProcessList` est une liste de process. Les relais et les clients partagent cette liste qu'ils complètent au fur et à mesure de leur découverte de process.
|
||||||
|
|
||||||
|
### 6.3. <a name='Tailledesdonnes'></a>Taille des données
|
||||||
|
|
||||||
|
Les objets `SharedPeer` indiquent la taille maximale des données pour les messages de type `Message` et de type `MessageConnect` dans l'attribut des `data_max_size` du sous attribut `relay`. Les messages plus gros que cette taille sont rejetés.
|
||||||
|
|
||||||
|
### 6.4. <a name='Preuvedetravail'></a>Preuve de travail
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### 6.5. <a name='AdresseSPdefaucet'></a>Adresse SP de faucet
|
||||||
|
|
||||||
|
L'utilisateur fourni aux relais une addresse Silent Payment (SP) dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis la clé privée du client).
|
||||||
|
|
||||||
|
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 suplémentaire avec le hash du message de type `MessageConnect` ou de type `Message` correspondant.
|
||||||
|
|
||||||
|
## 7. <a name='Traitmentsparlesclients'></a>Traitments par les clients
|
||||||
|
|
||||||
|
### 7.1. <a name='ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect'></a>Connexion d'un client à sa liste relais via les messages de type `MessageConnect`
|
||||||
|
|
||||||
|
#### 7.1.1. <a name='Rcuprationetchoixdesrelais'></a>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.
|
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.
|
||||||
|
|
||||||
@ -78,81 +154,266 @@ Ainsi il y a des doubles des messages pour chaque relais à la fois envoyés et
|
|||||||
|
|
||||||
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.
|
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).
|
Un ping (PoW inclue dans le delai) 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 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.
|
Les connexions sont en websocket avec ou sans SSL (url commençant par `ws://` ou `wss://`) et les messages sont en JSON.
|
||||||
|
|
||||||
## 7. <a name='RcuprationdesUTXOpourlesadressesSilentPaymentSPdepuislefaucetdeswalletsdesrelais'></a>Récupération des UTXO pour les adresses Silent Payment (SP) depuis le faucet des wallets des relais
|
#### 7.1.2. <a name='EnvoidumessagedetypeMessageConnectchaquerelais'></a>Envoi du message de type `MessageConnect` à chaque 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`).
|
L'utilisateur parcours 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 process.
|
||||||
|
|
||||||
# Traitement des messages de type `MessageConnect` par les relais
|
Il n'y a pas de retour attendu pour ce message.
|
||||||
|
|
||||||
## 8. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnect'></a>Connexion au réseau de relais via les messages de type `MessageConnect`
|
### 7.2. <a name='EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PCD sur les relais via les messages de type `Message`
|
||||||
|
|
||||||
## 9. <a name='BroadcastdesmessagesdetypeMessageConnectverslesrelais'></a>Broadcast des messages de type `MessageConnect` vers les relais
|
Une fois le `PCD` finalisé, il est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
|
||||||
|
|
||||||
# Traitement des messages de type `Message` par les relais
|
L'utilisateur parcours 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 process.
|
||||||
|
|
||||||
## 10. <a name='EnvoidePCDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PCD sur les relais via les messages de type `Message`
|
### 7.3. <a name='EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PRD sur les relais via les messages de type `Message`
|
||||||
|
|
||||||
## 11. <a name='EnvoidePRDsurlesrelaisvialesmessagesdetypeMessage'></a>Envoi de PRD sur les relais via les messages de type `Message`
|
Une fois le `PRD` finalisé, une transaction SP est réalisée, dans cette transactions plusieurs hashs sont ajoutés sur des outputs aux indexs suivants:
|
||||||
|
|
||||||
## 12. <a name='BroadcastdesmessagesdetypeMessageverslesrelais'></a>Broadcast des messages de type `Message` vers les relais
|
1. Le hash du message de type `Message` correspondant
|
||||||
|
2. Le hash du `PRD`
|
||||||
|
3. Le hash du process
|
||||||
|
4. Le hash de l'`item_name` de l'`Item` concerné
|
||||||
|
5. Le hash de la valeur de la signature (attribut `sig_value` du PRD)
|
||||||
|
6. Le hash du `PRD` d'origne associé au PRD (le cas échéant)
|
||||||
|
7. Le hash du `PCD` d'origine associé au PRD (le cas échéant)
|
||||||
|
8. Le hash du `PCD` de référence associé au PRD (le cas échéant)
|
||||||
|
9. Le hash d'un `Amount` de payment (le cas échéant)
|
||||||
|
10. Le hash d'un `Amount` de deposit (le cas échéant)
|
||||||
|
11. Un hash d'un commitment externe ou d'un `Number` (le cas échéant)
|
||||||
|
|
||||||
## 13. <a name='BroadcastdesmessagesdetypeMessageverslesclientsconnects'></a>Broadcast des messages de type `Message` vers les clients connectés
|
La clé `KeyConfidential` de cette transaction est utilisée pour chiffrer les champs suivants :
|
||||||
|
|
||||||
# Connexion au réseau de nodes de side chain
|
* `pcd_keys_role_confidential_list_enc_by_shared_secret`
|
||||||
|
|
||||||
# Connexion au réseau de nodes de layer 1
|
Pour les PRD de type `PRDResponse` :
|
||||||
|
|
||||||
# Horodatage et ancrage des PRD via les transactions Silent Payment (SP)
|
* `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`
|
||||||
|
* `part_1_enc_hash_enc_by_sp_shared_secret`
|
||||||
|
* `shard_enc_by_sp_shared_secret`
|
||||||
|
|
||||||
# Transactions mainnet Bitcoin
|
Pour les PRD de type `PRDConfirm` :
|
||||||
|
|
||||||
## 14. <a name='HorodatageetancragedesblocsdelasidechainsurBitcoin'></a>Horodatage et ancrage des blocs de la side chain sur Bitcoin
|
* `code_confirm_enc_by_shared_secret`
|
||||||
|
|
||||||
## 15. <a name='RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin'></a>Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin
|
Pour les PRD de type `PRDKeyBackup` :
|
||||||
|
|
||||||
## 16. <a name='GnrationdesadressesSP'></a>Génération des adresses SP
|
* `device_footprint_enc_by_sp_shared_secret`
|
||||||
|
* `part_1_enc_hash_enc_by_sp_shared_secret`
|
||||||
|
* `shard_enc_by_sp_shared_secret`
|
||||||
|
|
||||||
Le relais partage leur liste de relais au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedPeer`.
|
Pour les PRD de type `PRDKeyHello` :
|
||||||
|
|
||||||
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`.
|
* `part_1_enc_hash_enc_by_sp_shared_secret`
|
||||||
|
|
||||||
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).
|
Puis le `PRD` est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
|
||||||
|
|
||||||
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.
|
L'utilisateur parcours 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 process.
|
||||||
|
|
||||||
Dans l'ordre on génère donc :
|
### 7.4. <a name='TraitementdesmessagesdetypeMessageparlesclients'></a>Traitement des messages de type `Message` par les clients
|
||||||
|
|
||||||
1. Adresse `faucet_sp_address` de login du signet.
|
Le client reçoit un nouveau message dans le socket ouvert avec le relais.
|
||||||
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) :
|
Le client réalise les contrôles suivants :
|
||||||
|
|
||||||
1. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de login du signet.
|
* Calcul du hash du message et vérification de la non existance du hash dans le cache.
|
||||||
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 :
|
Le client met à jour ses propres listes suivantes :
|
||||||
|
|
||||||
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.
|
* Liste des relais depuis la liste partagée par le relais `SharedPeerList`.
|
||||||
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.
|
* Liste des process depuis la liste partagée par le relais `SharedProcessList`.
|
||||||
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. <a name='ExemplesdeCode'></a>Exemples de Code
|
Déchiffrement du message avec la `ProcessKey` du process et controles suivants :
|
||||||
|
|
||||||
|
* Calcul du hash du PCD ou PRD et vérification de la non existance du hash dans le cache.
|
||||||
|
* Voir [PRD-PCD-Specs.md](PRD-PCD-Specs.md) pour les détails des contrôles.
|
||||||
|
|
||||||
|
Mises à jours des données du cache.
|
||||||
|
|
||||||
|
## 8. <a name='Traitementsparlesrelais'></a>Traitements par les relais
|
||||||
|
|
||||||
|
### 8.1. <a name='TraitementdesmessagesdetypeMessageConnectparlesrelais'></a>Traitement des messages de type `MessageConnect` par les relais
|
||||||
|
|
||||||
|
Le relais enregistre le socket du client et lui attribut 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 existance 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 process depuis la liste partagée par le client `SharedProcessList`.
|
||||||
|
|
||||||
|
Le relais envoit en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
|
||||||
|
|
||||||
|
Mises à jours 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 suplémentaire avec le hash du message de type `MessageConnect` correspondant.
|
||||||
|
|
||||||
|
### 8.2. <a name='ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais'></a>Connexion au réseau de relais via les messages de type `MessageConnect` par les relais
|
||||||
|
|
||||||
|
Le relais parcoure 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 process.
|
||||||
|
|
||||||
|
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 suplémentaire avec le hash du message de type `MessageConnect` correspondant.
|
||||||
|
|
||||||
|
Il n'y a pas de retour attendu pour ce message.
|
||||||
|
|
||||||
|
## 9. <a name='TraitementdesmessagesdetypeMessageparlesrelais'></a>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 existance 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 process depuis la liste partagée par le client `SharedProcessList`.
|
||||||
|
|
||||||
|
Le relais envoit en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` communiquée par le client.
|
||||||
|
|
||||||
|
Mises à jours 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 suplémentaire avec le hash du message de type `MessageConnect` correspondant.
|
||||||
|
|
||||||
|
### 9.1. <a name='BroadcastdesmessagesdetypeMessageverslesrelais'></a>Broadcast des messages de type `Message` vers les relais
|
||||||
|
|
||||||
|
Le relais parcoure 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 process.
|
||||||
|
|
||||||
|
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 suplé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 suplémentaire avec le hash du message de type `Message` correspondant.
|
||||||
|
|
||||||
|
Le relais parcoure 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 process (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. <a name='BroadcastdesmessagesdetypeMessageverslesclientsconnects'></a>Broadcast des messages de type `Message` vers les clients connectés
|
||||||
|
|
||||||
|
Le relais parcoure 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 process.
|
||||||
|
|
||||||
|
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 suplémentaire avec le hash du message de type `Message` correspondant.
|
||||||
|
|
||||||
|
Il n'y a pas de retour attendu pour ce message.
|
||||||
|
|
||||||
|
## 10. <a name='Connexionsauxrseauxdenoeudsdebitcoinderseauxsidechainoumainnet'></a>Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet
|
||||||
|
|
||||||
|
### 10.1. <a name='ProtocoledeDcouvertedesPairs'></a>Protocole de Découverte des Pairs
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
Dans le cas de 4NK l'équivalent des DNS est la liste de relais partagée `SharedPeerList`.
|
||||||
|
|
||||||
|
### 10.2. <a name='ProtocoledeTransmissiondesTransactions'></a> Protocole de Transmission des Transactions
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
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 :
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
* **getdata**: Utilisé par un nœud pour demander les données spécifiques (transactions ou blocs) annoncées via un message inv.
|
||||||
|
|
||||||
|
* **tx**: Utilisé pour transmettre les détails d'une transaction.
|
||||||
|
|
||||||
|
* **block**: Utilisé pour transmettre les détails d'un bloc.
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
### 10.3. <a name='ProtocoledePartagedesBlocs'></a>Protocole de Partage des Blocs
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
* **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é.
|
||||||
|
|
||||||
|
* **Compact Block Relay**: Ce protocole permet une propagation plus efficace des nouveaux blocs en utilisant les informations que 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.
|
||||||
|
|
||||||
|
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.4. <a name='Validationetrelais'></a>Validation et relais
|
||||||
|
|
||||||
|
* **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.
|
||||||
|
|
||||||
|
* **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.5. <a name='GestiondesForks'></a>Gestion des Forks
|
||||||
|
|
||||||
|
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.
|
||||||
|
Sécurité et Résilience
|
||||||
|
|
||||||
|
Le réseau P2P de Bitcoin est conçu pour être résilient aux attaques et aux pannes. La nature décentralisée du réseau signifie qu'il n'y a pas de point de défaillance unique, et les mécanismes de consensus garantissent que tous les nœuds peuvent s'accorder sur l'état valide de la blockchain, même en présence de nœuds malveillants.
|
||||||
|
|
||||||
|
Ces protocoles et mécanismes permettent à Bitcoin de fonctionner de manière décentralisée, sécurisée et scalable, assurant la transmission fiable et efficace des transactions et des blocs à travers
|
||||||
|
|
||||||
|
### 10.6. <a name='Connexionaurseaudenodesdesidechain'></a>Connexion au réseau de nodes de side chain
|
||||||
|
|
||||||
|
#### 10.6.1. <a name='Clients'></a>Clients
|
||||||
|
|
||||||
|
Les clients se connectent comme un noeud depuis le SDK au réseau de nodes de side chain via les protocoles p2p de Bitcoin.
|
||||||
|
|
||||||
|
Les clients reçoivent les blocs et les transactions (mempool) de la side chain.
|
||||||
|
|
||||||
|
Les clients scannent les transactions de la side chain pour trouver les transactions Silent Payment (SP) correspondantes aux PRD, puis les PCD correspondant aux PRD.
|
||||||
|
|
||||||
|
#### 10.6.2. <a name='Relais-1'></a>Relais
|
||||||
|
|
||||||
|
Les relais hébergent un noeud 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. <a name='Connexionaurseaudenodesdelayer1'></a>Connexion au réseau de nodes de layer 1
|
||||||
|
|
||||||
|
Les relais hébergent un noeud 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. <a name='HorodatageetancragedesPRDvialestransactionsSilentPaymentSP'></a>Horodatage et ancrage des PRD via les transactions Silent Payment (SP)
|
||||||
|
|
||||||
|
Les PRD 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 (PRD).
|
||||||
|
|
||||||
|
Ces transactions sont ajoutées aux blocs, eux mêmes signés par les noeuds "certificator" de la side chain pour être ajoutés à cette timechain.
|
||||||
|
Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
|
||||||
|
|
||||||
|
La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la pocession de la clé privée associée).
|
||||||
|
|
||||||
|
## 11. <a name='TransactionsmainnetBitcoin'></a>Transactions mainnet Bitcoin
|
||||||
|
|
||||||
|
### 11.1. <a name='HorodatageetancragedesblocsdelasidechainsurBitcoin'></a>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.
|
||||||
|
|
||||||
|
Soit à 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. <a name='RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin'></a>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.
|
||||||
|
|
||||||
|
## 12. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||||
|
|
||||||
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
|
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.
|
||||||
|
|||||||
@ -483,15 +483,14 @@ This struct represents an encryption scheme using AES-256-GCM with a 96-bit init
|
|||||||
|
|
||||||
## 5. <a name='Messages'></a>Messages
|
## 5. <a name='Messages'></a>Messages
|
||||||
|
|
||||||
### 5.1. <a name='MessageClient'></a>MessageClient
|
### 5.1. <a name='Message'></a>MessageClient
|
||||||
|
|
||||||
MessageClient encapsulates a client message, including an encrypted request and its hash, essential for secure and verifiable client-server communication.
|
Message encapsulates a client message, including an encrypted request and its hash, essential for secure and verifiable client-server communication.
|
||||||
|
|
||||||
| Attribute Name | Type | Option | Description |
|
| Attribute Name | Type | Option | Description |
|
||||||
|----------------|---------|--------|------------------------------------------------------------------|
|
|----------------|---------|--------|------------------------------------------------------------------|
|
||||||
| message | Message | | Represents a message, assuming `Message` is a predefined struct. |
|
| message | Message | | Represents a message, assuming `Message` is a predefined struct. |
|
||||||
| request_enc | String | | The encrypted request content. |
|
| request_enc | String | | The encrypted request content. |
|
||||||
| request_hash | String | | The hash of the request content. |
|
|
||||||
|
|
||||||
### 5.2. <a name='MessageConnect'></a>MessageConnect
|
### 5.2. <a name='MessageConnect'></a>MessageConnect
|
||||||
|
|
||||||
@ -501,7 +500,7 @@ The MessageConnect struct is designed to handle connection-related messages, fac
|
|||||||
|----------------|---------|--------|------------------------------------------------------------------|
|
|----------------|---------|--------|------------------------------------------------------------------|
|
||||||
| message | Message | | Represents a message, assuming `Message` is a predefined struct. |
|
| message | Message | | Represents a message, assuming `Message` is a predefined struct. |
|
||||||
|
|
||||||
### 5.3. <a name='Message'></a>Message
|
### 5.3. <a name='MessageGeneric'></a>MessageGeneric
|
||||||
|
|
||||||
Message provides a general structure for messages, including shared peers and processes, and details like PoW challenges, supporting diverse communication needs
|
Message provides a general structure for messages, including shared peers and processes, and details like PoW challenges, supporting diverse communication needs
|
||||||
|
|
||||||
@ -551,13 +550,14 @@ SharedPeer specifies a peer within the network, playing a key role in distribute
|
|||||||
Represents a relay in the network, specifying its address and port, data handling capacity, and Proof of Work (PoW) requirements.
|
Represents a relay in the network, specifying its address and port, data handling capacity, and Proof of Work (PoW) requirements.
|
||||||
|
|
||||||
| Attribute Name | Type | Option | Description |
|
| Attribute Name | Type | Option | Description |
|
||||||
|----------------|--------|--------|-------------------------------------------------------------------|
|
|-------------------|--------|--------|-------------------------------------------------------------------|
|
||||||
| address_port | u16 | | The port address of the relay. |
|
| address_port | u16 | | The port address of the relay. |
|
||||||
| data_max_size | usize | | Maximum size of data the relay can handle. |
|
| data_max_size | usize | | Maximum size of data the relay can handle. |
|
||||||
| pow_difficulty | u32 | | The difficulty level for the Proof of Work required by the relay. |
|
| pow_difficulty | u32 | | The difficulty level for the Proof of Work required by the relay. |
|
||||||
| pow_pattern | String | | The pattern used for the Proof of Work. |
|
| pow_pattern | String | | The pattern used for the Proof of Work. |
|
||||||
| pow_prefix | String | | The prefix used for the Proof of Work. |
|
| pow_prefix | String | | The prefix used for the Proof of Work. |
|
||||||
|
| pow_timeout | u32 | | Timeout for pow |
|
||||||
|
| faucet_sp_address | u32 | | Faucet address |
|
||||||
|
|
||||||
|
|
||||||
### 5.7. <a name='L1Node'></a>L1Node
|
### 5.7. <a name='L1Node'></a>L1Node
|
||||||
@ -677,15 +677,16 @@ Number provides a numeric value and its unit, supporting a wide range of quantit
|
|||||||
|
|
||||||
## 7. <a name='Request'></a>Request
|
## 7. <a name='Request'></a>Request
|
||||||
|
|
||||||
Request captures the details of a system request, including its method, URI, and optional body, foundational for handling HTTP-based communications.
|
Defines a general request structure within the system, encapsulating details about the requested item, its type, version, and associated process and document references.
|
||||||
|
|
||||||
| Attribute Name | Type | Option | Description |
|
| Attribute Name | Type | Option | Description |
|
||||||
|----------------|-------------------------|--------|-----------------------------------------------|
|
|---------------------|----------------|--------|-----------------------------------------------------------------------------------------------|
|
||||||
| id | String | | Unique identifier for the request. |
|
| item_name | Option<String> | Yes | Optionally specifies the name of the item being requested. |
|
||||||
| method | String | | HTTP method of the request (e.g., GET, POST). |
|
| request_type | String | | Specifies the type of request. `type` is a reserved keyword in Rust, hence `request_type`. |
|
||||||
| uri | String | | URI of the request. |
|
| version | i64 | | Specifies the version of the item or process being requested. |
|
||||||
| headers | HashMap<String, String> | | Headers included in the request. |
|
| process_hash | String | | The hash of the process associated with the request. |
|
||||||
| body | Option<String> | Yes | Optional body of the request. |
|
| pcd_reference_hash | Option<String> | Yes | Optionally specifies the hash of the Portable Contract Document (PCD) related to the request. |
|
||||||
|
| item_reference_hash | Option<String> | Yes | Optionally specifies the hash of the item related to the request. |
|
||||||
|
|
||||||
## 8. <a name='PCD'></a>PCD
|
## 8. <a name='PCD'></a>PCD
|
||||||
|
|
||||||
@ -760,13 +761,32 @@ The PcdItemEnc struct encapsulates encrypted PCD items, detailing the version, t
|
|||||||
| pcd_item_enc_attribute_role_confidential_list | Vec<PcdItemEncAttributeRoleConfidential> | | List of role-confidential encrypted attributes. |
|
| pcd_item_enc_attribute_role_confidential_list | Vec<PcdItemEncAttributeRoleConfidential> | | List of role-confidential encrypted attributes. |
|
||||||
| pcd_item_enc_attribute_private_list | Vec<PcdItemEncAttributePrivate> | | List of private encrypted attributes. |
|
| pcd_item_enc_attribute_private_list | Vec<PcdItemEncAttributePrivate> | | List of private encrypted attributes. |
|
||||||
|
|
||||||
## 9. <a name='PRD'></a>PRD
|
## RequestPrd
|
||||||
|
|
||||||
|
Encapsulates a detailed request within the system, focusing on the interaction with Portable Request Documents (PRD) and specifying various levels of message confidentiality and intended service provider (SP) communication details.
|
||||||
|
|
||||||
|
| Attribute Name | Type | Option | Description |
|
||||||
|
|------------------------------------------------------|----------------|--------|----------------------------------------------------------------------------------------|
|
||||||
|
| request | Request | | A predefined struct representing the basic request information. |
|
||||||
|
| sig_value | String | | Valeur associée à la signature |
|
||||||
|
| pcd_keys_role_confidential_list_enc_by_shared_secret | String | | Encrypted list of PCD keys for role-confidential data, encrypted with a shared secret. |
|
||||||
|
| message_public | Option<String> | Yes | Optionally specifies a public message associated with the request. |
|
||||||
|
| message_confidential | Option<String> | Yes | Optionally specifies a confidential message associated with the request. |
|
||||||
|
| message_private | Option<String> | Yes | Optionally specifies a private message associated with the request. |
|
||||||
|
| sp_address_to | String | | The service provider address to which the request is directed. |
|
||||||
|
| sp_address_from | String | | The service provider address from which the request originates. |
|
||||||
|
| sp_address_reply | String | | The service provider address for replies to the request. |
|
||||||
|
| timestamp_declared | u64 | | A Unix timestamp indicating when the request was declared. |
|
||||||
|
| role_name_from | String | | The name of the role from which the request originates. |
|
||||||
|
| role_name_to | String | | The name of the role to which the request is directed. |
|
||||||
|
|
||||||
|
### 9. <a name='PRD'></a>RequestPrdResponse
|
||||||
|
|
||||||
RequestPrd and its variations (Confirm, KeyBackup, KeyHello, List, Message, Response, Update) represent different aspects and actions related to Portable Request Documents (PRD), covering everything from confirmation to updates, key management, and messaging, essential for managing and processing PRDs securely and efficiently.
|
RequestPrd and its variations (Confirm, KeyBackup, KeyHello, List, Message, Response, Update) represent different aspects and actions related to Portable Request Documents (PRD), covering everything from confirmation to updates, key management, and messaging, essential for managing and processing PRDs securely and efficiently.
|
||||||
|
|
||||||
| Attribute Name | Type | Option | Description |
|
| Attribute Name | Type | Option | Description |
|
||||||
|------------------------------------------|-----------------------|--------|-----------------------------------------------------------------------------|
|
|------------------------------------------|-----------------------|--------|-----------------------------------------------------------------------------|
|
||||||
| prd | RequestPrd | | Represents a Portable Request Document. |
|
| requestPrd | RequestRD | | Represents a Request. |
|
||||||
| sig_value | String | | The signature value for the response. |
|
| sig_value | String | | The signature value for the response. |
|
||||||
| pcd_origin_hash | Option<String> | Yes | Optional hash of the originating PCD. |
|
| pcd_origin_hash | Option<String> | Yes | Optional hash of the originating PCD. |
|
||||||
| payment_method_enc_by_shared_secret | Option<String> | Yes | Encrypted payment method, encrypted with a shared secret. |
|
| payment_method_enc_by_shared_secret | Option<String> | Yes | Encrypted payment method, encrypted with a shared secret. |
|
||||||
|
|||||||
@ -3,8 +3,9 @@
|
|||||||
* 2. [AES & Quantum resistant](#AESQuantumresistant)
|
* 2. [AES & Quantum resistant](#AESQuantumresistant)
|
||||||
* 3. [Bitcoin Silent Payment](#BitcoinSilentPayment)
|
* 3. [Bitcoin Silent Payment](#BitcoinSilentPayment)
|
||||||
* 4. [Bitcoin wallet](#Bitcoinwallet)
|
* 4. [Bitcoin wallet](#Bitcoinwallet)
|
||||||
* 5. [Data anchoring](#Dataanchoring)
|
* 5. [Bitcoin protocols](#Bitcoinprotocols)
|
||||||
* 6. [Layers](#Layers)
|
* 6. [Data anchoring](#Dataanchoring)
|
||||||
|
* 7. [Layers](#Layers)
|
||||||
|
|
||||||
<!-- vscode-markdown-toc-config
|
<!-- vscode-markdown-toc-config
|
||||||
numbering=true
|
numbering=true
|
||||||
@ -37,12 +38,17 @@ Voir [Doc_references.md](Doc_references.md).
|
|||||||
* <https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md>
|
* <https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md>
|
||||||
* <https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki>
|
* <https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki>
|
||||||
|
|
||||||
## 5. <a name='Dataanchoring'></a>Data anchoring
|
## 5. <a name='Bitcoinprotocols'></a>Bitcoin protocols
|
||||||
|
|
||||||
|
* <https://en.bitcoin.it/wiki/Protocol_specification>
|
||||||
|
* <https://en.bitcoin.it/wiki/Protocol_specification#Inventory_Vectors>
|
||||||
|
|
||||||
|
## 6. <a name='Dataanchoring'></a>Data anchoring
|
||||||
|
|
||||||
* <https://petertodd.org/2016/opentimestamps-announcement#fnref:rewrite>
|
* <https://petertodd.org/2016/opentimestamps-announcement#fnref:rewrite>
|
||||||
* <https://www.lopp.net/bitcoin-information/data-anchor.html>
|
* <https://www.lopp.net/bitcoin-information/data-anchor.html>
|
||||||
|
|
||||||
## 6. <a name='Layers'></a>Layers
|
## 7. <a name='Layers'></a>Layers
|
||||||
|
|
||||||
* <https://blackpaper.rgb.tech/consensus-layer/3.-client-side-validation/3.1.-proof-of-publication>
|
* <https://blackpaper.rgb.tech/consensus-layer/3.-client-side-validation/3.1.-proof-of-publication>
|
||||||
* <https://milan2016.scalingbitcoin.org/files/presentations/D2%20-%20A%20-%20Peter%20Todd.pdf>
|
* <https://milan2016.scalingbitcoin.org/files/presentations/D2%20-%20A%20-%20Peter%20Todd.pdf>
|
||||||
|
|||||||
@ -9,6 +9,8 @@ pub struct Relay {
|
|||||||
pub pow_difficulty: u32,
|
pub pow_difficulty: u32,
|
||||||
pub pow_pattern: String,
|
pub pow_pattern: String,
|
||||||
pub pow_prefix: String,
|
pub pow_prefix: String,
|
||||||
|
pub pow_timeout: u32,
|
||||||
|
pub faucet_address: String,
|
||||||
}
|
}
|
||||||
|
|
||||||
impl Relay {
|
impl Relay {
|
||||||
@ -18,6 +20,8 @@ impl Relay {
|
|||||||
pow_difficulty: u32,
|
pow_difficulty: u32,
|
||||||
pow_pattern: String,
|
pow_pattern: String,
|
||||||
pow_prefix: String,
|
pow_prefix: String,
|
||||||
|
pow_timeout: u32,
|
||||||
|
faucet_address: String,
|
||||||
) -> Self {
|
) -> Self {
|
||||||
Relay {
|
Relay {
|
||||||
address_port,
|
address_port,
|
||||||
@ -25,6 +29,8 @@ impl Relay {
|
|||||||
pow_difficulty,
|
pow_difficulty,
|
||||||
pow_pattern,
|
pow_pattern,
|
||||||
pow_prefix,
|
pow_prefix,
|
||||||
|
pow_timeout,
|
||||||
|
faucet_address,
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
// display_info method
|
// display_info method
|
||||||
@ -35,6 +41,8 @@ impl Relay {
|
|||||||
println!("PoW Difficulty: {}", self.pow_difficulty);
|
println!("PoW Difficulty: {}", self.pow_difficulty);
|
||||||
println!("PoW Pattern: {}", self.pow_pattern);
|
println!("PoW Pattern: {}", self.pow_pattern);
|
||||||
println!("PoW Prefix: {}", self.pow_prefix);
|
println!("PoW Prefix: {}", self.pow_prefix);
|
||||||
|
println!("PoW Timeout: {}", self.pow_timeout);
|
||||||
|
println!("Faucet Address: {}", self.faucet_address);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user