Ces gros blocages de la chaîne sont très inquiétants.
Je pense qu’il faudrait dédier une future version uniquement à la stabilisation du cœur via des refractorings, des tests unitaires et des audits du code critique.
Au moins, pour le moment, il n’y a eu aucune donnée corrompue intégrée à la chaine principale. Seulement des blocages (ce qui est beaucoup moins grave).
Ces bugs seraient beaucoup plus simple à détecter si on générait des évènements aléatoires sur le réseau de test. Personne pour coder un fuzzer ?
C’est sûr qu’il y a plein de points d’amélioration (ne serait-ce que retirer tous les any du code).
J’ai aussi en tête le développement d’un framework de test pour réaliser facilement des scénarios à vérifier, sans besoin d’être un grand codeur. Et aussi de découpler de nombreux composants, afin d’isoler les algorithmes et pouvoir les tester de façon unitaire.
On peut aussi détecter les blocages dès qu’ils surviennent par GitLab CI, en ayant un nœud qui lance régulièrement la commande :
duniter gen-next --show --check --submit-local
Cette commande génère un bloc et vérifie qu’il est valide. Il faut toutefois avoir une clé de membre actuellement pour que le bloc soit considéré valide, mais une petite option supplémentaire pourrait outrepasser ce cas spécifique pour vérifier tout sauf le fait que l’émetteur du bloc est membre.
Et donc, GitLab CI nous avertirait par mail immédiatement en cas de bloc invalide.
Le même principe peut être appliqué pour vérifier que la synchro fonctionne toujours, faire une vérification intégrale de la blockchain en mode --cautious, etc.
