Je vais vous décrire le fonctionnement de ma 1ère implémentation de la sous-toile forgeron, ce ne sera pas forcément le fonctionnement définitif, certaines choses pourront changer d’ici la migration effective sur la Ğ1 (et même après, rien n’est figé à jamais).
Rappel du pourquoi
Avoir une sorte de sous-toile forgeron, où en tout cas limiter de droit de créer des blocs via une certification spéciale de type forgeron et une licence spéciale forgeron est une idée que j’ai proposée il y a déjà plus de 3 ans:
Le fait que tous les membres de la toile de confiance peuvent écrire des blocs est pour moi l’une des plus grandes failles de sécurité de la Ğ1, ça va que nous somme encore petit, mais plus la Ğ1 grandira et plus cette faille deviendra problématique et facile à exploiter, car il y aura de plus en plus de gens lambda parmi les membres, dont parmi eux des utilisateurs trop négligeant (ou mal informés) sur la sécurité de leurs clés privées et de leurs machines.
Encore plus nécessaire avec le nouveau consensus BABE/GRANDPA
La migration sur substrate va s’accompagner d’un changement du mécanisme de consensus, nous allons passer d’une preuve de travail à difficulté personnalisée à un protocole hybride basé sur une VRF pour «tirer au sort» de manière vérifiable et non manipulable qui va écrire le prochain bloc, et sur un système de vote automatique des nœuds pour “finaliser” les blocs passés.
Pour plus de précision, voir le sujet dédié : Abandon de la PoW au profit de BABE/GRANDPA - #26 by cgeek
Ce changement de mécanisme de consensus à de nombreux avantages, mais également quelques inconvénients, qui font qu’il n’est pas envisageable d’adopter ce nouveau mécanisme de consensus si tous les membres peuvent potentiellement écrire des blocs.
La sécurité de BABE/GRANDPA est basée sur des mécanismes automatisés de rapport de fautes et de sanctions, elle nécessite que la liste des créateurs de bloc soit connue précisément onchain et qu’il soit tous bien en ligne sur les périodes ou ils sont inscrits.
Avec duniter v1 et sa PoW, si un membre déploie un nœud Duniter à l’arrache et l’oubli et que le nœud se désynchronise ce n’est pas grave, ça ne pénalise pas vraiment le réseau, et l’utilisateur ne sera pas impacté.
Avec Duniter-v2s, un utilisateur qui ne produit pas de bloc alors qu’il est censé le faire sera sanctionné et exclu automatiquement de la liste des autorités en cours (il pourra y re-rentrer quand il voudra via un extrinsic dédié si la sanction n’inclut pas de la suspension de droit pour un temps).
Différence entre membre forgeron et autorité
Être membre de la toile forgeron et être inscrit dans le set des autorités sont 2 notions distinctes.
Chaque membre forgeron peut demander (quand il est prêt techniquement), à rentrer dans le set des autorités via un extrinsic nommé authorityMembers.goOnline, puis à sortir du set des autorités via un extrinsic nommé authorityMembers.goOffline.
C’est seulement quand un membre est dans le set des autorités qu’il a l’obligation de produire des blocs quand c’est son tour, une fois qu’il est sorti du set des autorités (suite à sa demande goOffline), il n’a plus aucune obligation et peut partir en vacances tranquille.
Votre nœud substrate produira automatiquement des blocs lorsque vous êtes dans le set des autorités, et cessera automatiquement de le faire lorsque vous n’y êtes plus.
Il sera nécessaire de monitorer vos nœuds et de mettre en place un système d’alerte, je le ferai moi-même et expliquerai comment j’aurais fait.
Il sera également important de penser à exécuter l’extrinsic goOffline quand vous savez que vous ne pourrez pas intervenir dans une durée raisonnable en cas d’alerte.
La toile forgeron ne va donc pas définir directement qui créé des blocs, mais qui est éligible pour s’inscrire à la création des blocs (devenir une autorité pour un temps).
Le temps: la notion de sessions
Une session est une durée pendant laquelle le set des autorités ne peut pas changer. Si vous vous inscrivez à la session N (appel à l’extrinsic goOnline), vous ferez partie des autorités dès le 1er bloc de la session N+2.
Inversement, si vous faite déjà partie des autorités et que vous exécutez l’extrinsic goOffline, vous resterez autorité jusqu’au dernier bloc de la session N + 1. Votre désinscription sera effective au 1er bloc de la session N + 2.
Plus une session est longue , mieux c’est pour la stabilité du réseau, mais ça implique plus de latence pour entrer et sortir.
Une session dure 1h sur Kusama et 4 h sur Polkadot. 1h est une valeur minimale, pour la ğ1 ce sera au minima 1h (peut-être plus), nous avons encore largement le temps pour décider ça.
Fonctionnement de la toile forgeron
Nous écrirons le moment venu un guide plus détaillé à destination des utilisateurs, ma présente description est pour les contributeurs techniques.
Partons du cas d’usage d’un utilisateur membre de la toile de confiance (Kevin) et qui souhaite participer à la co-création des blocs.
La 1ère étape pour Kevin va être de lire et accepter la licence forgeron, une licence spéciale qui contiendra plus de règles de plus d’engagements que la licence Ğ1.
Ensuite, si Kevin est en accord avec le contenu de la Licence forgeron, la 2ᵉ étape est de déployer un nœud miroir (si ce n’est pas déjà fait), et de vérifier qu’il fonctionne bien, qu’il est bien synchro au réseau, demander du support sur le forum Duniter si besoin.
En 3ᵉ étape, il est recommandé de demander à au moins un membre forgeron de vérifier l’état de votre nœud, en lui fournissant à minima votre PeerId. Laissez passer quelques jours, si le nœud reste synchro et que tout semble bien fonctionner, il est temps de demander officiellement l’adhésion à la toile forgeron.
En 4ᵉ étape Kevin va demander l’adhésion à la toile forgeron via l’extrinsic smithsMembership.requestMembership. Cet extrinsic va lui demander un certain nombre d’information (qui seront listées et expliquées dans la licence forgeron et le guide) :
- Ses sessions keys : il s’agit de clés déléguées qui vont servir au nœud pour créer des blocs, Kevin doit les générer via la ligne de commande ou l’API RPC privée de son nœud, il pourra les modifier plus tard, mais tout membre forgeron doit avoir des sessions keys définies et connues onchain à tout instant t, il faut donc les définir dès que l’on demande l’adhésion. C’est aussi une preuve de sérieux qui servira de 1er filtre (il faut comprendre ce que c’est que ces session keys et comment les générer).
- Son endpoint p2p : ça permettra à ses potentiels certificateurs de vérifier qu’il a bien un nœud actif sur le réseau et bien configuré.
On pourrait ajouter en 3. le hash du texte de la licence forgeron, je ne l’ai pas fait car elle n’existe pas encore, mais quand elle sera rédigée ça pourrais être utile en cas de litige, c’est juste une idée, on en discutera le moment venu.
En 5ᵉ étape, dès lors que Kevin a publié sa demande d’adhésion en blockchain, tout membre forgeron peut le certifier dès le bloc suivant (6 secondes plus tard donc).
Pour devenir membre forgeron, Kevin doit obtenir au moins SmithsWotMinCertForMembership certifications en moins de SmithsPendingMembershipPeriod blocs, ces deux valeurs sont des paramètres de la monnaie qu’il nous faudra définir.
Si au bout de SmithsPendingMembershipPeriod blocs, Kevin à toujours moins de SmithsWotMinCertForMembership certifications, sa demande d’adhésion est supprimée et les certifications qu’il a reçues sont supprimées également, les certificateurs de Kevin récupèrent donc immédiatement ces certifications dans leur “stock” de certifications.
Lorsque Kevin reçoit sa Nème certification, si sa demande d’adhésion existe toujours et que N == SmithsWotMinCertForMembership, sa demande d’adhésion est confirmée et Kevin devient instantanément membre de la toile forgerons. Il peut alors dès le prochain bloc soumettre l’extrinsic goOnline pour s’inscrire parmi les autorités, il peut aussi ne pas le faire.
J’ai implémenté un paramètre MaxOfflineSessions, qui définit le nombre maximum de sessions consécutives où un membre forgeron a le droit de rester “désinscrit” avant que son adhésion soit supprimée. Il suffit de participer à une seule session pour repousser l’échéance, mais ça permet de s’assurer que ne reste membres forgerons que ceux qui participent régulièrement à la création des blocs.
Je pense à une valeur de l’ordre de quelques mois.
À côté de ça, tous les paramètres liés à l’adhésion et la certification existe aussi pour la sous-toile forgeron : durée de validité, durée minimale entre deux renouvellements, etc. Je ferai un point sur tous les paramètres dans un sujet dédié, ici restons centrés sur la toile forgeron.
La gouvernance onchain
Avec substrate, on a pas juste un programme binaire mais deux parties distinctes : le runtime et le client.
ATTENTION : Dans les milieux crypto, la notion de “client” désigne ce que nous appelons le nœud ou le cœur sur ce forum. Ce que nous appelons généralement “client” sur ce forum n’a rien à voir et est appelé “wallet” dans les milieux crypto.
Le “client” substrate, est aussi parfois nommé le “binary” ou “host”, c’est un programme binaire qui se met à jour comme un serveur blockchain classique.
En revanche, le runtime fonctionne différemment, son code (en wasm) est inclus dans le storage onchain, et ne peut être modifié que par l’appel de l’extrinsic system.setCode. Il n’est donc pas possible de mettre à jour le protocole (géré par le runtime), sans mécanisme de gouvernance onchain.
Pour les monnaies de test, il y aura une sudoKey, partagée seulement par quelques développeurs, qui permettra de mettre à jour le runtime, mais cela implique une centralisation du pouvoir qui ne sera pas envisageable pour la monnaie de production (la Ğ1).
C’est pourquoi nous devons obligatoirement définir un mécanisme de gouvernance onchain pour pouvoir migrer la Ğ1 sur substrate.
Je propose dans un premier temps de partir sur un mécanisme simple et proche de l’existant : donner le droit root à X% des membres forgerons.
Concrètement, cela signifie qu’il faudra que X% des membres forgerons signe une proposition de mise à jour du runtime (ou de tout autre appel en tant que root) pour qu’elle soit appliquée.
La pallet collective permet déjà d’appeler un extrinsic au nom d’un groupe, elle gère les votes au sein du groupe défini, puis si un seuil est atteint, l’extrinsic proposé est automatiquement exécuté avec une Origin spéciale de type Members(a, b), où a est le nombre de membres ayant voté pour et b le nombre de membres total dans le groupe.
La toile forgeron servirait donc à deux choses :
- Définir qui a le droit de s’inscrire parmi les créateurs de bloc.
- Définir qui a le droit de voter un changement de runtime (ou tout autre appel root).
Je suis favorable à ce que cette 2ᵉ fonction soit modifiée-supprimée pour diluer le pouvoir, et j’espère que nous aurons d’intéressantes discussions là-dessus après la migration effective de la Ğ1, il ne faut pas faire trop de choses d’un coup.