Probleme de synchronisation


#1

Bonjour,

J’essaye de me synchroniser sur le noeud duniter.org, j’ai bien le download qui se fait a 100%, mais après le applying reste a 0%

dans les logs j’ai ca :

2016-11-28T09:24:54+01:00 - info: Getting chunck #190/231 from 47500 to 47749 on peer cgeek.fr:9330
2016-11-28T09:24:59+01:00 - info: GOT chunck #190/231 from 47500 to 47749 on peer cgeek.fr:9330
2016-11-28T09:24:59+01:00 - error: Inner hash of block#47534 from %s does not match
2016-11-28T09:24:59+01:00 - warn: Chunk #190 DOES NOT CHAIN CORRECTLY from cgeek.fr:9330

j’ai essayé d’effacer le repertoire duniter_default mais toujours pareil


#2

Il bloque vraiment sur ce chunk #190, les autres sont bons, mais celui bloque


#3

Je confirme, j’ai voulu faire rejoindre mon noeud sur la branche principale (car beaucoup de difficulté a le faire automatiquement)

Et je tombe sur ce même problème de synchro. du coup mon noeud n’est plus dispo :confused:


#4

Je vais regarder cela aujourd’hui.

edit : donc la tranche #190 est incorrecte sur le réseau, j’essaye d’en retrouver une sauvegarde et la rendre disponible.


#5

idem pour moi


#6

Vous pouvez réessayer avec la version corrective 0.50.4.

En réalité toutes les tranches de la blockchain sont correctes, mais elles n’étaient pas restituées dans un état correct provoquant alors l’échec de la synchronisation.


#7

Marche au top avec la 0.50.4 :slight_smile:
merci @cgeek !


#8

Excellent Tortue et gege53, je vous vois synchronisés dans Sakia. Merci pour votre réactivité :thumbsup:


#9

Bon ca remarche, mais du coup, comme j’ai effacer le repertoire default, j’ai perdu l’association à mon compte…

C’est bon tout remarche comme il faut, j’ai un peu du mal avec ces histoires de secret key, password et cie, faut vraiment que je le liste le TRM


#10

La TRM ne parleras pas des histoires de secret key, password etc ! Ce n’est que dans la partie technique ça :wink:


#11

Merci @cgeek j’en ai profiter pour tester la mise a jours de mon nœud spécialisé avec “*” dans le package.json et ça marche il s’est mis à jours en 0.50.4 !!

Par contre malgré que presque tout les nœud ont bien fait la mise à jours, ça semble toujours forker fortement :confused:


#12

oui j’ai mon noeud qui boucle a tenter de rejoindre la branche principal:

2016-11-29T09:28:07+01:00 - trace: SWITCH: apply side block #58766-000024DECEAE129A809BCE40ED70CB529CCCFB9A6B120E7976E71A4F045528ED -> #58765-000003C30C3DD4E42400869964D1FCEC447A0DAC9A762055C4284318DB224631...
2016-11-29T09:28:08+01:00 - warn: Source T:5ECA9487CEF255DA1ED7B294DE118A3C51A5A329977295DE328741DEBC1AEDA1:11 is not available
2016-11-29T09:28:08+01:00 - warn: SWITCH: error %s httpCode=400, ucode=2015, message=Source already consumed

#13

Oui, le problème qui persiste est celui dont le symptôme est relevé par @Tortue : le basculement entre branche est buggué (visiblement au niveau du mécanisme qui prévient la double dépense).

A noter que DUP 0.6 pourrait calmer le jeu, mais autant profiter de cette profusion de forks pour renforcer l’algorithme de basculement.

Pareillement, je m’y met dans la journée en espérant identifier la/les erreur(s) :slight_smile:


Edit :

J’ai donc trouvé l’origine du problème, liée à l’issue #704 aujourd’hui close.

Explication technique

TLDR;

Les transactions ne s’enchaînent pas correctement dans la blockchain, et créent des situations de fork à chaque nouvelle transaction émise tout en empêchant la résolution de fork de les résorber.

Le protocole spécifie depuis la version 0.3 que les blocs doivent avoir des transactions en version 3, peu importe que le bloc soit en version 4 ou 5.

Cependant, un bug présent jusqu’à la version 0.50.0 (incluse) de Duniter modifiait la valeur du champ Version de la transaction pour y inscrire la même valeur que le champ Version du bloc une fois celui-ci ajouté à la base de donnée du nœud. Donc, un nœud avec ce bug propageait des blocs incorrects tandis qu’il recevait un bloc correct.

Cela posait d’abord des problèmes de synchronisation : quand un nouveau bloc était trouvé, celui-ci ne se propageait pas sur le réseau étant donné que le bloc était vu comme invalide.

