C’est suite à une recommandation de @kimamila l’été dernier que j’ai décidé de confondre ces 2 droits, pour répondre à son besoin de garder un fonctionnement le plus simple possible à expliquer.
Mais plus j’y pense et plus ça me pose vraiment problème que ces deux droits soient confondus, chacun d’eux exige des prérequis bien différents, et implique des responsabilités différentes également.
Les confondre me semble avoir trois effets néfastes :
- Cela oblige à être plus strict sur qui peut être forgeron, ce qui impacte directement la rédaction de la licence forgeron.
- Cela oblige à exclure du droit à voter les runtime upgrades ceux qui ne souhaitent pas ou peuvent pas être forgeron.
- Cela concentre trop de pouvoir aux mains des mêmes membres.
Être forgeron nécessite de disposer d’au moins un serveur dédié (éventuellement chez soi, pas nécessairement en datacenter), un peu de compétences d’adminsys, savoir sécuriser correctement un serveur, savoir monitorer son nœud autorité, et avoir la rigueur de le maintenir dans la durée.
Participer au vote sur les runtimes upgrade nécessite de savoir recompiler soi-même le runtime pour le vérifier, avoir les compétences pour comprendre les changements proposés, et avoir la rigueur de voter chaque proposition.
Par exemple, @tuxmain ne peut pas être forgeron, car il n’a pas de serveur à lui sous architecture x86_64, alors qu’il me semble légitime à voter les runtime upgrade.
À l’inverse, un adminsys professionnel membre de la Ğ1 mais qui ne contribue pas techniquement et ne comprend pas le protocole, me semble légitime à être forgeron, mais pas à avoir beaucoup de pouvoir sur les runtime upgrades.
Comment dissocier ces deux droits ?
Il y a sans doute plein de modalité possible, je pense que l’on doit trouver des modalités qui répondent aux contraintes suivantes :
- Dilution maximale du pouvoir
- Possibilité de faire passer un hotfix (ou correction de storage) très rapidement si nécessaire.
- Filtrage des propositions fantaisistes
- Protection contre les tentatives de sabordage (par exemple, pousser volontairement un runtime qui casse la blockchain et mettre les moyens en ingénierie sociale pour faire voter les gens pour).
Il est probable que cela nécessite au moins deux groupes : un groupe restreint qui filtre les propositions, et un groupe plus étendu (potentiellement tous les membres de la wot), qui vote pour ou contre les propositions qui ont été approuvées par le 1ᵉʳ groupe. Avec une possibilité pour le groupe restreint de créer des propositions d’urgence, qui auraient des modalités différentes en termes de quotas et de seuil.
Le diable se cache dans les détails, et notamment dans les conditions de seuils et quotas.
Pour éviter d’être bloqué par ceux qui ne votent pas parce qu’ils ne savent même pas qu’il y a un vote ou qu’ils s’en foutent, il me semble essentiel de ne comptabiliser que les membres qui ont indiqué explicitement qu’ils souhaitent participer régulièrement aux votes, ou alors carrément une inscription par scrutin.
On peut également faire du tirage au sort on-chain grâce à la source d’aléatoire vérifiable et non manipulable que nous fourni BABE.
Concilier dilution du pouvoir et sécurité est un dilemme très difficile, mais je pense qu’il est de notre devoir de faire au mieux pour diluer au maximum le pouvoir sans faire courir de risque non négligeable à la Ğ1.
Je propose qu’on commence à y réfléchir entre nous sur ce sujet, puis qu’on se fasse des visios dédiées, puis d’en discuter lors d’évènements IRL, idéalement avec des utilisateurs, pas juste entre informaticiens, car la gouvernance de notre blockchain concerne tous les membres de la Ğ1 