Proposition: Supprimer le comité technique

Protocols Ğ1v2 protocol
, ,
1

Je propose de supprimer le comité technique et de confier les mises à jour du runtime aux forgerons actifs. Une mise à jour serait autorisée dès que strictement plus de deux tiers d’entre eux l’approuvent, puis appliquée on-chain, sans fork.

C’est moi qui avais proposé la création d’un comité technique en mai 2022, puis annoncé sa mise en place dans la ĞDev en août 2022. J’avais aussi défendu son rôle au nom de l’expertise technique de ses membres.

À l’origine, je voulais éviter de concentrer les pouvoirs et distinguer deux responsabilités qui demandent des compétences différentes. Administrer un nœud et participer au consensus ne demande pas les mêmes connaissances que comprendre le code du runtime et évaluer les conséquences de ses modifications. C’est cette réflexion qui m’avait conduit à proposer un comité technique.

Je souhaite aujourd’hui revenir sur ce choix. La distinction des compétences reste valable, mais elle ne justifie plus, à mes yeux, de maintenir un comité doté d’un pouvoir privilégié. D’autant que cette séparation ne retire pas aux forgerons leur capacité à changer les règles par un hard fork lorsque les deux tiers d’entre eux s’accorde pour le faire.

La pratique m’a aussi amené à revoir l’argument de l’expertise. Être membre du comité technique ne signifie pas forcément mieux comprendre le code du runtime et ses évolutions qu’un forgeron. Lors du vote sur le runtime 1100 de la ĞTest, plusieurs membres ont expliqué avoir voté sans relire le code, en s’appuyant sur le travail et les avis d’autres personnes.

Moul indiquait ne pas avoir les compétences ni le temps nécessaires pour auditer le Rust. Il avait examiné le changelog, les MR et les échanges du forum, puis accordé sa confiance. Vit expliquait également avoir vérifié les hashes et voté sans revoir le code, en faisant confiance aux fondateurs de la Ğ1 qui avaient voté.

Je comprends cette démarche. On ne peut pas demander à chacun de maîtriser tout le code de Duniter. Mais vérifier qu’un runtime correspond au code publié et juger si ce code est correct sont deux vérifications différentes. Si le vote repose en partie sur la confiance accordée aux développeurs, les forgerons peuvent eux aussi prendre une décision sur cette base.

L’expertise collective que j’attendais du comité ne se traduit donc pas, en pratique, par la vérification indépendante du code que j’avais en tête. Les raisons pour lesquelles je défendais ce comité ne se vérifient pas comme je l’espérais. Il me paraît cohérent d’en tirer les conséquences et de proposer sa suppression.

Dans Duniter v1, nous faisions évoluer le protocole par des hard forks. Cette possibilité existe toujours dans Duniter v2.

Substrate (aujourd’hui renommé Polkadot SDK), permet à un opérateur de remplacer localement le runtime on-chain grâce au champ codeSubstitutes de la configuration de chaîne. La substitution prend effet à partir d’un bloc donné et reste applicable jusqu’à un changement de spec_version on-chain. Le fonctionnement est décrit dans le code du Polkadot SDK.

Si strictement plus de deux tiers des forgerons adoptent la même substitution au même bloc, ils peuvent poursuivre la chaîne avec les nouvelles règles et en finaliser les blocs. C’est le seuil requis par GRANDPA.

Les nœuds restés sur l’ancien runtime ne peuvent plus suivre dès que les nouvelles règles produisent un résultat différent. Le tiers des forgerons restant doivent alors se mettre à jour pour reprendre leur participation. Sans cela, ils sortent de l’ensemble des forgerons actifs au bout de quelques heures.

Cela touche aussi les nœuds RPC. Leurs opérateurs doivent adopter la substitution pour continuer à suivre la chaîne et à servir les applications. Un hard fork demande donc de coordonner bien plus que les seuls forgerons, avec un risque d’interruption de service pour les utilisateurs.

Le comité technique nous évite aujourd’hui cette coordination. Il autorise la publication du nouveau runtime on-chain, que les nœuds exécutent ensuite automatiquement. C’est le principe des mises à jour sans fork du Polkadot SDK. Je propose de conserver ce fonctionnement en faisant venir l’autorisation directement des forgerons.

