Gobernanza V2

Polkadot utiliza un mecanismo de gobernanza sofisticado que puede evolucionar elegantemente según las necesidades de los interesados. Su objetivo es garantizar que la mayoría de los derechos siempre puedan controlar la red.

El contenido de este artículo puede cambiar. 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 encargado de gestionar los parámetros, la gestión y las propuestas de gasto.
• Referéndum: Votación general sobre todos los demás asuntos, los interesados a largo plazo tienen mayor influencia.

Este sistema funcionó bien en las primeras etapas de operación, ayudando a un uso razonable de los fondos del tesoro y a actualizaciones y reparaciones oportunas. Sin embargo, a medida que el sistema madura, es necesario mejorar continuamente las deficiencias y seguir el progreso. Por ejemplo, en "gobernanza v1", todos los pesos de los referendos son iguales, solo se puede votar en un referendo a la vez, y el período de votación puede durar varias semanas. Esto hace que el sistema tienda a considerar cuidadosamente un número muy limitado de propuestas, en lugar de considerar ampliamente múltiples propuestas. Por lo tanto, nació "gobernanza v2".

"Gobernanza v2" o "Gov2" ha cambiado la forma en que se toman decisiones diarias, haciendo que los referendos tengan un impacto más amplio y ágil, aumentando significativamente la cantidad de decisiones colectivas que el sistema puede tomar.

Después de la revisión profesional final del código, Gov2 se lanzará en Kusama. Después de las pruebas en Kusama, se presentará una propuesta para su implementación en Polkadot.

A continuación, se presentarán los principios fundamentales de gobernanza de la red Polkadot. Comprender los orígenes de la gobernanza v1 ayudará a entender mejor la dirección de la segunda iteración. Estas diferencias y distinciones se resaltarán en los diversos subtemas.

Es importante tener en cuenta que, en esta etapa actual, la gobernanza sigue siendo un protocolo en constante desarrollo. Con la actualización de la gobernanza v2 ingresando a la red, también se están elaborando planes para la gobernanza v2.5.

premisa

En resumen, la red reúne una variedad de mecanismos novedosos, incluyendo funciones de transición de estado amorfo definidas en WebAssembly y almacenadas en la cadena, así como varios mecanismos de votación en cadena, como referendos con umbrales de mayoría absoluta adaptativos y mecanismos de votación 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 de actualización de la red. Ya sea que la propuesta sea presentada por los titulares de tokens públicos ( o por el consejo, debe someterse a un referéndum de todos los titulares, donde se toma la decisión con base en la cantidad de tokens en staking y el valor de confianza.

Hay varios cambios en la gobernanza v2. La nueva forma del modelo de gobernanza que refleja las características de descentralización es:

• Transferir todas las responsabilidades del consejo a los titulares de token mediante votación democrática
• Disolver el actual consejo directivo colectivo
• Permitir a los usuarios delegar sus derechos de voto a los miembros de la comunidad de más maneras.

El consejo en Gov1 cumplió los roles de representante de los poseedores de tokens pasivos, guardián del tesoro e iniciador de legislación, pero generalmente se considera una entidad centralizada. Para descentralizar aún más la red, Gov2 propone devolver las responsabilidades del consejo a la comunidad.

) referéndum

El referéndum es un esquema de votación simple, inclusivo y basado en el staking. Cada referéndum tiene una propuesta específica, que utiliza la forma de llamada de función de privilegios de runtime ###, incluyendo la llamada set_code más potente, que puede cambiar todo el código de runtime (.

Un referéndum es un evento discreto con un período de votación fijo. Al finalizar el período de votación y contabilizar los votos, si es aprobado se llamará a la función correspondiente. Un referéndum siempre es binario; la elección solo puede ser "a favor", "en contra" o completamente en blanco.

En la gobernanza v1, la votación puede iniciarse de las siguientes maneras:

• Propuestas presentadas públicamente
• Propuestas aprobadas por mayoría o unanimidad del consejo
• Propuesta presentada como parte de la ejecución de la votación 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 tiempo transcurrido desde el final de la votación hasta la ejecución real de la propuesta ), si es aprobada (.

Si el referéndum se cierra y se completan los conteos, se considera que se ha completado. Suponiendo que la propuesta sea aprobada, se programará para su ejecución. Si el referéndum está esperando resultados, es decir, está en votación, se considera que no se ha completado.

Si la propuesta es presentada por el público o por el consejo, habrá un período de retraso fijo de 28 días para su ejecución. Las propuestas presentadas como parte de una ejecución de referéndum anterior pueden establecer un período de retraso en la ejecución según sea necesario. El tratamiento de propuestas urgentes requiere "seguimiento rápido" de problemas significativos, lo que reduce el tiempo de ejecución.

En Gov2, cualquiera puede iniciar una votación en cualquier momento y puede iniciar múltiples votaciones. Gov2 introduce las nuevas funciones Origins) y Tracks( para ayudar en el proceso y manejo del protocolo de votación.

Origin puede considerarse como un descriptor rico del nivel de privilegio dado. El proponente ahora debe seleccionar el Origin adecuado para la solicitud según los requisitos de la propuesta.

Cada Origin está asociado con una categoría de referéndum, y cada categoría está asociada con un Track. El Track describe el ciclo de vida de la propuesta y es independiente de los Tracks de otras categorías. Tener diferentes Tracks independientes permite que la red ajuste la dinámica del referéndum según el nivel de privilegio implícito.

Por ejemplo, el impacto de la llamada set_code de la actualización de Runtime ) sobre el ecosistema es diferente de la aprobación de la propina del tesoro (, la llamada reportAwesome ), por lo que se necesitan diferentes Orígenes, donde diferentes tasas de votación, tasas de aprobación, depósitos y el período de ejecución más corto se determinarán previamente en el pallet.

( Propuesta de referéndum

Referéndum público

Cualquier persona puede proponer un referéndum depositando la cantidad mínima de tokens dentro de un número determinado de bloques ) durante un período de tiempo (. Si alguien está de acuerdo con la propuesta, puede depositar la misma cantidad de tokens para expresar su apoyo.

Esta operación se denomina "endorso". La propuesta que obtenga el mayor apoyo 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" la eficacia de diez cuentas que vinculan 1 DOT cada una.

Una vez que se presenta la propuesta ), se llevará a cabo la votación ###, y el token vinculado será liberado.

Para la gobernanza v1, puede haber hasta 100 propuestas públicas en la cola de propuestas.

En Gov2, cuando se crea un referéndum, la comunidad puede votar de inmediato. Sin embargo, el referéndum no está en un estado que permita finalizar o contar los votos, ser aprobado y ejecutado finalmente. Por el contrario, el referéndum debe cumplir con ciertos criterios para entrar en el estado de "decidiendo (Deciding)". Antes de entrar en este estado, sigue en estado pendiente.

Los criterios para entrar en estado Decided son los siguientes:

• Experimentó el período de introducción (lead-in period), es decir, el tiempo que debe transcurrir antes de que se pueda tomar una decisión. Esto ayuda a reducir la posibilidad de "decisión de emboscada", es decir, cuando un atacante con un gran control de derechos de voto puede aprobar una propuesta inmediatamente después de que se presenta, en lugar de permitir que todos los votantes tengan tiempo suficiente para considerar y participar.
• Debe haber un espacio restante decisivo. Todos los Track tienen un límite en la cantidad de referendos que se pueden decidir simultáneamente. Los Tracks con capacidades más poderosas tienen límites más bajos. Por ejemplo, el límite del nivel Root Origin es 1, es decir, solo se puede decidir 1 propuesta superpeligrosa a la vez.
• Debe pagar un depósito decisivo. Crear una votación cuesta muy poco, ya que el valor del depósito solo incluye el valor necesario para el almacenamiento en la cadena requerido para el seguimiento. Sin embargo, revisar y decidir sobre la votación conlleva el riesgo de agotar los espacios limitados en la cola de votación. Solicitar un depósito mayor, pero reembolsable, ayuda a reducir el spam.

Votación del Consejo (v1)

Aprobación unánime del consejo - Cuando todos los miembros del consejo están de acuerdo con una propuesta, puede llevarse a un referéndum. Este referéndum producirá una desviación negativa en la tasa de votación (, es decir, cuanto menor sea el número de votos de derechos, menor será el número requerido para su aprobación - consulte el sesgo adaptativo del grupo ).

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 sobre el referéndum, pero será un sistema de mayoría, ganando la parte que obtenga el 51% de los votos.

En cualquier momento dado, solo puede haber un referéndum válido, a menos que haya un referéndum de emergencia en curso.

Calendario de votación

En Governance v1, si hay al menos una propuesta en una de las colas, se llevará a cabo 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 que ocupen los primeros lugares en ambas colas.

Las propuestas mejor clasificadas se determinan por la cantidad de staking vinculada detrás de ellas. Si la cola actual intenta crear un referéndum sin propuestas ( la cola está vacía ), y hay propuestas en cola en otra cola, la propuesta mejor clasificada en esa cola pasará al referéndum.

