Gouvernance V2

Polkadot utilise un mécanisme de gouvernance sophistiqué qui lui permet d'évoluer élégamment en fonction des besoins des parties prenantes. Son objectif est de garantir que la majorité des intérêts puissent toujours contrôler le réseau.

Le contenu de cet article peut être modifié. Le protocole de gouvernance a déjà subi plusieurs itérations (v1 et v2), et il y aura encore plus de changements à l'avenir (v2.5).

Le premier système de gouvernance décentralisée de Polkadot (v1) se compose de trois composants principaux :

• Comité technique : gestion du calendrier de mise à niveau
• Conseil: exécutif élu par vote, responsable de la gestion des paramètres, de l'administration et des propositions de dépenses.
• Référendum : système de vote universel, accordant une plus grande influence aux parties prenantes à long terme.

Le système v1 a bien fonctionné au cours des premières années, aidant à garantir une utilisation appropriée des fonds du Trésor et à effectuer des mises à jour et des réparations en temps voulu. Mais à mesure que le système mûrit, il doit évoluer pour corriger les défauts et suivre les progrès. Par exemple, dans v1, tous les poids des référendums sont identiques, et il n'est possible de voter que sur un seul référendum à la fois, avec une période de vote pouvant durer plusieurs semaines. Cela a conduit le système à se concentrer sur un très petit nombre de propositions, plutôt que de considérer largement de nombreuses propositions.

Ainsi, "Gouvernance v2" ( Gov2) est né. Gov2 a changé la méthode de prise de décision quotidienne, rendant les référendums plus étendus et plus agiles, augmentant ainsi de manière significative le nombre de décisions collectives que le système peut prendre.

Gov2 a été lancé sur Kusama et proposera un déploiement sur Polkadot. Actuellement, Gov2 est en ligne sur le réseau Kusama.

Le contenu suivant présentera les principes fondamentaux de la gouvernance du réseau Polkadot. Comprendre les racines de v1 aide à mieux saisir la direction de la deuxième itération. Ces différences et distinctions seront mises en évidence dans les différents sous-thèmes.

Il est important de noter qu'à ce stade, la gouvernance est un protocole en constante évolution. Alors que la mise à jour v2 entre dans le réseau, le plan pour v2.5 est également en cours d'élaboration.

Prérequis

En résumé, ce réseau regroupe divers mécanismes novateurs, y compris des fonctions de transition d'état amorphe définies en WebAssembly et stockées sur la chaîne, ainsi que plusieurs mécanismes de vote en chaîne, tels que des référendums avec un seuil de majorité absolue adaptatif et un mécanisme de vote par approbation en bloc.

Tous les changements apportés à l'accord doivent être approuvés par un vote pondéré par les droits.

Mécanisme

Dans v1, les détenteurs de tokens actifs et le conseil gèrent conjointement les décisions de mise à niveau du réseau. Que la proposition soit soumise par le public ou par le conseil, elle doit finalement passer par un référendum national, où le montant des mises et la valeur de conviction sont utilisés comme poids pour prendre une décision.

La version 2 a plusieurs changements. La nouvelle modalité de gouvernance reflète ses caractéristiques de décentralisation de la manière suivante :

• Transférer la responsabilité du conseil aux détenteurs de tokens par un vote démocratique
• Dissoudre le conseil d'administration actuel
• Permettre aux utilisateurs de déléguer leur droit de vote à des membres de la communauté de plusieurs manières.

Dans v1, le conseil est considéré comme un représentant des détenteurs de tokens passifs, un gardien de la trésorerie et un initiateur législatif, mais est généralement perçu comme une entité centralisée. Pour aller vers une plus grande décentralisation, v2 propose de restituer les responsabilités du conseil à la communauté.

Référendum

Le référendum est un système de vote simple, inclusif et basé sur le staking. Chaque référendum a une proposition spécifique, utilisant des appels de fonctions de privilèges runtime.

Un référendum est un événement discret avec une période de vote fixe. Une fois la période de vote terminée et les bulletins comptabilisés, si approuvé, la fonction correspondante sera appelée. Un référendum est toujours binaire, le choix ne peut être que "pour", "contre" ou complètement abstention.

Dans v1, le référendum peut être lancé de la manière suivante :

