Traducción del artículo ¨Gov2: Polkadot´s Next Generation of Decentralised Governance¨ de Gavin Wood. Por Lorena Fabris
El primer sistema de gobernanza descentralizada de Polkadot fue bastante interesante en su momento: una estructura tricameral (tres cámaras) con un comité tecnócrata que gestionaba los plazos de actualización, un “gobierno” ejecutivo elegido y votado para gestionar los parámetros, la administración y las propuestas de gasto, así como un sistema de votación general para todo lo demás que recompensaba a los stakeholders de largo plazo con una mayor influencia. Se basó en la democracia parlamentaria y ha funcionado razonablemente bien durante los dos o tres primeros años de operación, ayudando a garantizar un buen uso de los fondos del tesoro, manteniendo un ritmo rápido con el despliegue de las actualizaciones y gestionando el despliegue de las correcciones más críticas de manera oportuna. Sin embargo, tiene sus inconvenientes.
El ejecutivo elegido (conocido como Consejo) está centralizado y generalmente no es anónimo. Esto pone en cierto grado de riesgo tanto el protocolo como los consejeros individuales, que pueden verse presionados para actuar de una manera u otra. El Comité Técnico, aunque ejerce un poder sustancialmente menor, tiene una exposición similar y una mayor centralización. En un mundo en el que las autoridades atraviesan la sociedad (tanto benignas como malévolas), la descentralización es cada vez más necesaria tanto para la protección y seguridad de todos los participantes.
Además, sólo existe un único modelo de referéndum “todo o nada”: todos los referendos tienen el máximo poder. En parte debido a esto, sólo puede haber un referéndum votado a la vez y estas votaciones duran varias semanas por defecto. Esto, y los limitados recursos (bandwidth) del Consejo, significa que en general el sistema favorece la consideración profunda de muy pocas propuestas en lugar de la consideración amplia de muchas. En lugar de aprovechar el poder de la multitud, lo limita inadvertidamente en sus esfuerzos por gestionar el volumen de decisiones potenciales.
La naturaleza de coarse – grained delegation significa que el sistema tiene un grado de exclusividad incorporado. Las barreras de entrada dentro del marco político efectivo son altas, lo que reduce la inclusividad y la diversidad, perjudicando la participación y la legitimidad.
Siempre estuvo claro que la primera versión de la gobernanza de Polkadot era sólo eso: algo que había que iterar con el tiempo. Ahora, me complace poder describir en detalle nuestra propuesta para la próxima generación de gobernanza dentro del ecosistema de Polkadot.
Presentación de Gov2
El sistema de gobernanza de próxima generación de Polkadot, conocido mientras está en desarrollo como Gov2, pretende resolver los problemas del sistema actual. En primer lugar, lo que no cambia: no rompe con el principio original de gobernanza de Polkadot, que sostiene que el 50% del stake total en el sistema debería, si tiene suficiente fuerza de convicción en su opinión, ser capaz en última instancia de comandar el futuro del sistema. Del mismo modo, no se rompe con el Voto por Convicción (Conviction Voting), pionero en Polkadot, que da mayor peso a los que están dispuestos a bloquear sus tokens en el sistema durante más tiempo. Además, sigue siendo útil un colectivo tecnocrático, aunque es algo diferente en importancia, tamaño, composición y mecanismo de membresía que el actual Comité Técnico.
En lo que más difiere es en cómo gestiona los medios prácticos de la toma de decisiones del día a día, haciendo que las repercusiones de los referendos tengan un mayor alcance y sean más ágiles para aumentar drásticamente el número de decisiones colectivas que el sistema es capaz de tomar. Profundicemos un poco más en su funcionamiento.
Reducir las Barreras
En realidad, Gov2 es mucho más sencillo en muchos aspectos que la gobernanza actual. No hay órganos adicionales que actúen como “ciudadanos de primera clase” en la gobernanza, como el Consejo y el Comité Técnico. No hay un calendario alternativo de propuestas. No hay una cola de propuestas públicas. En su lugar, sólo tenemos un mecanismo de decisión de primera clase: el referéndum. La principal diferencia en Gov2 es que puede haber muchos -quizá incluso miles- que se celebren simultáneamente.
En Gov2, cualquiera puede iniciar un referéndum en cualquier momento, y puede hacerlo tantas veces como quiera. Cualquiera puede también votar en estos referendos. No hay límites explícitos al número de referendos que se pueden votar en cualquier momento.
Pero esto podría dar lugar a que se voten más cosas de las que una persona normal con una cantidad razonable de tiempo podría evaluar. Esto podría reducir tanto la inclusividad como la seguridad. Así que, para hacer que esta potencial plétora de cosas para votar sea manejable para los simples humanos, introducimos algunas características novedosas e interesantes en el proceso de referéndum.
Origins y Tracks
Todos los referendos se basan en una propolsal (propuesta), que en realidad es otra forma de decir “una operación” en Polkadot. Es el mismo tipo de cosa que se describe y ejecuta cuando haces una transacción y se incluye en un bloque. Hay todo tipo de operaciones que Polkadot puede hacer, pero un par de ellas con las que probablemente ya estés familiarizado son transfer (transferencia), que puede mover activos entre cuentas, y stake, que permite a una cuenta hacer staking. Hay muchas otras. Lo que hace especial esta funcionalidad de gobernanza no son estas propolsals/operaciones, sino el Origin (procedencia) con el que se ejecutan.
Puedes pensar en un Origin como una especie de descriptor rico para un nivel de privilegio. Se pasa cuando se ejecuta una operación, y la lógica de la operación normalmente comprobará que es lo que debe ser. Cuando se ejecuta una operación normal, el parámetro Origin se establece en una variante conocida como Signed (Firmado). Esto implica que una cuenta específica en el sistema autorizó (generalmente a través de la firma de la transacción) que la operación ocurriera, y se ejecuta con este privilegio, implicando además, por ejemplo, que los fondos controlados por esta cuenta y sólo esta cuenta pueden ser gastados.
Las cosas a nivel de gobernanza funcionan para permitir que las operaciones se ejecuten con otros Origins más privilegiados. El más privilegiado de todos ellos es el Root Origin (Procedencia Raíz), que es todopoderoso. Este es el Origin desde el que se enviaban las proposals de todos los referendos aprobados en el antiguo sistema de gobernanza. En Gov2, tenemos muchos Origins diferentes, todos disfrutando de algunos privilegios exóticos, pero con muchos siendo significativamente menos poderosos y más nicho que Root.
En Gov2, permitimos que el proponente especifique con qué Origin quiere que se ejecute su proposal. Cada Origin soportado está asociado a una única clase de referéndum (es decir, un tipo de referendos), y la mayoría de estas clases corresponderán exactamente a un origin, pero puede haber algunas que estén compuestas por múltiples Origins. Cada clase tiene su propio Track (vía), que es básicamente un conducto en el que la propuesta vive y avanza, y es completamente independiente de los tracks de otras clases.
Tener tracks independientes nos permite adaptar la dinámica de los referendos en función de su nivel de privilegio implícito. Los referendos que ejecutan sus proposals desde Origins más poderosos (¡léase peligrosos!) tendrán salvaguardas más estrictas, umbrales más altos y períodos de consideración más largos. El Root Origin tiene los umbrales y salvaguardas más altos. Los Origins que transmiten relativamente poco poder (por ejemplo, el Tip Origin, que puede gastar como máximo 10 DOT del tesoro), tienen en consecuencia períodos de consideración más cortos y umbrales de aprobación más bajos.
Puesta en Marcha
Cuando se crea inicialmente un referéndum, es inmediatamente votable por cualquier persona de la comunidad. Sin embargo, no se encuentra en un estado en el que pueda finalizar (end), o en el que se cuenten sus votos, ser aprobado y promulgado sumariamente. En cambio, los referendos deben cumplir una serie de criterios antes de pasar a un estado conocido como Deciding (para decidir). Hasta que se encuentren en este estado, seguirán siendo undecided (pendientes).
Los criterios que deben cumplirse son tres: En primer lugar, todos los referendos tienen un lead-in period (periodo de espera). Se trata de un periodo de tiempo que debe transcurrir después de la proposal antes de poder decidir. De esta forma, se establece un periodo inicial de preaviso en el que se pueden presentar los votos para mitigar la posibilidad de que se produzcan “decision sniping¨, en los que un atacante que controle una cantidad sustancial de votos podría intentar que se aprobara una proposal poco después de proponerla, sin dar tiempo a que el conjunto de la población votante la considere y vote.
En segundo lugar, debe haber espacio para la decisión. Todos los tracks tienen su propio límite en el número de referendos que pueden decidirse simultáneamente. Cuanto más potentes sean los Origins permitidos en el track, menor será este límite. El Origin de nivel Root tiene un límite de uno, lo que implica que sólo se puede decidir una única propuesta muy peligrosa a la vez. Por el contrario, el Tipping Track, más bien poco potente, tiene límites mucho menos estrictos, ya que cualquier daño causado por su sobrepoblación es mínimo y es mucho más útil tener muchos tips (propinas) que se deciden a la vez sobre muchas llamadas de nivel Root. Cuando hay espacio disponible, entonces es el referéndum (por lo demás elegible) de la clase que tiene más votos a favor de la aprobación el que se eleva al estado de (deciding) decisión.
Por último, hay que pagar un Decision Deposit (depósito de decisión). La creación de un referéndum es barata, ya que el depósito que hay que pagar se refiere únicamente al almacenamiento en la cadena necesario para su seguimiento. Sin embargo, el hecho de que se decida un referéndum conlleva un mayor riesgo y utiliza un espacio limitado, ya que limitamos el número de referendos que se pueden decidir simultáneamente en cada track. Por lo tanto, hay que pagar un depósito mayor (aunque reembolsable) para mitigar el spam o inflar el sistema.
Decidir y Confirmar una Propuesta
Una vez que un referéndum entra en el estado deciding (de decidir), entonces es elegible para ser aprobado. Esta elegibilidad sólo dura un tiempo limitado (28 días en Polkadot), momento en el que si no se aprueba entonces se rechaza por defecto. Para ser aprobado, debe cumplir dos criterios (en cuyo caso decimos que es passing (aprobado) y debe seguir cumpliendo estos criterios durante un mínimo del Confirmation Period (Periodo de Confirmación). Los diferentes tracks tienen diferentes duraciones del Confirmation Period, y los más potentes tardan más en confirmarse. Se trata de una defensa adicional contra un votante ballena que intente hacer “snipe” al referéndum colocando un voto lo suficientemente grande como para que los criterios de aprobación sean alcanzados inesperadamente.
Los dos criterios de aprobación se refieren al approval (aprobación) y support (apoyo). Desaparece el sesgo de quórum adaptativo de los referendos anteriores. Ahora tenemos un sistema más flexible en el que estos requisitos pueden personalizarse a un nivel mucho más fino. Approval (aprobación) se define como el porcentaje de los votos de aprobación (es decir, tras el ajuste por convicción) frente al número total de los votos (tanto de aprobación como de rechazo). Support (apoyo) es el número total de votos de aprobación (es decir, sin tener en cuenta el ajuste por convicción) comparado con el total de votos posibles que podrían realizarse en el sistema.
Cada clase de referéndum tiene diferentes requisitos para estos valores. Sin embargo, lo más interesante es que estos requisitos pueden reducirse a lo largo del tiempo según un calendario bien definido. Lo que esto significa es que, a medida que la votación avanza a lo largo de los 28 días, podemos configurar las cosas de manera que se necesite una cantidad cada vez menor de apoyo y aprobación general de la proposal para que sea aprobada. En general, siempre empezarán y terminarán más o menos de la misma manera, empezando por los umbrales más altos y terminando por los más bajos, que siguen estando en consonancia con los principios generales: al menos un 50% de aprobación.
Lo que ocurra en el medio determinará la facilidad con la que se produzca una aprobación antes del plazo de 28 días. En el caso de las proposal que utilizan origins menos privilegiados (por ejemplo, la clase Tip, que sólo puede exigir un pago del tesoro de hasta 10 DOT) es mucho más razonable bajar la participación requerida a una cantidad más realista antes que las que utilizan clases muy privilegiadas, como Root. Del mismo modo, las clases que tienen más importancia política tenderán a aceptar menos controversia (y, por tanto, requerirán una aprobación más alta) al principio.
Después de la aprobación
Las proposals que no son aprobadas después de 28 días se consideran rechazadas por defecto. En este momento, se puede devolver el Decision Deposit (depósito de decisión). Si, por el contrario, la propuesta consigue pasar y permanecer (passing) en el Confirmation Period (Periodo de Confirmación) durante esos 28 días, entonces se considera approved (aprobada) y se programa su ejecución desde el origin con el que fue debidamente propuesta, tras un Enactment Period (Periodo de Promulgación).
El Enactment Period también se especifica cuando se propone el referéndum, pero está sujeto a un valor mínimo que depende del track. Algunas de los tracks más potentes obligan a establecer un Enactment Period más amplio para garantizar que la red tenga tiempo suficiente para prepararse para los cambios que pueda traer la proposal.
Intervenciones
A veces se pone de manifiesto que una proposal que ya se está votando (y quizás ya se está aprobando) contiene un problema y es conveniente cancelarla. Un ejemplo de esto sería una mejora de la cadena que más tarde se descubriera que contiene algún tipo de problema. Aunque esto no es muy común, tampoco es del todo inaudito.
En Gov2, existe una operación especial para intervenir de esta manera conocida como Cancelation (Cancelación). Esta operación rechaza inmediatamente un referéndum en curso, independientemente de su estado. En realidad, se presenta en dos formas, una de las cuales se limita a realizar la operación de limpieza y la otra, además, a recortar al proponente inicial el depósito o los depósitos pagados por el referéndum.
La cancelación es en sí misma una operación de gobernanza que debe ser votada por la red para poder ejecutarse. Esto plantea un posible problema de plazos, y para que sea útil, conseguir que se apruebe una propuesta de cancelación debe ser, por lo general, bastante más rápido que la aprobación de cualquier posible proposal target. Como tal, la cancelación viene con su propio Origin y track, que tiene un tiempo de espera bajo y curvas de aprobación/apoyo con reducciones ligeramente más agudas en sus umbrales para ser aprobados.
Delegación Ágil
En un mundo perfecto, en el que todo el mundo tuviera tiempo y virtuosismo ilimitados, todo el mundo investigaría, discutiría, consideraría y votaría cuidadosamente cada propuesta. Sin embargo, no vivimos en un mundo perfecto. No todo el mundo tiene tiempo o ganas de votar con detenimiento cada asunto. De esta constatación nació el Consejo en la gobernanza original de Polkadot: un órgano delegado por los votantes para suplir el hecho de que muchos de ellos no querían participar en el día a día de la gobernanza. Sin embargo, con la desaparición del Consejo en Gov2, necesitamos un medio alternativo para asegurar que los votantes “pasivos” sean escuchados.
El sistema de gobernanza original tenía una característica llamada Vote Delegation (Delegación de Voto), que hemos conservado y mejorado en Gov2. Para aquellos que no estén familiarizados, esto es similar a la premisa de la democracia líquida: puedes delegar tu poder de voto a otro votante en el sistema. Cuando tu delegado vota, no sólo ejerce su propio poder de voto, sino también el tuyo. Esto funciona con el voto por convicción, permitiéndote bloquear tus tokens para aumentar el nivel de poder de voto que tu delegado ejerce en tu nombre. Por supuesto, los tokens en cuestión nunca dejan de estar bajo tu control y eres libre de cambiar de delegado o recuperar el control directo cuando quieras.
Gov2, sin embargo, mejora esto con una característica bastante especial llamada Multirole Delegation (Delegación Multirol). Esto te permite especificar un different delegate (delegado diferente) para cada clase de referéndum en el sistema. Si no quieres delegar para una clase particular de referéndum, también puedes mantener el control directo para esa clase.
Esto significa que puedes delegar en una persona para cualquier referéndum sobre el reparto de pequeños tips (propinas) a los contribuyentes del ecosistema, en otra entidad para los referendos sobre gastos del tesoro más importantes, en otra entidad para las actualizaciones y parametrizaciones puramente técnicas de la red y, finalmente, mantener el control directo para cualquier otra decisión.
El Fellowship y la Whitelist
La opinión de los “expertos” bien informados desempeña un papel importante en cualquier sistema de gobernanza que funcione bien. Una tecnocracia tiene sus propios y graves defectos, por lo que no querríamos que los “expertos” ocuparan una posición de mando: introduce riesgos de centralización, de autoridad irresponsable y sienta las bases de lo que podría llegar a ser una cábala gobernante. Por esta razón, el Comité Técnico de la gobernanza original de Polkadot no tiene “poder de decisión”, sino sólo la capacidad de reducir el periodo de votación.
Dicho esto, oraclizar la opinión bien informada y permitir que ayude a optimizar la decision-making process (el proceso de toma de decisiones), aunque no tenga un efecto directo en el decision-making outcome (resultado de la misma), parece un objetivo razonable al que hay que aspirar. Lo más importante, y por el bien de todos los involucrados, es que el organismo de expertos no pueda subvertir en modo alguno la decisión global de los stakeholders (interesados).
Las propuestas Root-Origin son del tipo que se necesitan para las actualizaciones, arreglos y rescates, pero que necesariamente tienen el poder de romper y corromper el sistema de forma arbitraria. En Gov2, como son tan peligrosas, erramos en el lado de la seguridad y tenemos niveles extremadamente altos de aprobación y apoyo necesarios para su aprobación temprana y que se reducen a sus niveles finales sólo lentamente. Los periodos de espera y de promulgación también son amplios. En general, el proceso es lento, y esto es para dar a todo el mundo en Polkadot la máxima antelación para asegurar que las malas propuestas no salgan adelante.
Sin embargo, hay ocasiones en las que es importante desplegar un arreglo, una actualización o una lógica de rescate en un periodo de tiempo más corto. En estas ocasiones podemos suponer que existe un amplio consenso, pero las salvaguardas del proceso de votación mencionadas anteriormente hacen que la ejecución de dicho arreglo pueda ser difícil o inviable debido únicamente a las limitaciones de tiempo. La idea de que “los expertos están de acuerdo: esto es seguro y a la vez crítico en cuanto al tiempo” puede ser una herramienta muy útil para formar un proceso claro y bien pensado en el caso general, pero capaz de tomar decisiones en un plazo de tiempo ajustado cuando hay buenas razones para creer que las circunstancias lo requieren.
Quedan dos grandes preguntas por responder aquí: ¿cómo podría la cadena (una mancha de lógica determinista sin capacidad inherente para expresar u observar conceptos como “seguro” y “crítico en el tiempo”? E incluso si pudiera conocer tales circunstancias, ¿cómo adaptamos nuestra lógica sin comprometer nuestra trazabilidad y simplicidad generales?
El Fellowship
La respuesta a la primera pregunta está en un nuevo órgano de gobernanza. Para quienes estén familiarizados con el antiguo sistema de gobernanza, este órgano puede considerarse el sucesor lógico del Comité Técnico.
Se llama Polkadot Fellowship, y en su conjunto es una estructura lo suficientemente rica y sofisticada como para ser objeto de otro artículo. Inicialmente se ejecutará en la red Kusama, ya que Gov2 se desplegará allí con fines de prueba en vivo, sin embargo se migrará a Polkadot con el despliegue final de Gov2 y una vez allí servirá a ambas redes a través del puente Polkadot/Kusama.
El Fellowship es un cuerpo de expertos mayoritariamente autogobernado con el objetivo principal de representar a los humanos que encarnan y contienen la base de conocimiento técnico de la red y el protocolo Polkadot. A diferencia del actual Colectivo Técnico, está diseñado para ser mucho más amplio en cuanto a miembros (es decir, para funcionar bien incluso con decenas de miles de miembros) y con barreras de entrada mucho más bajas (tanto en términos de flujo de procesos administrativos como de expectativas de experiencia). Convertirse en candidato a miembro del Fellowship es tan fácil como hacer un pequeño depósito.
Para ayudar a garantizar una alta calidad de las decisiones colectivas a la luz de una membresía tan amplia, los miembros están asociados a un rango para designar el grado en que el sistema espera que su opinión esté bien informada, tenga una base técnica sólida y esté en línea con los intereses de Polkadot. Los miembros del Fellowship pueden votar sobre cualquier proposal del Fellowship y la opinión agregada de los miembros (ponderada por su rango) constituye la opinión considerada del Fellowship.
Por cierto, el medio técnico por el que vota el Fellowship es en realidad exactamente el mismo código (Substrate pallet) que el medio por el que votan los stakeholders de Polkadot en un referéndum y tiene exactamente las mismas facilidades (tracks múltiples, delegación ágil, &c).
Rangos y Dificultades
Introducir el concepto de rango está plagado de dificultades. Sin embargo, se nos presentan relativamente pocas opciones si nuestros requisitos son la descentralización, la responsabilidad y la seguridad para todos los involucrados. Creemos que es razonable utilizar la apertura, la transparencia y la resistencia a la corrupción que aporta el consenso descentralizado para garantizar que los “gobernantes” no estén por encima de las “normas” y que el rango venga acompañado de expectativas, normas y responsabilidad claras. Los inconvenientes del rango no sólo son malos para la red, sino que, a la luz de algunas posturas políticas recientes en materia de tecnología descentralizada, también lo son para los participantes: si el rango permitiera a un pequeño grupo de participantes tener el control efectivo de la red, podrían considerarse en control efectivo de la misma y, por tanto, responsables de lo que ocurra en ella.
Por ello, nos atenemos a tres principios: en primer lugar, el Fellowship nunca debe tener poder duro sobre la red: no puede cambiar los parámetros, realizar rescates ni mover activos. En cuanto a la gobernanza sobre la red, lo único que tiene en su poder es reducir el plazo efectivo en el que tiene lugar un referéndum.
En segundo lugar, el sistema de rangos y las ponderaciones deben diseñarse de forma que no se espere que pequeños grupos de individuos puedan captar y controlar la capacidad de decisión global. Aunque el Fellowship pondera más a los de mayor rango en la opinión agregada, el peso no debe ser tan alto como para que un pequeño número de opiniones de los miembros más altos sea insuperable en comparación con una opinión coherente procedente de los miembros de menor rango.
En tercer lugar, el Fellowship debería estar diseñado para hacer crecer y desarrollar sus miembros y sus niveles de experiencia agregados y, de este modo, garantizar que su capacidad general de toma de decisiones se fortalezca con el tiempo. Para que tenga éxito a largo plazo, el Fellowship debe ser una meritocracia efectiva en la que los que tienen compromiso, talento y experiencia alcancen mayores niveles de influencia. Para lograrlo, debemos dar claridad y transparencia en el proceso de ingreso y promoción en el rango. En la medida de lo posible, la identidad de un individuo no debe ser una consideración, sólo su capacidad.
Por ello, el Fellowship tendrá una constitución que describa en términos específicos los requisitos y las expectativas de los individuos para alcanzar y mantener un determinado rango. Los rangos superiores pueden votar y promover a los rangos inferiores votando con base en esta constitución. La degradación se produce automáticamente después de un periodo en el que el miembro es incapaz de defender su posición ante sus compañeros. La suspensión sólo puede producirse a través de un referéndum general (Polkadot), lo que proporciona un medio para garantizar que la controversia o la impopularidad dentro del Fellowship no resulte (necesariamente) en la expulsión. Además, para evitar la posibilidad de que el Fellowship se convierta en una cábala, la entrada en los rangos superiores también requiere un referéndum general (Polkadot) y no puede ser otorgada simplemente por los compañeros del Fellowship.
Whitelist
Mientras que el Fellowship puede representar el cuerpo de expertos humanos de Polkadot en la cadena y proporcionar una pieza de lógica determinista de la que se obtiene su opinión agregada, puede que no esté claro cómo podemos integrar esto en el sistema de referéndum general. De hecho, esto se consigue utilizando una combinación de conceptos que ya conocemos y una pieza maravillosamente sencilla de lógica en cadena llamada Whitelist pallet.
La paleta Whitelist hace una cosa: permite a un Origin escalar el nivel de privilegio de otro Origin para una determinada operation (operación). En términos de Gov2, permite al Fellowship autorizar a un nuevo origin (que llamaremos Whitelisted-Root) para que se ejecute con privilegios de nivel Root. Puedes pensar en ello como una especie de sudo de Unix, excepto que sólo funciona con comandos específicos que el Fellowship ha preautorizado. Lo que esto significa es que podemos tener un nuevo track en la gobernanza de Polkadot que es para las proposals que habrán sido incluidas en la whitelist por el Fellowship. Si el referéndum se aprueba, entonces se ejecutarán dentro de la paleta Whitelist con este origin Whitelisted-Root. La paleta Whitelist verifica dos cosas: que este origin es realmente el Whitelisted-Root (es decir, que el referéndum fue aprobado en este track) y que la proposal ha sido efectivamente incluida en la whitelist del Fellowship. Si es así, sigue adelante y ejecuta la operación con privilegios de nivel Root.
Con esto no tenemos que cambiar nada de cómo funciona el sistema de referéndum (¡yey!). Ahora tenemos un nuevo track (para el origin Whitelisted-Root) cuyos parámetros permiten una votación más corta, con la seguridad de que, a través de un proceso abierto y transparente, un cuerpo de expertos globales en el protocolo Polkadot ha determinado que esto es seguro y crítico en cuanto al tiempo.
Calendario y Trabajo Futuros
Gov2 se lanzará en Kusama de forma inminente, tras la auditoría profesional final de su código. Una vez probada en Kusama, se hará una proposal para que la red Polkadot la vote.
Está prevista una actualización de este sistema de gobernanza global, cuyo nombre en código es “Gov2.5”, para su eventual despliegue unos meses después. Aportará dos características claves: en primer lugar, una función de “collect-call¨ (llamada a cobro revertido) para la delegación de votos, que permitirá a los usuarios (a través de sus wallets) ofrecer sus fondos para la delegación sin pagar ninguna tarifa de transacción; en cambio, el delegado podrá pagar opcionalmente las tarifas de transacción para obtener los fondos delegados. En segundo lugar, se introducirá una transacción gratuita para dejar de delegar, que podrá ser utilizada de forma limitada por todos los usuarios que deleguen. En conjunto, estas características permiten a las wallets ofrecer a sus usuarios una integración de gobernanza altamente racionalizada y de costo cero, lo que esperamos que atraiga una mayor participación de los usuarios en el proceso general de gobernanza.