bot 🇬🇧 2024-06-11

Cet article est une traduction automatique depuis sa version en anglais. Il contient certaines opinions de l'auteur qui pourraient ne pas ĂȘtre partagĂ©es par d'autres contributeurs de Duniter. (marquĂ©es par '🞰' dans le texte ci-dessous)

Duniter v2 alpha 🌀

Cela fait un moment que nous avons annoncĂ© la version 2 de Duniter dans cet article de blog. Depuis ce temps, beaucoup de travail a Ă©tĂ© accompli, non seulement sur Duniter v2 lui-mĂȘme, mais sur tout l'Ă©cosystĂšme v2, y compris l'indexeur Duniter Squid et les clients de version 2 comme Cesium v2 et Ğecko. Il est maintenant temps d'annoncer la version alpha de Duniter v2, prĂȘt pour les tests avec le rĂ©seau gdev.

Table des matiĂšres

  1. Une blockchain toujours autonome đŸ’«
  2. Rejoindre le rĂ©seau de test ☄
  3. La blockchain en tant que bien commun đŸŒČ
    1. Une solution au problùme des frais 💾
    2. Gouvernance onchain pour les mises-à-jour du code 🆙
    3. Un Ă©cosystĂšme logiciel construit avec la communautĂ© (🞰) đŸ€

Une blockchain toujours autonome đŸ’«

Duniter v1 est une solo chain gĂ©rĂ©e par les membres de la toile de confiance Ğ1. Bien que nous utilisions Substrate, le SDK de Polkadot, nous ne voulons pas ĂȘtre une parachain de Polkadot ou Kusama pour des raisons Ă  la fois techniques et politiques. Du point de vue technique, la toile de confiance nĂ©cessite de stocker beaucoup de donnĂ©es en blockchain ce qui est incompatible avec certaines limitations des parachains. Du point de vue politique, nous voulons que les outils restent entre les mains de leurs utilisateurs pour toujours et ne pouvons pas dĂ©lĂ©guer le consensus Ă  une "chaĂźne relais" qui coĂ»te de la "monnaie non-libre", mĂȘme si ce coĂ»t est offert dans le cadre du programme "common good parachain". C'est pourquoi nous invitons les membres de la Ğ1 qui tiennent Ă  son indĂ©pendance Ă  rejoindre le rĂ©seau de test gdev.

Rejoindre le rĂ©seau de test ☄

Nous avons dĂ©jĂ  lancĂ© plusieurs rĂ©seaux de test par le passĂ© pour nous familiariser avec la technologie. Maintenant que le logiciel se stabilise, nous sommes prĂȘts Ă  accueillir plus de personnes sur notre rĂ©seau de test gdev. Vous pouvez rejoindre en tant que nƓud miroir si vous souhaitez simplement dĂ©couvrir, et annoncer un endpoint RPC public si vous voulez participer Ă  la dĂ©centralisation. Si vous vous sentez confiant et souhaitez participer au consensus, vous pouvez mĂȘme exĂ©cuter un nƓud smith. La documentation est disponible dans la section wiki en anglais.

Le rĂ©seau de test est un moyen de se familiariser avec le systĂšme d'identitĂ© Duniter. Comme c'est un rĂ©seau de test, vous pouvez obtenir une certification sans rencontres IRL simplement en fournissant une clĂ© publique dans la section Ğdevdu forum. Les clients en version bĂȘta sont configurĂ©s pour se connecter Ă  ce rĂ©seau de test par dĂ©faut.

La blockchain en tant que bien commun đŸŒČ

Nous avons déjà mentionné l'approche "logiciel en tant que bien commun" du projet Duniter dans l'article précédent :

Bien commun : "une ressource gérée collectivement par une communauté"

Nous avons approfondi ce sujet avec la communautĂ© Ğ1, en particulier pour rĂ©soudre le problĂšme des frais, mais aussi sur les aspects de gouvernance. Plus de dĂ©tails ci-dessous.

Une solution au problùme des frais 💾

La blockchain est une ressource partagĂ©e et ouverte, pas comme un systĂšme multi-utilisateurs qui limite les connexions SSH Ă  un ensemble de clĂ©s prĂ©configurĂ©es connues, mais comme une machine virtuelle qui exĂ©cute le mĂȘme code de maniĂšre distribuĂ©e. Elle dispose d'un systĂšme de permission et doit prendre en compte le coĂ»t d'exĂ©cution si elle ne veut pas ĂȘtre attaquĂ©e par une attaque par dĂ©ni de service. Comme c'est un systĂšme distribuĂ©, il n'y a pas moyen de simplement se fier aux limitations par IP et d'autres mesures doivent ĂȘtre mises en Ɠuvre.