• Propositions soumises publiquement
• Proposition adoptée par la majorité ou l'unanimité du conseil.
• Proposition soumise dans le cadre de l'exécution du référendum précédent
• Proposition d'urgence soumise par le comité technique et approuvée par le conseil d'administration

Tous les référendums ont une période de délai d'exécution. C'est le temps écoulé entre la fin du référendum et la mise en œuvre effective de la proposition ( si elle est approuvée ).

Si le référendum est clôturé et que les résultats sont comptabilisés, il est considéré comme terminé. Si la proposition est approuvée, elle sera mise en œuvre. Si le vote est en cours, il est considéré comme non terminé.

Les propositions soumises par le public ou le conseil ont un délai d'exécution fixe de 28 jours. Les propositions soumises dans le cadre de l'exécution d'un référendum précédent peuvent avoir un délai fixé selon les besoins. Le traitement des propositions d'urgence nécessite des "suivis rapides" pour des problèmes majeurs, avec un temps d'exécution plus court.

Dans v2, tout le monde peut commencer un référendum à tout moment, sans limite de nombre. v2 introduit les concepts d'Origins( et de Tracks) pour aider au processus et au traitement des référendums.

L'Origin peut être considéré comme une description riche du niveau de privilège donné. Le proposeur doit choisir l'Origin approprié en fonction des exigences de la proposition.

Chaque Origine est associée à une catégorie de vote, chaque catégorie étant liée à une Piste. La Piste décrit le cycle de vie de la proposition, indépendamment des autres catégories. Différentes pistes indépendantes permettent au réseau d'ajuster la dynamique de vote en fonction des niveaux de privilèges implicites.

Par exemple, l'impact de la mise à niveau Runtime sur l'écosystème, qui est différent de l'approbation des pourboires du trésor, nécessite donc différentes Origines, où les différents taux de vote, taux d'approbation, dépôts et périodes d'exécution minimales seront préalablement déterminés.

( proposition de référendum

Référendum public

Toute personne peut proposer un référendum en déposant un nombre minimum de tokens pendant une période déterminée. Si quelqu'un est d'accord, il peut déposer le même nombre de tokens pour montrer son soutien, ce que l'on appelle "soutien". La proposition ayant le plus grand nombre de tokens liés en soutien sera sélectionnée pour le référendum du prochain cycle de vote.

Une fois que la proposition est soumise ), le vote aura lieu ### et le token lié sera libéré.

Dans v1, la file d'attente des propositions peut contenir jusqu'à 100 propositions publiques.

Dans v2, après la création d'un vote, la communauté peut voter immédiatement. Cependant, ce vote n'est pas dans un état où il peut être terminé ou où les bulletins peuvent être comptés, approuvés et exécutés. Le vote doit répondre à certains critères pour passer à l'état "Décision(Deciding)". Avant cela, il reste dans un état indécis.

Les critères pour entrer dans l'état "Decided" sont les suivants :

• A traversé une période d'importation, c'est-à-dire le temps nécessaire avant de prendre une décision. Cela aide à réduire la probabilité de "décision de tir".
• Il doit encore y avoir de l'espace de décision restant. Tous les Track ont une limite sur le nombre de référendums qui peuvent être décidés simultanément.
• Un dépôt déterminé doit être payé. Créer un référendum coûte peu, mais il existe un risque que le référendum consomme une position limitée dans la file d'attente. Un dépôt plus important mais remboursable aide à réduire le spam.

Vote référendaire du Conseil (v1)

Le conseil a adopté à l'unanimité - Lorsqu'un membre du conseil est d'accord, la proposition peut être soumise à un référendum. Ce référendum entraînera un biais de taux de vote négatif.

Adoption par la majorité du conseil - Le vote peut également avoir lieu lorsque seule une majorité simple est d'accord, mais selon le système de vote à la majorité.

Il ne peut y avoir qu'un seul référendum valide à tout moment, sauf s'il y a un référendum d'urgence en cours.

Calendrier de vote

Dans v1, en supposant qu'il y ait au moins une proposition dans la file d'attente, un nouveau référendum est effectué tous les 28 jours. Les propositions approuvées par le conseil ont une file d'attente, et les propositions soumises par le public ont également une file d'attente. Les référendums alternent entre les propositions classées en tête des deux files d'attente.

Le classement est déterminé par le nombre de mises en jeu liées. Si la file d'attente actuelle tente de créer un vote sans proposition, la file ( est vide ), tandis qu'une autre file d'attente a des propositions en attente, la proposition la plus en tête de l'autre file d'attente entrera dans le vote.

Il est interdit de voter simultanément sur plusieurs référendums, à l'exception des référendums d'urgence. Les référendums d'urgence qui se déroulent en même temps que des référendums ordinaires sont la seule situation où il est possible de voter sur plusieurs référendums en même temps.

Dans la version 2, lorsqu'une proposition est approuvée, un délai de qualification de 28 jours est partagé. Si l'approbation n'est pas obtenue à la fin de cette période, elle sera automatiquement rejetée.

Référendum vote (v2)

Dans v2, si la proposition répond aux exigences de taux d'approbation et de soutien, elle est approuvée, le système de biais de groupe adaptatif a été supprimé.

Le taux d'approbation est défini comme la part du poids de vote approuvé ( après ajustement de la conviction ) dans le poids total de vote.

Le taux de soutien est le nombre total de votes approuvés ( en ignorant la conviction ) par rapport au nombre total de votes possibles dans le système.

Il doit répondre à cette norme dans le délai de confirmation le plus court possible. Différentes pistes ont des délais de confirmation et des exigences différents. Il est maintenant possible de configurer en fonction du montant de soutien requis et de l'approbation globale. Pour les propositions de sources à faible privilège, il est plus raisonnable de réduire le taux de vote requis à un nombre réaliste le plus tôt possible. Pour les propositions de grande importance politique, il est possible de demander plus tôt un taux d'approbation plus élevé afin d'éviter les controverses.

Dans v2, les propositions non approuvées après 28 jours sont considérées comme refusées par défaut, et le dépôt de décision est remboursé. Si la proposition reste approuvée avant la fin de la période de confirmation, elle est considérée comme approuvée et prévue pour être exécutée à partir de la source de proposition après la période de formulation. La période de formulation est spécifiée lors de la proposition, mais est soumise à un minimum basé sur la piste. Des pistes plus puissantes imposent une période d'exécution plus longue, garantissant que le réseau dispose de suffisamment de temps pour se préparer aux changements.

Verrouillage volontaire

Polkadot utilise le concept de "verrouillage volontaire", permettant aux détenteurs de token d'augmenter leur pouvoir de vote en déclarant leur volonté de verrouiller leurs tokens pour une certaine durée. Le nombre de votes de chaque détenteur sera calculé selon la formule suivante :

Nombre de votes = token * facteur de conviction

La période de verrouillage double à chaque fois, le multiplicateur de conviction augmentera le multiplicateur de vote de un.

Le nombre maximum de périodes de verrouillage est de 6 fois (, pour un total de 32 périodes de verrouillage ), une période de verrouillage équivaut à 28 jours. Seul le doublement est autorisé, et il n'est pas possible de verrouiller 24 cycles tout en augmentant la conviction de 5,5.

Peut être utilisé pour voter et staker même après le verrouillage, seule la transfert vers un autre compte est interdit.

Les votes sont toujours "comptés" à la fin de la période de vote, sans être affectés par la période de verrouillage.

Biais de groupe adaptatif

Utilisé plus longtemps dans v2, remplacé par le système d'Approbation/Soutien.

Conseil d'administration

Dans v1, les parties prenantes passives sur Polkadot sont représentées par le "Conseil". Le Conseil est une entité on-chain, composée de plusieurs participants, chacun représentant un compte on-chain. Le Conseil sur Polkadot est actuellement composé de membres.

En plus de contrôler le Trésor, le Conseil est principalement responsable de trois tâches de gouvernance :

• Référendum sage sur la proposition
• Annuler les référendums dangereux ou malveillants
• Commission technique des élections

Dans v2, des stratégies de substitution sont nécessaires pour remplacer les responsabilités précédemment exercées par le conseil d'administration en tant qu'institution de délégation des électeurs. v2 est construit sur la fonctionnalité de délégation de vote de v1, permettant aux électeurs de déléguer leurs droits de vote à d'autres électeurs dans le système. Grâce à la délégation multi-rôle, les électeurs peuvent désigner des représentants différents pour chaque type de référendum dans le système. Par exemple, ils peuvent déléguer à une entité la gestion de catégories de référendums à faible impact, choisir un autre représentant pour gérer des catégories ayant des conséquences plus importantes, tout en conservant l'intégralité de leurs droits de vote pour les autres catégories.

Annulation du référendum

Dans v1, si le comité technique est d'accord à l'unanimité ou si une source Root déclenche, la proposition peut être annulée. Le dépôt de la proposition annulée sera détruit.

De plus, une majorité des deux tiers du conseil peut annuler le référendum. Si des problèmes sont découverts plus tard dans la proposition de référendum, cela peut être utilisé comme dernier recours.

Si l'annulation du litige est telle que le conseil ne peut obtenir une majorité des deux tiers, alors le sort de la proposition sera décidé conjointement par les parties prenantes.

Dans v2, il existe une opération spéciale appelée Cancelation(, utilisée pour intervenir sur les propositions déjà votées. Cette opération rejettera immédiatement le référendum en cours, quelle que soit son état. Il est également stipulé que si la proposition est malveillante ou constitue un spam, le dépôt du proposeur sera confisqué.

L'annulation elle-même est une opération de gouvernance, elle doit être exécutée par un vote en ligne. L'annulation a son propre Origine et Suivi, avec une période d'importation très courte et une courbe de taux d'approbation/soutien, et le seuil diminue rapidement, car elle n'est appelée qu'en cas d'urgence.

Comité technique

Dans v1, le comité technique )TC( est introduit en tant que l'une des trois institutions de gouvernance de Kusama. Le TC est composé d'équipes ayant réussi à mettre en œuvre ou à définir le runtime ou l'hôte de Polkadot. Par un vote à la simple majorité du conseil, des équipes peuvent être ajoutées ou supprimées du TC.

L'objectif de TC est d'empêcher les référendums malveillants, de mettre en œuvre des corrections de bugs, de revenir sur des mises à jour runtime erronées ou d'ajouter de nouvelles fonctionnalités. TC a le droit d'utiliser le pallet Democracy pour accélérer les propositions, c'est la seule source capable de déclencher la fonction d'accélération. Nous pouvons considérer TC comme la "seule source" qui ne peut pas générer de propositions mais peut accélérer des propositions existantes.

Le référendum rapide est le seul référendum qui peut se dérouler en même temps qu'un autre référendum. Ainsi, grâce au référendum rapide, deux référendums actifs peuvent avoir lieu simultanément. Voter pour l'un n'empêche pas de voter pour l'autre.

Dans la version 2, un nouveau comité de succession "Polkadot Fellowship" est introduit, remplaçant le comité technique. Il servira aux réseaux Polkadot et Kusama.

Bourse Polkadot

Fellowship est une institution d'experts fondamentalement autonome, dont l'objectif principal est de représenter les personnes ayant des connaissances sur le réseau Polkadot et les technologies de protocole. Fellowship classe ses membres par "niveaux", représentant le degré de sagesse de leurs opinions, la solidité de leur base technique, ainsi que leur conformité aux intérêts de Polkadot.

Contrairement au Technical Collective actuel, il vise à élargir le nombre de membres ) pouvant accueillir des milliers de membres ( et à avoir un seuil d'entrée beaucoup plus bas. Devenir membre candidat est très simple, il suffit de déposer une petite caution.

Les membres de la Fellowship peuvent voter sur toute proposition de la Fellowship, les opinions des membres sont pondérées par niveau selon ) pour constituer l'avis de la Fellowship.

Le mécanisme de vote Fellowship est le même que le mécanisme de vote des parties prenantes de Polkadot pour les référendums proposés.

Système de niveaux

Pour empêcher un petit nombre de participants d'exercer un contrôle effectif sur le réseau, le système adhère à trois principes principaux :

1. La fellowship ne doit jamais avoir de pouvoir dur sur le réseau : elle ne peut pas modifier les paramètres, effectuer des réparations ou déplacer des actifs. Le seul pouvoir réside dans la capacité à réduire le calendrier des référendums.

2. Fellowship accorde plus de poids aux opinions de haut niveau dans l'avis général, mais cela ne devrait pas être si élevé que les opinions de quelques membres de haut niveau ne puissent pas surpasser les opinions unanimes des membres de bas niveau.