Audit genesis Ğ1: aucune certification forgeron ne pourra être émise après le bloc genesis

Nodes Duniter-v2s
1

Je poursuis actuellement l’audit de Duniter v2 en urgence, étant donné que la migration définitive a déjà été annoncée pour dans une dizaine de jours. Ce soir, j’ai identifié un nouveau problème.

Dans l’état actuel du genesis, aucune certification forgeron ne pourra être émise après le bloc genesis.

Conséquence directe : aucun nouveau forgeron ne pourra jamais entrer dans la toile des forgerons.

Explication du bug

Voici ce qui se passe techniquement :

  • Lors de la génération du genesis, les 15 smiths initiaux sont organisés en « clique » : chacun certifie tous les autres.
  • Cela signifie que chaque smith reçoit 14 certifications (une de chacun des 14 autres).

Le problème vient d’une règle appelée SmithMaxByIssuer :

  • Cette règle limite le nombre maximum de certifications qu’un smith peut émettre.
  • Or, la construction du genesis ne vérifie pas cette limite (elle interdit seulement l’auto-certification).
  • En revanche, dès le bloc 1, l’appel runtime certify_smith applique strictement la condition issued_certs < SmithMaxByIssuer

Résultat :

Les forgerons du genesis ont déjà dépassé la limite autorisée (SmithMaxByIssuer = 12)
Donc à partir du bloc 1, ils ne peuvent plus émettre la moindre certification supplémentaire.

:right_arrow: Aucune nouvelle certification possible.
:right_arrow: Aucun nouveau smith ne pourra être ajouté.
:right_arrow: Le système est verrouillé dès le départ.

Solutions envisagées

Mon plan initial (il y a 8 mois)

Mon idée à l’époque n’était pas de générer automatiquement une clique complète, mais de construire manuellement une toile initiale de forgerons, où chacun déclarerait explicitement qui il souhaite certifier.

La trace de cette intention est visible ici :

Malheureusement, j’ai eu des problèmes de santé peu après, ce qui m’a empêché de mettre ce processus en place. Aujourd’hui, avec la migration imminente, nous n’avons plus le temps d’implémenter une telle procédure proprement.

Proposition alternative (rapide et pragmatique)

Modifier l’algorithme de génération des données de genesis :

Au lieu que chaque forgeron reçoive 14 certifications (une de chacun des autres), chaque forgeron recevrait seulement 3 certifications réparties au hasard.

Cela permettrait :

  • De respecter la limite SmithMaxByIssuer
  • De laisser de la capacité d’émission de certifications après le bloc 0
  • D’éviter le blocage définitif du système
  • De corriger le problème sans refonte complète du process de genesis

Issue gitlab: g1 Genesis State Prevents New Smiths After Genesis (#348) · Issues · nodes / rust / Duniter v2S · GitLab

10 Likes
Audit des paramètres du runtime Ğ1
2

Voici un script Python qui génère une toile aléatoire où chacun a exactement 3 certifications émises et 3 certifications reçues. (remplacer la liste par la liste des smiths)

import random

def generate(smiths, n=3):
        certs = []
        issuers = []
        recipients = []
        # Fill the bags
        for smith in smiths:
                issuers += [smith] * n
                recipients += [smith] * n
        # While the bags are not empty
        while len(issuers) > 0:
                # Pick one identity in each bag
                issuer = random.randint(0, len(issuers)-1)
                recipient = random.randint(0, len(issuers)-1)
                # If they are not the same
                if issuers[issuer] == recipients[recipient]:
                        continue
                # If they are not already an edge
                if (issuers[issuer], recipients[recipient]) in certs:
                        continue
                # Remove them from the bags
                certs.append((issuers.pop(issuer), recipients.pop(recipient)))
        return certs

print(generate([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]))
1 Like
3

Pourquoi ce problème ne s’est pas produit en gtest ?

4

Trop peu de smiths dans la clique.

1 Like
5

Non, même avec le même nombre de smiths dans la clique, ça n’aurait pas été détecté, car en gtest: SmithMaxByIssuer = 100.

2 Likes
6

Oui j’ai répondu un peu vite, en regardant l’historique Git on avait une clique de 13.

Tu as raison c’est ce stock de 100.

1 Like
7

J’ai exploré cette solution : elle demande des changements de code un peu complexes et risqués, tout en ne respectant plus la signification de « clique ».

Je propose une approche plus simple et moins risquée : déclarer explicitement dans g1.yaml l’état exact de la toile forgeron initiale. C’est en effet supporté dans le code ; j’ai ajouté un test pour m’en assurer. Voici une MR GitLab qui déclare une toile forgeron initiale à la main avec les certifs reçus par chacun :

@cgeek, @tuxmain, @poka, pouvez-vous la reviewer ?

4 Likes
8

C’est ok pour moi!
Comment as-tu généré ce set se certification smiths ? A la main ou via un algo ?
Je vais ajouter cette génération de format automatiquement dans duniter-mocks.

3 Likes
9

Aucun des deux, ça a été généré par GPT-5.3-Codex dans Codex Desktop au milieu d’un long chat pour résoudre le problème. J’ai retrouvé mon message dans l’historique, mais ce n’est pas forcément reproductible, car il avait déjà du contexte issu de la discussion précédente:

can you adapt the g1.yaml content replace clique_smiths by smiths and write placeholders received certs from existing smith members names?

1 Like
10

Pour info j’avais anticipé cela en postant un script juste plus haut, c’était pas la peine de consommer des kWh pour ça.

1 Like
11

Je n’ai pas Python configuré sur ma machine de dev, et même si ça avait été le cas, il aurait fallu formatter manuellement les inputs et outputs du script pour les exploiter correctement. À ce moment-là, c’était simplement trop chronophage par rapport à l’objectif.

Concernant l’usage de l’IA, je préfère qu’on évite les remarques de principe ou les sous-entendus. Dans les faits, l’IA a permis à cgeek et poka d’entrer rapidement dans le code de Cesium 2 et d’avancer beaucoup plus vite vers une version finalisée. Sans ces outils, il est probable que la migration vers la v2 aurait pris significativement plus de temps. On peut évidemment débattre des outils et des méthodes, mais les jugements implicites sur leur légitimité n’apportent pas grand-chose au débat technique.

Enfin, la remarque sur la consommation d’électricité me semble hors sujet dans le cadre de cette discussion. Si tu souhaites échanger sur ces considérations plus générales, je suis tout à fait ouvert à en parler en privé. En revanche, merci d’éviter en public les commentaires fondés sur des positions personnelles quant à ce qui serait “bien” ou “mal” en matière d’usage d’outils, surtout quand cela n’est pas directement lié au sujet technique en cours.

6 Likes