Concrètement, une pallet permettrait à chaque forgeron actif d’enregistrer un marqueur contenant le hash du runtime qu’il approuve.

  1. Chaque forgeron actif peut enregistrer son soutien à un hash de runtime.
  2. Dès que strictement plus de deux tiers des forgerons actifs soutiennent le même hash, la mise à jour est autorisée automatiquement.
  3. N’importe qui peut alors publier le code correspondant on-chain. La pallet vérifie que son hash correspond exactement au hash approuvé avant d’appliquer la mise à jour.

Le forgeron dont le soutien fait franchir le seuil pourrait fournir le code dans la même transaction, pour déclencher immédiatement la mise à jour.

On pourrait ainsi distribuer le runtime proposé avec une nouvelle version de Duniter. En installant cette version, le forgeron signalerait son accord par la publication du marqueur. L’installation n’activerait aucune substitution locale, puisque la mise à jour attendrait l’accord de la supermajorité.

Une fois approuvé et publié on-chain, le nouveau runtime serait exécuté automatiquement par tous les nœuds compatibles. Cela inclut les forgerons qui n’ont pas soutenu la proposition et les nœuds RPC. Les opérateurs RPC n’auraient donc pas à synchroniser une mise à jour de leur logiciel avec la décision des forgerons.

C’est ce qui motive ma proposition. Les deux tiers des forgerons dispose déjà du pouvoir technique de changer les règles et de poursuivre la chaîne par un hard fork. Je propose de permettre l’exercice de cette capacité directement on-chain, pour conserver les mises à jour sans hard fork pour en éviter les perturbations.

Le travail des développeurs resterait tout aussi nécessaire pour proposer, expliquer, auditer et tester les mises à jour. Les forgerons s’appuieraient sur ce travail pour décider de les adopter, comme ils le font lorsqu’ils choisissent une version du logiciel à installer. Les personnes capables de relire le runtime pourraient continuer à partager leurs analyses. Ce travail n’a pas besoin d’être associé à un pouvoir privilégié détenu par un comité.

Qu’en pensez-vous ?

2

Si je comprends bien, ce qui était demandé aux membres du comité technique serait maintenant demandé à X forgerons actifs. Soit une opération manuelle avant de déclencher la mise à jour.

Le premier problème que je vois est que X va augmenter avec le temps alors que le nombre de membres du comité technique restera plutôt stable. Il sera donc bien plus difficile de contacter X forgerons pour leur demander de mettre à jour, que de demander cela aux quelques membres du comité. Les votes de celui-ci demandaient déjà du temps pour contacter les membres, avec 2/3 des forgerons à contacter ce sera pire. Amha.

Je pense surtout aux failles zéro day à mettre à jour rapidement…

Sinon j’aime bien l’idée, je trouve cela plus organique, moins centralisé.

3

Je n’ai sans doute pas été assez clair sur ce point. Dans le fonctionnement que je propose, les forgerons n’auraient pas à effectuer un vote manuel en plus de la mise à jour de leur nœud. La version de Duniter installée publierait automatiquement leur soutien au runtime qu’elle embarque.

Il resterait donc à choisir d’installer cette version, mais aucune manipulation supplémentaire ne serait nécessaire pour approuver le runtime.

C’est d’ailleurs déjà le cas pour les hard forks : il suffit que deux tiers des forgerons installent une même version de Duniter qui contient le runtime substitué pour déclencher le hard fork.

Oui, réunir l’accord d’un plus grand nombre de personnes peut prendre davantage de temps. C’est aussi une conséquence de la décentralisation que je trouve souhaitable pour les changements de règles. Plus le réseau compte de forgerons indépendants, plus il faut obtenir une adhésion large avant de modifier son fonctionnement. Cela limite la possibilité qu’un petit groupe impose un changement.

L’automatisation du soutien ne supprime pas ce besoin de coordination. Elle évite simplement d’ajouter une procédure de vote à la mise à jour habituelle du logiciel.

Sur ce point, il faut distinguer les vulnérabilités du runtime de celles du binaire Duniter.

