Polkadot utilise un mécanisme de gouvernance sophistiqué qui lui permet d'évoluer continuellement en fonction des besoins des parties prenantes. Son objectif est de garantir que la majorité des participations puisse toujours contrôler le réseau.
Le contenu de cet article peut être sujet à des modifications. Le protocole de gouvernance a déjà subi plusieurs itérations (v1 et v2), et il y aura d'autres changements à l'avenir (v2.5).
Le premier système de gouvernance décentralisé de Polkadot (v1) est composé de trois composants principaux :
Comité technique : gestion du calendrier de mise à niveau
Conseil: gouvernement exécutif élu, responsable de la gestion des paramètres, ainsi que de la gestion et des propositions de dépenses.
Référendum : Système de vote universel, donnant plus d'influence aux parties prenantes à long terme
Le système a bien fonctionné pendant les premières années, mais avec la maturité, il a besoin d'évoluer continuellement pour améliorer ses défauts et suivre les progrès. Par exemple, dans "gouvernance v1", tous les poids de vote étaient les mêmes, on ne pouvait voter que sur un seul référendum à la fois, et la période de vote pouvait durer plusieurs semaines. Cela a conduit le système à privilégier une réflexion approfondie sur un très petit nombre de propositions, plutôt qu'à considérer largement plusieurs propositions. Ainsi, "gouvernance v2" est née.
"Gouvernance v2" ou "Gov2" a modifié les méthodes de prise de décision quotidiennes, élargissant et rendant plus agile l'impact des référendums, ce qui augmente considérablement le nombre de décisions collectives que le système peut prendre.
Gov2 sera lancé et testé sur Kusama avant de proposer son déploiement sur Polkadot. Actuellement, Gov2 est déjà en ligne sur le réseau Kusama.
Le contenu suivant présentera 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 divers sous-thèmes.
Il est important de noter qu'à ce stade, la gouvernance est encore un protocole en constante évolution. Avec la mise à jour de la gouvernance v2, le plan pour la gouvernance v2.5 est également en cours d'élaboration.
précondition
En résumé, ce réseau rassemble plusieurs mécanismes novateurs, y compris une fonction de conversion d'état amorphe stockée sur la chaîne définie par WebAssembly (, ainsi que divers mécanismes de vote sur la chaîne, tels que des référendums avec un seuil de majorité absolue adaptatif et des votes d'approbation par lots.
Toutes les modifications de l'accord doivent être approuvées par un vote pondéré en fonction des droits.
) mécanisme
Dans la gouvernance v1, les détenteurs de tokens 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 être soumise à un référendum populaire, avec des poids basés sur le montant de la mise et la valeur de la conviction.
La gouvernance v2 présente plusieurs changements. La nouvelle mode de gouvernance reflète les caractéristiques de décentralisation de la manière suivante :
Transférer la responsabilité du conseil aux détenteurs de tokens par vote démocratique.
Dissoudre le conseil d'administration actuel
Permettre aux utilisateurs de déléguer leurs droits de vote aux membres de la communauté de plusieurs manières
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 associée, utilisant des appels de fonction de privilège runtime sous la forme ###, y compris l'appel set_code le plus puissant, qui peut basculer tout le code 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 comptés, si approuvé, les fonctions pertinentes seront appelées. Un référendum est toujours binaire ; les choix de vote ne peuvent être que "pour", "contre" ou complètement abstention.
Dans la gouvernance v1, le référendum peut être lancé de plusieurs manières :
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 correspondante. C'est une période de temps entre la fin du référendum et l'exécution réelle de la proposition.
Dans Gov2, n'importe qui peut initier un référendum à tout moment, sans limite de nombre. Gov2 introduit les concepts d'Origins) et de Tracks( pour aider au processus et au traitement des accords de référendum.
Origin peut être considéré comme un descripteur du niveau de privilège donné. Le proposeur doit choisir l'Origin approprié pour la demande en fonction des exigences de la proposition.
Chaque origine est associée à une catégorie de vote, et chaque catégorie a une piste. La piste décrit le cycle de vie de la proposition et est indépendante des autres catégories. Différentes pistes indépendantes permettent au réseau d'ajuster la dynamique du vote en fonction du niveau de privilège implicite.
Par exemple, l'impact de la mise à niveau Runtime sur l'écosystème, qui diffère de l'approbation des pourboires du Trésor, nécessite donc des Origines différentes, où les différents taux de vote, taux d'approbation, dépôts et périodes d'exécution minimales seront prédéterminés.
) proposition de vote
Référendum public
N'importe qui peut proposer un référendum en déposant un montant minimum de tokens pendant une certaine période. Si quelqu'un est d'accord, il peut déposer le même montant de tokens pour exprimer son soutien.
Cela s'appelle "endorsement". La proposition ayant le plus de tokens liés sera sélectionnée pour le prochain cycle de vote. Notez que cela peut différer du nombre absolu d'endossements ; par exemple, trois comptes chacun lié à 20 DOT "dépasseront" dix comptes chacun lié à 1 DOT.
Une fois que la proposition a été soumise pour le vote (, le token lié sera libéré.
Pour la gouvernance v1, il peut y avoir un maximum de 100 propositions publiques dans la file d'attente des propositions.
Dans Gov2, une fois le référendum créé, la communauté peut voter immédiatement. Cependant, ce référendum n'est pas dans un état pouvant être terminé, comptabiliser les votes, obtenir une approbation et être exécuté définitivement. Au contraire, le référendum doit respecter certains critères pour entrer dans l'état "décider )Décider ###". Avant cela, il reste en attente.
Les critères pour entrer dans l'état Décidé sont les suivants :
A traversé une période d'importation, c'est-à-dire le temps que l'on doit passer avant de pouvoir commencer à prendre une décision. Cela aide à réduire la possibilité de "sniping des décisions", c'est-à-dire qu'un attaquant contrôlant un grand nombre de droits de vote pourrait adopter une proposition immédiatement après sa présentation, sans laisser aux électeurs le temps suffisant pour réfléchir et participer.
Il doit également y avoir un espace de décision restant. Tous les Track ont des limites sur le nombre de référendums pouvant être décidés simultanément. Des pistes plus puissantes limitent davantage. Par exemple, la limite du niveau Root Origin est de 1, ce qui signifie qu'il ne peut y avoir qu'une seule proposition super dangereuse décidée à la fois.
Un dépôt de décision doit être payé. Le coût de création d'un référendum est très faible, car le dépôt ne comprend que la valeur nécessaire pour le stockage en chaîne. Cependant, il existe un risque d'épuisement des emplacements limités dans la file d'attente des référendums lors de l'examen et de la décision. Exiger un dépôt plus important mais remboursable aide à réduire le spam.
Vote du Conseil (v1)
Vote unanime du Conseil - Lorsqu'un membre du Conseil approuve une proposition, celle-ci peut être soumise à un référendum. Ce référendum entraînera un biais de taux de vote négatif (, c'est-à-dire que moins il y a de votes de droits, moins le nombre requis pour l'adoption est faible ).
Adoption par la majorité du conseil - Un vote par référendum peut également être effectué lorsque seule une simple majorité des membres du conseil est d'accord, mais il sera basé sur le système de vote majoritaire où le côté obtenant 51% des voix l'emporte.
Il ne peut y avoir qu'un seul référendum valide à tout moment, à moins qu'un référendum d'urgence soit en cours.
Calendrier de vote
Dans la gouvernance v1, s'il y a au moins une proposition dans la file d'attente, un nouveau référendum sera organisé toutes les 28 jours. Les propositions approuvées par le conseil ont une file d'attente, tout comme les propositions soumises par le public. Des référendums seront alternés entre les propositions en tête des deux files d'attente.
Les propositions les mieux classées sont déterminées par le montant des mises qui leur sont associées. Si la file d'attente actuelle essaie de créer un vote sans proposition et que la file ( est vide ), et qu'une autre file a des propositions en attente, alors la proposition la mieux classée de l'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 des 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 de qualification de 28 jours. Si elle n'est toujours pas approuvée à la fin de cette période, la proposition 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, la proposition sera approuvée, c'est-à-dire que le système de biais de groupe adaptatif sera supprimé.
Le taux d'approbation ( est défini comme le poids des votes d'approbation ) après ajustement de la conviction ( représentant la part du poids total des votes ) incluant les parts d'approbation et de rejet (.
Le taux de soutien ) Support ( est le nombre total de votes approuvés ) en ignorant les ajustements de conviction ( par rapport au nombre total de votes qui peuvent ê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 d'approbation et de soutien différents. Il est maintenant possible de configurer via le montant de soutien requis et l'approbation globale. Pour les propositions utilisant des sources de moindre privilège, il est plus raisonnable de réduire le taux de vote requis à un nombre plus réaliste plus tôt, comparé aux propositions utilisant des catégories de privilège élevé ) comme Root(. Les cours ayant une grande signification politique peuvent demander plus tôt une approbation plus élevée pour éviter les controverses.
Dans Gov2, les propositions non approuvées après 28 jours seront considérées comme rejeté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 proposée après la période de formulation. La période de formulation est spécifiée lors de la proposition de vote populaire, mais est également soumise à un minimum basé sur les pistes. Des pistes plus puissantes imposeront une période d'exécution plus longue pour s'assurer que le réseau a suffisamment de temps pour se préparer aux changements que la proposition pourrait entraîner.
Verrouillage volontaire
Polkadot utilise le concept de "verrouillage volontaire", permettant aux détenteurs de tokens d'augmenter leur pouvoir de vote en déclarant combien de temps ils sont disposés à verrouiller leurs tokens. Ainsi, le nombre de votes de chaque détenteur de token sera calculé à l'aide de la formule suivante :
Nombre de votes = token * multiplicateur de conviction
La période de verrouillage double à chaque fois, le multiplicateur de conviction augmentera le multiplicateur de vote de un.
Multiplicateur de vote pour la période de verrouillage 00.111224384165326
La limite maximale pour le réglage des "doublages" de la période de verrouillage est de 6), pour un total de 32 périodes de verrouillage (, une période de verrouillage équivaut à 28 jours. Le doublement est uniquement autorisé, par exemple, il n'est pas possible de verrouiller 24 périodes et d'augmenter la conviction de 5,5.
Une fois que le token est verrouillé, il peut toujours être utilisé pour voter et pour le staking ; il est seulement interdit de transférer ces tokens vers un autre compte.
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 tokens.
Biais adaptatif de groupe
L'adaptation des biais de groupe a été utilisée plus longtemps dans la gouvernance v2 et a été remplacée par le système d'Approbation/Soutien.
) Conseil
Dans la gouvernance v1, les parties prenantes passives sur Polkadot sont représentées par un organe de gestion appelé "Conseil". Le Conseil est une entité on-chain composée de plusieurs participants, chaque participant représentant un compte on-chain. Sur Polkadot, le Conseil est actuellement composé de membres.
En plus de contrôler le Trésor, le Conseil est également principalement responsable de trois missions de gouvernance :
Référendum sur les propositions judicieuses
Annuler les référendums dangereux ou malveillants
Commission technique des élections
Dans la gouvernance v2, des stratégies alternatives sont nécessaires pour remplacer les responsabilités précédemment exercées par le conseil d'administration en tant qu'agence de délégation des électeurs, afin de compenser le fait que de nombreuses personnes choisissent de ne pas participer à la gouvernance quotidienne. Gov2 est construit sur la fonction de délégation de vote de v1, où les électeurs peuvent choisir de déléguer leurs droits de vote à un autre électeur dans le système. Cela est réalisé par l'amélioration d'une fonctionnalité appelée délégation multi-rôle, où les électeurs peuvent désigner des représentants différents pour chaque catégorie de référendum dans le système. Ainsi, les électeurs peuvent déléguer une entité pour gérer une catégorie de référendum d'impact mineur, tout en choisissant un autre représentant différent pour gérer une autre catégorie avec des conséquences plus significatives, tout en conservant le plein droit de vote sur toutes les catégories restantes.
( Annuler le référendum
Dans la gouvernance v1, si le comité technique est d'accord à l'unanimité pour annuler une proposition, ou si la source Root ) déclenche cette fonction comme sudo(, alors 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 tardivement dans la proposition de référendum ), comme des erreurs dans le code runtime que la proposition exécutera (, cela pourrait être considéré comme un dernier recours.
Si la controverse entourant l'annulation est suffisamment grande pour que le conseil ne puisse pas obtenir une majorité des deux tiers, alors 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 Cancelation) pour annuler###, utilisée pour intervenir dans les propositions déjà votées. Cette opération rejettera immédiatement le référendum en cours, quel que soit son état. Il y a également une disposition stipulant que si la proposition est malveillante ou du spam, le dépôt du proposeur sera confisqué.
L'annulation est en soi une opération de gouvernance qui doit être exécutée par un vote du réseau. L'annulation est accompagnée de son propre Origine et Traçabilité, elle a une période d'importation très courte et une courbe de taux d'approbation/de soutien, qui descend légèrement plus rapidement grâce à un seuil, car elle est déclenchée en cas d'urgence.
Comité technique
Dans la gouvernance v1, le comité technique (TC) est l'une des trois chambres de la gouvernance de Kusama(, les deux autres chambres é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.
L'objectif de TC est d'empêcher les votes malveillants, d'implémenter des corrections de bugs, de revenir sur des mises à jour de runtime erronées ou d'ajouter de nouvelles fonctionnalités éprouvées sur le terrain. TC a le droit d'utiliser le pallet Democracy pour accélérer les propositions, et est le seul capable de
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
15 J'aime
Récompense
15
8
Partager
Commentaire
0/400
MetaMuskRat
· 07-30 04:17
Ah, v2 n'a pas vraiment beaucoup changé.
Voir l'originalRépondre0
CoffeeOnChain
· 07-28 20:33
Après tant d'itérations, ça va toujours ?
Voir l'originalRépondre0
ApyWhisperer
· 07-28 18:01
La gouvernance est vraiment agréable, quand va-t-on passer à v3 ?
Voir l'originalRépondre0
0xOverleveraged
· 07-27 10:12
Quand V2 et V2.5 seront-ils stables ?
Voir l'originalRépondre0
ServantOfSatoshi
· 07-27 10:04
La gouvernance dépend toujours du capital Haha
Voir l'originalRépondre0
BearHugger
· 07-27 09:58
Ce mécanisme de gouvernance est fiable.
Voir l'originalRépondre0
ForkYouPayMe
· 07-27 09:52
v2 c'est vraiment génial ! C'est tellement mieux que v1
Gouvernance Polkadot V2 : Un nouveau chapitre de la Décentralisation des décisions
Gouvernance V2
Polkadot utilise un mécanisme de gouvernance sophistiqué qui lui permet d'évoluer continuellement en fonction des besoins des parties prenantes. Son objectif est de garantir que la majorité des participations puisse toujours contrôler le réseau.
Le contenu de cet article peut être sujet à des modifications. Le protocole de gouvernance a déjà subi plusieurs itérations (v1 et v2), et il y aura d'autres changements à l'avenir (v2.5).
Le premier système de gouvernance décentralisé de Polkadot (v1) est composé de trois composants principaux :
Le système a bien fonctionné pendant les premières années, mais avec la maturité, il a besoin d'évoluer continuellement pour améliorer ses défauts et suivre les progrès. Par exemple, dans "gouvernance v1", tous les poids de vote étaient les mêmes, on ne pouvait voter que sur un seul référendum à la fois, et la période de vote pouvait durer plusieurs semaines. Cela a conduit le système à privilégier une réflexion approfondie sur un très petit nombre de propositions, plutôt qu'à considérer largement plusieurs propositions. Ainsi, "gouvernance v2" est née.
"Gouvernance v2" ou "Gov2" a modifié les méthodes de prise de décision quotidiennes, élargissant et rendant plus agile l'impact des référendums, ce qui augmente considérablement le nombre de décisions collectives que le système peut prendre.
Gov2 sera lancé et testé sur Kusama avant de proposer son déploiement sur Polkadot. Actuellement, Gov2 est déjà en ligne sur le réseau Kusama.
Le contenu suivant présentera 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 divers sous-thèmes.
Il est important de noter qu'à ce stade, la gouvernance est encore un protocole en constante évolution. Avec la mise à jour de la gouvernance v2, le plan pour la gouvernance v2.5 est également en cours d'élaboration.
précondition
En résumé, ce réseau rassemble plusieurs mécanismes novateurs, y compris une fonction de conversion d'état amorphe stockée sur la chaîne définie par WebAssembly (, ainsi que divers mécanismes de vote sur la chaîne, tels que des référendums avec un seuil de majorité absolue adaptatif et des votes d'approbation par lots.
Toutes les modifications de l'accord doivent être approuvées par un vote pondéré en fonction des droits.
) mécanisme
Dans la gouvernance v1, les détenteurs de tokens 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 être soumise à un référendum populaire, avec des poids basés sur le montant de la mise et la valeur de la conviction.
La gouvernance v2 présente plusieurs changements. La nouvelle mode de gouvernance reflète les caractéristiques de décentralisation de la manière suivante :
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 associée, utilisant des appels de fonction de privilège runtime sous la forme ###, y compris l'appel set_code le plus puissant, qui peut basculer tout le code 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 comptés, si approuvé, les fonctions pertinentes seront appelées. Un référendum est toujours binaire ; les choix de vote ne peuvent être que "pour", "contre" ou complètement abstention.
Dans la gouvernance v1, le référendum peut être lancé de plusieurs manières :
Tous les référendums ont une période de délai d'exécution correspondante. C'est une période de temps entre la fin du référendum et l'exécution réelle de la proposition.
Dans Gov2, n'importe qui peut initier un référendum à tout moment, sans limite de nombre. Gov2 introduit les concepts d'Origins) et de Tracks( pour aider au processus et au traitement des accords de référendum.
Origin peut être considéré comme un descripteur du niveau de privilège donné. Le proposeur doit choisir l'Origin approprié pour la demande en fonction des exigences de la proposition.
Chaque origine est associée à une catégorie de vote, et chaque catégorie a une piste. La piste décrit le cycle de vie de la proposition et est indépendante des autres catégories. Différentes pistes indépendantes permettent au réseau d'ajuster la dynamique du vote en fonction du niveau de privilège implicite.
Par exemple, l'impact de la mise à niveau Runtime sur l'écosystème, qui diffère de l'approbation des pourboires du Trésor, nécessite donc des Origines différentes, où les différents taux de vote, taux d'approbation, dépôts et périodes d'exécution minimales seront prédéterminés.
) proposition de vote
Référendum public
N'importe qui peut proposer un référendum en déposant un montant minimum de tokens pendant une certaine période. Si quelqu'un est d'accord, il peut déposer le même montant de tokens pour exprimer son soutien.
Cela s'appelle "endorsement". La proposition ayant le plus de tokens liés sera sélectionnée pour le prochain cycle de vote. Notez que cela peut différer du nombre absolu d'endossements ; par exemple, trois comptes chacun lié à 20 DOT "dépasseront" dix comptes chacun lié à 1 DOT.
Une fois que la proposition a été soumise pour le vote (, le token lié sera libéré.
Pour la gouvernance v1, il peut y avoir un maximum de 100 propositions publiques dans la file d'attente des propositions.
Dans Gov2, une fois le référendum créé, la communauté peut voter immédiatement. Cependant, ce référendum n'est pas dans un état pouvant être terminé, comptabiliser les votes, obtenir une approbation et être exécuté définitivement. Au contraire, le référendum doit respecter certains critères pour entrer dans l'état "décider )Décider ###". Avant cela, il reste en attente.
Les critères pour entrer dans l'état Décidé sont les suivants :
A traversé une période d'importation, c'est-à-dire le temps que l'on doit passer avant de pouvoir commencer à prendre une décision. Cela aide à réduire la possibilité de "sniping des décisions", c'est-à-dire qu'un attaquant contrôlant un grand nombre de droits de vote pourrait adopter une proposition immédiatement après sa présentation, sans laisser aux électeurs le temps suffisant pour réfléchir et participer.
Il doit également y avoir un espace de décision restant. Tous les Track ont des limites sur le nombre de référendums pouvant être décidés simultanément. Des pistes plus puissantes limitent davantage. Par exemple, la limite du niveau Root Origin est de 1, ce qui signifie qu'il ne peut y avoir qu'une seule proposition super dangereuse décidée à la fois.
Un dépôt de décision doit être payé. Le coût de création d'un référendum est très faible, car le dépôt ne comprend que la valeur nécessaire pour le stockage en chaîne. Cependant, il existe un risque d'épuisement des emplacements limités dans la file d'attente des référendums lors de l'examen et de la décision. Exiger un dépôt plus important mais remboursable aide à réduire le spam.
Vote du Conseil (v1)
Vote unanime du Conseil - Lorsqu'un membre du Conseil approuve une proposition, celle-ci peut être soumise à un référendum. Ce référendum entraînera un biais de taux de vote négatif (, c'est-à-dire que moins il y a de votes de droits, moins le nombre requis pour l'adoption est faible ).
Adoption par la majorité du conseil - Un vote par référendum peut également être effectué lorsque seule une simple majorité des membres du conseil est d'accord, mais il sera basé sur le système de vote majoritaire où le côté obtenant 51% des voix l'emporte.
Il ne peut y avoir qu'un seul référendum valide à tout moment, à moins qu'un référendum d'urgence soit en cours.
Calendrier de vote
Dans la gouvernance v1, s'il y a au moins une proposition dans la file d'attente, un nouveau référendum sera organisé toutes les 28 jours. Les propositions approuvées par le conseil ont une file d'attente, tout comme les propositions soumises par le public. Des référendums seront alternés entre les propositions en tête des deux files d'attente.
Les propositions les mieux classées sont déterminées par le montant des mises qui leur sont associées. Si la file d'attente actuelle essaie de créer un vote sans proposition et que la file ( est vide ), et qu'une autre file a des propositions en attente, alors la proposition la mieux classée de l'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 des 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 de qualification de 28 jours. Si elle n'est toujours pas approuvée à la fin de cette période, la proposition 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, la proposition sera approuvée, c'est-à-dire que le système de biais de groupe adaptatif sera supprimé.
Le taux d'approbation ( est défini comme le poids des votes d'approbation ) après ajustement de la conviction ( représentant la part du poids total des votes ) incluant les parts d'approbation et de rejet (.
Le taux de soutien ) Support ( est le nombre total de votes approuvés ) en ignorant les ajustements de conviction ( par rapport au nombre total de votes qui peuvent ê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 d'approbation et de soutien différents. Il est maintenant possible de configurer via le montant de soutien requis et l'approbation globale. Pour les propositions utilisant des sources de moindre privilège, il est plus raisonnable de réduire le taux de vote requis à un nombre plus réaliste plus tôt, comparé aux propositions utilisant des catégories de privilège élevé ) comme Root(. Les cours ayant une grande signification politique peuvent demander plus tôt une approbation plus élevée pour éviter les controverses.
Dans Gov2, les propositions non approuvées après 28 jours seront considérées comme rejeté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 proposée après la période de formulation. La période de formulation est spécifiée lors de la proposition de vote populaire, mais est également soumise à un minimum basé sur les pistes. Des pistes plus puissantes imposeront une période d'exécution plus longue pour s'assurer que le réseau a suffisamment de temps pour se préparer aux changements que la proposition pourrait entraîner.
Verrouillage volontaire
Polkadot utilise le concept de "verrouillage volontaire", permettant aux détenteurs de tokens d'augmenter leur pouvoir de vote en déclarant combien de temps ils sont disposés à verrouiller leurs tokens. Ainsi, le nombre de votes de chaque détenteur de token sera calculé à l'aide de la formule suivante :
Nombre de votes = token * multiplicateur de conviction
La période de verrouillage double à chaque fois, le multiplicateur de conviction augmentera le multiplicateur de vote de un.
Multiplicateur de vote pour la période de verrouillage 00.111224384165326
La limite maximale pour le réglage des "doublages" de la période de verrouillage est de 6), pour un total de 32 périodes de verrouillage (, une période de verrouillage équivaut à 28 jours. Le doublement est uniquement autorisé, par exemple, il n'est pas possible de verrouiller 24 périodes et d'augmenter la conviction de 5,5.
Une fois que le token est verrouillé, il peut toujours être utilisé pour voter et pour le staking ; il est seulement interdit de transférer ces tokens vers un autre compte.
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 tokens.
Biais adaptatif de groupe
L'adaptation des biais de groupe a été utilisée plus longtemps dans la gouvernance v2 et a été remplacée par le système d'Approbation/Soutien.
) Conseil
Dans la gouvernance v1, les parties prenantes passives sur Polkadot sont représentées par un organe de gestion appelé "Conseil". Le Conseil est une entité on-chain composée de plusieurs participants, chaque participant représentant un compte on-chain. Sur Polkadot, le Conseil est actuellement composé de membres.
En plus de contrôler le Trésor, le Conseil est également principalement responsable de trois missions de gouvernance :
Dans la gouvernance v2, des stratégies alternatives sont nécessaires pour remplacer les responsabilités précédemment exercées par le conseil d'administration en tant qu'agence de délégation des électeurs, afin de compenser le fait que de nombreuses personnes choisissent de ne pas participer à la gouvernance quotidienne. Gov2 est construit sur la fonction de délégation de vote de v1, où les électeurs peuvent choisir de déléguer leurs droits de vote à un autre électeur dans le système. Cela est réalisé par l'amélioration d'une fonctionnalité appelée délégation multi-rôle, où les électeurs peuvent désigner des représentants différents pour chaque catégorie de référendum dans le système. Ainsi, les électeurs peuvent déléguer une entité pour gérer une catégorie de référendum d'impact mineur, tout en choisissant un autre représentant différent pour gérer une autre catégorie avec des conséquences plus significatives, tout en conservant le plein droit de vote sur toutes les catégories restantes.
( Annuler le référendum
Dans la gouvernance v1, si le comité technique est d'accord à l'unanimité pour annuler une proposition, ou si la source Root ) déclenche cette fonction comme sudo(, alors 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 tardivement dans la proposition de référendum ), comme des erreurs dans le code runtime que la proposition exécutera (, cela pourrait être considéré comme un dernier recours.
Si la controverse entourant l'annulation est suffisamment grande pour que le conseil ne puisse pas obtenir une majorité des deux tiers, alors 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 Cancelation) pour annuler###, utilisée pour intervenir dans les propositions déjà votées. Cette opération rejettera immédiatement le référendum en cours, quel que soit son état. Il y a également une disposition stipulant que si la proposition est malveillante ou du spam, le dépôt du proposeur sera confisqué.
L'annulation est en soi une opération de gouvernance qui doit être exécutée par un vote du réseau. L'annulation est accompagnée de son propre Origine et Traçabilité, elle a une période d'importation très courte et une courbe de taux d'approbation/de soutien, qui descend légèrement plus rapidement grâce à un seuil, car elle est déclenchée en cas d'urgence.
Comité technique
Dans la gouvernance v1, le comité technique (TC) est l'une des trois chambres de la gouvernance de Kusama(, les deux autres chambres é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.
L'objectif de TC est d'empêcher les votes malveillants, d'implémenter des corrections de bugs, de revenir sur des mises à jour de runtime erronées ou d'ajouter de nouvelles fonctionnalités éprouvées sur le terrain. TC a le droit d'utiliser le pallet Democracy pour accélérer les propositions, et est le seul capable de