Mmh, en fait j’ai dit une bêtise 
C’est interdiction d’avoir moins que 1.00 unité dans la base courante.
Je n’en était pas sur, et avec la base et le DU actuel c’est la même valeur donc ça aide pas 
Discussion à propos de l’utilisation de Merkle tries comme structure principale des blocs et qui permet de “stocker” l’état de la monnaie, permettant de supprimer des anciens blocs au fur et à mesure, ainsi que de prouver certaines informations que pourraient demander des clients (les nœuds ne seraient donc plus des tiers de confiances pour ces requêtes).
La RFC à été mise à jour pour prendre en compte les idées exprimées, et la partie “Block” contiendra les détails de la structure du Merkle tree.
1 Like
Nouvelle mise à jour : structure du document revue pour essayer de le rendre plus digeste. Intègre aussi les dernières idées au niveau des transactions et un nouveau format d’addresses unifié.
Ces derniers jours je relis pas mal d’anciens posts du forum pour voir les différentes réflexions autour de Duniter et de certaines faiblesses. L’une d’entre elle est que l’équipe de développeurs à un pouvoir assez important sur les choix d’évolutions. Ne serait-il pas une bonne idée d’intégrer à la blockchain un système de vote qui permettrais de modifier certains paramètres ? De plus, essayer de déplacer un certain nombre de limites qui sont codés en dur en paramètres intégrés à la blockchain, de telle sorte qu’elle puisse évoluer sans nécessiter de modifications dans le code ?
Avec les techniques exposées précédemment sur les groupements de transaction, on se rend compte que les votes seraient très simple a intégrer et qu’après leur échéance leur données pourraient être oubliées.
A quel paramètres tu penses ?
La plupart des paramètres de la blockchain qui pourrait s’adapter à son usage sans modification du code ou fork de la blockchain. L’idée est simplement de pouvoir faire évoluer les règles de la monnaie sans avoir besoin d’avoir des connaissances techniques en informatique, et sans devoir attendre que l’équipe de dev en ai envie ou aie le temps.
Pour ma part je ne comprends pas trop pourquoi le DU est actualisé tous les 6 mois et pas plus régulièrement, de sorte qu’elle s’adapte rapidement aux nombre de membres et d’avoir une évolution continue du DU et éviter des “cassures” tous les 6 mois.
Si d’autres personnes pensent la même chose, il est possible d’en parler, et de proposer aux membres un changement. S’il obtient la quasi-totale majorité, alors il est accepté automatiquement par le protocole. On peut envisager ça pour le temps inter-bloc, si on veut augmenter la rapidité de validation des transaction; voir même c s’il s’avère que dans quelques décennies l’espérance de vie d’un humain soit significativement plus longue (ou plus courte, pourquoi pas).
Pour moi ce qui est important c’est que tout le monde puisse participer et donner sa voix, et pour ne pas qu’un petit groupe comme le “staff” semble prendre toutes les décisions, ce qui à déjà été remonté sous la forme de “malaises”.
1 Like
A cause de ça : Nombre de chiffres requis pour le DU - #4 by Galuel
Sinon, faire un protocole qui change c’est vraiment compliqué. Je comprends bien la problématique, cependant, rien n’oblige à l’implémenter pour la v11. Il faut savoir rester raisonnable dans les objectifs recherchés…
La v11 ne sera pas la dernière version du protocole de toute façon. Il n’y aura techniquement jamais de dernière version, toujours de nouvelles choses à faire.
Ya un moment ou il faut savoir fermer le cahier des charges. Ce qui n’empêche pas de réfléchir en profondeur sur la méthode de gouvernance de la blockchain pendant ce temps, pour une version ultérieure.
L’intention est louable mais je pense que c’est très dangereux pour la simple et bonne raison que sur les sujets pointu la majorité a souvent tord.
Ceci étant il y a une infinité de dégradés entre notre fonctionnement actuel et une démocratie totale, et je suis favorable a une gouvernance davantage partagée, a impliquer davantage les utilisateurs dans les décisions.
Cependant, le vote direct a la majorité me semble être une très très très mauvaise méthode et je suis convaincu qu’un tel choix nous mènera a la mort technique de la monnaie suite a une mauvaise décision de la majorité.
Je n’ai pas la solution idéale, je pense que nous devrions demander conseil a des spécialistes ie gouvernance, je sais que @poka a une certaine expérience en gouvernance sur un autre projets, j’aimerais que tu nous apporte ton point de vue poka, sans doute d’autres personnes un t’elle des connaissances dans ce domaine, manisfestez-vous
Ma crainte principale est la suivante : Imaginons en décision entre deux choix A et B, que la grande majorité des utilisateurs souhaitent A mais qu’une partie des informaticiens ou théoriciens y soient fondamentalement opposés, expliquent et démontre que c’est très dangereux, mais hélas la plupart des utilisateurs ne comprennent pas ces explications trop techniques et maintiennent leur vote pour B : et suite a ce mauvais choix un problème technique majeur survient et la monnaie s’arrête (ou son bon fonctionnement est fortement altéré).
Une solution serait peut-être que les développeurs de la duniter team est un droit de véto pour bloquer un changement qu’il considérerait trop risqué.
Typiquement, la réévaluation du Du tout les 6 mois, il y a des raisons techniques précises qui l’impose liés au nombre de chiffres que l’on stocke dans Duniter pour stocker le montant du DU. Et même si dans le nouveau protocole tu veut descendre au millième plutôt qu’au centime, ça ne déplace que peu la limite.
Un fonctionnement qui me conviendrai, et que j’ai déjà cité plusieurs fois dans mes discussions perso, ce serait un mécanisme de prise de décision par traitement des objections, inspiré par exemple de l’Holacraty.
L’idée est qu’un changement ne peut être acté que s’il n’y a plus aucune objection valide a ce changement (que toutes les objections valides ont donc été traitées). Alors oui c’est possible d’implémenter un tel protocole mais c’est encore plus compliqué que le protocole de la monnaie ou de la wot, j’ai lu en entier le protocole holocraty (il y a longtemps déjà) il me semble vraiment très bien fait mais aussi très complexe a implémenter :
5 Likes
Merci, ça va me faire une très bonne lecture.
2 Likes
Ça vaut vraiment le coup, c’est un système vraiment très bien fait, et qui m’a fait définitivement rompre avec le concept archaïque de “vote”
Je pense que cette discussion va intéresser @1000i100 aussi 
Pour compléter mes propos : la V11 va devenir rapidement importante pour des raisons de performances et de robustesse du réseau avec la montée en charge.
La gouvernance peut encore attendre, prendre des décisions tel que modifier c ou la vitesse de calcul des blocs, il n’y en aura pas besoin avec une dizaine d’année minimum.
2 Likes
Quand je parlais de vote, c’était bien pour exprimer une prise de décision et non une méthode particulière 
Cela reste toutefois beaucoup trop complexe pour le moment, donc on verra plus tard.
J’essaye surtout de faire un protocole qui permettra de rajouter de nouveaux éléments avec le moins de hard fork possibles. On pourrait par exemple mettre les paramètres dans l’état, mais pas encore de moyen de les changer.
2 Likes
+1, je serait favorable a ce qu’on réfléchisse a l’intégration d’un protocole de gouvernance pour la v12. Mais se sera long, on peut par exemple se fixer comme objectif une v11 stable pour 2020 et une v12 avec gouvernance intégrée stable pour 2023.
3 Likes
La lecture est un peu trop conséquente pour que je m’y atèle maintenant, mais de ce que j’en connais, cela me semble des mécanisme en effet très intéressant pour s’adapter efficacement aux nouvelles situations entre individu fortement investi par une raison d’être commune.
Hors, plus la communauté grandi, moins il me semble probable qu’elle constitue un groupe d’individu fortement investi et avec un raison d’être commune, donc je ne sais pas à quel point ce système serait robuste face à une incitation financière à grande échelle pour faire pencher des choix dans une direction.
Pour ça, le véto de facto des développeurs de part le besoin d’aller changer le code me semble un compromis temporairement acceptable.
Des règles plus facilement changeable que ce soit par vote simple ou par d’autres méchanisme (comme ceux inspiré de l’holacratie), me semble pouvoir prendre toute leur place quand il n’y aura plus une monnaie libre unique, dont la réputation et la confiance dans ses fondement théorique dépend, mais un ensemble de monnaies libres certaines plus stable et conservatrice, d’autres plus expérimentales…
Mais nous en somme loin aujourd’hui.
4 Likes
http://trm.creationmonetaire.info/appendice-2.html#les-4-libertes-economiques
Pour rappel, la première des 4 liberté défini dans la trm est tout de même :
- La liberté de choix de son système monétaire
Sans quoi la position monopolistique d’une monnaie, fut-elle basé sur Duniter, ne pourrais plus être considéré comme libre.
Et cela me semble valable que le monopole soit un monopole légal, ou un monopole d’usage / de facto par une position de premier arrivant notable.
Mais je dérive (un peu) du sujet “protocole v11”
Je rappelerais simplement le sens de liberté tel que défini par TRM : non-nuisance. Un protocole qui permet à des personnes de nuire par vote au choix réalisé par les autres ne saurait implémenter une monnaie libre.
2 Likes
Exactement c’est l’un des aspects qui me dérange dans le vote. Il ne respecte pas le principe de non-nuisance. Si un choix est nuisible pour un individu, alors c’est que les implications de ce choix génèrent une ou plusieurs tensions chez l’individu, tensions qui peuvent être traités et accompagnés pour être transformés en objections constructives avec d’éventuelles propositions de reformulation/modification du choix de départ. C’est en quelque sorte ce que propose l’holacraty.
Au final c’est déjà ce que nous faisons de manière non formalisée sur ce forum concernant les choix techniques, on traite toutes les objections, ce qui transforme la proposition initiale jusqu’a devenir une proposition pour laquelle il n’y a plus d’objection valable (où jusqu’a abandon de la proposition si au moins une objection n’est pas résoluble).
Mais a plus grande échelle, il faudra bien que l’on finisse par formaliser nos process de décision internes au sein de la duniter team et plus largement au sein de l’ensemble des contributeurs.
La communauté g1 dans son ensemble certes, mais la duniter team et plus largement l’ensemble des contributeurs techniques constituent bien un groupe fortement investi et avec un raison d’être commune, et cela sera toujours ainsi.
l’Holocraty n’est pas adaptée aux petits groupes, nous sommes encore trop peu de contributeurs pour l’expérimentée, mais elle est en revanche particulièrement adaptée aux grands groupes. je me souviens du témoignage d’un patron de startup ou la gouvernance n’étais pas formalisée, il se sont posés la question de la gouvernance lorsqu’il ont dépassés la quinzaine de permanents, et sont alors passer en Holacraty.
Pour ce qui est de la façon d’impliquer davantage les utilisateurs qui ne sont pas contributeurs, la 1er des choses est déjà de communiquer sur nos grandes décisions et leur pourquoi dans les grandes lignes, se sera déjà un grand pas en avant
Ensuite, faciliter la contribution, pour ça il faut des contributeurs disponibles et disposés a accueillir et accompagner les nouveaux souhaitant contribuer, ce qui prend du temps et de l’énergie 
En revanche, concernant la question de faire participer aux choix techniques des utilisateurs qui ne contribuent pas et qui ne s’exprime pas sur l’espace de discussion dédié a ces choix, je n’y suis pas favorable. Je suis d’avis qu’une personne n’a de poids légitime sur une décision que si elle fait l’effort de s’informer et d’exprimer sont point de vue. En bref, qui ne dit mots consent.
3 Likes
Ce qui me semble important, c’est la transparence. Dans la mesure où le code est libre et vérifiable par tous, il y a déjà une transparence intrinsèque. Il est vrai que ce peut être « obfusqué » pour les non-informaticiens. Le seul risque ici est plutôt la prise de pouvoir par les informaticiens sur la vie de la monnaie, mais quand on dit « les informaticiens », ce n’est pas « le staff du forum duniter », c’est bien « l’ensemble des informaticiens du monde ». Et même si dans cette catégorie il y a probablement des individus qui ont soif de pouvoir, il ne s’agit que d’une minorité au regard de la communauté entière des informaticiens. Il y aura toujours de bonnes âmes parmi eux pour dénoncer ce qui est contraire à l’intérêt général.
Tu dis qu’actuellement il faut que « le staff » prenne une décision pour qu’elle soit implémentée. Je répondrais que si un sous-ensemble de membres n’est pas d’accord avec telle ou telle décision, rien ne leur interdit de faire leur propre fork. Et si tu argues qu’il leur faut des informaticiens pour ça, il leur en faudrait aussi en cas de vote : si aucun informaticien n’a envie d’implémenter une fonctionnalité parce que tous les informaticiens la jugent mauvaise, on revient à la même situation. Le vote en blockchain pourrait uniquement être un moyen de faire pression sur les informaticiens autour de fonctionnalités qu’ils ne veulent pas implémenter. Ils peuvent avoir de bonnes raisons pour le faire par le fait qu’ils sont experts dans le domaine, mais aussi de mauvaises, comme refuser d’implémenter une fonctionnalité qui pourrait leur retirer du pouvoir.
À ce sujet, je partage l’avis d’Éloïs : l’un des principaux problèmes du vote populaire, c’est qu’il est souvent affectif et émotionnel plutôt que raisonné et décidé en toute connaissance de cause. D’autre part, les décisions à prendre sont souvent liées à des choix techniques qui sont difficiles à expliquer à tous. On le voit bien, même ici, un choix qui paraît « simple » comme le choix de l’intervalle de réactualisation du DU n’est pas trivial et nécessite des connaissances que même un très bon informaticien peut avoir « zappées ».
Ce qui manque peut-être est un « cahier des charges explicatif » qui résume les choix faits, leurs principaux contre-arguments et leur réfutation ainsi que d’éventuelles références pour ceux qui veulent en savoir plus, afin que tous aient un accès encore plus transparents aux choix pris et leurs raisons. Il y a déjà un wiki en place, comme dirait Ğaluel, yapluka.
5 Likes