Lors de l’audit de sécurité que j’ai réalisé avec les modèles d’OpenAI, les vulnérabilités que j’ai trouvées concernaient le binaire, pas le runtime. Leur correction a nécessité la mise à jour Duniter v2.3.0. Une décision du comité technique ne pouvait pas déployer ces correctifs sur les machines des opérateurs : chacun devait mettre à jour son nœud.

Même avec le comité technique, nous devons donc déjà être capables de joindre rapidement les forgerons, et plus largement les opérateurs de nœuds, en cas de faille dans le binaire. Le groupe Telegram des forgerons v2 sert notamment à cela. On peut discuter d’autres canaux pour que les alertes importantes atteignent tout le monde.

Cela ne signifie évidemment pas qu’il ne peut pas y avoir de faille dans le runtime. Dans ce cas, un comité restreint pourrait effectivement autoriser un correctif plus vite qu’une supermajorité de forgerons. C’est un avantage du système actuel, et un compromis à discuter.

Ce besoin de réactivité existe déjà aujourd’hui, quel que soit le devenir du comité technique.

4

Afin de laisser plus de temps à ce débat, je propose de conserver le comité technique pour le prochain runtime (qui aura pour numéro de version 1200).

J’ai ouvert une Merge Request pour simplement ajouter la possibilité pour les forgerons de faire, sans hard fork, ce qu’ils peuvent déjà faire avec un hard fork : upgrader le runtime.

Le comité technique restera actif en parallèle de ce nouveau mécanisme, nous laissant ainsi le temps de le tester tout en conservant le comité technique au cas où.

D’ici le runtime d’encore après (1300), nous aurons davantage de recul et d’expérience sur le comité technique et les runtime upgrades pour rediscuter de la pertinence de le maintenir, de le modifier ou de le supprimer.

Nous pourrions aussi décider de conserver les deux mécanismes de runtime upgrade sans hard fork : le comité technique et l’approbation des deux tiers des forgerons. Même si je reste favorable à la suppression du comité technique à terme, je ne souhaite pas que cette question retarde la sortie du runtime 1200, qui contient des correctifs attendus.

5

Voici la merge request pour permettre aux deux tiers des forgerons d’autoriser un runtime upgrade sans hard fork:

Par défaut, les forgerons auront simplement à effectuer la mise à jour pour que leur nœud vote automatiquement en faveur du runtime upgrade embarqué dans celle-ci.

Les forgerons qui ne souhaitent pas adopter ce comportement pourront utiliser le flag --disable-auto-runtime-upgrade. Ils devront alors saisir manuellement le hash du runtime pour lequel ils souhaitent voter via le flag --runtime-upgrade-hash <HASH>.

6

Ce qui est sûr c’est que le comité technique dans son état actuel avait vocation à être remplacé par quelque chose de plus démocratique. Ajouter la possibilité du vote forgeron me paraît une très bonne évolution du côté de l’exécutif puisque cela concrétise par un vote la possibilité technique du hard fork. Par contre, plutôt que de supprimer le comité technique, après les RML17 j’étais plutôt resté sur l’idée d’un éclatement en plusieurs comités avec différentes règles :

  • l’ensemble des membres, sans quota de participation, mais avec une mesure en suffrages exprimés
  • un ensemble de membres tirés au sort, avec un quota de participation
  • une assemblée technique

Un vote passerait si les trois comités sont du même avis, c’est-à-dire qu’un runtime upgrade obtient :

  • une validation technique venant de techniciens identifiés (ça peut être une toile forgeron ou autre)
  • une validation par des membres tirés au sort que la toile aurait pour mission d’informer des tenants et aboutissants, et qui seraient “élus” pour une décision (à la manière des conventions citoyennes mais avec un pouvoir législatif)
  • une mesure du consentement sur la toile entière dans un temps donné par la temporalité des autres conseils à quota fixe

J’aimerais beaucoup avoir les avis de @1000i100 et @Yvv sur ce sujet.

7

Je suis touché que tu consultes mon avis, je t’en remercie, d’autant qu’il va contrarier ton post précédent. ;-).

Ce que tu proposes est exactement le genre de cheminement que je trouve redoutable, qui reproduit tous les schémas d’une complexité croissante, et de débats inextricables sur des concepts de représentativité - fatalement factice - et de systèmes de votes ; avec tous les biais dans le choix et le paramétrage des variables.

