Forks réguliers avec obligation de resynchroniser à partir de zéro


#1

Bonjour,

Je manque un peu de temps pour tout suivre de manière exhaustive en ce moment… Mais je suis assez surpris parce que j’ai l’impression qu’il y a beaucoup de forks en ce moment, avec des gens qui perdent des données.

Est-ce que quelqu’un pourrait m’expliquer en détail ce qui fait que ça fork ? Ou me pointer vers une doc sur le sujet.

Ensuite, à partir du moment où il y a un fork qui se produit, comment savoir quelle est la branche qui “a raison” ? Comment Duniter essaye-t-il de résoudre ça au départ ?

Et dans les cas où ça reste coincé, comment savoir si quel nœud se synchroniser ?

En se synchronisant sur un nœud avec une “branche avancée”, on perd les données des branches “bloquée”, si je ne me trompe pas ?

J’ai un peu l’impression qu’en cas de fork + synchro sur un nœud “sur la branche principale”, on perd tout l’intérêt d’un système décentralisé… (Puisqu’on se retrouve à faire confiance à un dev qui nous dit “quelle est la vérité”.)

Tout ça est encore un peu flou pour moi, j’aimerais comprendre par quels mécanismes on arrive dans ces situations et comment en sortir de manière la plus sécurisée et décentralisée possible.

Merci d’avance


#2

La raison des forks est au cas par cas et pour des raisons multiples.
Mêmes les développeurs les plus avancés, qui maîtrisent la bête ne savent pas toujours ce qu’il se passe. Il faut comprendre la raison du fork.

L’important est que les donnés en chaîne, respectent le protocole. Il est pas question de suivre la branche décidée par un développeur. Le développeur est censé trouvé le bug du pourquoi des nœuds ne sont pas d’accord sur des données (évènements) et trouvée quelle branche respecte le protocole.


#3

Mais du coup, pour quelqu’un comme moi qui n’est pas développeur (mais technicien tendance sysadmin), comment on peut comprendre les détails derrières un fork ? J’essaye de suivre le salon de discussion et un peu les forums mais ça reste très flou…

Je confirme, ça reste assez flou pour moi. Y aurait-il un exemple décrit quelque part avec le détail ?


#4

Il faut lire les analyses de cgeek :


Ou de moul :


#5

Pour l’instant nous ne disposons pas de beaucoup d’outils pour que tout un chacun puisse participer à la compréhension de la cause d’un fork sans mettre les mains dans le code de Duniter en mode debug et/ou analyse des logs. Mais c’est dans les cartons.

Donc pour l’instant en effet, ce sont plutôt les développeurs qui peuvent donner des indications.


#6

Si tu fait tourner un nœud “desktop”, ou un nœud serveur en y connectant l’interface web, tu peux observer le réseau et la branche la plus majoritaire parmi les nœuds. C’est le seul outil de monitoring multi-nœuds pour l’instant (Sakia étant en sommeil pour l’instant).

Si, dans l’interface, ton nœud est bloqué sur une branche minoritaire, il te faut refaire une synchronisation sur un nœud majoritaire.

Pour les non développeurs, toujours installer et lancer la dernière version de Duniter conseillée sur ce forum par les développeurs et se synchroniser sur la branche conseillée si besoin.

In english : Keep Calm and Resync ! :wink:


#7

Là je propose qu’il y ait un endroit facile à retrouver


#8

Avec le groupe @Blacksmith et @TestSmith, c’est nous qui vous retrouverons… :male_detective:

Ta boîte mail surveiller tu devras,
Car la version conseillée tu recevras…
Maître Ḡedi.