Les utilisateurs sont identifiĂ©s par une clĂ© publique cryptographique avec un nombre "infini" de possibilitĂ©s dans le sens oĂč il est extrĂȘmement improbable que la mĂȘme clĂ© soit choisie deux fois avec une gĂ©nĂ©ration alĂ©atoire correcte (IPv4 est de 32 bits, IPv6 est de 128 bits, nous utilisons des clĂ©s publiques ed25519 de 256 bits). Cela est nĂ©cessaire pour la sĂ©curitĂ© des clĂ©s mais empĂȘche l'application d'un quota par clĂ©. Parce que nous avons une toile de confiance, nous pourrions limiter l'utilisation de la blockchain Ă  un ensemble restreint de clĂ©s, mais cela empĂȘcherait les comptes anonymes (non liĂ©s Ă  une partie de la TdC) d'utiliser la blockchain. Toutes les blockchains publiques dont nous avons entendu parler ont adoptĂ© la mĂȘme solution : les frais. Toute opĂ©ration sur la blockchain coĂ»te de l'argent Ă  l'auteur, ce qui limite la quantitĂ© de ressources qu'il peut utiliser. De plus, les validateurs peuvent prioriser les transactions en fonction de leur propre intĂ©rĂȘt grĂące Ă  un mĂ©canisme de pourboire.

Cette solution a plusieurs problĂšmes incompatibles avec notre vision du logiciel en tant que bien commun et d'une monnaie Ă©galitaire :

Dans certaines situations comme Ethereum, le coût ("gaz") est devenu si prohibitif que de nombreux utilisateurs ont quitté la plateforme. Dans certaines situations comme Solana, le coût de base est si bas que les attaques DDos ne sont pas assez chÚres et se produisent fréquemment, déclenchant des frais de priorisation.

Dans notre recherche pour combiner le meilleur des deux mondes, nous avons trouvĂ© une solution qui devrait permettre une utilisation totalement gratuite de la blockchain la plupart du temps, et pendant les attaques une utilisation gratuite limitĂ©e par un quota pour les humains identifiĂ©s par la toile de confiance. Cette solution est basĂ©e sur le framework de benchmark de substrate. Comme nous connaissons assez prĂ©cisĂ©ment le coĂ»t du pire scĂ©nario en termes de taille de stockage et de temps d'exĂ©cution, ainsi que la capacitĂ© maximale de la machine de rĂ©fĂ©rence, nous pouvons dĂ©finir un seuil d'activitĂ© au-dessous duquel chaque action est gratuite. Lorsque ce seuil est dĂ©passĂ© — trĂšs probablement Ă  cause d'une attaque — les frais cessent d'ĂȘtre nuls et l'attaque s'Ă©puise par manque de moyens. Pendant ces attaques, les comptes non anonymes (= liĂ©s Ă  la toile de confiance) bĂ©nĂ©ficient toujours de frais nuls (sous quota).

Nous pensons que cette solution encouragera les personnes lassées des frais bancaires à essayer notre blockchain et permettra à des applications inattendues, non pertinentes en présence de frais, d'émerger. Par exemple une comptabilité interne transparente basée sur un systÚme de comptes publics au sein des organisations.

Gouvernance onchain pour les mises-à-jour du code 🆙

Les systÚmes avancés de gouvernance sur blockchain ("DAO") pour les mises-à-jour du code comme ceux utilisés par Kusama sont intéressants, mais :

Pour le moment, nous voulons simplement rendre le fonctionnement v1 plus transparent. D'abord, les dĂ©veloppeurs ont une idĂ©e, ils l'implĂ©mentent bĂ©nĂ©volement, en discutent avec les autres dĂ©veloppeurs, et la soumettent aux forgerons. Ces derniers ne sont pas nĂ©cessairement des techniciens, mais ils font confiance aux dĂ©veloppeurs et installent la mise-Ă -jour. En v2, nous devions impĂ©rativement augmenter la sĂ©curitĂ© du groupe forgeron par une toile de confiance forgeron (plus d'informations Ă  ce sujet plus tard) et nous devions nous doter d'une capacitĂ© de mise-Ă -jour plus rĂ©active, d'oĂč, un comitĂ© technique mieux informĂ©. Nous avons d'abord pensĂ© que ce serait un problĂšme de centralisation pour la communautĂ©, mais nous avons constatĂ© que : 1ïžâƒŁ c'est une particularitĂ© des systĂšmes de consensus sans fork qu'un systĂšme de vote plus sophistiquĂ© peut aider Ă  passer Ă  l'Ă©chelle mais pas rĂ©soudre (🞰), 2ïžâƒŁ ce n'est pas ce que la communautĂ© attend en matiĂšre de dĂ©veloppement logiciel, d'oĂč la section suivante (🞰).

Un Ă©cosystĂšme logiciel construit avec la communautĂ© (🞰) đŸ€

Ce que la communautĂ© attend vraiment n'est pas une perfection thĂ©orique dans le processus de prise de dĂ©cision, mais des Ă©volutions de l'application finale qu'ils auront en main. En d'autres termes, la maniĂšre dont les interfaces utilisateurs sont conçues est plus importante pour l'utilisateur moyen que les fondations techniques sur lequel elles reposent. Il est plus important que leurs demandes de fonctionnalitĂ©s soient implĂ©mentĂ©es dans un dĂ©lai raisonnable que le processus de cette mise en Ɠuvre. Nous concentrerons donc d'abord nos efforts sur l'Ă©tablissement et le maintien d'un lien fluide entre la volontĂ© de la communautĂ© et l'implĂ©mentation, et mettrons en place seulement ensuite des mĂ©canismes d'auto-gouvernance plus "bottom-up" que "top-down". Cela signifie que nous expĂ©rimenterons probablement d'abord avec des systĂšmes d'information et de vote offchain avant de les implĂ©menter onchain.