No se pueden votar múltiples referendos al mismo tiempo, salvo en el caso de referendos de emergencia. Los referendos de emergencia que se llevan a cabo simultáneamente con referendos regulares ( o propuestas del consejo ) son la única situación en la que se pueden votar múltiples referendos al mismo tiempo.

Cuando la propuesta sea aprobada, la gobernanza v2 compartirá el mismo período de elegibilidad de 28 días. Si no se aprueba al final de esta etapa, la propuesta será automáticamente rechazada.

Referéndum votación ( gobernanza v2)

En la Gobernanza v2, si la propuesta cumple con los requisitos de tasa de aprobación y tasa de apoyo, la propuesta será aprobada, es decir, se ha eliminado el sistema de sesgo adaptativo del grupo.

La tasa de aprobación ( se define como el peso del voto de aprobación ) después de ajustar la convicción (, que representa la parte del peso total del voto ) que incluye las cuotas de aprobación y rechazo (.

La tasa de apoyo ) Soporte ( es el número total de votos aprobados ) ignorando el ajuste de convicción ( en comparación con el número total de votos que podrían 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 propuestas que utilizan fuentes de menor privilegio, es más razonable reducir el porcentaje de votos requerido a una cantidad más realista más temprano en comparación con propuestas que utilizan categorías de alto privilegio ) como Root(. Las que tienen un significado político más grande pueden solicitar una mayor aprobación más temprano para evitar controversias.

En Gov2, las propuestas no 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 logra mantenerse aprobada antes de que finalice 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 al proponer un voto universal, pero también está sujeto a un mínimo basado en la pista. Las pistas más robustas impondrán un período de ejecución más largo para garantizar que la red tenga tiempo suficiente para prepararse para cualquier cambio 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 declarando el tiempo que están dispuestos a bloquear sus tokens. Por lo tanto, el número de votos de cada titular de token 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 cada vez, y el multiplicador de convicción aumentará el multiplicador de votos en uno.

Número de período de bloqueo Multiplicador de votación 0 1 1 2 2 3 4 4 8 5 16 6 32 6

El número máximo de veces que se puede "duplicar" el período de bloqueo se establece en 6), por lo que hay 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 puedes bloquear 24 ciclos y hacer que tu convicción aumente 5.5.

Una vez que el token está bloqueado, aún puedes usarlo para votar y hacer staking; solo se te prohíbe transferir estos tokens a otra cuenta.

Los votos siempre se "calcularán" al mismo tiempo, es decir, al final del período de votación. Esto no se ve afectado por el período de bloqueo de tokens.

Sesgo adaptativo del grupo

La desviación adaptativa del grupo se utilizó durante más tiempo en Governance v2 y fue reemplazada por el sistema de Aprobación/S apoyo.

) Consejo

En la gobernanza v1, los interesados pasivos en Polkadot son representados por una entidad de gestión llamada "Consejo". El Consejo es una entidad en cadena, compuesta por múltiples participantes, cada uno de los cuales representa una cuenta en cadena. En Polkadot, el Consejo está compuesto actualmente por miembros.

Además de controlar el tesoro nacional, el consejo también es responsable principalmente de tres tareas de gobernanza:

• Votación inteligente de propuestas
• Cancelar referendos peligrosos o maliciosos
• Comité Técnico de Elecciones

En la gobernanza v2, se necesita una estrategia alternativa para reemplazar las funciones del consejo de administración como organismo 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 votos de v1, donde los votantes pueden elegir delegar su derecho de voto a otro votante en el sistema. Esto se logra mediante 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, por ejemplo, un votante puede delegar a una entidad para gestionar una categoría de referéndum de menor impacto, mientras elige a otro representante diferente para gestionar otra categoría con consecuencias más significativas, y aún así conservar el pleno derecho de voto sobre cualquier categoría restante.

( Cancelar el referéndum

En la gobernanza v1, si el comité técnico está de acuerdo en cancelar la propuesta, o si la fuente Root ) activa esta función como sudo(, se puede cancelar la propuesta. El depósito de la propuesta cancelada será destruido.

Además, una mayoría de dos tercios del consejo puede cancelar el referéndum. Si se detectan problemas en la propuesta del referéndum más tarde ), si hay errores en el código runtime que se ejecutará de la propuesta (, esto puede ser utilizado como último recurso.

si la controversia cancelada es lo suficientemente grande, para