Polkadot utiliza un ingenioso mecanismo de gobernanza que le permite evolucionar constantemente según las necesidades de los interesados. Su objetivo es asegurar que la mayoría de las participaciones siempre puedan controlar la red.
El contenido de este artículo puede estar sujeto a cambios. El protocolo de gobernanza ha pasado por varias iteraciones (v1 y v2), y habrá más cambios en el futuro (v2.5).
El primer sistema de gobernanza descentralizada de Polkadot (v1) consta de tres componentes principales:
Comité Técnico: gestionar el cronograma de actualizaciones
Consejo: un "gobierno" electo responsable de gestionar parámetros, propuestas de gestión y gastos.
Referéndum: sistema de votación universal que otorga mayor influencia a los interesados a largo plazo
El sistema funcionó bien en los primeros años, pero a medida que maduraba, necesitaba evolucionar continuamente para mejorar sus deficiencias y mantenerse al día con los avances. Por ejemplo, en "gobernanza v1", todos los pesos de las votaciones eran iguales, solo se podía votar en una propuesta a la vez, y el período de votación podía durar varias semanas. Esto llevó a que el sistema tendiera a considerar cuidadosamente un número muy limitado de propuestas, en lugar de considerar ampliamente múltiples propuestas. Así nació "gobernanza v2".
"Gobernanza v2" o "Gov2" ha cambiado la forma en que se toman las decisiones diarias, ampliando y agilizando el alcance de los referendos, lo que aumenta significativamente la cantidad de decisiones colectivas que el sistema puede tomar.
Gov2 se lanzará y probará en Kusama antes de proponer su implementación en Polkadot. Actualmente, Gov2 ya está en la red Kusama.
El siguiente contenido presentará los principios de gobernanza fundamentales de la red Polkadot. Comprender las raíces de la gobernanza v1 ayudará a entender mejor la dirección de la segunda iteración. Estas diferencias se destacarán en varios subtemas.
Es importante señalar que, en esta etapa actual, la gobernanza sigue siendo un protocolo en constante desarrollo. Con la actualización de la gobernanza v2, también se está elaborando el plan para la gobernanza v2.5.
premisa
En resumen, la red reúne una variedad de mecanismos novedosos, incluyendo funciones de transformación de estado amorfo almacenadas en la cadena definidas por WebAssembly (, así como varios mecanismos de votación en cadena, como referendos con umbrales de mayoría absoluta adaptativa y votaciones de aprobación por lotes.
Cualquier cambio en el acuerdo debe ser acordado a través de un referéndum ponderado por derechos.
) mecanismo
En la gobernanza v1, los titulares de tokens activos y el consejo gestionan conjuntamente las decisiones sobre la actualización de la red. Independientemente de si la propuesta es presentada por el público o por el consejo, debe ser sometida a un referéndum general, donde se toma la decisión basada en el monto de la participación y el valor de la creencia.
La gobernanza v2 tiene varios cambios. La nueva forma del modelo de gobernanza que refleja las características de descentralización es:
Transferir la responsabilidad del consejo a los titulares de tokens a través de una votación democrática
Disolver la actual junta directiva
Permitir a los usuarios delegar sus derechos de voto a los miembros de la comunidad de más maneras
referéndum
El referéndum es un esquema de votación simple, inclusivo y basado en la participación. Cada referéndum tiene una propuesta relacionada, que utiliza la forma de llamada a funciones de privilegios de runtime ###, incluyendo la llamada set_code más poderosa, que puede cambiar todo el código de runtime (.
El referéndum es un evento discreto con un período de votación fijo. Una vez que finaliza el período de votación y se cuentan los votos, si se aprueba, se llamarán a las funciones correspondientes. El referéndum siempre es binario; las opciones de votación solo pueden ser "a favor", "en contra" o abstenerse completamente.
En la gobernanza v1, el referéndum se puede iniciar de las siguientes maneras:
Propuesta presentada públicamente
Propuestas aprobadas por la mayoría o por unanimidad del consejo
Propuesta presentada como parte de la ejecución del referéndum anterior
Propuesta de emergencia presentada por el comité técnico y aprobada por la junta directiva
Todas las votaciones tienen un período de demora de ejecución correspondiente. Este es el período de tiempo entre el final de la votación y la implementación real de la propuesta.
En Gov2, cualquier persona puede iniciar un referéndum en cualquier momento, sin límite de次数. Gov2 introduce los conceptos de Origins) y Tracks( para ayudar en el proceso y manejo del protocolo de referéndum.
Origin puede considerarse como un descriptor del nivel de privilegio dado. El proponente necesita seleccionar el Origin adecuado para la solicitud según los requisitos de la propuesta.
Cada Origin está asociado a una categoría de referéndum, y cada categoría tiene una Track. La Track describe el ciclo de vida de la propuesta y es independiente de otras categorías. Diferentes Tracks independientes permiten a la red ajustar la dinámica del referéndum según el nivel de privilegio implícito.
Por ejemplo, el impacto de la actualización de Runtime en el ecosistema es diferente de la aprobación de las propinas del tesoro, por lo que se necesitan diferentes Orígenes, donde la tasa de votación, la tasa de aprobación, el depósito y el período de ejecución más corto se determinarán de antemano.
) propuesta de referéndum
Referéndum público
Cualquiera puede proponer un referéndum depositando la cantidad mínima de tokens durante un período determinado. Si alguien está de acuerdo, puede depositar la misma cantidad de tokens para mostrar su apoyo.
Esto se llama "endorso". La propuesta que obtenga el mayor soporte de tokens vinculados será seleccionada para el próximo ciclo de votación. Tenga en cuenta que esto puede diferir de la cantidad absoluta de endosos; por ejemplo, tres cuentas que vinculan 20 DOT cada una "superarán" a diez cuentas que vinculan 1 DOT cada una.
Una vez que se presente la propuesta ( para votación ), el token vinculado será liberado.
Para la gobernanza v1, puede haber hasta 100 propuestas públicas en la cola de propuestas.
En Gov2, una vez que se crea el referéndum, la comunidad puede votar de inmediato. Sin embargo, el referéndum no está en un estado que permita finalizar, contar los votos, obtener aprobación y ejecutar finalmente. Por el contrario, el referéndum debe cumplir ciertos criterios para entrar en el estado de "decidiendo ###Deciding(". Hasta entonces, permanece en estado pendiente.
Los estándares para entrar en estado Decided son los siguientes:
Pasó por un período de importación, es decir, el tiempo que debe transcurrir antes de que se pueda comenzar a decidir. Esto ayuda a reducir la posibilidad de "decidir un ataque", es decir, que un atacante con un gran control sobre los derechos de voto pueda aprobar una propuesta inmediatamente después de la propuesta, sin dar a todos los votantes el tiempo suficiente para considerar y participar.
Debe haber espacio restante para tomar decisiones. Todos los Track tienen un límite en la cantidad de referendos que se pueden decidir simultáneamente. Los límites de Tracks más poderosos son más bajos. Por ejemplo, el límite del nivel Root Origin es 1, lo que significa que solo se puede decidir una propuesta de súper peligro a la vez.
Se debe pagar un depósito decidido. Crear una votación es muy barato, ya que el depósito solo incluye el valor necesario para el almacenamiento en cadena. Sin embargo, revisar y decidir sobre la votación conlleva el riesgo de agotar las posiciones limitadas en la cola de votaciones. Requerir un depósito más grande pero reembolsable ayuda a reducir el spam.
Referéndum del consejo )v1(
Aprobación unánime del consejo - Cuando todos los miembros del consejo están de acuerdo con una propuesta, se puede llevar a votación pública. Esta votación pública producirá una desviación de la tasa de voto negativo ), es decir, cuanto menor sea el número de votos a favor, menor será el número requerido para su aprobación (.
Aprobación por mayoría del consejo - Cuando solo una simple mayoría de los miembros del consejo esté de acuerdo, también se puede votar en el referéndum, pero será un sistema de mayoría, donde la parte que obtenga el 51% de los votos será la ganadora ).
Solo puede haber un referéndum válido a la vez, a menos que haya un referéndum de emergencia en curso.
Calendario de votación
En la gobernanza v1, se asumirá que hay al menos una propuesta en la cola, y se realizará una nueva votación cada 28 días. Las propuestas aprobadas por el consejo tienen una cola, y las propuestas presentadas por el público también tienen una cola. Se alternará la votación entre las propuestas mejor clasificadas de las dos colas.
Las propuestas más destacadas se determinan por la cantidad de participación vinculada detrás de ellas. Si la cola actual intenta crear un referéndum sin propuestas y la cola ( está vacía ), y hay propuestas en cola en otra cola, la propuesta más destacada de la otra cola entrará en el referéndum.
No se pueden votar múltiples referendos en el mismo período, salvo en el caso de referendos urgentes. Los referendos urgentes que ocurren al mismo tiempo que un referendo regular son la única situación en la que se puede votar sobre múltiples referendos simultáneamente.
Cuando la propuesta sea aprobada, la gobernanza v2 compartirá el mismo período de calificación de 28 días. Si no se aprueba al final de esta fase, la propuesta será automáticamente rechazada.
Votación de referéndum ( gobernanza v2)
En la gobernanza v2, si una propuesta cumple con los requisitos de tasa de aprobación y tasa de apoyo, la propuesta será aprobada, es decir, se eliminará el sistema de sesgo adaptativo del grupo.
La tasa de aprobación ( se define como el peso del voto de aprobación ) después del ajuste de convicción ( en relación con el peso total del voto ), que incluye la participación de la aprobación y el rechazo (.
La tasa de apoyo ) Soporte ( es el número total de votos aprobados ) ignora el ajuste de convicción ( en comparación con el número total de votos que pueden realizarse en el sistema.
Debe cumplir con este estándar en el menor tiempo posible durante el período de confirmación. Diferentes rutas tienen diferentes períodos de confirmación y requisitos de aprobación y apoyo. Ahora se puede configurar a través de la cantidad de apoyo requerida y la aprobación general. Para las propuestas que utilizan fuentes de menor privilegio, es más razonable reducir la tasa de votación requerida a un número más realista más temprano en comparación con las propuestas que utilizan categorías de alto privilegio ) como Root(. Los cursos con un gran significado político pueden solicitar una mayor aprobación con anticipación para evitar controversias.
En Gov2, las propuestas que no sean aprobadas después de 28 días se considerarán rechazadas por defecto y se devolverá el Depósito de Decisión. Si la propuesta permanece aprobada antes de que termine el período de confirmación, se considerará aprobada y se planea ejecutar a partir de la fuente propuesta después del período de formulación. El período de formulación se designa cuando se propone una votación general, pero también está sujeto a un mínimo basado en el camino. Los Tracks más poderosos impondrán un período de ejecución más largo para garantizar que la red tenga suficiente tiempo para prepararse para los cambios que la propuesta pueda traer.
Bloqueo voluntario
Polkadot utiliza el concepto de "bloqueo voluntario", que permite a los titulares de tokens aumentar su poder de voto al declarar cuánto tiempo están dispuestos a bloquear sus tokens. Por lo tanto, el número de votos de cada titular de tokens se calculará utilizando la siguiente fórmula:
Número de votos = token * multiplicador de convicción
El número de períodos de bloqueo se duplica en cada ronda, el multiplicador de convicción aumentará el multiplicador de votos en uno.
Multiplicador de votos de período de bloqueo 00.111224384165326
El número máximo de veces que se puede "duplicar" el período de bloqueo se establece en 6), con un total de 32 períodos de bloqueo (, un período de bloqueo equivale a 28 días. Solo se permite duplicar, por ejemplo, no se puede bloquear 24 ciclos y hacer que la convicción aumente 5.5.
Una vez que los tokens están bloqueados, aún se pueden usar para votar y hacer staking; solo se prohíbe transferir estos tokens a otra cuenta.
Los votos siempre se "calculan" al mismo tiempo, es decir, al final del período de votación. Esto no se ve afectado por el período de bloqueo del token.
Sesgo adaptativo del grupo
La desviación adaptativa de grupos se ha utilizado durante más tiempo en la gobernanza v2 y ha sido reemplazada por el sistema de Aprobación/S apoyo.
) Consejo
En la gobernanza v1, los interesados pasivos en Polkadot son representados por un organismo de gestión llamado "Consejo". El Consejo es una entidad en la cadena, compuesta por múltiples participantes, cada uno de los cuales representa una cuenta en la cadena. En Polkadot, el Consejo actualmente está compuesto por miembros.
Además de controlar el tesoro nacional, el consejo es principalmente responsable de tres tareas de gobernanza:
Referéndum inteligente de propuestas
Cancelar referendos peligrosos o maliciosos
Comisión Técnica Electoral
En la gobernanza v2, se necesitan estrategias alternativas para reemplazar las funciones del consejo que anteriormente actuaba como una entidad de delegación de votantes, para compensar el hecho de que muchas personas eligen no participar en la gobernanza diaria. Gov2 se basa en la función de delegación de votación de v1, donde los votantes pueden elegir delegar su derecho de voto a otro votante dentro del sistema. Esto se logra a través de una mejora llamada delegación de múltiples roles, donde los votantes pueden designar diferentes representantes para cada categoría de referéndum en el sistema. Por lo tanto, los votantes pueden delegar a una entidad para gestionar una categoría de referéndum de menor impacto, mientras eligen a otro representante diferente para gestionar otra categoría con consecuencias más significativas, y aún así conservar el derecho completo de voto sobre cualquier categoría restante.
( Cancelar el referéndum
En la gobernanza v1, se puede cancelar una propuesta si el comité técnico está de acuerdo unánimemente en cancelarla, o si la fuente Root ) activa esta función, como sudo (. El depósito de la propuesta cancelada será destruido.
Además, una mayoría de dos tercios del consejo puede anular el referéndum. Si se descubren problemas en la propuesta del referéndum más tarde ), como errores en el código de ejecución que se implementará en la propuesta ###, esto puede considerarse como último recurso.
Si la controversia cancelada es lo suficientemente grande como para que el consejo no pueda obtener una mayoría de dos tercios, entonces será decidido conjuntamente por los interesados el destino de la propuesta.
En la gobernanza v2, hay una operación especial llamada Cancelation### que se utiliza para intervenir en propuestas que ya han sido votadas. Esta operación rechazará inmediatamente el referéndum en curso, sin importar su estado. También hay una disposición que asegura que si la propuesta es maliciosa o spam, el depósito del proponente será confiscado.
La cancelación es en sí misma una operación de gobernanza que debe ejecutarse mediante votación en la red. La revocación viene acompañada de su propio Origen y Seguimiento, tiene un período de importación muy corto y una curva de tasa de aprobación / tasa de apoyo, que desciende un poco más rápido a través del umbral, ya que se invoca solo en situaciones urgentes.
( Comité Técnico
En la gobernanza v1, el comité técnico )TC( es uno de los tres órganos de gobernanza de Kusama, los otros dos son el consejo y el referéndum ). El TC está compuesto por equipos que han implementado o definido el runtime de Polkadot o el Host de Polkadot. A través de una votación por mayoría simple del consejo, se pueden añadir o eliminar equipos en el TC.
El objetivo de TC es prevenir votaciones maliciosas, implementar correcciones de errores, revertir actualizaciones de runtime erróneas o agregar nuevas funciones que hayan sido probadas en la práctica. TC tiene el derecho de usar el pallet de Democracia para acelerar propuestas, y es el único que puede
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
15 me gusta
Recompensa
15
8
Compartir
Comentar
0/400
MetaMuskRat
· 07-30 04:17
Ah, v2 tampoco tiene grandes cambios.
Ver originalesResponder0
CoffeeOnChain
· 07-28 20:33
¿Está bien después de tantas iteraciones?
Ver originalesResponder0
ApyWhisperer
· 07-28 18:01
La gobernanza es genial, ¿cuándo sube a v3?
Ver originalesResponder0
0xOverleveraged
· 07-27 10:12
¿Cuándo se estabilizarán tanto v2 como v2.5?
Ver originalesResponder0
ServantOfSatoshi
· 07-27 10:04
La gobernanza depende del capital, jaja
Ver originalesResponder0
BearHugger
· 07-27 09:58
Este mecanismo de gobernanza es confiable.
Ver originalesResponder0
ForkYouPayMe
· 07-27 09:52
¡La versión 2 es realmente buena! Es mucho mejor que la versión 1.
Gobernanza de Polkadot V2: Un nuevo capítulo en la Descentralización de decisiones
Gobernanza V2
Polkadot utiliza un ingenioso mecanismo de gobernanza que le permite evolucionar constantemente según las necesidades de los interesados. Su objetivo es asegurar que la mayoría de las participaciones siempre puedan controlar la red.
El contenido de este artículo puede estar sujeto a cambios. El protocolo de gobernanza ha pasado por varias iteraciones (v1 y v2), y habrá más cambios en el futuro (v2.5).
El primer sistema de gobernanza descentralizada de Polkadot (v1) consta de tres componentes principales:
El sistema funcionó bien en los primeros años, pero a medida que maduraba, necesitaba evolucionar continuamente para mejorar sus deficiencias y mantenerse al día con los avances. Por ejemplo, en "gobernanza v1", todos los pesos de las votaciones eran iguales, solo se podía votar en una propuesta a la vez, y el período de votación podía durar varias semanas. Esto llevó a que el sistema tendiera a considerar cuidadosamente un número muy limitado de propuestas, en lugar de considerar ampliamente múltiples propuestas. Así nació "gobernanza v2".
"Gobernanza v2" o "Gov2" ha cambiado la forma en que se toman las decisiones diarias, ampliando y agilizando el alcance de los referendos, lo que aumenta significativamente la cantidad de decisiones colectivas que el sistema puede tomar.
Gov2 se lanzará y probará en Kusama antes de proponer su implementación en Polkadot. Actualmente, Gov2 ya está en la red Kusama.
El siguiente contenido presentará los principios de gobernanza fundamentales de la red Polkadot. Comprender las raíces de la gobernanza v1 ayudará a entender mejor la dirección de la segunda iteración. Estas diferencias se destacarán en varios subtemas.
Es importante señalar que, en esta etapa actual, la gobernanza sigue siendo un protocolo en constante desarrollo. Con la actualización de la gobernanza v2, también se está elaborando el plan para la gobernanza v2.5.
premisa
En resumen, la red reúne una variedad de mecanismos novedosos, incluyendo funciones de transformación de estado amorfo almacenadas en la cadena definidas por WebAssembly (, así como varios mecanismos de votación en cadena, como referendos con umbrales de mayoría absoluta adaptativa y votaciones de aprobación por lotes.
Cualquier cambio en el acuerdo debe ser acordado a través de un referéndum ponderado por derechos.
) mecanismo
En la gobernanza v1, los titulares de tokens activos y el consejo gestionan conjuntamente las decisiones sobre la actualización de la red. Independientemente de si la propuesta es presentada por el público o por el consejo, debe ser sometida a un referéndum general, donde se toma la decisión basada en el monto de la participación y el valor de la creencia.
La gobernanza v2 tiene varios cambios. La nueva forma del modelo de gobernanza que refleja las características de descentralización es:
referéndum
El referéndum es un esquema de votación simple, inclusivo y basado en la participación. Cada referéndum tiene una propuesta relacionada, que utiliza la forma de llamada a funciones de privilegios de runtime ###, incluyendo la llamada set_code más poderosa, que puede cambiar todo el código de runtime (.
El referéndum es un evento discreto con un período de votación fijo. Una vez que finaliza el período de votación y se cuentan los votos, si se aprueba, se llamarán a las funciones correspondientes. El referéndum siempre es binario; las opciones de votación solo pueden ser "a favor", "en contra" o abstenerse completamente.
En la gobernanza v1, el referéndum se puede iniciar de las siguientes maneras:
Todas las votaciones tienen un período de demora de ejecución correspondiente. Este es el período de tiempo entre el final de la votación y la implementación real de la propuesta.
En Gov2, cualquier persona puede iniciar un referéndum en cualquier momento, sin límite de次数. Gov2 introduce los conceptos de Origins) y Tracks( para ayudar en el proceso y manejo del protocolo de referéndum.
Origin puede considerarse como un descriptor del nivel de privilegio dado. El proponente necesita seleccionar el Origin adecuado para la solicitud según los requisitos de la propuesta.
Cada Origin está asociado a una categoría de referéndum, y cada categoría tiene una Track. La Track describe el ciclo de vida de la propuesta y es independiente de otras categorías. Diferentes Tracks independientes permiten a la red ajustar la dinámica del referéndum según el nivel de privilegio implícito.
Por ejemplo, el impacto de la actualización de Runtime en el ecosistema es diferente de la aprobación de las propinas del tesoro, por lo que se necesitan diferentes Orígenes, donde la tasa de votación, la tasa de aprobación, el depósito y el período de ejecución más corto se determinarán de antemano.
) propuesta de referéndum
Referéndum público
Cualquiera puede proponer un referéndum depositando la cantidad mínima de tokens durante un período determinado. Si alguien está de acuerdo, puede depositar la misma cantidad de tokens para mostrar su apoyo.
Esto se llama "endorso". La propuesta que obtenga el mayor soporte de tokens vinculados será seleccionada para el próximo ciclo de votación. Tenga en cuenta que esto puede diferir de la cantidad absoluta de endosos; por ejemplo, tres cuentas que vinculan 20 DOT cada una "superarán" a diez cuentas que vinculan 1 DOT cada una.
Una vez que se presente la propuesta ( para votación ), el token vinculado será liberado.
Para la gobernanza v1, puede haber hasta 100 propuestas públicas en la cola de propuestas.
En Gov2, una vez que se crea el referéndum, la comunidad puede votar de inmediato. Sin embargo, el referéndum no está en un estado que permita finalizar, contar los votos, obtener aprobación y ejecutar finalmente. Por el contrario, el referéndum debe cumplir ciertos criterios para entrar en el estado de "decidiendo ###Deciding(". Hasta entonces, permanece en estado pendiente.
Los estándares para entrar en estado Decided son los siguientes:
Pasó por un período de importación, es decir, el tiempo que debe transcurrir antes de que se pueda comenzar a decidir. Esto ayuda a reducir la posibilidad de "decidir un ataque", es decir, que un atacante con un gran control sobre los derechos de voto pueda aprobar una propuesta inmediatamente después de la propuesta, sin dar a todos los votantes el tiempo suficiente para considerar y participar.
Debe haber espacio restante para tomar decisiones. Todos los Track tienen un límite en la cantidad de referendos que se pueden decidir simultáneamente. Los límites de Tracks más poderosos son más bajos. Por ejemplo, el límite del nivel Root Origin es 1, lo que significa que solo se puede decidir una propuesta de súper peligro a la vez.
Se debe pagar un depósito decidido. Crear una votación es muy barato, ya que el depósito solo incluye el valor necesario para el almacenamiento en cadena. Sin embargo, revisar y decidir sobre la votación conlleva el riesgo de agotar las posiciones limitadas en la cola de votaciones. Requerir un depósito más grande pero reembolsable ayuda a reducir el spam.
Referéndum del consejo )v1(
Aprobación unánime del consejo - Cuando todos los miembros del consejo están de acuerdo con una propuesta, se puede llevar a votación pública. Esta votación pública producirá una desviación de la tasa de voto negativo ), es decir, cuanto menor sea el número de votos a favor, menor será el número requerido para su aprobación (.
Aprobación por mayoría del consejo - Cuando solo una simple mayoría de los miembros del consejo esté de acuerdo, también se puede votar en el referéndum, pero será un sistema de mayoría, donde la parte que obtenga el 51% de los votos será la ganadora ).
Solo puede haber un referéndum válido a la vez, a menos que haya un referéndum de emergencia en curso.
Calendario de votación
En la gobernanza v1, se asumirá que hay al menos una propuesta en la cola, y se realizará una nueva votación cada 28 días. Las propuestas aprobadas por el consejo tienen una cola, y las propuestas presentadas por el público también tienen una cola. Se alternará la votación entre las propuestas mejor clasificadas de las dos colas.
Las propuestas más destacadas se determinan por la cantidad de participación vinculada detrás de ellas. Si la cola actual intenta crear un referéndum sin propuestas y la cola ( está vacía ), y hay propuestas en cola en otra cola, la propuesta más destacada de la otra cola entrará en el referéndum.
No se pueden votar múltiples referendos en el mismo período, salvo en el caso de referendos urgentes. Los referendos urgentes que ocurren al mismo tiempo que un referendo regular son la única situación en la que se puede votar sobre múltiples referendos simultáneamente.
Cuando la propuesta sea aprobada, la gobernanza v2 compartirá el mismo período de calificación de 28 días. Si no se aprueba al final de esta fase, la propuesta será automáticamente rechazada.
Votación de referéndum ( gobernanza v2)
En la gobernanza v2, si una propuesta cumple con los requisitos de tasa de aprobación y tasa de apoyo, la propuesta será aprobada, es decir, se eliminará el sistema de sesgo adaptativo del grupo.
La tasa de aprobación ( se define como el peso del voto de aprobación ) después del ajuste de convicción ( en relación con el peso total del voto ), que incluye la participación de la aprobación y el rechazo (.
La tasa de apoyo ) Soporte ( es el número total de votos aprobados ) ignora el ajuste de convicción ( en comparación con el número total de votos que pueden realizarse en el sistema.
Debe cumplir con este estándar en el menor tiempo posible durante el período de confirmación. Diferentes rutas tienen diferentes períodos de confirmación y requisitos de aprobación y apoyo. Ahora se puede configurar a través de la cantidad de apoyo requerida y la aprobación general. Para las propuestas que utilizan fuentes de menor privilegio, es más razonable reducir la tasa de votación requerida a un número más realista más temprano en comparación con las propuestas que utilizan categorías de alto privilegio ) como Root(. Los cursos con un gran significado político pueden solicitar una mayor aprobación con anticipación para evitar controversias.
En Gov2, las propuestas que no sean aprobadas después de 28 días se considerarán rechazadas por defecto y se devolverá el Depósito de Decisión. Si la propuesta permanece aprobada antes de que termine el período de confirmación, se considerará aprobada y se planea ejecutar a partir de la fuente propuesta después del período de formulación. El período de formulación se designa cuando se propone una votación general, pero también está sujeto a un mínimo basado en el camino. Los Tracks más poderosos impondrán un período de ejecución más largo para garantizar que la red tenga suficiente tiempo para prepararse para los cambios que la propuesta pueda traer.
Bloqueo voluntario
Polkadot utiliza el concepto de "bloqueo voluntario", que permite a los titulares de tokens aumentar su poder de voto al declarar cuánto tiempo están dispuestos a bloquear sus tokens. Por lo tanto, el número de votos de cada titular de tokens se calculará utilizando la siguiente fórmula:
Número de votos = token * multiplicador de convicción
El número de períodos de bloqueo se duplica en cada ronda, el multiplicador de convicción aumentará el multiplicador de votos en uno.
Multiplicador de votos de período de bloqueo 00.111224384165326
El número máximo de veces que se puede "duplicar" el período de bloqueo se establece en 6), con un total de 32 períodos de bloqueo (, un período de bloqueo equivale a 28 días. Solo se permite duplicar, por ejemplo, no se puede bloquear 24 ciclos y hacer que la convicción aumente 5.5.
Una vez que los tokens están bloqueados, aún se pueden usar para votar y hacer staking; solo se prohíbe transferir estos tokens a otra cuenta.
Los votos siempre se "calculan" al mismo tiempo, es decir, al final del período de votación. Esto no se ve afectado por el período de bloqueo del token.
Sesgo adaptativo del grupo
La desviación adaptativa de grupos se ha utilizado durante más tiempo en la gobernanza v2 y ha sido reemplazada por el sistema de Aprobación/S apoyo.
) Consejo
En la gobernanza v1, los interesados pasivos en Polkadot son representados por un organismo de gestión llamado "Consejo". El Consejo es una entidad en la cadena, compuesta por múltiples participantes, cada uno de los cuales representa una cuenta en la cadena. En Polkadot, el Consejo actualmente está compuesto por miembros.
Además de controlar el tesoro nacional, el consejo es principalmente responsable de tres tareas de gobernanza:
En la gobernanza v2, se necesitan estrategias alternativas para reemplazar las funciones del consejo que anteriormente actuaba como una entidad de delegación de votantes, para compensar el hecho de que muchas personas eligen no participar en la gobernanza diaria. Gov2 se basa en la función de delegación de votación de v1, donde los votantes pueden elegir delegar su derecho de voto a otro votante dentro del sistema. Esto se logra a través de una mejora llamada delegación de múltiples roles, donde los votantes pueden designar diferentes representantes para cada categoría de referéndum en el sistema. Por lo tanto, los votantes pueden delegar a una entidad para gestionar una categoría de referéndum de menor impacto, mientras eligen a otro representante diferente para gestionar otra categoría con consecuencias más significativas, y aún así conservar el derecho completo de voto sobre cualquier categoría restante.
( Cancelar el referéndum
En la gobernanza v1, se puede cancelar una propuesta si el comité técnico está de acuerdo unánimemente en cancelarla, o si la fuente Root ) activa esta función, como sudo (. El depósito de la propuesta cancelada será destruido.
Además, una mayoría de dos tercios del consejo puede anular el referéndum. Si se descubren problemas en la propuesta del referéndum más tarde ), como errores en el código de ejecución que se implementará en la propuesta ###, esto puede considerarse como último recurso.
Si la controversia cancelada es lo suficientemente grande como para que el consejo no pueda obtener una mayoría de dos tercios, entonces será decidido conjuntamente por los interesados el destino de la propuesta.
En la gobernanza v2, hay una operación especial llamada Cancelation### que se utiliza para intervenir en propuestas que ya han sido votadas. Esta operación rechazará inmediatamente el referéndum en curso, sin importar su estado. También hay una disposición que asegura que si la propuesta es maliciosa o spam, el depósito del proponente será confiscado.
La cancelación es en sí misma una operación de gobernanza que debe ejecutarse mediante votación en la red. La revocación viene acompañada de su propio Origen y Seguimiento, tiene un período de importación muy corto y una curva de tasa de aprobación / tasa de apoyo, que desciende un poco más rápido a través del umbral, ya que se invoca solo en situaciones urgentes.
( Comité Técnico
En la gobernanza v1, el comité técnico )TC( es uno de los tres órganos de gobernanza de Kusama, los otros dos son el consejo y el referéndum ). El TC está compuesto por equipos que han implementado o definido el runtime de Polkadot o el Host de Polkadot. A través de una votación por mayoría simple del consejo, se pueden añadir o eliminar equipos en el TC.
El objetivo de TC es prevenir votaciones maliciosas, implementar correcciones de errores, revertir actualizaciones de runtime erróneas o agregar nuevas funciones que hayan sido probadas en la práctica. TC tiene el derecho de usar el pallet de Democracia para acelerar propuestas, y es el único que puede