En su momento, el primer sistema de gobernanza descentralizada de Polkadot era muy interesante: una estructura de separación de poderes con un comité técnico para gestionar el calendario de actualizaciones, un "gobierno" ejecutivo elegido por aprobación para gestionar los parámetros, la gestión y las propuestas de gasto, y una votación común. sistema utilizado para todo lo demás, recompensando a los tenedores a largo plazo con una mayor influencia. Se basa libremente en la democracia parlamentaria y ha tenido un desempeño razonablemente bueno en sus primeros dos o tres años de funcionamiento, lo que ha ayudado a garantizar que los fondos fiscales se gasten de manera inteligente, que las actualizaciones se implementen rápidamente y que las correcciones críticas se administren de manera oportuna. Sin embargo, también tiene sus inconvenientes.
El ejecutivo electo (llamado Asamblea) está centralizado y generalmente no es anónimo. Esto expone tanto al acuerdo como a los parlamentarios individuales a cierto grado de riesgo, ya que pueden verse presionados a comportarse de cierta manera. Los comités técnicos, si bien poseen menos poder, enfrentan riesgos similares y una mayor centralización. En la sociedad actual, ya sea bien intencionada o maliciosa, la descentralización es cada vez más necesaria para la seguridad de todos los participantes.
Además, sólo existe un modelo de referendo de “todo o nada”: el que tiene mayor poder de todos los referendos. En parte por esta razón, sólo se puede celebrar un referéndum a la vez, y estas votaciones duran semanas por defecto. Los problemas resultantes, así como el ancho de banda limitado del parlamento, significan que el sistema es más propicio para una consideración en profundidad de un pequeño número de propuestas que para una consideración amplia de muchas propuestas. En lugar de aprovechar el poder del poder de la multitud, lo limita inadvertidamente en instituciones que se esfuerzan por gestionar el potencial de toma de decisiones.
La naturaleza de la delegación general significa que una cierta exclusividad está incorporada al sistema. Las barreras de entrada a marcos políticos eficaces son altas, lo que reduce la inclusión y la diversidad, y reduce la participación y la legitimidad.
Está claro que la primera versión de la gobernanza de Polkadot es algo que se repetirá con el tiempo. Ahora, me entusiasma detallar las propuestas de gobernanza de próxima generación que estamos introduciendo dentro del ecosistema de Polkadot.
#Presentamos Gov2
El sistema de gobernanza de próxima generación de Polkadot, conocido en desarrollo como Gov2, tiene como objetivo resolver los problemas del sistema actual. Primero, no cambia lo siguiente: no viola los principios de gobernanza originales de Polkadot, que es que un total del 50% del sistema debería poder controlar en última instancia el futuro del sistema si tienen suficiente fe en sus opiniones. . Asimismo, no se aleja del pionero Conviction Voting en Polkadot, que dio mayor peso a aquellos dispuestos a bloquear sus tokens en el sistema por más tiempo. Además, el Colectivo Técnico seguirá necesitando un Grupo Técnico, aunque diferente en importancia, tamaño, composición y mecanismos de membresía de los Comités Técnicos actuales.
La mayor diferencia es cómo gestiona los medios prácticos de la toma de decisiones del día a día, dando más alcance y agilidad a las consecuencias del referéndum, aumentando significativamente el número de decisiones colectivas que el sistema puede tomar. Echemos un vistazo más profundo a cómo funciona.
Bajar el umbral
En muchos sentidos, Gov2 es en realidad más simple que los sistemas de gobernanza actuales. No existen otras instituciones que sirvan como “primera categoría de ciudadanos” en la gobernanza, como los parlamentos y los comités técnicos. No existe un calendario rotativo de propuestas. No hay cola de propuestas públicas. En cambio, tenemos sólo un mecanismo de toma de decisiones de tipo 1: el referéndum. La principal diferencia con Gov2 es que puede haber muchos mecanismos de este tipo, tal vez incluso miles, que se produzcan simultáneamente.
En Gov2, cualquiera puede iniciar un referéndum en cualquier momento y puede hacerlo de forma continua. Cualquiera también puede votar en estos referendos. No existe un límite claro al hecho de que un referéndum pueda votarse en cualquier momento.
Pero esto puede dar lugar a que se voten tantos asuntos que una persona promedio tal vez no pueda evaluarlos todos en un período de tiempo razonable. Esto puede reducir la inclusión y la seguridad. Entonces, para que estos posibles elementos de votación sean factibles para la gente común, estamos introduciendo algunas características nuevas e interesantes en el proceso del referéndum.
Orígenes y órbitas
Todos los referendos se basan en propuestas, que en realidad son otra forma de decir “acciones” en Polkadot. Esto es lo mismo que se describe y ejecuta cuando realiza una transacción y la incluye en un bloque. Polkadot puede realizar una amplia variedad de operaciones, pero algunas de las que quizás ya conozca son la operación de "transferencia", que puede mover activos entre cuentas, y la operación de "participación", que bloquea cuentas. Hay muchas otras operaciones. Lo que hace especial a esta característica de gobernanza no son las propuestas/acciones, sino el Origen con el que se ejecutan.
Puedes pensar en Origin como un rico descriptor de niveles de privilegios. Cuando se realiza una operación, se pasa el Origen y la lógica de la operación generalmente verifica si es lo que debería ser. Cuando se ejecuta una transacción normal, el parámetro Origen se establece en una variante llamada Firmado. Esto significa que una cuenta específica en el sistema (generalmente autorizada al firmar una transacción) permite que se realice la operación y se ejecuta con este privilegio, lo que implica además que, por ejemplo, se pueden gastar fondos que solo pueden ser controlados por esta cuenta.
Las operaciones a nivel de gobernanza permiten que las operaciones se ejecuten como otros orígenes más privilegiados. El más privilegiado entre ellos es Root Origin, que tiene poderes ilimitados. Este es el Origen desde el cual se enviarán todas las propuestas de referéndum aprobadas. En Gov2 tenemos muchos Origins diferentes, todos disfrutando de ciertas ventajas, pero muchos de ellos son mucho más débiles y más especializados que Root.
En Gov2, permitimos a los proponentes especificar el Origen en el que quieren que se ejecuten sus propuestas. Cada Origen admitido está asociado con una categoría de referéndum, y la mayoría de estas categorías corresponderán exactamente a un Origen, pero puede haber algunas categorías que estén compuestas por múltiples Orígenes. Cada categoría tiene su propio Track, que es básicamente un conducto por donde pasan las propuestas, y es completamente independiente de los Tracks de las otras categorías.
Tener vías separadas nos permite adaptar la dinámica de un referéndum en función de su nivel implícito de privilegio. Un referéndum que promulgara sus propuestas del origen más poderoso (léase: ¡peligroso!) tendría protecciones más estrictas, umbrales más altos y períodos de consideración más largos. Root Origin tiene los umbrales y salvaguardas más altos. Los orígenes que transfieren relativamente poco poder (como Tip Origin, que puede pagar hasta 10 DOT del tesoro) tienen períodos de consideración más cortos y umbrales de aprobación más bajos.
puesta en marcha
Cuando se creó el referéndum por primera vez, cualquier miembro de la comunidad podía votar inmediatamente. Pero aún no ha llegado a un estado en el que sus votos puedan cerrarse o contarse, aprobarse y ejecutarse posteriormente. En cambio, los referendos deben cumplir una serie de condiciones antes de ser llamados un estado de "decisión", y hasta que entran en este estado, permanecen indecisos.
Es necesario que se cumplan tres condiciones: en primer lugar, todos los referendos tienen un período previo. Este es el tiempo que debe pasar después de la propuesta. Esto proporciona tiempo para un período de notificación inicial para que se puedan enviar los votos, evitando la posibilidad de una "toma de decisión" en la que un atacante que controle una gran cantidad de derechos de voto podría intentar aprobar una propuesta poco después de su presentación, rechazando en bloque votar La gente tiene tiempo para pensar y votar.
En segundo lugar, debe haber espacio para la toma de decisiones. Todas las vías tienen sus propios límites en cuanto al número de referendos que pueden decidirse simultáneamente. Cuanto más poderoso (¡por ejemplo, más peligroso!) pueda ejecutar el Origen en la pista, menor será este límite. El nivel raíz Origin está limitado a 1, lo que significa que solo se puede decidir una propuesta súper peligrosa a la vez. Por el contrario, la vía de inflexión bastante débil es mucho más restrictiva, ya que cualquier daño que pueda causar un exceso de decisiones es mínimo y tener muchas llamadas a nivel raíz es más útil. Cuando haya espacio disponible, los referendos (de otro modo elegibles) para las categorías con las aprobaciones más favorables se elevarán al estado de decisión.
Finalmente se deberá abonar el depósito de decisión. Crear un referéndum es barato y solo requiere un depósito asociado con el almacenamiento en cadena necesario para rastrearlo. Sin embargo, permitir que se decidan referendos conlleva mayores riesgos y utiliza un espacio limitado porque limitamos el número de referendos que se pueden decidir en cada vía simultáneamente. Por lo tanto, se debe realizar un depósito mayor (aunque reembolsable) para mitigar el riesgo de enviar spam o inflar el sistema.
Decidir y confirmar propuestas.
Una vez que un referéndum alcanza el estado de toma de decisiones, pasa a ser elegible para su aprobación. Esta calificación solo es válida por un tiempo limitado (28 días en Polkadot), después del cual, si no se aprueba, se deniega de forma predeterminada. Para ser aprobado, debe cumplir dos criterios (en este caso, lo llamamos "aprobado") y debe continuar cumpliendo esos criterios durante un período mínimo de tiempo durante el período de confirmación. Diferentes órbitas tienen diferentes duraciones de períodos de confirmación, y las órbitas más potentes tardan más en confirmarse. Esta es una defensa adicional para evitar que los votantes de las ballenas "disparen" el referéndum emitiendo un voto lo suficientemente grande.
Dos criterios de aprobación se relacionan con la aprobación y el apoyo. El sesgo adaptativo del quórum de referendos pasados ya no existe. Ahora tenemos un sistema más flexible que puede adaptar estos requisitos a un nivel más granular. La aprobación se define como la proporción del peso del voto de aprobación (es decir, ajustado por creencia) del peso total del voto (peso del voto para aprobación y rechazo). El apoyo es el número total de votos de aprobación (es decir, ignorando los ajustes a las creencias) en comparación con el número total de votos que podrían haberse generado en el sistema.
Cada categoría de referéndum tiene diferentes requisitos para estos valores. Sin embargo, lo más interesante es que estos requisitos pueden reducirse gradualmente según un calendario bien definido. Esto significa que a medida que avanza la votación durante los 28 días, podemos configurar las cosas para que el apoyo y la aprobación general necesarios para que se apruebe una propuesta sea menor. En términos generales, siempre comenzarán y terminarán de la misma manera, comenzando con el umbral más alto y terminando con el umbral más bajo que aún se adhiere al principio general: se requiere al menos un 50% de aprobación.
Lo que sucede en el medio determina qué tan fácil es obtener la aprobación antes del plazo de 28 días. Para las propuestas que utilizan orígenes menos privilegiados (como la categoría Tip, que solo puede solicitar pagos de hasta 10 DOT al tesoro), sería más razonable reducir los votos requeridos antes. Las propuestas que utilizan categorías altamente privilegiadas, como Root, tendrán más probabilidades de recibir menos controversia desde el principio (y, por lo tanto, requerirán una mayor aprobación).
Después de la aprobación
Después de 28 días, las propuestas no aprobadas se consideran rechazadas por defecto. En este punto, se puede reembolsar el depósito de decisión. Por otro lado, si una propuesta logra ser aprobada y permanecer aprobada durante esos 28 días, entonces se considera aprobada y está programada para ser implementada por el Origen que la propone adecuadamente dentro de un cierto período de implementación después de su propuesta.
El período de implementación también se especifica cuando se hace la propuesta, pero depende del itinerario. Algunas de las vías más sólidas requerirán períodos de implementación más prolongados para garantizar que la red tenga tiempo suficiente para prepararse para cualquier cambio que pueda traer la propuesta.
#intervención
A veces sucede que una propuesta que ya está en la boleta (quizás ya aprobada) contiene problemas y quieres cancelarla. Un ejemplo sería una actualización de cadena que luego se descubre que contiene algún tipo de problema. Si bien esto no es muy común, tampoco es algo inaudito.
En Gov2, existe una operación especial llamada Intervención de cancelación. Una acción así rechazaría inmediatamente un referéndum en curso, independientemente de su estatus. En realidad, se presenta en dos formas, una de las cuales sólo realiza operaciones básicas y la otra que también reduce el monto del depósito que el proponente paga para el referéndum.
La cancelación en sí es una operación de gobernanza que debe ser votada por la red para ser ejecutada. Esto plantea posibles problemas con los plazos, en el sentido de que, para ser útil, una propuesta para lograr que una propuesta de cancelación se apruebe rápidamente debe generalmente aprobarse mucho más rápido que una propuesta objetivo probable. Como tal, Cancelación tiene su propio Origen y Seguimiento, con tiempos de arranque más bajos y una curva de aprobación/apoyo ligeramente más pronunciada para superar barreras.
Delegación flexible
En un mundo perfecto, donde todos tuvieran tiempo y habilidades ilimitados, cada propuesta sería investigada, discutida, considerada y votada cuidadosamente. Sin embargo, en un mundo perfecto, no vivimos. No todo el mundo tiene el tiempo o el deseo de investigar cada tema en profundidad. De esta comprensión surgió el Consejo, el gobierno original de Polkadot: un organismo designado por los votantes para compensar el hecho de que muchos de ellos no estaban dispuestos a participar en el gobierno diario. Sin embargo, con los consejos eliminados en Gov2, necesitamos un medio alternativo para garantizar que se escuchen las voces de los votantes "pasivos".
El sistema de gobernanza original tenía una característica llamada delegación de votación, que mantuvimos y mejoramos en Gov2. Para quienes no estén familiarizados, esto es similar a la premisa de la democracia líquida: puedes delegar tu voto a otro votante del sistema. Cuando sus representantes votan, no sólo son dueños de su voto, sino que también son dueños de su voto. Esto funciona en conjunto con la votación por convicción, lo que le permite bloquear sus tokens para aumentar el nivel de poder de voto que tiene su delegado cuando vota en su nombre. Por supuesto, los tokens involucrados nunca salen de su control y puede cambiar de representante o recuperar el control directo en cualquier momento.
En Gov2, sin embargo, esto se mejoró mediante una función especial llamada Delegación multifunción. Esto le permite especificar un representante diferente para cada categoría de referéndum en su sistema. Si no desea delegar en una categoría específica del referéndum, también puede conservar el control directo de esa categoría.
Esto significa que puede transferir un trabajo a una persona para cualquier propuesta en la que los contribuyentes del ecosistema reciban propinas, a otra entidad para propuestas con mayores desembolsos financieros y a otra entidad para propuestas puramente técnicas para actualizaciones y parametrización de la red, y conservar el control directo sobre cualquier otra decisión. !
Grupo académico y lista blanca
En cualquier sistema de gobernanza que funcione bien, la opinión de “expertos” informados juega un papel importante. La gobernanza experta conlleva sus propios defectos graves, por lo que no queremos que los “expertos” sean colocados en una posición de mando: esto introduce centralización, autoridad que no rinde cuentas y la base que, en última instancia, puede convertirse en el núcleo de la dominación. Ésta es la razón lógica por la que el comité técnico originalmente gobernado por Polkadot no tiene “poder de decisión”.
Su nombre es Polkadot Fellowship, que se llama "Academia" en Gov2. Los becarios desempeñan un papel en la red y no son responsables de la decisión final sobre la implementación de una propuesta. En cambio, apoyan el proceso de gobernanza mediante el seguimiento y la formulación de recomendaciones sobre aspectos técnicos, de cumplimiento, de riesgo y de otro tipo de las propuestas candidatas. La propuesta es opcional, no obligatoria, y puede ser adoptada o ignorada en el referéndum.
Los becarios no son anónimos y se les pide que revelen sus identidades para aumentar la transparencia y la rendición de cuentas. Este es uno de los roles del grupo académico en Gov2.
Gov2 también introduce un mecanismo llamado "lista blanca" que permite a un grupo de entidades del sistema obtener poderes especiales de gobernanza. Esto se puede utilizar para una variedad de propósitos, incluida la introducción de nuevos miembros al ecosistema, recompensar a los contribuyentes del ecosistema u otros usos similares. El mecanismo de lista blanca es altamente configurable y la comunidad puede decidir cómo utilizarlo.
en conclusión
En general, Gov2 es una mejora importante en la gobernanza de Polkadot, cuyo objetivo es resolver problemas en el sistema existente y mejorar la inclusión, la eficiencia y la transparencia de la gobernanza. Introduce una serie de características nuevas, como multipista, origen, lista blanca y grupo académico, así como un sistema de elección de delegación más flexible para satisfacer mejor las diferentes necesidades de gobernanza.
El objetivo de este sistema es fortalecer la gobernanza descentralizada, garantizar la seguridad de todos los participantes y mejorar la calidad y cantidad de la toma de decisiones públicas. Proporciona herramientas más sólidas para el desarrollo futuro del ecosistema de Polkadot para garantizar su éxito y sostenibilidad a largo plazo.
Autor: Gavin Wood
Ver originales
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.
Gov2: la próxima generación de gobernanza descentralizada para Polkadot
Introducción
En su momento, el primer sistema de gobernanza descentralizada de Polkadot era muy interesante: una estructura de separación de poderes con un comité técnico para gestionar el calendario de actualizaciones, un "gobierno" ejecutivo elegido por aprobación para gestionar los parámetros, la gestión y las propuestas de gasto, y una votación común. sistema utilizado para todo lo demás, recompensando a los tenedores a largo plazo con una mayor influencia. Se basa libremente en la democracia parlamentaria y ha tenido un desempeño razonablemente bueno en sus primeros dos o tres años de funcionamiento, lo que ha ayudado a garantizar que los fondos fiscales se gasten de manera inteligente, que las actualizaciones se implementen rápidamente y que las correcciones críticas se administren de manera oportuna. Sin embargo, también tiene sus inconvenientes.
El ejecutivo electo (llamado Asamblea) está centralizado y generalmente no es anónimo. Esto expone tanto al acuerdo como a los parlamentarios individuales a cierto grado de riesgo, ya que pueden verse presionados a comportarse de cierta manera. Los comités técnicos, si bien poseen menos poder, enfrentan riesgos similares y una mayor centralización. En la sociedad actual, ya sea bien intencionada o maliciosa, la descentralización es cada vez más necesaria para la seguridad de todos los participantes.
Además, sólo existe un modelo de referendo de “todo o nada”: el que tiene mayor poder de todos los referendos. En parte por esta razón, sólo se puede celebrar un referéndum a la vez, y estas votaciones duran semanas por defecto. Los problemas resultantes, así como el ancho de banda limitado del parlamento, significan que el sistema es más propicio para una consideración en profundidad de un pequeño número de propuestas que para una consideración amplia de muchas propuestas. En lugar de aprovechar el poder del poder de la multitud, lo limita inadvertidamente en instituciones que se esfuerzan por gestionar el potencial de toma de decisiones.
La naturaleza de la delegación general significa que una cierta exclusividad está incorporada al sistema. Las barreras de entrada a marcos políticos eficaces son altas, lo que reduce la inclusión y la diversidad, y reduce la participación y la legitimidad.
Está claro que la primera versión de la gobernanza de Polkadot es algo que se repetirá con el tiempo. Ahora, me entusiasma detallar las propuestas de gobernanza de próxima generación que estamos introduciendo dentro del ecosistema de Polkadot.
#Presentamos Gov2
El sistema de gobernanza de próxima generación de Polkadot, conocido en desarrollo como Gov2, tiene como objetivo resolver los problemas del sistema actual. Primero, no cambia lo siguiente: no viola los principios de gobernanza originales de Polkadot, que es que un total del 50% del sistema debería poder controlar en última instancia el futuro del sistema si tienen suficiente fe en sus opiniones. . Asimismo, no se aleja del pionero Conviction Voting en Polkadot, que dio mayor peso a aquellos dispuestos a bloquear sus tokens en el sistema por más tiempo. Además, el Colectivo Técnico seguirá necesitando un Grupo Técnico, aunque diferente en importancia, tamaño, composición y mecanismos de membresía de los Comités Técnicos actuales.
La mayor diferencia es cómo gestiona los medios prácticos de la toma de decisiones del día a día, dando más alcance y agilidad a las consecuencias del referéndum, aumentando significativamente el número de decisiones colectivas que el sistema puede tomar. Echemos un vistazo más profundo a cómo funciona.
Bajar el umbral
En muchos sentidos, Gov2 es en realidad más simple que los sistemas de gobernanza actuales. No existen otras instituciones que sirvan como “primera categoría de ciudadanos” en la gobernanza, como los parlamentos y los comités técnicos. No existe un calendario rotativo de propuestas. No hay cola de propuestas públicas. En cambio, tenemos sólo un mecanismo de toma de decisiones de tipo 1: el referéndum. La principal diferencia con Gov2 es que puede haber muchos mecanismos de este tipo, tal vez incluso miles, que se produzcan simultáneamente.
En Gov2, cualquiera puede iniciar un referéndum en cualquier momento y puede hacerlo de forma continua. Cualquiera también puede votar en estos referendos. No existe un límite claro al hecho de que un referéndum pueda votarse en cualquier momento.
Pero esto puede dar lugar a que se voten tantos asuntos que una persona promedio tal vez no pueda evaluarlos todos en un período de tiempo razonable. Esto puede reducir la inclusión y la seguridad. Entonces, para que estos posibles elementos de votación sean factibles para la gente común, estamos introduciendo algunas características nuevas e interesantes en el proceso del referéndum.
Orígenes y órbitas
Todos los referendos se basan en propuestas, que en realidad son otra forma de decir “acciones” en Polkadot. Esto es lo mismo que se describe y ejecuta cuando realiza una transacción y la incluye en un bloque. Polkadot puede realizar una amplia variedad de operaciones, pero algunas de las que quizás ya conozca son la operación de "transferencia", que puede mover activos entre cuentas, y la operación de "participación", que bloquea cuentas. Hay muchas otras operaciones. Lo que hace especial a esta característica de gobernanza no son las propuestas/acciones, sino el Origen con el que se ejecutan.
Puedes pensar en Origin como un rico descriptor de niveles de privilegios. Cuando se realiza una operación, se pasa el Origen y la lógica de la operación generalmente verifica si es lo que debería ser. Cuando se ejecuta una transacción normal, el parámetro Origen se establece en una variante llamada Firmado. Esto significa que una cuenta específica en el sistema (generalmente autorizada al firmar una transacción) permite que se realice la operación y se ejecuta con este privilegio, lo que implica además que, por ejemplo, se pueden gastar fondos que solo pueden ser controlados por esta cuenta.
Las operaciones a nivel de gobernanza permiten que las operaciones se ejecuten como otros orígenes más privilegiados. El más privilegiado entre ellos es Root Origin, que tiene poderes ilimitados. Este es el Origen desde el cual se enviarán todas las propuestas de referéndum aprobadas. En Gov2 tenemos muchos Origins diferentes, todos disfrutando de ciertas ventajas, pero muchos de ellos son mucho más débiles y más especializados que Root.
En Gov2, permitimos a los proponentes especificar el Origen en el que quieren que se ejecuten sus propuestas. Cada Origen admitido está asociado con una categoría de referéndum, y la mayoría de estas categorías corresponderán exactamente a un Origen, pero puede haber algunas categorías que estén compuestas por múltiples Orígenes. Cada categoría tiene su propio Track, que es básicamente un conducto por donde pasan las propuestas, y es completamente independiente de los Tracks de las otras categorías.
Tener vías separadas nos permite adaptar la dinámica de un referéndum en función de su nivel implícito de privilegio. Un referéndum que promulgara sus propuestas del origen más poderoso (léase: ¡peligroso!) tendría protecciones más estrictas, umbrales más altos y períodos de consideración más largos. Root Origin tiene los umbrales y salvaguardas más altos. Los orígenes que transfieren relativamente poco poder (como Tip Origin, que puede pagar hasta 10 DOT del tesoro) tienen períodos de consideración más cortos y umbrales de aprobación más bajos.
puesta en marcha
Cuando se creó el referéndum por primera vez, cualquier miembro de la comunidad podía votar inmediatamente. Pero aún no ha llegado a un estado en el que sus votos puedan cerrarse o contarse, aprobarse y ejecutarse posteriormente. En cambio, los referendos deben cumplir una serie de condiciones antes de ser llamados un estado de "decisión", y hasta que entran en este estado, permanecen indecisos.
Es necesario que se cumplan tres condiciones: en primer lugar, todos los referendos tienen un período previo. Este es el tiempo que debe pasar después de la propuesta. Esto proporciona tiempo para un período de notificación inicial para que se puedan enviar los votos, evitando la posibilidad de una "toma de decisión" en la que un atacante que controle una gran cantidad de derechos de voto podría intentar aprobar una propuesta poco después de su presentación, rechazando en bloque votar La gente tiene tiempo para pensar y votar.
En segundo lugar, debe haber espacio para la toma de decisiones. Todas las vías tienen sus propios límites en cuanto al número de referendos que pueden decidirse simultáneamente. Cuanto más poderoso (¡por ejemplo, más peligroso!) pueda ejecutar el Origen en la pista, menor será este límite. El nivel raíz Origin está limitado a 1, lo que significa que solo se puede decidir una propuesta súper peligrosa a la vez. Por el contrario, la vía de inflexión bastante débil es mucho más restrictiva, ya que cualquier daño que pueda causar un exceso de decisiones es mínimo y tener muchas llamadas a nivel raíz es más útil. Cuando haya espacio disponible, los referendos (de otro modo elegibles) para las categorías con las aprobaciones más favorables se elevarán al estado de decisión.
Finalmente se deberá abonar el depósito de decisión. Crear un referéndum es barato y solo requiere un depósito asociado con el almacenamiento en cadena necesario para rastrearlo. Sin embargo, permitir que se decidan referendos conlleva mayores riesgos y utiliza un espacio limitado porque limitamos el número de referendos que se pueden decidir en cada vía simultáneamente. Por lo tanto, se debe realizar un depósito mayor (aunque reembolsable) para mitigar el riesgo de enviar spam o inflar el sistema.
Decidir y confirmar propuestas.
Una vez que un referéndum alcanza el estado de toma de decisiones, pasa a ser elegible para su aprobación. Esta calificación solo es válida por un tiempo limitado (28 días en Polkadot), después del cual, si no se aprueba, se deniega de forma predeterminada. Para ser aprobado, debe cumplir dos criterios (en este caso, lo llamamos "aprobado") y debe continuar cumpliendo esos criterios durante un período mínimo de tiempo durante el período de confirmación. Diferentes órbitas tienen diferentes duraciones de períodos de confirmación, y las órbitas más potentes tardan más en confirmarse. Esta es una defensa adicional para evitar que los votantes de las ballenas "disparen" el referéndum emitiendo un voto lo suficientemente grande.
Dos criterios de aprobación se relacionan con la aprobación y el apoyo. El sesgo adaptativo del quórum de referendos pasados ya no existe. Ahora tenemos un sistema más flexible que puede adaptar estos requisitos a un nivel más granular. La aprobación se define como la proporción del peso del voto de aprobación (es decir, ajustado por creencia) del peso total del voto (peso del voto para aprobación y rechazo). El apoyo es el número total de votos de aprobación (es decir, ignorando los ajustes a las creencias) en comparación con el número total de votos que podrían haberse generado en el sistema.
Cada categoría de referéndum tiene diferentes requisitos para estos valores. Sin embargo, lo más interesante es que estos requisitos pueden reducirse gradualmente según un calendario bien definido. Esto significa que a medida que avanza la votación durante los 28 días, podemos configurar las cosas para que el apoyo y la aprobación general necesarios para que se apruebe una propuesta sea menor. En términos generales, siempre comenzarán y terminarán de la misma manera, comenzando con el umbral más alto y terminando con el umbral más bajo que aún se adhiere al principio general: se requiere al menos un 50% de aprobación.
Lo que sucede en el medio determina qué tan fácil es obtener la aprobación antes del plazo de 28 días. Para las propuestas que utilizan orígenes menos privilegiados (como la categoría Tip, que solo puede solicitar pagos de hasta 10 DOT al tesoro), sería más razonable reducir los votos requeridos antes. Las propuestas que utilizan categorías altamente privilegiadas, como Root, tendrán más probabilidades de recibir menos controversia desde el principio (y, por lo tanto, requerirán una mayor aprobación).
Después de la aprobación
Después de 28 días, las propuestas no aprobadas se consideran rechazadas por defecto. En este punto, se puede reembolsar el depósito de decisión. Por otro lado, si una propuesta logra ser aprobada y permanecer aprobada durante esos 28 días, entonces se considera aprobada y está programada para ser implementada por el Origen que la propone adecuadamente dentro de un cierto período de implementación después de su propuesta.
El período de implementación también se especifica cuando se hace la propuesta, pero depende del itinerario. Algunas de las vías más sólidas requerirán períodos de implementación más prolongados para garantizar que la red tenga tiempo suficiente para prepararse para cualquier cambio que pueda traer la propuesta.
#intervención
A veces sucede que una propuesta que ya está en la boleta (quizás ya aprobada) contiene problemas y quieres cancelarla. Un ejemplo sería una actualización de cadena que luego se descubre que contiene algún tipo de problema. Si bien esto no es muy común, tampoco es algo inaudito.
En Gov2, existe una operación especial llamada Intervención de cancelación. Una acción así rechazaría inmediatamente un referéndum en curso, independientemente de su estatus. En realidad, se presenta en dos formas, una de las cuales sólo realiza operaciones básicas y la otra que también reduce el monto del depósito que el proponente paga para el referéndum.
La cancelación en sí es una operación de gobernanza que debe ser votada por la red para ser ejecutada. Esto plantea posibles problemas con los plazos, en el sentido de que, para ser útil, una propuesta para lograr que una propuesta de cancelación se apruebe rápidamente debe generalmente aprobarse mucho más rápido que una propuesta objetivo probable. Como tal, Cancelación tiene su propio Origen y Seguimiento, con tiempos de arranque más bajos y una curva de aprobación/apoyo ligeramente más pronunciada para superar barreras.
Delegación flexible
En un mundo perfecto, donde todos tuvieran tiempo y habilidades ilimitados, cada propuesta sería investigada, discutida, considerada y votada cuidadosamente. Sin embargo, en un mundo perfecto, no vivimos. No todo el mundo tiene el tiempo o el deseo de investigar cada tema en profundidad. De esta comprensión surgió el Consejo, el gobierno original de Polkadot: un organismo designado por los votantes para compensar el hecho de que muchos de ellos no estaban dispuestos a participar en el gobierno diario. Sin embargo, con los consejos eliminados en Gov2, necesitamos un medio alternativo para garantizar que se escuchen las voces de los votantes "pasivos".
El sistema de gobernanza original tenía una característica llamada delegación de votación, que mantuvimos y mejoramos en Gov2. Para quienes no estén familiarizados, esto es similar a la premisa de la democracia líquida: puedes delegar tu voto a otro votante del sistema. Cuando sus representantes votan, no sólo son dueños de su voto, sino que también son dueños de su voto. Esto funciona en conjunto con la votación por convicción, lo que le permite bloquear sus tokens para aumentar el nivel de poder de voto que tiene su delegado cuando vota en su nombre. Por supuesto, los tokens involucrados nunca salen de su control y puede cambiar de representante o recuperar el control directo en cualquier momento.
En Gov2, sin embargo, esto se mejoró mediante una función especial llamada Delegación multifunción. Esto le permite especificar un representante diferente para cada categoría de referéndum en su sistema. Si no desea delegar en una categoría específica del referéndum, también puede conservar el control directo de esa categoría.
Esto significa que puede transferir un trabajo a una persona para cualquier propuesta en la que los contribuyentes del ecosistema reciban propinas, a otra entidad para propuestas con mayores desembolsos financieros y a otra entidad para propuestas puramente técnicas para actualizaciones y parametrización de la red, y conservar el control directo sobre cualquier otra decisión. !
Grupo académico y lista blanca
En cualquier sistema de gobernanza que funcione bien, la opinión de “expertos” informados juega un papel importante. La gobernanza experta conlleva sus propios defectos graves, por lo que no queremos que los “expertos” sean colocados en una posición de mando: esto introduce centralización, autoridad que no rinde cuentas y la base que, en última instancia, puede convertirse en el núcleo de la dominación. Ésta es la razón lógica por la que el comité técnico originalmente gobernado por Polkadot no tiene “poder de decisión”.
Su nombre es Polkadot Fellowship, que se llama "Academia" en Gov2. Los becarios desempeñan un papel en la red y no son responsables de la decisión final sobre la implementación de una propuesta. En cambio, apoyan el proceso de gobernanza mediante el seguimiento y la formulación de recomendaciones sobre aspectos técnicos, de cumplimiento, de riesgo y de otro tipo de las propuestas candidatas. La propuesta es opcional, no obligatoria, y puede ser adoptada o ignorada en el referéndum.
Los becarios no son anónimos y se les pide que revelen sus identidades para aumentar la transparencia y la rendición de cuentas. Este es uno de los roles del grupo académico en Gov2.
Gov2 también introduce un mecanismo llamado "lista blanca" que permite a un grupo de entidades del sistema obtener poderes especiales de gobernanza. Esto se puede utilizar para una variedad de propósitos, incluida la introducción de nuevos miembros al ecosistema, recompensar a los contribuyentes del ecosistema u otros usos similares. El mecanismo de lista blanca es altamente configurable y la comunidad puede decidir cómo utilizarlo.
en conclusión
En general, Gov2 es una mejora importante en la gobernanza de Polkadot, cuyo objetivo es resolver problemas en el sistema existente y mejorar la inclusión, la eficiencia y la transparencia de la gobernanza. Introduce una serie de características nuevas, como multipista, origen, lista blanca y grupo académico, así como un sistema de elección de delegación más flexible para satisfacer mejor las diferentes necesidades de gobernanza.
El objetivo de este sistema es fortalecer la gobernanza descentralizada, garantizar la seguridad de todos los participantes y mejorar la calidad y cantidad de la toma de decisiones públicas. Proporciona herramientas más sólidas para el desarrollo futuro del ecosistema de Polkadot para garantizar su éxito y sostenibilidad a largo plazo.
Autor: Gavin Wood