L’enjeu est ce que j’appelle la synchronisation, ou comment faire avancer de façon synchrone un système réparti.
À cet enjeu il convient de poser certaines hypothèses, pour Duniter j’ai choisi :
- faible connectivité : on suppose que les nœuds disposent d’un faible débit de données, et d’une connexion instable (tend à être établie par intermittence)
- les membres du réseau ne sont pas tous disponibles pour l’écriture
- tout membre n’est pas forcément honnête, et peut aussi faire des erreurs (bugs logiciels, erreur de configuration, …)
À ces 3 hypothèses j’ai ajouté, de façon moins impactante :
- fréquence relativement élevée (1h d’attente = trop lent)
- capacité de traitement limitée : on suppose que le traitement d’une seule donnée décisionnelle (donnée à vocation de synchronisation) prend un temps non-négligeable
De là, certains algorithmes conviennent, d’autres moyennement, d’autres encore pas du tout.
Citons en exemples :
-
La PoW, fonctionne très bien dans ce contexte car :
- faible connectivité OK : 1 seule trame réseau
- membres pas tous disponibles OK : il suffit d’un seul membre (à l’exclusion près)
- membre malhonnête/buggué OK : tant qu’il reste des membres honnêtes/conformes
- fréquence OK : 5’
- capacité de traitement : 1 seul message (le bloc)
- faible connectivité OK : 1 seule trame réseau
-
Algorand qui se rapproche de ce que tu évoques @pparent76, mais :
- dont la crypto sous-jacente est très récente et peu éprouvée
- suppose une connectivité élevée en cas de divergence sévère
- dont la crypto sous-jacente est très récente et peu éprouvée
-
Ma proposition initiale, basée sur FBA :
- suppose une connectivité élevée
- membre malhonnête/buggué : comment gérer les multiples avis ?
- capacité de traitement limitée : potentiellement de nombreux échanges
- suppose une connectivité élevée
Je t’invite à lire ces deux sujets sur Algorand et FBA, tu y trouveras pas mal d’informations sur le cheminement de Duniter.