Sauf que ce bug a également eu un effet pervers par le biais des transactions : les logiciels clients tels Sakia/Cesium ont envoyé des transactions en référençant des transactions précédentes telles que le leur présentaient les nœuds, c’est-à-dire parfois avec une version incorrecte de transaction source. Logiquement, les nœuds auraient dû refuser ces transactions car les sources associées n’auraient jamais dû exister, mais ayant eux-mêmes enregistrés les transactions avec ces versions incorrectes, les sources associées ont existé de fait, et les nœud ont accepté ces transactions.

La blockchain se retrouve donc avec des transactions qui s’enchaînent entre elles via un mécanisme d’empreinte, sauf que celle-ci référence parfois une transaction en version 5, alors qu’une telle transaction n’existe pas (elle existe, mais en version 3).

Ajoutez à cela que le mécanisme de synchronisation initiale ne contrôle pas ni ne force la valeur du champ Version d’une transaction et l’on obtient un réseau pollué par de faux enregistrements, ce qui contribue très largement à l’apparition de forks d’une part, mais surtout empêche le basculement de branche d’autre part.

Cette situation crée donc des forks, et en plus les empêche de se résorber.

Pour résumer :

  • la blockchain est intègre, au sens où les empreintes de blocs sont toutes correctes et l’intégrité des transactions est garantie par leur signature
  • le problème vient de la référence qui lie 2 transactions, l’empreinte, qui est calculée avec une version parfois incorrecte

Solution

TLDR;

cgeek va faire une nouvelle version bientôt.

La solution que je retiens évite de revenir sur une partie de la blockchain (plusieurs mois …).

Je vais donc modifier le protocole pour acter le fait qu’un bloc v4 ou v5 peut contenir des transactions consumant des transactions précédentes dont la version diffère de celle signée originellement.

Concrètement quand un bloc passe, si celui-ci contient une transaction TB qui consomme une transaction TA d’un bloc précédent via une empreinte TB->TAv3, alors si la transaction TAv3 n’est pas trouvée, on tente encore 2 autres coups :

  • TB->TAv4 (transaction source dont l’empreinte est calculée avec le champ Version: 4)
  • TB->TAv5 (transaction source dont l’empreinte est calculée avec le champ Version: 5)

Dès qu’un des coups fonctionne, on s’arrête là. De sorte qu’aucune double dépense n’est possible : c’est juste qu’il existe 3 empreintes possibles menant à la même source.


Version corrective 0.50.5 | Résolution de forks
#14

Piouf beau micmac tout ça !
Bien joué pour avoir trouvé l’origine du problème et toutes ces conséquences ! :slight_smile:

Lors du passage en prod du coup tu garderas toutes ces conditions devenues inutiles ? Où tu feras le ménage (au risque de créer de nouveau bug) ?

N’est il pas intéressant de relancer une nouvelle test_net fraichement créée quelques semaines avant la mise en prod? (si ménage du code)


#15

Tu vises juste … c’est un point délicat.

Mais en effet, je pense retirer tout code inutile afin d’avoir une base la plus propre possible, quitte à relancer un TestNet court (quelques jours, préparatoire à une monnaie de prod) afin de valider le code. En plus, ça aura l’avantage de chauffer un peu tout le monde avant la mise en prod et régler les derniers détails.

Il me semble que la simplicité est primordiale à la fois pour éviter les bugs, mais aussi pour que d’autres développeurs puissent contribuer à soutenir leur monnaie.


Monnaie Duniter "Sou" > État d'âme du collectif mayennais
#16

Dans tous les cas il semble bien de garder une monnaie test, même avec une monnaie de prod en route…


#17

Oui excellente idée.
Peut être même pourrait t-on lors du lancement de la monnaie de prod, lancer une monnaie de test aux paramètres quasi-identiques.
Pour pouvoir, en cas de besoin ultérieur d’intervenir sur la monnaie de prod, faire dabord l’intervention sur sa monnaie teste jumelle pour voir si ça réagi comme prévu !


#18

C’est ce qu’il faut faire, mais la monnaie de test devrait tout de même avoir un c test >> c prod le reste étant similaire. Normalement une bonne mise en prod passe pas une mise en environnement de test, vérification, avant de publier une release publique… Bon en pratique on ne le fait pas toujours, ce qui a tendance à créer des soucis… Mais il y a aussi des soucis à tarder à résoudre un bug… Donc bref…


#19

merci pour l’explication technique, c’est intéressant !

Je pense que même pour une version de prod ça peut être mieux d’avoir un cœur duniter capable de vérifier les transactions sources sous plusieurs versions différentes.
Car en cas de besoin, on sera aussi amené à avoir parfois (certes très rarement) un changement de version même sur une monnaie de prod non ?


#20

Sans aucun doute. Bitcoin lui-même évolue et change de versions.