J’essaie de comprendre plus précisément les attaques possibles que peut subir duniter pour prendre le contôle de la blockchain.
Les attaques possible que je recense :
Création de compte membre à la pelle via l’attaquant
Cette attaque n’est normalement pas possible via les contraintes de la toile de confiance. Si une faille dans la création de membre via la toile de confiance, l’attaque est pour moi imparable car ces faux comptes membres vont pouvoir prendre le contrôle de la blockchain même avec une faible puissance de calcul.
L’attaquant a un seul compte membre mais une puissance de calcul illimitée
Dans ce cas, duniter a un facteur d’exclusion (exFact) qui l’empêche de calculer un tiers du temps. Mais il ne faut pas que la puissance minimale de calcul (powMin) soit trop faible car exFact est multiplié à powMin. Dans ce cas l’attaquant ne serai pas exclu
L’attaquant contrôle autour de un tier des noeuds membre calculant (une petite dizaine aujourd’hui) (peut être possible avec une attaque sibylle multiple de la toile?) et a une puissance de calcul illimitée
Dans ce cas, il a toujours un compte membre qui peut calculer et il faut s’en remettre au handicap pour exclure ces membres. Hors j’ai l’impression d’après remuniter de cgeek, que le handicap est très faible. Donc que rien n’empêche à quelques membres de détenir plus de la moitié des bloques courant.
La formule de la difficulté d’un noeud membre calculant :
diff = powMin*exFact + handicap
Voilà pour ma réflexion, merci de me dire si j’ai oublié des attaques possibles et si mon analyse est pas trop erronée…
Alors attention un premier point fondamental a comprendre est que le niveau de difficulté n’est pas une grandeur linéaire mais exponentielle, c’est à dire que la fonction f(diff) = portion des hashs acceptés parmi tout les hashs possibles est exponentielle. Plus précisément a chaque augmentation du niveau de difficulté de 1 on divise par ~ 1.189 la plage de hashs possibles.
Ainsi les handicap, qui paraissent “faibles” sur remuniter sont en fait très forts, on pourrait a la place les exprimer en coefficient de réduction des plages de hashs possibles, en l’on verrait qu’un handicap de 6 correspond a une difficulté multipliée environ par 3, ce n’est qui n’est pas du tout négligeable !
Il faut aussi et surtout que issuersCount ne soit pas trop faible, car la valeur et la durée du facteur d’exclusion en dépendent, pour ce faire il faut s’assurer que tout noeud membre connecté au réseau est au moins 1 bloc dans la fenêtré courante, d’où le fait que l’option éco que tu a dev doit être désactivée ou modulée lorsque le noeud risque de sortir de la fenêtre courante
Merci pour les éclaircissement @elois !
Effectivement, je n’avais pas compris que la difficulté était exponentielle.
Il n’empêche que si on prend le cas actuel (26 issuers) , un attaquant qui arrive à contrôler 5 issuers et qui a un super calculateur à sa disposition, il peut se retrouver à produire plus de 50% des blocs et prendre le contrôle de la blockchain. Car le handicap n’est pas assez élevé pour nous exclure des calculs même si on détient 20% des blocs de la fenêtre courante.
C’est pour ça que je me demande si on est bien à l’abri du 3ème cas d’attaque que je décris ? Est ce qu’il faudrait pas augmenter le handicap pour qu’il devienne exclusif quand un membre détient une trop grande partie des blocs de la fenêtre ?
Pour ta 2ème partie de réponse, je comprends mieux le commentaire de @cgeek sur la MR du mode eco. Effectivement il semble important de passer en mode boost quand un membre n’a plus qu’un bloc dans la fenêtre !
Par contre, je me demandai cette fenêtre change suivant le nombre de noeuds membre calculant ?