C’est une solution.
Il faut également prendre en compte le problème de raréfaction des interfaces BMA.
Tu as probablement raison, c’est ce qui doit limiter la propagation des données sur le réseau.
Question bête, mais ça prendrait trop de place de sauvegarder la piscine quelques jours ?
Après écriture, on met le document dans un coin et on ne le supprime que X jours après ? (Ou si plus de place, après c’est chaque nœud qui gère sa politique).
1 Like
En fait c’est déjà le cas. Les documents ne sont supprimés des piscines que quand ils expirent, ou pour une transaction quand elle ne passe pas après plusieurs essais par le nœud.
Et bien sûr tout document écrit en blockchain est retiré des piscines. En cas de rollback à cause d’un fork, les documents sont réintégrés en piscine.
1 Like
C’est ce qui se passe dans le rollback que je ne maitrise pas, dans ma tête j’imaginais un “dépouillement” de la blockchain pour en reconstituer les documents, et donc un processus laborieux.
Y-aurait-il moyen alors de “sauvegarder” les documents encore en stock avant un reset ? De toutes façons s’ils sont là c’est qu’ils ont été émis, donc tenter de les remettre en blockchain ne coûte pas très cher quand c’est ponctuel après un fork. Ca permettrait de limiter les pertes.
@Nartagnan avant de proposer quoi que ce soit il faut comprendre les causes des pertes, dans le présent incident il y en a deux :
- Le fait que les documents soient dater par les clients au temps du bloc courant, alors que le block courant peut très bien être supprimé par un roll back, et le document de venir donc invalide, il ne pourra donc jamais être écrit en blockchain car il n’est plus valide, et il n’est pas possible de le rerendre valide car il est signé cryptographiquement, l’utilisateur doit donc réémettre le document…
Solution : que les clietns datent les document qu’il construisent a t moins 3 jours.
- Le fait que le nœud G1.duniter.org soit trop utilisé et les autres noeuds pas assez, dés que ce noeud a un problème, tout ce qu’il n’a pas pu synchronisé avec le reste du réseau se retrouve perdu.
Solution : Dans Cesium sélectionner un nœud au hasard parmi un pool de nœuds. (Sakia ne souffre pas de ce problème car il envoi les documents a plusieurs nœuds, enfin je crois).
EDIT : Donc in finé il n’y a rien a faire coté Duniter (outre corriger le bug qui a empêcher de roll back). C’est coté clients que se trouvent les solutions.
Il me semble que @kimamila avait fait en sorte que Cesium envoie les documents sur tous les forks détectés par l’application. Ca me semblait être une approche correcte.
Si c’est vrai alors toutes les pertes sont uniquement du au cas 1, ça tombe bien c’est facile a résoudre coté clients 
Oui, mais pourquoi donc aucun des forks n’a pu accepter les docs perdus ? Même si l’idée que tu proposes est intéressante et simple à mettre en oeuvre, je ne vois pas en quoi le cas 1 aurait fait disparaitre des documents.
Ça ne les fais pas disparaître ça les rend invalide, mais coté utilisateur c’est perçu comme une disparition donc c’est pareil
Pourtant si un doc A est envoyé sur 2 forks F1 et F2. Si le noeud sur F1 rollback sur F2, en quoi le doc A disparait du noeud ?
Je ne sais pas comment @kimamila gère ça, peut être que Cesium n’a perçu qu’une seule branche, peut être qu’il percevait bien les 2 mais que le document a été envoyer sous une seule version (avec un seul et même blockstamp), tant qu’on en sais pas comment c’est gérer coté Cesium on ne peut rien conclure !
1 Like
Salut je n’ai toujours pas de trace des virements que j’ai effectué Samedi soir, est-ce perdu ? Dois je les refaire pour ceux dont je me souviens ?
Pour les autres virement je ne sais plus à qui je devais de la June et d’ailleurs il se peut que des virements devaient m’être envoyé durant cette nuit (pas sûr).
Auriez vous avez la possibilité de le voir quelque part ? Est-ce que les virements on été effectués mais je ne les visualise pas ?
Exemple : virement de 185 G1 destiné à Pascale Roncoroni à 20h57 Samedi 26/05.
Pardon de mon insistance… 
1 Like
Je pense que @cgeek pourra t’en dire plus avec son backup mais j’ai peu d’espoir là : il y a des données qui ont semble-t-il été effacées du réseau par le rollback bloqué par le bug rencontré sur une période assez longue. C’est un incident technique particulièrement grave 
(et en plein RML pour couronner le tout)
Ce que je conseille à l’avenir :
- Si vous gérez une entreprise, ou que vous vendez un grand nombre d’objets, faites comme pour l’euro et tenez une caisse qui suit vos échanges (surtout si vous faites beaucoup d’échanges en un temps restreint). C’est laborieux mais ça vous protège contre ce type de bug logiciel (vous pourrez alors recontacter la personne qui pourra reproduire le transfert)
- Il faudra communiquer sur ces incidents et demander à chacun de vérifier son historique de transactions
- Pour les gros virements, attendez que la chaine valide la transaction avant de valider l’échange !
- Il faudra éduquer les utilisateurs pour les faire utiliser le plus possible des noeuds autre que le noeud par défaut. Il faut en parler aux apéro
On va apprendre du bug et voir qu’est-ce qu’on peut faire pour rendre tout ça plus robuste…
2 Likes
Ca marche, merci pour ces infos, bon je je fais les virements pour lesquels je me souviens, tant pis pour le reste. Hé oui pendant les RML c’est ultra chaud
Bon courage les mecs et merci pour ce que vous faites. Respect
Have a nice day !
Sur Bitcoin il y a une pseudo régle d’usage, attendre que la TX soit validé par au moins 6 blocs, avant de la prendre pour argent comptant.
Peut etre qu’on pourrait émettre une recommandation en ce sens aussi ?
Je compte réutiliser cette règle pour mon appli :
- Toto envoi une TX vers mon service
- La TX est ajouté dans 1 bloc (i.e. 1ère confirmation par le réseau)
- Un bloc est forgé par dessus (i.e. 2ème conf par le réseau)
- etc pour x blocs (6 dans mon cas soit en temps humain 30 minutes)
- Je crédite le compte de Toto sur mon service
On pourrait, raccourcir cela si on a un détecteur de fork solide au niveau noeud, mais à l’instant t, le noeud est aveugle d’une partie du réseau il me semble.
My 2Cts,
Oui, nous en avions déjà parlé, mais ce fil actualise ce besoin.
Dans Cesium, je pourrais afficher un marqueur “en attente de validation” quand la TX date de moins de 6 blocs.
Le second souci est l’importance de dater la TX avec le hash du bloc courant.
ça me parait etre une mauvaise pratique, en cas de fork, le hash courant du bloc est invalide sur l’autre chaine, donc la TX, n’est pas “transférable”.
Le fait à mon avis de prendre le hash du bloc n-6 corrigerai pas mal de souci de TX perdu dans le “petits fork”, non ? 
Plus généralement à quoi ça sert ?
Je me pose moi même la question Le blockstamp pour les documents de WoT, je comprends bien, mais pour les TX… ? Il y a probablement une raison que j’ai oublié. @elois @cgeek
Oui c’est déjà ce que je fait pour mon service de mail payable automatiquement en Ğ1, j’ai un script qui passe régulièrement et qui n’active le service que si la tx a été inscrite il y a plus de 6 blocs
C’est nécessaire sinon on vas se retrouver avec un dépot sédimentaire de toutes les anciennes TX qui n’ont pas été inscrite pour X ou Y raison, les document tx ont une durée de vie limitée en piscine (1 semaine pour la Ğ1), au delà elles expirent et sont supprimer.
Donc créer une TX datée a J-3 ça lui donnerai quand même 4 jours pour etre écrite ce qui est largement suffisant
En revanche créer une tx a t -6 blocks non c’est totalement insuffisant et ça ne changerait rien pour le type d’incident qu’on a eu ce dimanche.
1 Like