Tout cela vient à l’encontre de l’efficacité et la réactivité requises par notre monde moderne, et plus encore par notre contexte bénévole à géométrie variable.

En revanche je suis emballé par les propositions d’Elois, car depuis le début je trouve cette posture sur la nécessité d’un Comité technique contre productive et surtout maintenant, obsolète.

  • Je retiens avant tout la notion qu’Elois appelle “Soutien”. Ce n’est pas un vote, c’est une décision du forgeron pour son propre nœud.
    → cela remet sa décision en amont, cela redonne un sens de type “pull” que le “push” de la décision d’un Comité avait évacué (avec seulement une possibilité de veto qui nécessite une mobilisation des 2/3 des forgerons, donc factice ; ils n’ont pas le temps ni l’énergie pour une telle mobilisation).
  • Je retiens la notion de “score”, lorsque le nombre de forgerons dépasse cette variable, alors le reste des serveurs prend le runtime upgrade.
    → C’est exactement le genre de protocole que j’appelle de mes vœux depuis la RML de Laval.

Mais il faut bien sûr affiner ce protocole. Il manque toujours à mes yeux :

  • l’identification préalable de la nature de l’upgrade, en gros : bugfix ou évolution ?
  • Le réglage de l’inertie, donc le nombre requis de forgerons qui ont acté la mise à jour et qui déclenche celle de tous les “silencieux”.
  • Le contrôle du code : l’ia et plus encore les automatisations changent la donne, profondément et dans les deux sens. Cela ouvre considérablement le spectre des personnes pouvant se consacrer à un contrôle, non seulement en terme de compétence mais aussi en terme d’énergie requise. En contrepartie, cela augmente le risque de failles et de négligence, notamment si des automatisations sont mises en oeuvre en grillant des étapes (précipitation).

et

  • Définition des rôles ; donc onboarding vs formation pour ouvrir les rôles aux candidats.
  • Mise en oeuvre du canal forgeron structuré, dédié exclusivement à ça.

RQ : le plus délicat reste le premier point selon moi.
La question démocratique repose sur l’ouverture des candidatures à jouer un rôle d’une part ; elle ne concerne d’autre part que le cas n°2 de l’upgrade “évolution”. Celui-ci fait alors l’objet d’une prolongation du protocole de triage, qui peut ouvrir progressivement des votes, seulement lorsqu’ils s’avèrent nécessaires, de façon également protocolaire. Dans une matrice simple de type [ portée - urgence ], qui détermine l’étendue du vote. Toujours pas besoin de Comités ni de Commissions pour tout ça.

RQ2 : j’évacue le cas des fix de binaire, puisqu’ils ne s’inscrivent pas dans le protocole du runtime upgrade.

Mon avis et ma reco : lancer une RML à court terme pour accoucher de ces protocoles, des premières automatisations et des boucles de contrôles humainement et préalablement éprouvées et validées.

8

je vois pas en quoi le tirage au sort est complexe et je ne changerai pas d’avis facilement sur cette question
On a un outil formidable, qui sert maintenant à se connecter, et il servirait pas à décider!?

9

Je suis en grande partie d’accord, il faut conserver des mécanismes suffisamment simples et efficaces. En plus des arguments de @Yvv, j’ajoute celui de la compréhension du processus de modification des règles par le plus grand nombre : plus ce processus est compliqué, moins il sera compris, et l’incompréhension peut créer de la méfiance, voire de la défiance.

C’était déjà comme cela que fonctionnaient les changements de protocole en v1. Chaque membre forgeron injectait un « marqueur » dans les blocs qu’il produisait, puis, lorsque 70 % des forgerons actifs avaient injecté ce marqueur, cela déclenchait la mise à jour. Un forgeron était considéré comme « actif » s’il avait écrit au moins un bloc récemment (plus précisément dans la fenêtre courante).

Ce mécanisme a réellement été utilisé, notamment en janvier 2019 pour le passage de la Ğ1 au protocole v11.

Dans le sujet Sortie de Duniter 1.7, cgeek invitait les forgerons à installer la nouvelle version, précisait qu’il ne manquait plus que quelques personnes « pour que tout bascule », et HugoTrentesaux parlait explicitement de « participer au vote pour la 1.7 ».

