Polkadot a adopté un mécanisme de gouvernance sophistiqué qui peut évoluer élégamment en fonction des besoins des parties prenantes. Son objectif est de garantir que la majorité des participations contrôle toujours le réseau.
Le contenu de cet article peut être sujet à des changements. 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é de Polkadot (v1) se compose de trois composants principaux :
Comité technique : gestion du calendrier de mise à niveau
Conseil: un "gouvernement" élu, responsable de la gestion des paramètres, de la gestion et des propositions de dépenses.
Référendum : vote général sur toutes les autres affaires, les parties prenantes à long terme ont plus d'influence.
Ce système fonctionnait bien au début de son fonctionnement, aidant à une utilisation raisonnable des fonds de la trésorerie et à une mise à jour et réparation rapides. 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 sont identiques, et il n'est possible de voter que pour un seul référendum à la fois, la période de vote pouvant durer plusieurs semaines. Cela a conduit à ce que le système ait tendance à considérer attentivement un très petit nombre de propositions, plutôt qu'à envisager largement plusieurs propositions. C'est pourquoi "gouvernance v2" a vu le jour.
"Gouvernance v2" ou "Gov2" a changé la manière dont les décisions quotidiennes sont prises, rendant les référendums plus influents et agiles, et augmentant considérablement le nombre de décisions collectives que le système peut prendre.
Après un examen professionnel final du code, Gov2 sera lancé sur Kusama. Après des tests sur Kusama, une proposition sera faite pour le déployer sur Polkadot.
Les principes de gouvernance fondamentaux du réseau Polkadot seront d'abord présentés. Comprendre les origines de la gouvernance v1 aide à mieux saisir la direction de la deuxième itération. Ces différences et distinctions 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 sur le réseau, des plans pour la gouvernance v2.5 sont également en cours.
Prémisse
En résumé, ce réseau intègre une variété de mécanismes novateurs, y compris des fonctions de transition d'état amorphes définies par WebAssembly et stockées sur la chaîne, ainsi que divers mécanismes de vote en chaîne, tels que des référendums avec des seuils de majorité absolue adaptatifs et des mécanismes de vote d'approbation par lots.
Tous les changements apportés au protocole doivent être convenus 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 ( détenteurs de tokens ) ou par le conseil, elle doit finalement être soumise à un référendum de tous les détenteurs, avec des poids basés sur le montant de mise et la valeur de conviction.
La gouvernance v2 a quelques changements. La nouvelle façon dont le modèle de gouvernance reflète les caractéristiques de décentralisation est :
Transférer toutes les responsabilités 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 à des membres de la communauté de différentes manières.
Le conseil dans Gov1 a rempli les rôles de représentant des détenteurs de tokens passifs, de gardien du trésor et d'initiateur législatif, 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 schéma de vote simple, inclusif et basé sur le staking. Chaque référendum a une proposition spécifique, utilisant des appels de fonction de privilège runtime sous la forme (, y compris l'appel set_code le plus puissant, qui peut changer l'intégralité du code runtime ).
Un référendum est un événement discret avec une période de vote fixe. À la fin de la période de vote et après le comptage des bulletins, si approuvé, la fonction correspondante sera appelée. Un référendum est toujours binaire ; les choix ne peuvent être que "pour", "contre" ou totalement abstention.
Dans la gouvernance v1, les référendums peuvent être lancés de l'une des manières suivantes :
Propositions soumises publiquement
Proposition adoptée par vote majoritaire ou à l'unanimité par le Conseil.
Proposition soumise dans le cadre de l'exécution d'un 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 la mise en œuvre effective 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 programmée pour être exécutée. Si le référendum attend des résultats, c'est-à-dire s'il est en cours de vote, il est considéré comme non terminé.
S'il s'agit d'une proposition soumise par le public ou le conseil, il y a 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 réglé si nécessaire. Le traitement des propositions urgentes nécessite des "suivis rapides" sur des questions majeures, ce qui réduit le temps d'exécution.
Dans Gov2, tout le monde peut lancer un référendum à tout moment et peut en initier plusieurs. Gov2 introduit les nouvelles fonctionnalités Origins( et Tracks) pour aider le processus et le traitement des protocoles de référendum.
Origin peut être considéré comme une description riche du niveau de privilège donné. Le proposeur doit désormais choisir l'Origin approprié en fonction des exigences de la proposition.
Chaque origine est associée à une catégorie de vote, et chaque catégorie est liée à une piste. La piste décrit le cycle de vie de la proposition, et est indépendante des autres pistes de catégorie. Avoir différentes pistes indépendantes permet au réseau d'ajuster la dynamique du vote en fonction des niveaux de privilège implicites.
Par exemple, l'impact de l'appel set_code ( lors de la mise à niveau de Runtime ) sur l'écosystème est différent de l'approbation du pourboire du trésor ( pour l'appel reportAwesome ), nécessitant ainsi des Origines différentes, 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 sur le pallet.
( proposition de vote
Référendum public
Toute personne peut proposer un référendum en déposant le nombre minimum de tokens dans un certain nombre de blocs ) pendant une période donnée ###. Si quelqu'un accepte la proposition, il peut déposer le même nombre de tokens pour montrer son soutien.
Cette opération est appelée "endorsement". La proposition obtenant le plus grand soutien de tokens liés sera sélectionnée pour le prochain cycle de vote. Notez que cela peut différer du nombre absolu d'endorsements ; par exemple, trois comptes liant chacun 20 DOT auront une efficacité "supérieure" à celle de dix comptes liant chacun 1 DOT.
Une fois que la proposition est soumise (, le vote est lancé ), et le token lié sera libéré.
Pour la gouvernance v1, il peut y avoir jusqu'à 100 propositions publiques dans la file d'attente des propositions.
Dans Gov2, lorsque le référendum est créé, la communauté peut immédiatement voter. Cependant, ce référendum n'est pas dans un état où il peut être clôturé ou comptabilisé, approuvé et finalement exécuté. Au contraire, le référendum doit répondre à certains critères pour entrer dans l'état "Décider (Deciding)". Avant d'atteindre cet état, il reste dans un état d'attente.
Les critères pour entrer dans l'état Decided sont les suivants :
A traversé la période de préparation ( lead-in period ), c'est-à-dire le temps nécessaire avant qu'une décision puisse être prise. Cela aide à réduire la possibilité de "décision instantanée", c'est-à-dire qu'un attaquant contrôlant une grande quantité de droits de vote pourrait immédiatement approuver une proposition après qu'elle a été faite, plutôt que de laisser l'ensemble des votants avoir suffisamment de temps pour réfléchir et participer.
Il doit encore y avoir un espace restant pour décider. Tous les Track ont des limites sur le nombre de référendums pouvant être décidés simultanément. Les pistes avec des capacités plus puissantes ont des limites plus basses. Par exemple, la limite pour un Origin de niveau Root est de 1, c'est-à-dire qu'il ne peut décider qu'une seule proposition super dangereuse à 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 la valeur du dépôt ne comprend que la valeur nécessaire pour le stockage en chaîne requis pour le suivi. Cependant, passer en revue et décider sur le référendum comporte le risque d'épuiser les emplacements limités dans la file d'attente des référendums. Exiger un montant de dépôt plus élevé mais remboursable aide à réduire le spam.
Vote du conseil (v1)
Adoption à l'unanimité par le conseil - Lorsqu'un membre du conseil approuve une proposition, celle-ci peut être soumise à référendum. Ce référendum produira un biais de taux de vote négatif (, c'est-à-dire que moins il y a de votes de droits, moins il en faut pour qu'elle soit adoptée - voir biais de groupe adaptatif ).
Adoption par la majorité du conseil - Lorsqu'une simple majorité des membres du conseil est d'accord, un vote peut également être effectué sur le référendum, mais cela sera un 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, sauf s'il y a un référendum d'urgence en cours.
Calendrier de vote
Dans la Gouvernance v1, si au moins une proposition est présente dans l'une des files d'attente, un nouveau vote public aura lieu 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. Des votes seront organisés alternativement entre les propositions les mieux classées des deux files d'attente.
Les propositions les mieux classées sont déterminées par le montant de la mise qui leur est associée. Si la file d'attente actuelle essaie de créer un vote sans proposition ( et que la file d'attente d'une autre proposition est en attente, alors la proposition la mieux classée de l'autre file d'attente entrera dans le vote.
Il est interdit de voter sur plusieurs référendums en même temps, sauf en cas de référendum d'urgence. Le référendum d'urgence qui se déroule en même temps qu'un référendum ordinaire ) ou une proposition du conseil ( est la seule situation où il est possible de voter sur plusieurs référendums simultanément.
Lorsque la proposition est approuvée, la gouvernance v2 partage la même période d'éligibilité de 28 jours. Si elle n'est toujours pas approuvée à la fin de cette période, la proposition sera automatiquement rejetée.
Vote de référendum ) gouvernance v2(
Dans la Gouvernance v2, si une proposition satisfait aux exigences de taux d'approbation et de soutien, alors cette proposition sera approuvée, c'est-à-dire que le système de biais de groupe adaptatif a été supprimé.
Le taux d'approbation ) est défini comme le poids de vote d'approbation ( après ajustement de la conviction ) représentant la part totale du poids de vote ( incluant les parts d'approbation et de rejet ).
Le taux de soutien (Support) est le nombre total de votes approuvés ( en ignorant l'ajustement de la conviction ) par rapport à la comparaison avec le nombre total de votes qui pourraient être effectués dans le système.
Il doit répondre à cette norme dans le délai de confirmation le plus court. Différentes voies ont des délais de confirmation et des exigences d'approbation et de soutien différents. Il est maintenant configurable via la quantité de soutien requise et l'approbation globale. Pour les propositions utilisant des sources à faible 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 haut privilège ( comme Root). Celles ayant une plus grande signification politique peuvent demander plus tôt une approbation plus élevée pour éviter les 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 parvient à rester 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 la piste. Des pistes plus puissantes imposeront des périodes d'exécution plus longues pour s'assurer que le réseau dispose de suffisamment de temps pour se préparer à tout changement 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 la durée pendant laquelle ils sont disposés à verrouiller leurs tokens. Ainsi, le nombre de voix 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 tour, le multiplicateur de conviction augmentera le multiplicateur de vote de un.
Durée de verrouillage Multiplicateur de vote
0 1
1 2
2 3
4 4
8 5
16 6
32 6
La durée de "double" est réglée sur un maximum de 6(, donc un total de 32 périodes de verrouillage ), une période de verrouillage équivaut à 28 jours. Seul le double est autorisé, par exemple, vous ne pouvez pas verrouiller 24 cycles et faire augmenter votre conviction de 5,5.
Une fois que les tokens sont verrouillés, vous pouvez toujours les utiliser pour voter et staker ; vous êtes seulement interdit de transférer ces tokens à 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 de groupe adaptatif
Le biais adaptatif des groupes a été utilisé plus longtemps dans Governance v2 et a été remplacé par le système d'Approvisionnement/Support.
( 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é en chaîne composée de plusieurs participants, chaque participant représentant un compte en chaîne. Sur Polkadot, le Conseil est actuellement composé de membres.
En plus de contrôler le Trésor public, le conseil est également principalement responsable de trois tâches de gouvernance :
Proposition de référendum sage
Annuler les référendums dangereux ou malveillants
Commission technique électorale
Dans la gouvernance v2, une stratégie alternative est nécessaire pour remplacer les responsabilités du 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 fonctionnalité de délégation de vote de v1, permettant aux électeurs de choisir de déléguer leurs droits de vote à un autre électeur dans le système. Cela est réalisé en améliorant une fonctionnalité appelée délégation multi-rôle, dans laquelle les électeurs peuvent désigner différents représentants pour chaque catégorie de référendum dans le système. Ainsi, par exemple, un électeur peut déléguer une entité pour gérer une catégorie de référendum ayant peu d'impact, tout en choisissant un autre représentant différent pour gérer une autre catégorie ayant des conséquences plus significatives, tout en conservant pleinement ses droits de vote sur toutes les autres catégories restantes.
) Annuler le référendum
Dans la gouvernance v1, si le comité technique consent à l'unanimité à annuler une proposition, ou si la source Root ( déclenche cette fonctionnalité 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 un problème est découvert tardivement dans la proposition de référendum (, par exemple, s'il y a une erreur dans le code runtime qui sera exécuté ), cela peut être considéré comme un dernier recours.
si la controverse annulée est suffisamment grande, pour
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 J'aime
Récompense
13
6
Partager
Commentaire
0/400
HodlNerd
· 07-01 15:56
la théorie des jeux dans la gouvernance est géniale... mais as-tu vu la distribution statistique de la participation des électeurs ? un peu préoccupant pour être honnête
Voir l'originalRépondre0
BearMarketSurvivor
· 07-01 15:56
Ce n'est rien d'autre qu'une nouvelle méthode pour se faire prendre pour des cons.
Voir l'originalRépondre0
GhostChainLoyalist
· 07-01 15:42
Quand pourrons-nous vraiment atteindre la Décentralisation ?
Voir l'originalRépondre0
CryptoMotivator
· 07-01 15:40
Est-ce que tout le monde s'est agité avec la mise à jour v2.5 ?
Voir l'originalRépondre0
BackrowObserver
· 07-01 15:40
Je ne peux pas supporter, en avoir trop, je ne me souviens pas...
Voir l'originalRépondre0
CoconutWaterBoy
· 07-01 15:39
Gouvernance v2 ? Il vaudrait mieux ajouter un DAO communautaire.
Polkadot gouvernance V2 : l'évolution de la décision décentralisée
Gouvernance V2
Polkadot a adopté un mécanisme de gouvernance sophistiqué qui peut évoluer élégamment en fonction des besoins des parties prenantes. Son objectif est de garantir que la majorité des participations contrôle toujours le réseau.
Le contenu de cet article peut être sujet à des changements. 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é de Polkadot (v1) se compose de trois composants principaux :
Ce système fonctionnait bien au début de son fonctionnement, aidant à une utilisation raisonnable des fonds de la trésorerie et à une mise à jour et réparation rapides. 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 sont identiques, et il n'est possible de voter que pour un seul référendum à la fois, la période de vote pouvant durer plusieurs semaines. Cela a conduit à ce que le système ait tendance à considérer attentivement un très petit nombre de propositions, plutôt qu'à envisager largement plusieurs propositions. C'est pourquoi "gouvernance v2" a vu le jour.
"Gouvernance v2" ou "Gov2" a changé la manière dont les décisions quotidiennes sont prises, rendant les référendums plus influents et agiles, et augmentant considérablement le nombre de décisions collectives que le système peut prendre.
Après un examen professionnel final du code, Gov2 sera lancé sur Kusama. Après des tests sur Kusama, une proposition sera faite pour le déployer sur Polkadot.
Les principes de gouvernance fondamentaux du réseau Polkadot seront d'abord présentés. Comprendre les origines de la gouvernance v1 aide à mieux saisir la direction de la deuxième itération. Ces différences et distinctions 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 sur le réseau, des plans pour la gouvernance v2.5 sont également en cours.
Prémisse
En résumé, ce réseau intègre une variété de mécanismes novateurs, y compris des fonctions de transition d'état amorphes définies par WebAssembly et stockées sur la chaîne, ainsi que divers mécanismes de vote en chaîne, tels que des référendums avec des seuils de majorité absolue adaptatifs et des mécanismes de vote d'approbation par lots.
Tous les changements apportés au protocole doivent être convenus 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 ( détenteurs de tokens ) ou par le conseil, elle doit finalement être soumise à un référendum de tous les détenteurs, avec des poids basés sur le montant de mise et la valeur de conviction.
La gouvernance v2 a quelques changements. La nouvelle façon dont le modèle de gouvernance reflète les caractéristiques de décentralisation est :
Le conseil dans Gov1 a rempli les rôles de représentant des détenteurs de tokens passifs, de gardien du trésor et d'initiateur législatif, 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 schéma de vote simple, inclusif et basé sur le staking. Chaque référendum a une proposition spécifique, utilisant des appels de fonction de privilège runtime sous la forme (, y compris l'appel set_code le plus puissant, qui peut changer l'intégralité du code runtime ).
Un référendum est un événement discret avec une période de vote fixe. À la fin de la période de vote et après le comptage des bulletins, si approuvé, la fonction correspondante sera appelée. Un référendum est toujours binaire ; les choix ne peuvent être que "pour", "contre" ou totalement abstention.
Dans la gouvernance v1, les référendums peuvent être lancés de l'une des manières suivantes :
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 la mise en œuvre effective 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 programmée pour être exécutée. Si le référendum attend des résultats, c'est-à-dire s'il est en cours de vote, il est considéré comme non terminé.
S'il s'agit d'une proposition soumise par le public ou le conseil, il y a 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 réglé si nécessaire. Le traitement des propositions urgentes nécessite des "suivis rapides" sur des questions majeures, ce qui réduit le temps d'exécution.
Dans Gov2, tout le monde peut lancer un référendum à tout moment et peut en initier plusieurs. Gov2 introduit les nouvelles fonctionnalités Origins( et Tracks) pour aider le processus et le traitement des protocoles de référendum.
Origin peut être considéré comme une description riche du niveau de privilège donné. Le proposeur doit désormais choisir l'Origin approprié en fonction des exigences de la proposition.
Chaque origine est associée à une catégorie de vote, et chaque catégorie est liée à une piste. La piste décrit le cycle de vie de la proposition, et est indépendante des autres pistes de catégorie. Avoir différentes pistes indépendantes permet au réseau d'ajuster la dynamique du vote en fonction des niveaux de privilège implicites.
Par exemple, l'impact de l'appel set_code ( lors de la mise à niveau de Runtime ) sur l'écosystème est différent de l'approbation du pourboire du trésor ( pour l'appel reportAwesome ), nécessitant ainsi des Origines différentes, 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 sur le pallet.
( proposition de vote
Référendum public
Toute personne peut proposer un référendum en déposant le nombre minimum de tokens dans un certain nombre de blocs ) pendant une période donnée ###. Si quelqu'un accepte la proposition, il peut déposer le même nombre de tokens pour montrer son soutien.
Cette opération est appelée "endorsement". La proposition obtenant le plus grand soutien de tokens liés sera sélectionnée pour le prochain cycle de vote. Notez que cela peut différer du nombre absolu d'endorsements ; par exemple, trois comptes liant chacun 20 DOT auront une efficacité "supérieure" à celle de dix comptes liant chacun 1 DOT.
Une fois que la proposition est soumise (, le vote est lancé ), et le token lié sera libéré.
Pour la gouvernance v1, il peut y avoir jusqu'à 100 propositions publiques dans la file d'attente des propositions.
Dans Gov2, lorsque le référendum est créé, la communauté peut immédiatement voter. Cependant, ce référendum n'est pas dans un état où il peut être clôturé ou comptabilisé, approuvé et finalement exécuté. Au contraire, le référendum doit répondre à certains critères pour entrer dans l'état "Décider (Deciding)". Avant d'atteindre cet état, il reste dans un état d'attente.
Les critères pour entrer dans l'état Decided sont les suivants :
Vote du conseil (v1)
Adoption à l'unanimité par le conseil - Lorsqu'un membre du conseil approuve une proposition, celle-ci peut être soumise à référendum. Ce référendum produira un biais de taux de vote négatif (, c'est-à-dire que moins il y a de votes de droits, moins il en faut pour qu'elle soit adoptée - voir biais de groupe adaptatif ).
Adoption par la majorité du conseil - Lorsqu'une simple majorité des membres du conseil est d'accord, un vote peut également être effectué sur le référendum, mais cela sera un 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, sauf s'il y a un référendum d'urgence en cours.
Calendrier de vote
Dans la Gouvernance v1, si au moins une proposition est présente dans l'une des files d'attente, un nouveau vote public aura lieu 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. Des votes seront organisés alternativement entre les propositions les mieux classées des deux files d'attente.
Les propositions les mieux classées sont déterminées par le montant de la mise qui leur est associée. Si la file d'attente actuelle essaie de créer un vote sans proposition ( et que la file d'attente d'une autre proposition est en attente, alors la proposition la mieux classée de l'autre file d'attente entrera dans le vote.
Il est interdit de voter sur plusieurs référendums en même temps, sauf en cas de référendum d'urgence. Le référendum d'urgence qui se déroule en même temps qu'un référendum ordinaire ) ou une proposition du conseil ( est la seule situation où il est possible de voter sur plusieurs référendums simultanément.
Lorsque la proposition est approuvée, la gouvernance v2 partage la même période d'éligibilité de 28 jours. Si elle n'est toujours pas approuvée à la fin de cette période, la proposition sera automatiquement rejetée.
Vote de référendum ) gouvernance v2(
Dans la Gouvernance v2, si une proposition satisfait aux exigences de taux d'approbation et de soutien, alors cette proposition sera approuvée, c'est-à-dire que le système de biais de groupe adaptatif a été supprimé.
Le taux d'approbation ) est défini comme le poids de vote d'approbation ( après ajustement de la conviction ) représentant la part totale du poids de vote ( incluant les parts d'approbation et de rejet ).
Le taux de soutien (Support) est le nombre total de votes approuvés ( en ignorant l'ajustement de la conviction ) par rapport à la comparaison avec le nombre total de votes qui pourraient être effectués dans le système.
Il doit répondre à cette norme dans le délai de confirmation le plus court. Différentes voies ont des délais de confirmation et des exigences d'approbation et de soutien différents. Il est maintenant configurable via la quantité de soutien requise et l'approbation globale. Pour les propositions utilisant des sources à faible 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 haut privilège ( comme Root). Celles ayant une plus grande signification politique peuvent demander plus tôt une approbation plus élevée pour éviter les 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 parvient à rester 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 la piste. Des pistes plus puissantes imposeront des périodes d'exécution plus longues pour s'assurer que le réseau dispose de suffisamment de temps pour se préparer à tout changement 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 la durée pendant laquelle ils sont disposés à verrouiller leurs tokens. Ainsi, le nombre de voix 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 tour, le multiplicateur de conviction augmentera le multiplicateur de vote de un.
Durée de verrouillage Multiplicateur de vote 0 1 1 2 2 3 4 4 8 5 16 6 32 6
La durée de "double" est réglée sur un maximum de 6(, donc un total de 32 périodes de verrouillage ), une période de verrouillage équivaut à 28 jours. Seul le double est autorisé, par exemple, vous ne pouvez pas verrouiller 24 cycles et faire augmenter votre conviction de 5,5.
Une fois que les tokens sont verrouillés, vous pouvez toujours les utiliser pour voter et staker ; vous êtes seulement interdit de transférer ces tokens à 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 de groupe adaptatif
Le biais adaptatif des groupes a été utilisé plus longtemps dans Governance v2 et a été remplacé par le système d'Approvisionnement/Support.
( 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é en chaîne composée de plusieurs participants, chaque participant représentant un compte en chaîne. Sur Polkadot, le Conseil est actuellement composé de membres.
En plus de contrôler le Trésor public, le conseil est également principalement responsable de trois tâches de gouvernance :
Dans la gouvernance v2, une stratégie alternative est nécessaire pour remplacer les responsabilités du 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 fonctionnalité de délégation de vote de v1, permettant aux électeurs de choisir de déléguer leurs droits de vote à un autre électeur dans le système. Cela est réalisé en améliorant une fonctionnalité appelée délégation multi-rôle, dans laquelle les électeurs peuvent désigner différents représentants pour chaque catégorie de référendum dans le système. Ainsi, par exemple, un électeur peut déléguer une entité pour gérer une catégorie de référendum ayant peu d'impact, tout en choisissant un autre représentant différent pour gérer une autre catégorie ayant des conséquences plus significatives, tout en conservant pleinement ses droits de vote sur toutes les autres catégories restantes.
) Annuler le référendum
Dans la gouvernance v1, si le comité technique consent à l'unanimité à annuler une proposition, ou si la source Root ( déclenche cette fonctionnalité 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 un problème est découvert tardivement dans la proposition de référendum (, par exemple, s'il y a une erreur dans le code runtime qui sera exécuté ), cela peut être considéré comme un dernier recours.
si la controverse annulée est suffisamment grande, pour