La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Architecture de clients Duniter

Présentations similaires


Présentation au sujet: "Architecture de clients Duniter"— Transcription de la présentation:

1 Architecture de clients Duniter
Présentation des problématiques clients et présentation d’un exemple d’architecture (Sakia)

2 Récap du réseau Duniter

3 Blockchain recap #A1 #A2 #A3 #A4 A A B A B A B 200 200 230 120 B C C C
Certification A->B Certification B->A Joiner A Joiner B Identity A Identity B Joiner C Certification B->C Certification C->B Identity C UD 200 Certification A->C TX 50 : B→C TX 30 : B→A #A1 #A2 #A3 #A4 A A B A B A B 200 200 230 120 B C C C 200 250

4 Récap du réseau Duniter
Node Chaque noeud connait une partie du réseau, mais pas nécessairement la totalité Node Les noeuds ne peuvent pas se faire confiance : Les noeuds peuvent avoir des bugs Les noeuds peuvent tenter de tricher → Ils ne peuvent faire confiance qu’à eux meme ! Node Node Node

5 Récap du réseau Duniter
Node Chaque noeud possède - sa propre vue relative du réseau - sa propre vue relative de la blockchain Chain B Node Chain A Le problème des clients : - Comment avoir une vue correcte du réseau ? - A quel noeud faire confiance ? - Comment accéder à ces données suffisament rapidement ? Node Chain A Node Chain B Node Chain B

6 Récap du multibranches
Un exemple : un fork apparait car deux noeuds ont émit un Blog valide (#A3 et #B3) dans un intervalle de temps trop court. Blockchain A #A1 #A2 #A3 #A4 #B3 #B4 #B5 Blockchain B

7 Récap du multibranches
Blockchain A #A1 #A2 #A3 #A4 Blockchain B #B3 #B4 #B5 #B6

8 Récap du multibranches
Blockchain A #A1 #A2 #A3 #A4 Blockchain B, forking from A #B3 #B4 #B5 #B6 #B7 Blockchain B a 30 minutes d’avance sur la A. Les noeuds sur la blockchain A passe à la blockchain B. Les données des blocks #A3 et #A4 sont peut-etre “perdues”, et doivent alors etre réintégrées dans la blockchain B.

9 Un exemple : L’architecture de Sakia

10 Architecture générale
Account Core Models/View Data display Animations User actions Identities Handles and caches informations about identities Wallet History Handles and caches wallet transfers and UD history Network Data Access Layer Cache, distributed requests Network Layer Nodes discovery, endpoints handling Communities

11 La couche réseau

12 Couche réseau Network explorer Handles the nodes exploration
Decides which one is synced Computes the fork window Nodes Unique for a node pubkey Multiple endpoints (but only one used) Check the state of its ucoin node Explores the network locally to the ucoin node

13 Algorithme de découverte réseau

14 Rule n°4 Latest timestamp
Quel noeud requeter ? On ne peut se connecter à des noeuds “au hasard” Ils retourneraient des données incohérentes entre eux L’état de la blockchain est représenté par le hash du block courant du noeud. Rule n°1 By block occurence Rule n°2 Highest Number of last issuers Rule n°3 Highest PoW Rule n°4 Latest timestamp

15 Couche d’accès aux données réseau
BMA Data Access Handles request to Basic Merkle API Caches requests Distribute requests to knew synced nodes Broadcasts POST requests to knew nodes Handles network errors (timeouts, disconnections...) Other API Other API

16 Algorithme de mise en cache

17 Les rollbacks dans le cache
Un rollback est détecté : passage en mode “picking” Quand on requete un block : on le récupère depuis le réseau on le compare a celui qu’on avait dans le cache si le hash est le meme, le block n’a pas changé dans cette chain (1) Si le hash est différent, on remplace le block mis en cache (2) (1) (2) #A1 #A2 #A3 #A4 #A5 #A6 Les blocks de A sont remplacés par ceux de B #B5 #B6 #B7

18 Historique des transactions

19 Historique des transactions

20 Rollback des transactions
Rollback detecte : activation du mode “picking” : Pour chaque transaction, de la plus vieille a la plus récente : - on regarde le block correspondant a la transaction - si le hash a change, on verifie l’etat de chaque transaction present dans ce block #A1 #A2 #A3 #A4 #A5 #A6 - Tx1 est presente, on la garde - Tx2 n’est plus presente, on la remet en etat ‘invalidée’ Tx0 Tx1 Tx2 #B5 #B6 #B7 Tx1 Tx2 Après le rollback, on rafraichit les transactions en partant du point de fork

21 Couche de vérifications

22 Requetage de noeuds sans confiance
Du point de vue des clients, on ne doit pas faire une confiance aveugle dans les noeuds : - Les noeuds peuvent avoir des bugs - Les noeuds peuvent essayer de tricher ? ?

23 Requetage de noeuds sans confiance
Vérifications de base, sur chaque donnees : - Vérification des hash - Vérification des signatures - Vérification du format des réponses Pour choisir à quel noeud faire confiance : - Mode SPV : Requetage de noeuds jusqu’à ce que 10 noeuds répondent la meme information

24 Questions /réponses

25 Merci - @inso sur twitter insoleet sur github
Sur diaspora


Télécharger ppt "Architecture de clients Duniter"

Présentations similaires


Annonces Google