Le principe de ce mécanisme avait été discuté auparavant dans le sujet Évolutions du protocole vers v11, v12, etc..

Ce que je propose est très similaire à ce processus que l’on avait déjà en v1, à deux différences près :

  • En v2, il n’y a pas de fenêtre courante. La définition d’un forgeron « actif » est désormais plus simple et plus large : tout forgeron qui a produit au moins un bloc dans les dernières 48 h. Cela permet d’éviter qu’une minorité passe en force lorsque plusieurs forgerons passent hors ligne pendant quelques heures pour une opération de maintenance (comme une mise à jour du binaire, par exemple).
  • En v1, une fois le seuil de 70 % atteint, tous les nœuds qui n’avaient pas fait la mise à jour pour supporter la nouvelle version du protocole se désynchronisaient, y compris les nœuds miroirs, ce qui pouvait causer des pannes au niveau des applications. En v2, le mécanisme que je propose dans ce topic (et dans cette Merge Request) garde le même seuil qu’en v1 (70 %), mais les autres nœuds (forgerons ou miroirs) n’ont pas besoin de se mettre à jour pour supporter le nouveau protocole (si les changements sont limités au seul runtime).

Avec le recul, je pense que nous aurions dû faire cela dès le début de la v2. Mais transposer en v2 la même philosophie que celle du mécanisme qu’on avait en v1 n’est pas trivial (ma Merge Request n’est pas si simple), et à l’époque, je ne voyais pas comment faire cela facilement. J’avais encore peu d’expérience avec Substrate, et nous n’avions pas les IA pour nous aider.

À l’époque où j’ai commencé la v2 (en 2021 et 2022), je pensais aussi qu’il fallait profiter du passage en v2 pour découpler les rôles « produire des blocs » et « acter les changements de protocole », notamment parce que c’est ce que faisaient toutes les autres blockchains basées sur Substrate, et que Substrate fournissait une pallet clé en main et auditée pour mettre en place un comité technique.

Le choix d’un comité technique était donc la solution la plus simple et la plus accessible techniquement pour répondre à la question « comment on change le runtime ? ». J’aurais voulu avoir le temps de remettre en question ce choix avant que l’on bascule la Ğ1 en v2, mais j’ai eu des aléas de la vie (et notamment des problèmes de santé) qui ont fait que j’ai été totalement absent de fin 2022 à début 2025, puis peu présent en 2025.

Le mécanisme que je propose aujourd’hui (qui transpose en v2 le processus qu’on avait déjà en v1), j’ai eu l’idée de la façon de le réaliser techniquement début 2026, il y a déjà 9 mois, mais les priorités à court terme étaient ailleurs. La date de la bascule était annoncée et il y avait plein d’autres choses à finaliser. Je me disais alors que proposer de supprimer le comité technique juste avant la bascule en v2 n’aurait pas été bienvenu, et que je proposerais cette idée après la bascule en v2.

Après la bascule en v2, j’ai eu besoin de prendre un peu de repos, puis, en revenant, j’ai priorisé Dunipod pour qu’on puisse remplacer le Cesium+ centralisé que Benoît veut décommissionner dès que possible.

Tout ça pour dire que je souhaitais la suppression du comité technique depuis déjà un moment, mais j’avais besoin que d’autres choses se décantent pour pouvoir prendre le temps de poser une proposition concrète.

10

Bonjour, je trouve l’idée de base très élégante : intégrer en soft-fork ce que les forgerons peuvent de toute façon faire en hard-fork.

D’un autre côté, vous pourriez aussi conserver le comité technique en plus mais le réduire à 2-3 “dirigeants” : la Ğ1 est de toute façon suspendue à l’existence de quelques mainteneurs. Ça ne me choquerait pas, surtout si vous intégrer la nouvelle proposition d’Eloïs en parallèle. Ça apporte la souplesse.

Je vous regarde de loin, mais comme ça j’ai l’impression de voir surtout Eloïs, Hugo et peut-être poka parmi les experts vraiment actifs.

11

Nope comme précisé sur un autre poste je prends ma retraite ici pour quelques temps tout du moins, trop occupé ailleurs.

