Les RML16 du 25 au 29 Mai est l’événement de rencontre des développeurs informatiques véritablement intéressés par la maintenance, l’innovation de la blockchain Duniter/Ğ1, avec pour thème central de cette 16ème édition la migration vers Substrate.
La 16ème occasion de rencontre des développeurs historiques et nouveaux, permettant de monter en compétence sur le chemin de la maîtrise de la blockchain Duniter/Ğ1 !
Les développeurs intéressés doivent se faire connaître auprès des développeurs déjà inscrits et rejoindre le canal télégram dédié (canal privé).
si avec quelques tests, il est possible de bloquer toutes les transactions de la blockchain, on peut craindre ce que donnerait une attaque concertée sur la même blockchain. Après, peut-être que la migration vers substrate évitera ce genre de problématique…
Pour redémarrer au plus vite peut-être qu’il suffirait de vider les piscines, ou au moins de supprimer le document problématique ?
Ensuite si on veut éviter que le problème se reproduise il faut corriger le bug.
Et oui Substrate utilise un autre format et je pense que ses codeurs/décodeurs sont très largement testés, y compris dans des cas d’usage complètement différents, puisqu’ils servent à beaucoup de projets et de gens différents. Comme on n’aura pas à gérer toute la partie formatage, il y aura moins de risque.
Pour info, je suis sur Duniter 1.9-dev (pour GVA):
$ sqlite3 $HOME/.config/duniter/duniter_default/txs.db 'DELETE FROM txs WHERE hash = "880A176F660BC095A5856B9223A2CFB622B1762CC1322D2C7DE714179C1044AC"'
Error: no such table: txs
Je suppose que cette table a été migré sur une nouvelle DB avec Rust.
Je vais attendre sagement de me re-synchro sur un nœud à jour.
C’est même incroyable que le problème n’ai pas été relevé avant.
C’est étonnant que le mot clé “Certifications” n’ai jamais été utilisé en commentaire auparavant.
Il fallait une majuscule et le pluriel, c’est peut-être pour ça. Ce serait intéressant d’aller vérifier, néanmoins j’arrive à corriger l’anomalie en changeant le parsing du bloc donc je suis à peu près certain.
Oui, mon nœud a forgé ce bloc il y a quelques instants, mais c’est parfaitement normal que l’heure blockchain n’avance que lentement… il nous faudra une petite accélération pour revenir à une heure proche de l’heure réelle, c’est comme ça que ça marche.
Pas besoin, a priori tout le monde suit… c’est juste que les nœuds qui ont la mauvaise transaction dans leur piscine ne peuvent pas forger de bloc, si j’ai bien compris… mais tout bloc qui ne contient pas la transaction foireuse devrait être accepté correctement.
Apparemment oui.
Mais en ce qui me concerne ça ma permis de me rendre compte que mon noeud est out depuis un moment…
Pas sûr qu’avec Duniter 1.9 ce problème de parsing se serait posé étant donné que la logique des transactions a été migré en Rust.
Mais bon, je crois que je vais revenir à Duniter 1.8.1 (ou attendre 1.8.2 si un fix est prévu par cgeek) et donc couper le dernier noeud GVA en ligne.
Mais avant ça il faut que je rétrograde g1-stats et Jaklis pour utiliser BMA de nouveau, sinon plusieurs services tiers seront perdus (comme carte.monnaie-libre.fr).
Bref c’est un autre sujet.
Ce n’est pas le code des transactions qui pose problème, mais celui du parsing de bloc. La 1.9 est aussi affectée, je viens de vérifier.
Sinon, pour info voici une Merge Request corrective pour Duniter 1.8. Vous pouvez y jeter un œil, toutefois je mergerai sans confirmation de votre part (sauf si vous voyez un bug manifeste bien sûr ).
Si tu veux je peux tenter d’apporter le correctif sur la branche « Duniter 1.9 GVA », par contre je ne trouve pas précisément le commit sur lequel se base cette version.