Je pense qu’il est temps d’animer la discussion sur la gouvernance de la blockchain v2. J’ai reçu plusieurs sollicitations d’utilisateurs et ai moi même plein d’idées. Si on est prêt à temps, on pourra l’implémenter d’ici la migration, sinon on pourra le faire après, mais dans tous les cas, il faut que ce soit réfléchi collectivement.
Voici certains sujets qui peuvent alimenter la réflexion:
Dans l’idée, on devrait travailler le sujet en amont en petit groupe avec 1-2 devs et 4-5 utilisateurs et proposer un atelier bien plus large pour les RML17. Cet atelier pourra avoir lieu avec tous les devs sur le camping pour associer un maximum de personnes par exemple le mercredi matin où le FISH n’est pas disponible.
Quelques informations à prendre en compte dans la discussion :
la question de la gouvernance est trop importante pour être laissée à la charge seule des développeurs. Ce serait à la fois une responsabilité trop lourde et un piège de mauvaise représentation. Nous avons absolument besoin que des utilisateurs s’emparent de cette question
lorsque l’on doit implémenter quelque chose, il faut que tout soit spécifié dans les moindres détails (personnes éligibles au vote, durée du vote, conditions de cloture du vote, conditions de soumission d’une proposition, quotas, seuils, …) on ne peut donc pas se contenter d’idées générales, il faut les expliciter méticuleusement
les contraintes techniques ne devraient pas déterminer la forme que prendra cet outil de gouvernance, mais il peut arriver qu’elles viennent alimenter la réflexion. Elles doivent être prises en compte à un moment ou un autre, d’où la nécessité de faire travailler ensemble les utilisateurs (en essayant d’être représentatif de la communauté Ğ1) et les développeurs (à la fois en tant que membres, mais ayant la compréhension technique)
le pouvoir de modification du code représente un pouvoir absolu sur le futur (le passé n’étant pas modifiable dans une blockchain), il permet de tout faire et ne doit donc pas être pris à la légère. Pour l’instant dans la v1 il est détenu par les forgerons, dans le code actuel de la v2 il est détenu par un comité technique fermé modifié par vote de celui-ci. Idéalement il doit être détenu par la communauté entière sans que cela soit bloquant pour prendre des décisions.
l’abstention est souvent majoritaire, et doit être systématiquement prise en compte.
le consentement est une notion fondamentale qui doit éclairer toute réflexion de gouvernance
toutes les décisions étaient déjà possibles en v1, mais compliquées car nécessitant une mise à jour logicielle et risquées car si les forgerons étaient divisés, la mise à jour pouvait donner lieu à un fork et donc scinder la monnaie en deux. L’avantage de la v2 sur substrate, c’est les “forkless runtime upgrades”, c’est-à-dire la possibilité de faire des mises à jour sur l’ensemble du réseau une fois le consensus établi. De plus certaines décisions ne nécessitent pas de mise à jour de code, juste l’appel d’un extrinsic, ce qui facilite grandement leur application et permet de gérer un plus grand nombre de propositions.
dans la réflexion sur le système de vote, il faut prendre en compte la compréhension de ce pour quoi on vote. Ça implique de produire et valider des informations vulgarisées mais correctes dans la langue maternelle du membre, et de garantir leur validation officielle pour éviter la désinformation.
Quelques exemples de décision qui doivent pouvoir être prises (ou pas) :
correction de bug : cette décision est souvent très technique et difficile à vulgariser, et nécessite une modification du code (donc le plus haut degré de pouvoir). Elle doit pouvoir avoir lieu relativement vite pour limiter l’impact du bug. Il peut arriver que révéler en détail la nature du bug facilite son exploitation en attente d’une correction, et donc doit être prise dans un certain secret. Cette décision nécessite une forte confiance dans un nombre limité de personnes ayant des compétences techniques poussées, c’est un cas très délicat à mon avis, il faudra le détailler en visio.
modification d’un paramètre : cette décision peut être assez simple à expliquer et ne pas nécessiter de modification de code (dépend des cas). Mais elle peut avoir un impact très fort sur la communauté. Exemple : changer le nombre de certifications nécessaires pour produire le DU ou être à son tour capable de certifier
nomination d’un forgeron : les forgerons ont en temps normal un rôle essentiellement technique, mais ceci peut prendre une dimension importante dans les moments de conflits car ils sont en mesure de produire un fork, c’est-à-dire s’accorder sur une version alternative de la blockchain, et donc de scinder la communauté en deux. Normalement les forgerons sont gérés par la sous-toile forgeron, mais un vote pourrait par exemple aboutir à la nomination de forgerons hors toile de confiance. Ce point aussi nécessite des échanges poussés en visio
éjection d’un membre : pour être bien clair, ceci est déjà possible en v1 si les forgerons s’accordent pour une mise à jour du code qui prive un utilisateur de son statut de membre, ce n’est donc pas spécifique à la v2. C’est une décision qui ne nécessite pas forcément du pouvoir de modification du code, mais a une énorme portée symbolique. Un système de gouvernance doit être en mesure de prendre ce genre de décision sans que cela impacte la confiance de la communauté dans la Ğ1. Ce genre de décision peut être légitime si on se rend compte qu’une personne a plusieurs comptes membres. Se doter explicitement ce cette capacité peut augmenter la confiance globale dans la toile si ses conditions d’application sont justes et consenties par une immense majorité.
amende : pour démystifier, c’est également possible en v1 si une majorité des forgerons s’y accorde. Un organe de gouvernance peut décider de retirer des Ğ1 à un compte pour les mettre sur un autre (trésorerie commune par exemple, ou compte inaccessible). Encore une fois, il faut s’assurer que ce genre de décision ne soit pas pris de manière abusive. Mais si on se rend compte que quelqu’un a mené une grande escroquerie, il peut être pertinent d’avoir un moyen d’action pour lui retirer les Ğ1 mal acquises
récupération d’un compte perdu (solde ou identité) : en v1 c’est aussi possible via une mise à jour logicielle d’une majorité de forgeron, mais c’était un processus très lourd, donc on ne l’a jamais fait. En v2 ce sera plus facile, il faut donc savoir si on se l’autorise (on peut aussi décider de ne pas le faire, c’est-à-dire de refuser de traiter ces propositions, mais c’est en soi une décision de gouvernance). Une des difficultés de ce genre de décision est que l’on peut recevoir de nombreuses demandes et ne pas avoir la capacité de les examiner. Le processus de gouvernance doit donc avoir un mécanisme anti-spam pour éviter d’avoir à gérer trop de propositions impossibles à traiter. Mais sous certaines conditions, on pourrait vouloir permettre la récupération de compte, tout en s’assurant que ce ne soit pas utilisable à de mauvaises fins.
Je vais prochainement proposer une date pour une visio. Pour l’instant les personnes que je sais intéressées (n’hésitez pas à signaler votre intérêt pour écouter / participer à ces discussions, tout en sachant qu’il y aura un grand atelier public au RML17 et que ceci est surtout un travail de préparation en amont) :
Caroline (rencontrée chez Yvv)
Fab (sur Telegram “questions aux développeurs”)
Bertrand Ollivier (sur Telegram “questions aux développeurs”)
Je pense qu’il faut au moins se soumettre à cette contrainte technique, car la contourner est faisable mais très compliqué et lourd, et qu’elle a des conséquences non négligeables sur la gouvernance :
il est impossible de voter de manière à la fois anonyme ET vérifiable
C’est-à-dire que les personnes qui peuvent vérifier le résultat du vote (au moins tous les membres, mais c’est pareil avec un comité réduit d’assesseurs) savent qui a voté quoi.
Pour des votes périodiques à dates fixes, ce que j’appellerais l’opposition (ceux qui ont “perdu” le dernier vote) patiente et attends la prochaine échéance pour tenter de renverser le vote en sa faveur.
Comment gérer ces nouvelles tentatives dans un vote qui n’est pas périodique ? Si l’opposition a convaincu plus de votants à sa cause, peut-elle demander un nouveau vote ? Mais à quelle échéance ?
Je n’ai pas de réponse pour cela, mais la durée d’une décision et la condition préalable de sa remise en question potentielle doit être précisée pour éviter les demandes de votes à répétition dans des délais trop rapprochés.
Bonjour, tout ça me semble fort technique. Pourtant, je veux pourtant bien être tenue au courant des rencontres. Car évidemment il faut que ces choix de gouvernence soit accessible à tout les membre.
Bien d’accord sur privilegier le fonctionnement par consentement (si on est d’accord qu’il s’agit de decision par levée d’objections argumentées)
Dans ce cas, cela change la notion d’abstention, puisque par ce type de consentement, la particularité est l’expression d’une objection et non le silence…
Du coup, cela necessite de pouvoir donner une valeur aux “objections argumentées”.
Bien d’accord également sur le besoin que tous aient accès à une information fiable pour pouvoir décider. Du coup, cela va poser le problème d’un système de verification et de validation des informations et/ ou formulations et/ ou d’interpretation de la situation, des possibilités, des contraintes techniques etc…
Ça peut, pour éviter de biaiser les votes par le jugement social ou l’intimidation. Quelqu’un qui voudrait acheter mon vote ou me menacer, ne peut savoir si j’ai voté pour lui ou non.
Ou alors quand une personne est directement impliquée, ça peut réduire le sentiment d’être obligé de voter ça ou ça pour ne pas blesser la personne qu’on connaît ou pour ne pas être jugé par les autres, etc.
Le débat transparent est important mais la possibilité de l’anonymat l’est aussi.
Mais je pense que ce n’est pas nécessaire pour commencer, et pour les décisions qu’on devra prendre. Ce sera un chantier pour plus tard.
prendre des décisions dans le cadre que tu évoques là ne semble pas une être une solution. si le module de votation de substrate n’ est pas opérationnel soit on rend le vote de certains random représentatifs d’ un échantillon acceptable (1/1oo dévoilés) soit nous devrions changer de système
Alors là quand je lis cela sur certain point s’est du développement mais pour d’autres point on peut apercevoir une forme de dérive avec le même paradigme que nous sommes avec la monnaie dette où un petit quorum auraient le pouvoir décisionnelle sur tout le monde?
déjà cela parle de quorum donc qui sera le quorum et comment il sera composé, nommé, pour combien de temps?
1: Pourquoi une nomination de forgeron? si une personne souhaite de mettre une noeuds chez lui pour aider la communeauté à utilisé la june pour que les échange soit plus fuide, il ne pourrait pas car il n’a pas été choisie par ce quorum?
2: Pour les amendes, normalement personne ne peut aller prendre sur le compte d’une personne ou à moins que dans le code il y a des backdoors pour permettre se genre de pratique? C’est normalement le rôle de la Toile de Confiance. Laissons le rapport entre humain gérer dans des discutions au gapéros, gmarché, et autre. C’est le rôle du groupe humain proche de la sitaution qui gère cela car ils seront à même d’avoir le regard juste sur la situation.( reprenons notre souveraineté humaine).
et en relisant je pense pas que les forgerons soient au dessus des autres pour décider ou de juger ils sont là que pour faire vivre la june sinon on prend des carnets comme dans le jardin d’échange universel.
3: Pour l’éjection d’un membre il se fait naturelement au bout de deux ans si la personne a démontré aux autres personnes qu’elle n’ai pas juste, morale ou bienveillante en vers les autres personnes elle ne sera pas re certifier et le bouche à oreille va vite.
Enfin que l’on ai un outil pour faciliter les échanges ok, que l’on règle les soucis, les anicroches du logiciel et que l’on ajuste cette outils pour du positif je suis d’accords. Mais si c’est pour faire une transition avec une forme de systeme pseudo verticale comme nous connaissons actuellement. Cela va à l’encontre des propos tenu dans les réunions d’informations où le systeme est horizontale ( ce qui permet que tous le monde soient responsable d’eux même, s’engagent et soient acteurs dans cette monnaie) et je le répète reprenons notre souveraineté humaine et créons ce nouveau paradigme sur la confiance en vers l’autre.
Je pense que si il y a lieu de prendre des décisions à propos de la G1 elle doivent être prise avec tous les membres actif de la G1, un systéme de votation sur 15 jours.
Je ne vois pas pourquoi des “Forgerons” aurais plus de droit. si l’on désir de l’horizontalité il faut prendre toute les décisions de façon horizontal.
explication de chat GPT a un enfant de 6ans pour que je comprenne:
"Actuellement, nous utilisons un système où les gens doivent travailler dur pour ajouter une nouvelle page au livre, en résolvant un puzzle mathématique difficile. Mais bientôt, nous allons utiliser un nouveau système qui va choisir aléatoirement la personne qui va écrire la prochaine page. Ce système est très juste et personne ne peut tricher.
De plus, une fois que la page est écrite, les ordinateurs qui vérifient les informations vont voter pour dire si tout est correct. Si tout le monde est d’accord, la page est ajoutée définitivement au livre."
je pense que le titre du poste “Gouvernance” m’a quelque peu irrité la corné et me faire secréter du liquide occulaire.
Je reviens sur le commentaire oùj’ai esséyé de comprendre ce principe de sous toile de forgerons par une retranscription vulgarisé par ChatGPT.
Après mûre réflexion pour moi la june était basé sur le coté décentralisation où chacun sans avoir une autorité supprême au dessus de lui peu avoir et faire tourner un noeud duniter.
cela pourrais conduire à une sélèction par accointance des forgerons.
Ce qu’il n’est pas dû tout en phase avec la license. Et cela ne va par en alignement avec mes valeurs qui on fait que je suis entré dans la june.
L’ “autorité” dont tu parles existe déjà dans Duniter v1 : c’est le pouvoir législatif incarné par les développeurs du fait de l’écriture nécessaire de code source pour le logiciel.
L’adoption de ces lois se fait déjà dans Duniter v1 par simple “demande” de la part des développeurs, et les nœuds forgerons se mettent à jour sans vraiment avoir vérifié que le logiciel téléchargé contient bien ce qui est supposé être présent dedans (à quelques rares exceptions près).
La différence dans Duniter v2 c’est que l’adoption des lois de la blockchain se fait à chaud, sans intervention particulière des hébergeurs de nœuds. Le processus d’adoption est directement écrit dans le protocole de la blockchain, qui permet de stocker les lois dans la blockchain et le processus associté pour les mettre à jour.
Donc Duniter v2 ne fait jamais qu’industrialiser et rendre contrôlable le processus de mise à jour de la blockchain.
Il n’y a pas plus de “pouvoir” des développeurs que dans Duniter v1 à mon sens, c’est même plutôt le contraire car il ne suffit pas juste que je demande sur un obscur forum la mise à jour pour que celle-ci se réalise. Non : il faut un vote, public, sur un plan de mise à jour qui contient explicitement la date de mise à jour planifiée, l’empreinte exacte de l’ensemble des lois qui seront alors en vigueur à cette date, de sorte que d’autres développeurs puissent vérifier avant que des votes ne soient soumis.
En plus le comité technique peut être assez large (je crois me rappeler qu’il est possible de monter à 1.000 personnes, peut-être plus, il faudrait vérifier).
Et dans tous les cas il est toujours possible pour des gens qui ne sont pas d’accord avec la tournure que prend la blockchain de la forker et forcer l’utilisation de leurs propres lois.
Bref, démystifions cette histoire d’autorité comme si celle-ci sortait d’un chapeau des développeurs qui voudraient encore plus de pouvoir.
des intrusions systématiquement éludées et qui reviennent en plus à mettre l’ integrité des comptes en porte à faux lorsqu’ on présente la G1 à des nouveaux
je demande donc une preuve à ceux qui l’ affirment que les comptes G1 v1 pourraient etre prélevé à leur dépend sans quoi nous sommes face à une tentative de détournement subventionné
AVERTISSEMENT : Je ne suis pas certain de ce que j’avance, donc j’invite le lecteur ou la lectrice à faire fonctionner son cerveau et à tourner sept fois ses mains sur son clavier avant de répondre.
Vous pouvez directement mentionner @HugoTrentesaux, qui affirme cela.
Mais c’est assez facile d’imaginer une évolution du code de DuniterV1 qui indique, par exemples :
nous ne traiterons pas les transactions allant vers les comptes X,Y et Z (censure de certains comptes)
nous appliquons une exception sur les règles de dépense des Ğ1 au bloc X, et nous appliquons une amende :
-1000 G1 sur le compte X
+1000 G1 sur le compte A
nous appliquons une exception sur les règles au bloc X pour supprimer les certifications du compte membre Y afin de l’éjecter de la toile.
… Toute la difficulté étant de faire accepter ce code à la majorité des noeuds.
Par ailleurs, il est à noter que la liste de possibilités est intitulée ainsi :
Si je ne me trompe pas, Hugo indique ce qu’il est possible de faire en appliquant un appel ‘sudo’. Il mentionne les pouvoirs que pourrait avoir le comité technique si les règles les lui donne. Il est très sain de dire ce qui est possible, pour décider si ça doit rester possible de le faire ou pour décider si on restreint cette possibilité.
La question de la gouvernance couvre :
que peut-on prendre comme décisions ? càd :
qu’est-ce qui est possible techniquement. Par exemple, même si tous les junistes le voulaient, Duniter ne peut techniquement pas faire pousser des pommiers.)
parmi ces possibilités technique, qu’est-ce que les règles restreignent (et inversement, qu’est-ce que les règles autorisent) ?
qui peut les prendre et selon quelles modalités ? (faut-il un certain pourcentage de toute la toile pour prendre une décision, et si oui lequel ?)
l’ atelier est très respectable en soi et avant les rml, un débrief sur ce forum necessaire.
la comparaison entre v1 et v2 doit en revenche rester objective. prélever un compte signifie aujourd’ hui violation de propriété et si un code different autorisait cette extorsion même par consensus majoritaire nous ne parlerions encore une fois plus de la G1 et la minorité qui residuellement maintenait la blockchain originale reprendrait simplement le cours des choses sans accro et donc sans la violation
Je trouve que dans tes formulations (cette citation n’est qu’un exemple parmi d’autres), tu instruis à charge, comme si les développeurs de la v2 étaient de gros ripoux que tu es en train de démasquer. Ce serait sympa d’être un poil plus… sympa.