Ma contre proposition est de passer elois root sur le réseau g1, ça me semble plus simple, moins prise de tête.

12

bonjour, pourrions-nous connaitre les membres du Comité Technique actuel svp ?
Merci :folded_hands:

13

Les membres du comité techniques sont visible ici : Ğ1 vote view

14

Il sont visibles dans Tikka.

15

Je ne suis pas dans le comité technique actuel de 8 personnes et souhaiterais encore moins y être s’il ne comportait que 2 à 3 « dirigeants ».

Être mainteneur de Duniter est très différent d’avoir le pouvoir d’acter un changement de runtime : les implications ne sont pas les mêmes.

Même si nous ne sommes que quelques mainteneurs, le code peut être relu et audité par des personnes qui ne sont pas mainteneurs, et devrait d’ailleurs l’être.

Nous devons également prendre le temps d’expliquer les motivations derrière chaque changement, ainsi que les raisons techniques qui nous poussent à choisir tel ou tel compromis.

Le fait que ceux qui actent les changements du runtime ne soient pas les mainteneurs oblige justement ces derniers à expliquer les changements et leurs motivations.

D’ailleurs, ceux qui ont le pouvoir « d’acter » les changements devraient soit les auditer eux-mêmes avec une IA frontier de leur choix, soit demander à des personnes reconnues pour leurs compétences techniques de le faire.

Si les personnes qui ont ce pouvoir redeviennent les forgerons, comme je le propose, je suis favorable à ajouter à l’engagement forgeron une obligation d’auditer ou de faire auditer les propositions de nouveau runtime.

Pour aider en ce sens, je compte écrire une petite documentation expliquant comment donner à un agent IA les moyens d’auditer un nouveau runtime, avec une proposition de prompt sur les questions à poser et une liste des modèles que je considère comme suffisamment intelligents pour réaliser un tel audit.

La confiance n’empêche pas le contrôle, et les mainteneurs peuvent parfois faire des erreurs ou mal calibrer certains compromis techniques (moi le premier).

Je pense que nous devons utiliser les progrès récents en IA pour permettre un contrôle plus décentralisé des changements. La barrière à l’entrée pour auditer les changements de runtime n’est plus aussi haute qu’elle l’était auparavant.

16

Question un peu bête, est-ce qu’actuellement il existe une IA capable d’auditer hors-connexion?

L’IA pose des soucis de centralisation, entre autres.

17

Je ne sais pas encore si un modèle local serait assez intelligent pour permettre à quelqu’un qui ne sait pas relire le code d’auditer le runtime de Duniter. Pour le moment, je ne fais confiance qu’à Opus 5.5 avec Claude Code et GPT 6.1 Sol avec Codex pour ce travail.

La harness, l’environnement qui permet au modèle d’explorer le code et d’exécuter des tests, est aussi importante que le modèle. Une harness mal adaptée peut fortement dégrader les performances d’un très bon modèle. Les modèles d’OpenAI sont optimisés pour Codex, ceux d’Anthropic pour Claude Code.

J’aimerais tester des modèles à poids ouverts, mais mes abonnements Anthropic et OpenAI sont avantageux pour mon usage. Tester d’autres modèles via une API ou du matériel dédié me coûterait trop cher.

Les plsu gros modèles à poids ouverts restent trop couteux pour particulier. Pour Kimi K3 par exemple, Moonshot recommande des configurations de 64 accélérateurs NVidia, soit déjà un mini data center. GLM 5.3 Flash est plus accessible : certaines versions fortement quantifiées fonctionnent sur 128 Go, comme un DGX Spark à environ 4 800 €. Pour une version 4 bits avec davantage de marge, il faut plutôt compter 10 000 à 11 000 €, avec deux Spark ou un Mac Studio de 256 Go.

Avec un accès à différents modèles et harness, je pourrais leur faire auditer des versions du runtime contenant des bugs ou vulnérabilités introduits volontairement, pour vérifier s’ils les trouvent. Je peux préparer ces tests et vérifier leurs conclusions avant de les conseiller.

Si quelqu’un dispose d’un DGX Spark ou d’un mac studio avec au moins 256 Go de mémoire, je suis preneur d’un accès SSH temporaire pour faire des essais.