La gouvernance du Runtime

Protocols Ğ1v2 protocol
1

Le Runtime est l’exécutable qui contient l’ensemble des règles du protocole onchain, c’est-à-dire toutes les règles que chaque nœud doit exécuter au risque de forker.

Dès que l’on souhaite faire évoluer le protocole, c’est le Runtime qui doit être mis à jour. La procédure est assez simple :

  1. des développeurs modifient le code en local pour prendre en compte les modifications du protocole et produisent le Runtime (un fichier .wasm) ;
  2. sur la blockchain, un client pousse ce fichier .wasm dans un bloc, ce qui met à jour le Runtime pour tous les nœuds du réseau.

Là où la gouvernance entre en jeu, c’est sur ce point 2°.

Dans Duniter v1, le processus équivalent consistait à mettre son nœud à jour (mise à jour logicielle physique, à froid). C’était donc la « loi de la majorité » qui s’appliquait, par rapport aux membres forgerons.

Dans Duniter v2 c’est pareil, sauf que la mise à jour logicielle se fait à chaud. Pas besoin de mettre à jour Duniter, le logiciel est directement dans la blockchain. Mais alors, il faut définir les droits d’accès à cette fonction de mise à jour du Runtime : car si tout le monde peut le faire, ce serait une faille béante de sécurité.

On peut avoir un admin, mais alors toute la sécurité de la blockchain dépend de lui. On peut aussi restreindre l’appel à l’acceptation de N membres de la toile, N membres des forgerons actuels, etc., bref on fait ce qu’on veut mais il faut faire un choix.

Des idées ?

6 Likes
2

De ce que je comprends, le client ne peut pousser une mise à jour que si N conditions sont remplies par le document envoyé (signatures, token, autres…).

Le processus de décision est donc en partie hors chaîne (vote par exemple) et en partie inchain (il faut la signature de X membres sur le document ou un token particulier ou autre).

Je serais d’avis de reprendre ce qui avait été décidé à un moment (plusieurs type de compte membres ou de niveau de certification, pour avoir une catégorie forgeron).

Gouvernance : une catégorie de membres (forgerons) qui décide par un moyen X (vote selon le protocole Y) si elle autorise la mise à jour logiciel N par un client.

Qu’en pensez-vous ?

1 Like
3

On peut vraiment faire comme on veut. Utiliser un module de décision par Référendum, de décision arbitraire par un Admin, etc.

Dans la pallet Democracy, c’est onchain.

1 Like
4

Se baser sur N membres forgerons me semble bien…

5

J’ai creusé un peu la pallet Democracy, mais en fait elle ne permet pas d’exécuter des appels en Root, origine qui est pourtant requise pour la fonction set_code (mise à jour du code du Runtime).

Plus je regarde et plus j’ai l’impression qu’il faudra développer notre propre pallet de mise à jour collective du Runtime, as-tu compris la même chose @tuxmain ?

6

Je crois me souvenir qu’@elois avait parlé d’une palette de gouvernance assez modulaire, à laquelle on pouvait fournir les listes électorales par exemple. On pourrait donc lui donner une liste de comptes sortant des palettes de TdC.

Mais je n’ai pas cherché plus.

Si une telle palette modulaire n’existe pas j’ai peur qu’il faille faire la nôtre, puisque la plupart des blockchains sont ploutocratiques et n’ont pas de TdC digne de ce nom…

3 Likes
7

En fait si, j’avais mal lu. C’est même précisément ce que fait la palette, agir en tant que Root.

C’est certainement cette palette.

Par contre je cherche encore comment exclure certaines méthodes publiques qu’elle offre, par exemple propose permet à n’importe qui de pousser une proposition. Or, pour l’instant, je souhaiterais que les propositions ne soient soumises que par une certaine catégorie de membres (les forgerons par ex.), ce qui correspond à la méthode external_propose où l’on précise l’origine autorisée (liste de membres dans mon idée).

A première vue on doit pouvoir faire en sorte que le poids de la méthode soit telle qu’elle ne puisse jamais figurer dans un bloc :thinking: mais je vais voir s’il n’y a pas plus direct.

5 Likes
8

Je propose de commencer par donner le droit root aux 2/3 des membres forgerons, ça signifie qu’il faudrait que plus de 66% des membres forgerons votent un call pour qu’il soit exécuté en tant que root.
C’est plus simple (géré par la pallet collective) et plus sécurisé dans un premier temps.

Je suis très favorable à la mise en place d’une démocracie on-chain, mais dans un 2ème temps (après la migration), sinon ça ferait trop de changements d’un coup pour les utilisateurs (et pour les développeurs aussi).

Il suffit de configurer le BaseCallFilter (pallet system), on peut interdire n’importe-quel extrinsic, donc ce n’est pas un problème.

3 Likes
9

Parfait :slight_smile: