Gouvernance V2

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

Le contenu de ce document peut être sujet à des modifications. 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 parties principales :

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

Le système a bien fonctionné au début de son fonctionnement, aidant à une utilisation raisonnable des fonds du Trésor et à des mises à jour et des réparations en temps opportun. Cependant, à mesure que le système mûrit, il est nécessaire d'améliorer constamment ses défauts et de suivre les progrès. Par exemple, dans "gouvernance v1", tous les poids de vote des référendums sont les mêmes, 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 conduit le système à se concentrer sur un très petit nombre de propositions, plutôt que de considérer largement plusieurs propositions.

Ainsi, "gouvernance v2" ( Gov2) est née. Elle a changé la façon dont les décisions quotidiennes sont prises, rendant les référendums plus larges et plus agiles, augmentant considérablement le nombre de décisions collectives que le système peut prendre.

Le projet Gov2 prévoit de lancer sur Kusama après un audit final de son code. Après les tests sur Kusama, il sera proposé de le déployer sur Polkadot.

Le contenu suivant présentera d'abord les principes de gouvernance fondamentaux du réseau Polkadot. Comprendre les origines de la gouvernance v1 aide à mieux saisir la direction de la deuxième itération. Ces différences 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. Avec la mise à jour de la gouvernance v2 qui entre dans le réseau, des plans pour la gouvernance v2.5 sont également en cours d'élaboration.

Prérequis

En résumé, ce réseau regroupe plusieurs mécanismes novateurs, notamment :

• Fonction de conversion d'état sans forme définie, stockée sur la chaîne et définie dans un langage intermédiaire neutre de la plateforme (WebAssembly)
• Plusieurs mécanismes de vote en chaîne, tels que les référendums avec un seuil de majorité absolue adaptatif et les mécanismes de vote d'approbation en masse.

Tous les changements au protocole doivent être approuvés par un vote pondéré en fonction des droits.

Mécanisme

Dans la gouvernance v1, les détenteurs de jetons actifs et le conseil gèrent ensemble les décisions de mise à niveau du réseau. Que la proposition soit faite par le public ( ou par le conseil, elle doit finalement passer par un référendum populaire, où la décision est prise en fonction des montants de mise et des valeurs de confiance.

La gouvernance v2 présente quelques changements. La nouvelle approche de gouvernance reflète les caractéristiques de décentralisation de la manière suivante :

• Transférer les responsabilités du conseil aux détenteurs de jetons par un vote démocratique
• Dissoudre le conseil d'administration actuel
• Permettre aux utilisateurs de déléguer leurs droits de vote à des membres de la communauté de plusieurs manières

Le conseil dans Gov1 agit en tant que représentant des détenteurs de jetons passifs, gardiens du trésor et initiateurs de la législation, mais est généralement considéré comme une entité centralisée. Pour décentraliser davantage le réseau, Gov2 propose de rendre 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 est associé à une proposition, utilisant un appel de fonction privilégié sous la forme ), y compris le plus puissant appel set_code, qui peut basculer tout le code d'exécution (.

Un référendum est un événement discret avec une période de vote fixe. Après la clôture de la période de vote et le comptage des bulletins, si approuvé, une fonction sera appelée. Un référendum est toujours binaire, avec seulement les choix "pour", "contre" ou l'abstention.

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

• Propositions soumises publiquement
• Proposition adoptée par une 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 retard d'exécution. C'est le temps entre la fin du référendum et l'exécution réelle de la proposition ) si elle est approuvée (.

Si le référendum est clôturé et que le décompte est terminé, il est considéré comme achevé. Si la proposition est approuvée, elle sera mise en œuvre. Si le référendum est en cours de vote, il est considéré comme non achevé.

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 d'exécution fixé si nécessaire. Le traitement des propositions urgentes nécessite des "suivis rapides" sur des questions importantes, ce qui réduit le temps d'exécution.

Dans Gov2, tout le monde peut initier à tout moment un nombre illimité de référendums. Gov2 introduit de nouvelles fonctionnalités telles que Origins) source ( et Tracks) pistes ( pour faciliter le processus de référendum.

L'Origin peut être considéré comme un descripteur du niveau de privilège donné. Le proposeur doit choisir le bon Origin pour la demande en fonction des exigences de la proposition.

Chaque Origine est associée à une catégorie de référendum, et chaque catégorie est liée à une Piste. La Piste décrit le cycle de vie d'une proposition, indépendamment des autres catégories. Différentes Pistes indépendantes permettent au réseau d'ajuster la dynamique du référendum en fonction du niveau de privilège implicite.

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

Vote sur la proposition

Référendum public

Toute personne peut proposer un référendum en déposant un nombre minimum de jetons pendant une période déterminée. Si quelqu'un est d'accord, il peut déposer le même nombre de jetons pour exprimer son soutien.

Cela s'appelle "endorsement". La proposition bénéficiant du plus grand soutien en tokens liés deviendra le référendum du prochain cycle de vote. Notez que cela peut différer du nombre absolu d'endossements.

Une fois la proposition soumise ) et entrée en vote (, les jetons liés seront libérés.

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

Dans Gov2, la communauté peut voter immédiatement après la création d'un référendum. Cependant, le référendum n'est pas dans un état où il peut être terminé ou comptabilisé, approuvé et finalement exécuté. Au contraire, le référendum doit satisfaire à certains critères pour entrer dans l'état "décision". Avant cela, il reste en attente.

Les critères pour entrer dans un état de décision sont les suivants :

• Période d'importation, c'est le temps qui doit être passé avant de décider de commencer. Cela aide à réduire la probabilité de "décision de sniper".
• Il doit y avoir un espace restant décisif. Tous les Track limitent le nombre de référendums pouvant être décidés simultanément. Des pistes plus puissantes ont des limites plus basses.
• Un dépôt décisif doit être payé. Le coût de création d'un référendum est très faible, mais l'examen et la décision comportent le risque d'épuiser les places limitées dans la file d'attente. Exiger un dépôt plus élevé mais remboursable aide à réduire le spam.

Vote du conseil )v1(

Adoption à l'unanimité par le conseil - Lorsque tous les membres sont d'accord, la proposition peut être soumise à un référendum. Ce référendum entraînera un biais dans le taux de vote négatif.

Approbation par la majorité du conseil - Un référendum peut également être organisé lorsque seule une simple majorité est d'accord, mais il doit être basé sur le système de vote majoritaire.

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 la gouvernance v1, supposons qu'il y ait au moins une proposition dans la file d'attente, un nouveau référendum a lieu tous les 28 jours. Il y a une file d'attente pour les propositions approuvées par le conseil et une autre pour les propositions soumises par le public. Les référendums sont alternés entre les propositions les mieux classées des deux files.

Le classement est déterminé par la quantité de mise liée. Si la file actuelle tente de créer un vote sans proposition ) et que la file est vide (, tandis qu'une autre file a des propositions en attente, la proposition la plus en tête de cette autre file entrera dans le vote.

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

Lorsque la proposition est approuvée, la gouvernance v2 partage la même période d'éligibilité de 28 jours. Si la proposition n'est toujours pas approuvée à la fin de cette période, elle sera automatiquement rejetée.

Référendum de vote ) gouvernance v2(

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

Le taux d'approbation est défini comme la part du poids des votes approuvés ) après ajustement par conviction ( par rapport au poids total des votes.

Le taux de soutien est le nombre total de votes approuvés ) en ignorant l'ajustement de conviction ( par rapport au nombre total de votes qui pourraient être effectués dans le système.

Il doit satisfaire à cette norme dans le délai de confirmation le plus court possible. Différentes pistes ont des délais de confirmation et des exigences de soutien à l'approbation différents. Il est maintenant possible de configurer le montant de soutien requis et l'approbation globale. Pour les propositions de sources à faible privilège, le taux de vote requis peut être abaissé à un nombre plus raisonnable plus tôt qu'avec des catégories à haut privilège ) telles que Root(. Les propositions ayant une signification politique importante peuvent demander plus tôt une approbation plus élevée afin d'éviter des controverses.

Dans Gov2, les propositions qui n'ont pas été approuvées après 28 jours seront considérées comme refusées par défaut et le dépôt de décision sera remboursé. Si la proposition reste approuvée avant la fin de la période de confirmation, elle sera 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 à une limite minimale basée sur la piste. Une exécution de piste plus robuste impose une période d'exécution plus longue, garantissant que le réseau a suffisamment de temps pour se préparer aux changements.

Verrouillage volontaire

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

Nombre de votes = jetons * facteur de conviction

Le nombre de périodes de verrouillage double à chaque tour, le multiplicateur de conviction augmente le multiplicateur de vote de un.

Multiplicateur de vote pour la période de verrouillage 0 0.1 1 1 2 2 4 3 8 4 16 5 32 6

Le nombre maximal de "doublages" pendant la période de blocage est de 6) au total pendant 32 périodes de blocage (, une période de blocage équivalant à 28 jours. Seul le doublage est autorisé, il n'est pas possible de verrouiller 24 cycles pour augmenter la conviction de 5,5.

Après le verrouillage des tokens, ils peuvent toujours être utilisés pour voter et staker; seule la transfert vers un autre compte est interdit.

Les votes sont toujours "calculés" au même moment, c'est-à-dire à la fin de la période de vote. Cela n'est pas affecté par la période de verrouillage des jetons.

Biais de groupe adaptatif

L'écart de groupe adaptatif a été utilisé plus longtemps dans la gouvernance v2 et a été remplacé par le système d'Approvisionnement/Soutien.

Conseil

Dans la gouvernance v1, les parties prenantes passives 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.

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

• Vote référendaire sage
• Annuler les référendums dangereux ou malveillants
• Commission technique des élections

Dans la gouvernance v2, il est nécessaire de remplacer le conseil d'administration par une stratégie alternative en tant qu'organisme de délégation des électeurs, afin de compenser le fait que de nombreuses personnes ne participent pas à la gouvernance quotidienne. Gov2 est basé sur la fonctionnalité de délégation de vote de v1, où les électeurs peuvent déléguer leur droit de vote à un autre électeur dans le système. Il s'améliore grâce à la fonctionnalité de délégation multi-rôles, permettant aux électeurs de désigner des représentants différents pour chaque type de référendum dans le système. Ainsi, les électeurs peuvent déléguer à une entité la gestion de catégories de référendums d'impact faible, tout en choisissant un autre représentant pour gérer des catégories ayant un impact plus significatif, tout en conservant l'intégralité de leur droit de vote sur les autres catégories.

Annulation du référendum

Dans la gouvernance v1, si le comité technique est d'accord à l'unanimité pour annuler une proposition, ou si une source Root déclenche cette fonction, 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 un problème est découvert plus tard dans la proposition de référendum ), comme une erreur dans le code runtime (, cela peut être utilisé en dernier recours.

Si l'annulation de la controverse est suffisamment importante pour que le conseil ne puisse pas obtenir une majorité des deux tiers, le sort de la proposition sera décidé conjointement par les parties prenantes.

Dans la gouvernance v2, il existe une opération spéciale appelée Annulation utilisée pour intervenir dans 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 du spam, la caution du proposeur sera confisquée.

L'annulation est en elle-même une opération de gouvernance, qui doit être exécutée par un vote du réseau. L'annulation a sa propre Origine et Suivi, avec une période d'importation très courte et une courbe de taux d'approbation/soutien, qui diminue un peu plus rapidement en raison de l'appel en cas d'urgence.

Comité Technique

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

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

Le vote rapide est le seul vote qui peut se dérouler en même temps qu'un autre vote. Ainsi, grâce au vote rapide, deux votes actifs peuvent avoir lieu simultanément. Voter pour l'un ne bloque pas les utilisateurs de voter pour l'autre.

Dans la gouvernance v2, un nouveau comité de succession a été introduit, appelé "Polkadot Fellowship", pour remplacer le comité technique. Il servira aux réseaux Polkadot et Kusama.

Bourse Polkadot

Cette Fellowship est une institution d'experts essentiellement autonome, dont l'objectif principal est de représenter les personnes possédant des connaissances sur le réseau Polkadot et les technologies de protocole. Fellowship