- Tema
75k Popularidad
29k Popularidad
9k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
12k Popularidad
2k Popularidad
- Anclado
75k Popularidad
29k Popularidad
9k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
12k Popularidad
2k Popularidad
Gobernanza de Polkadot V2: Un mecanismo de decisión descentralizado más eficiente y flexible
Gobernanza V2
Polkadot utiliza un ingenioso mecanismo de gobernanza que le permite evolucionar de manera elegante 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 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) se compone de tres componentes principales:
El sistema v1 funcionó bien durante los primeros años de operación, ayudando a garantizar el uso adecuado de los fondos del tesoro y las actualizaciones y reparaciones oportunas. Sin embargo, a medida que el sistema maduraba, era necesario evolucionar para mejorar las deficiencias y mantenerse al día con los avances. Por ejemplo, en v1, todos los pesos de los referendos eran iguales, solo se podía votar en un referendo 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 muchas propuestas.
Por lo tanto, "Gobernanza v2" ( Gov2) ha surgido. Gov2 cambia la forma en que se toman las decisiones diarias, ampliando y agilizando el alcance de la influencia de los referendos, lo que aumenta significativamente la cantidad de decisiones colectivas que el sistema puede tomar.
Gov2, tras su lanzamiento en Kusama, propondrá su despliegue en Polkadot. Actualmente, Gov2 ya está en la red Kusama.
El siguiente contenido presentará los principios de gobernanza fundamentales de la red Polkadot. Comprender el origen de v1 ayudará a entender mejor la dirección de la segunda iteración. Estas diferencias y distinciones se destacarán en los diferentes subtemas.
Es importante tener en cuenta que, en esta etapa, la gobernanza es un protocolo en constante evolución. A medida que la actualización v2 ingresa a la red, también se está elaborando el plan para la v2.5.
Supuesto
En resumen, la red reúne una variedad de mecanismos novedosos, incluidos los funciones de transición de estado amorfo definidas por WebAssembly y almacenadas en la cadena, así como varios mecanismos de votación en la cadena, como el referéndum con umbrales de mayoría absoluta adaptativa y mecanismos de votación de aprobación por lotes.
Todos los cambios al protocolo deben ser acordados a través de un referendum ponderado por derechos.
Mecanismo
En v1, los titulares de tokens activos y el consejo gestionan conjuntamente las decisiones de 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 nacional, tomando como peso el monto de las apuestas y el valor de la creencia para tomar decisiones.
v2 tiene varios cambios. La nueva modalidad de gobernanza refleja su característica de descentralización de la siguiente manera:
En v1, el consejo actúa como representante de los poseedores de tokens pasivos, guardián de la tesorería y promotor legislativo, pero generalmente se considera una entidad centralizada. Para avanzar hacia una mayor descentralización, v2 propone devolver las responsabilidades del consejo a la comunidad.
Referéndum
El referéndum es una propuesta de votación simple, inclusiva y basada en la participación. Cada referéndum tiene una propuesta específica, que utiliza la forma de llamada a funciones de privilegio de runtime.
El referéndum es un evento discreto con un periodo de votación fijo. Una vez que termina el periodo de votación y se cuentan los votos, se llamará a la función correspondiente si se aprueba. El referéndum siempre es binario, las opciones solo pueden ser "a favor", "en contra" o abstenerse por completo.
En v1, la votación se puede iniciar de las siguientes maneras:
Todas las votaciones tienen un período de retraso en su ejecución. Este es el tiempo desde que finaliza la votación hasta que la propuesta se ejecuta realmente ( si es aprobada ).
Si el referéndum se cierra y se completan los conteos, se considera que ha sido completado. Si la propuesta es aprobada, se programará su ejecución. Si está en votación, se considera que no ha sido completado.
Las propuestas presentadas por el público o el consejo tienen un período de retraso de ejecución fijo de 28 días. Las propuestas presentadas como parte de la ejecución de referendos previos pueden tener un período de retraso establecido según sea necesario. El tratamiento de propuestas urgentes requiere un "seguimiento rápido" de problemas significativos, con un tiempo de ejecución más corto.
En v2, cualquier persona puede iniciar una votación en cualquier momento y sin límite de veces. v2 introduce los conceptos de Origins( y Tracks) para ayudar en el proceso y manejo de las votaciones.
Origin puede considerarse un descriptor rico para un nivel de privilegio dado. El proponente debe seleccionar el Origin adecuado según los requisitos de la propuesta.
Cada Origin está relacionado con una categoría de referéndum, y cada categoría está relacionada con un Track. El Track describe el ciclo de vida de la propuesta, independientemente 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 la propina del Tesoro, por lo que se requieren diferentes Orígenes, donde diferentes tasas de votación, tasas de aprobación, depósitos y el ciclo de ejecución más corto se determinarán de antemano.
( propuesta de referéndum
Referéndum público
Cualquier persona 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 expresar su apoyo, lo que se conoce como "aval". La propuesta que reciba el mayor apoyo en tokens vinculados será seleccionada para el referéndum del siguiente ciclo de votación.
Una vez que se presente la propuesta ), se llevará a cabo la votación ###, y el token vinculado será liberado.
En la versión 1, la cola de propuestas puede tener un máximo de 100 propuestas públicas.
En v2, después de crear un referéndum, la comunidad puede votar de inmediato. Sin embargo, el referéndum no se encuentra en un estado en el que se pueda finalizar o contar los votos, aprobar y ejecutar. El referéndum debe cumplir ciertos criterios para entrar en el estado de "decidiendo (Deciding)". Antes de eso, sigue siendo un estado pendiente.
Los estándares para entrar en estado Decided son los siguientes:
Referéndum del Consejo (v1)
Aprobación unánime del consejo - Cuando todos los miembros del consejo estén de acuerdo, la propuesta se puede someter a referéndum. Este referéndum generará una desviación en la tasa de votos negativos.
La mayoría del consejo aprueba - Cuando solo hay una mayoría simple de acuerdo, también se puede votar, pero se adopta el sistema de votación por mayoría.
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 v1, se supone que hay al menos una propuesta en la cola, y se realiza una nueva votación pública 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. Las votaciones se alternan entre las propuestas en la parte superior de ambas colas.
El ranking se determina por la cantidad de participación vinculada. Si la cola actual intenta crear un referéndum sin propuestas, la cola de referéndum ( está vacía ), y otra cola tiene propuestas en espera, la propuesta que esté más adelante en la otra cola entrará en el referéndum.
No se puede votar simultáneamente en múltiples referendos, a excepción de los 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 en múltiples referendos.
En v2, cuando la propuesta es aprobada, se comparte un período de calificación de 28 días. Si no se aprueba al final de esta etapa, se rechaza automáticamente.
Votación de referéndum (v2)
En v2, si la propuesta cumple con los requisitos de tasa de aprobación y tasa de apoyo, se aprueba, eliminando el sistema de sesgo adaptativo de grupos.
La tasa de aprobación se define como la proporción del peso de voto aprobado ( ajustado por la convicción ) sobre el peso total del voto.
La tasa de apoyo es la comparación del total de votos aprobatorios ( ignorando la convicción ) con el posible total de votos 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. Ahora se puede configurar a través de la cantidad de apoyo requerida y la aprobación general. Para las propuestas de fuentes de bajo privilegio, es más razonable reducir la tasa de votación requerida a un número real más temprano. Las que tienen un gran significado político pueden solicitar una aprobación más alta lo antes posible para evitar controversias.
En v2, las propuestas que no sean aprobadas después de 28 días se considerarán rechazadas por defecto, y se reembolsará el Depósito de Decisión. Si la propuesta se mantiene aprobada antes del final del período de confirmación, se considerará aprobada y se planificará su ejecución a partir de la fuente de propuesta después del período de elaboración. El período de elaboración se especifica al proponer, pero está sujeto a límites mínimos basados en la pista. Pistas más robustas imponen un período de ejecución más largo, asegurando que la red tenga tiempo suficiente para prepararse para los cambios.
Bloqueo voluntario
Polkadot utiliza el concepto de "bloqueo voluntario", permitiendo a los titulares de tokens aumentar su poder de voto declarando su disposición a bloquear el token por un período de tiempo. El número de votos de cada titular 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 duplicará en cada ronda, y el multiplicador de convicción aumentará el multiplicador de votos en uno.
El número máximo de períodos de bloqueo es de 6 veces (, con un total de 32 períodos de bloqueo ), un período de bloqueo equivale a 28 días. Solo se permite duplicar, si no se pueden bloquear 24 períodos y aumentar la convicción en 5.5.
Se puede seguir utilizando para votar y hacer staking después de estar bloqueado, solo se prohíbe la transferencia a otra cuenta.
Los votos siempre se "calculan" al final del período de votación, sin verse afectados por el período de bloqueo.
Sesgo adaptativo del grupo
Se utiliza durante más tiempo en v2 y ha sido reemplazado por el sistema de Aprobación/Soporte.
Consejo
En v1, los interesados pasivos en Polkadot están representados por el "Consejo". El Consejo es una entidad en la cadena, compuesta por múltiples participantes, cada uno representando una cuenta en la cadena. Actualmente, el Consejo en Polkadot está compuesto por miembros.
Además de controlar el tesoro nacional, el consejo se encarga principalmente de tres tareas de gobernanza:
En v2, se necesitan estrategias de sustitución para reemplazar las responsabilidades del consejo de administración que anteriormente actuaba como la institución de delegación de votantes. v2 se basa en la función de delegación de votos de v1, donde los votantes pueden delegar su derecho a votar a otros votantes dentro del sistema. A través de la delegación de múltiples roles, los votantes pueden designar diferentes representantes para cada tipo de referéndum en el sistema. Por ejemplo, se puede delegar a una entidad la gestión de categorías de referéndum de bajo impacto, elegir a otro representante para gestionar categorías de mayor impacto y conservar el derecho completo de voto en las demás categorías.
Cancelación del referéndum
En v1, si el comité técnico está de acuerdo por unanimidad o si se activa por una fuente Root, 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 descubren problemas en la propuesta del referéndum más tarde, esto puede considerarse como un último recurso.
Si la controversia es tan grande que el consejo no puede obtener una mayoría de dos tercios, entonces los interesados decidirán conjuntamente el destino de la propuesta.
En v2, hay una operación especial llamada Cancelation( que se utiliza para intervenir en propuestas ya votadas. Esta operación rechazará inmediatamente el referéndum en curso, independientemente de su estado. También se establece que si la propuesta es maliciosa o es spam, se asegurará de que el depósito del proponente sea confiscado.
La cancelación en sí misma es una operación de gobernanza, debe ser ejecutada mediante votación en la red. La revocación tiene su propio origen y seguimiento, con un período de importación muy corto y una curva de tasa de aprobación/soporte, que desciende rápidamente a medida que se reduce el umbral, ya que solo se invoca en situaciones urgentes.
Comité Técnico
En v1, el Comité Técnico )TC( se introduce como una de las tres instituciones de gobernanza de Kusama. El TC está compuesto por equipos que han implementado con éxito o definido el runtime de Polkadot o el Host. A través de la votación por mayoría simple del consejo, se pueden agregar 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. TC tiene el derecho de usar el pallet de Democracia para acelerar propuestas, siendo la única fuente que puede activar la función de aceleración. Podemos considerar a TC como la "única fuente" que no puede generar propuestas pero puede acelerar propuestas existentes.
La votación rápida es la única votación que puede llevarse a cabo simultáneamente con otra votación. Por lo tanto, a través de la votación rápida, se pueden llevar a cabo dos votaciones activas al mismo tiempo. Votar en una de ellas no impedirá votar en la otra.
En v2, se introduce un nuevo comité de sucesión "Polkadot Fellowship", que reemplaza al comité técnico. Servirá a las redes Polkadot y Kusama.
Beca Polkadot
Fellowship es una institución experta de autogobierno básico, cuyo objetivo principal es representar a las personas con conocimientos sobre la red Polkadot y la tecnología de protocolos. Fellowship clasifica a sus miembros a través de "niveles", que representan el grado de sabiduría de sus opiniones, la solidez de su base técnica y el grado en que se alinean con los intereses de Polkadot.
A diferencia del actual Technical Collective, está diseñado para ampliar el número de miembros ) puede albergar a miles de miembros ( y el umbral de entrada es mucho más bajo. Es muy fácil convertirse en miembro candidato, solo se necesita depositar un pequeño monto como garantía.
Los miembros de Fellowship pueden votar sobre cualquier propuesta de Fellowship, y las opiniones combinadas de los miembros ) se ponderan por niveles ( para formar las opiniones a considerar por Fellowship.
El mecanismo de votación de Fellowship es el mismo que el mecanismo de votación de los interesados en Polkadot para las propuestas de referéndum.
Sistema de niveles
Para evitar que unos pocos participantes obtengan un control efectivo sobre la red, el sistema se adhiere a tres principios principales:
La Fellowship nunca debe tener poder duro sobre la red: no puede cambiar parámetros, realizar reparaciones o mover activos. El único poder radica en la capacidad de acortar el cronograma de votación.
Fellowship otorga más peso a las opiniones de alto rango en la opinión general, pero no debería ser tan alto que las opiniones de unos pocos miembros de alto rango no puedan superar las opiniones unánimes de los miembros de bajo rango.