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

Récap du réseau Duniter

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

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

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

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

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

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.

Un exemple : L’architecture de Sakia

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

La couche réseau

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

Algorithme de découverte réseau

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

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

Algorithme de mise en cache

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

Historique des transactions

Historique des transactions

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

Couche de vérifications

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 ? ?

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

Questions /réponses

Merci - @inso sur twitter insoleet sur github inso@framasphere.org Sur diaspora