O para On-chain Governance [Polkadot A to Z]

La gobernanza on-chain (en cadena) es una de las partes más importantes de Polkadot y Kusama. Es la única forma de proponer cambios en el tiempo de ejecución (runtime) y, siempre que la comunidad de titulares de tokens DOT esté de acuerdo en que los cambios están justificados y elija votar favorablemente, se puede promulgar el cambio de tiempo de ejecución propuesto. El cambio actualizará la lógica del tiempo de ejecución (runtime logic), como en el código que ejecuta la blockchain. ¡Esto es enorme! Los desarrolladores ya no tienen una influencia absoluta sobre el código en el que se ejecuta la red. El poder de actualizar la lógica de la red se pone en manos de los poseedores de tokens. Pero, ¿cómo funciona todo?

Al otorgar la capacidad de cambiar la lógica del tiempo de ejecución a los titulares de tokens, la gobernanza on-chain debe implementarse con ciertas consideraciones de seguridad. Identificar las trampas comunes de la gobernanza pública on-chain y encontrar soluciones que sean eficientes es imperativo para un mecanismo saludable. El mecanismo de gobernanza actual es eficaz, pero todavía hay margen de mejora. Actualmente se está trabajando en la Gobernanza 2.0, que pretende ser más ágil, inclusiva, segura y descentralizada, y la retocaremos al final de esta publicación. Para comprender lo que eso significa, primero debemos profundizar en el estado actual de la gobernanza on-chain.

Por qué es importante la gobernanza on-chain

Es común pensar en una base de código como un organismo vivo que siempre está cambiando. Su mantenimiento repercute directamente en su salud. Una blockchain no es diferente, ya que se ejecuta en código después de todo. Por lo tanto, el éxito de una red blockchain radica en su flexibilidad y capacidad para adaptarse al cambio. Las cadenas basadas en Substrate, con sus actualizaciones sin forks (consulte la publicación Polkadot A to Z: F for Forkless para comprender mejor ese concepto) están diseñadas para ser adaptables. Las blockchains que puedan adaptarse a los cambios en el ecosistema, como mejoras en los mecanismos de consenso, redes más eficientes, mejor criptografía o cualquier otro componente que la componga, serán las exitosas.

Los cambios en el código de la blockchain antes de la característica de actualizaciones sin forks requerían que los desarrolladores bifurcaran (fork) la base del código. Con bifurcaciones (forks) convencionales, los desarrolladores del código base podrían cambiar el tiempo de ejecución sin ningún tipo de acuerdo en cadena (on-chain) o consenso sobre la actualización. Los propietarios de BTC o ETH no tienen nada que decir sobre cómo se desarrolla o actualiza la red. Entonces, ¿por qué no hacer una de las utilidades de un token, la capacidad de votar sobre los cambios que se podrían realizar en el tiempo de ejecución? Esta es la esencia de la gobernanza en cadena (on-chain).

Al dar a los poseedores (holders) de tokens la capacidad de crear y votar propuestas de cambios en el tiempo de ejecución, aparecen algunos incentivos diferentes. Un incentivo para que los titulares de tokens tengan un sentido de equidad y se preocupen por los cambios en el tiempo de ejecución, pero también para asegurarse de que solo se permitan cambios que tengan sentido. En segundo lugar, un posible incentivo adverso de participantes maliciosos en la red para tratar de romper el sistema proponiendo referéndums maliciosos. Es decir, la gobernanza en cadena (on-chain) debe crear un entorno propicio para permitir la promulgación de cambios sensibles, pero también para protegerse contra los maliciosos. Los componentes del sistema incluyen, pero no se limitan a: propuestas, referendos, votación de stake ponderado, sesgo de quórum adaptativo, bloqueo voluntario, también conocido como votación con convicción, y actualizaciones sin forks. Así que abramos el capó y miremos adentro, para ver cómo estos componentes funcionan juntos.

Las partes móviles.

La gobernanza debe ser justa y equitativa y, en el caso de los sistemas de blockchain, suficientemente descentralizada. Esto viene con desafíos; ¿Cómo nos aseguramos de que los poseedores de tokens estén representados de manera justa y que un solo grupo de poseedores de tokens no controle el sistema de gobierno basado en el stake? La gobernanza en cadena (on-chain) de las cadenas basadas en Substrate como Polkadot y Kusama tiene varios pasos y tiene ciertos componentes que funcionan juntos para ofrecer un ciclo de votación de titulares de tokens bien representado sobre posibles cambios en el tiempo de ejecución. Con la idea de un origen, existen diferentes entidades que pueden participar en la gobernanza. Los orígenes usan la plataforma Democracy (Democracia) en Substrate, lo que permite una funcionalidad que permite a la gobernanza en cadena y la capacidad de actualizar el tiempo de ejecución.

Orígenes que pueden participar en la gobernanza:

1. Titulares de tokens DOT
2. Consejo (Council)
3. Technical Committee (Comité Técnico)

El ciclo de gobernanza en cadena, en orden cronológico, son:

1. Propuesta
2. Referéndum
3. Votación
4. Promulgación

Para comprender la gobernanza en cadena, debemos comprender las entidades de origen, los componentes del ciclo y cómo funcionan juntos.

Consejo

El consejo es un origen en cadena (on-chain origin) cuyo propósito es representar a los poseedores de tokens pasivos. Aunque es un grupo central de autoridad, los candidatos deben ser elegidos para el consejo por titulares de tokens. Por lo tanto, ganar favoritismo entre la comunidad es imperativo para ganar un asiento en el consejo. Los miembros del consejo tienen algunas responsabilidades clave; iniciar referéndums sensatos, cancelar referéndums no controvertidos, lesivos y maliciosos, administrar la tesorería y elegir miembros del comité técnico. Actualmente en Polkadot hay 13 asientos del consejo, con espacio para hasta 20 candidatos o en inglés " runners-up" (aquellos que esperan convertirse en miembros del consejo). Y en Kusama hay 19 plazas, con espacio para hasta 19 candidatos. El consejo rota (los consejales son reelegidos) cada 7 días en Polkadot y cada 24 horas en Kusama.

Comité Técnico

El Comité Técnico es un grupo de equipos que han demostrado sus conocimientos técnicos al implementar con éxito un tiempo de ejecución de Polkadot. Los equipos pueden ser agregados o eliminados por mayoría simple de votos en el Consejo.

El propósito del Comité Técnico es protegerse contra referendos maliciosos, implementar correcciones de errores, revertir actualizaciones de tiempo de ejecución defectuosas o agregar funciones nuevas pero probadas en batalla. Estos cambios a través del comité técnico se aceleran para su votación e implementación.

Propuestas

Puede haber dos tipos de propuestas en cadena (on-chain). Propuestas públicas, que son realizadas por titulares de tokens. Y las propuestas del Consejo, que vienen en forma de mociones externas, ya sea hechas por un miembro del Consejo o por un poseedor de token. El Consejo también tiene una moción interna especial, pero estas no se convierten en referéndums. Las mociones internas no requieren la funcionalidad del pallet de Democracy, ya que manejan asuntos que no requieren cambios en el tiempo de ejecución, como el manejo de propuestas de tesorería o la elección de miembros del Comité Técnico. Se pueden hacer propuestas públicas vinculando (bonding) la cantidad mínima de tokens (actualmente 100 DOT en Polkadot), y una vez que la propuesta se ha publicado en la cadena, los poseedores de tokens señalan su apoyo aprobándola. El respaldo requiere que vinculen la misma cantidad de tokens que la cuenta que publicó originalmente la propuesta. La cantidad de vinculación es la métrica crítica al elegir qué propuestas se convierten en referéndums. Una propuesta con 3 cuentas que vinculan 10 DOT cada una supera a 29 cuentas que vinculan 1 DOT cada una. Los tokens vinculados se devolverán a las cuentas originales cuando la propuesta se convierta en referéndum.

Referéndum

Las propuestas del Consejo se convertirán en referendos / referéndums cuando una mayoría simple de los miembros del consejo esté de acuerdo con la propuesta. Así es como el consejo puede iniciar la legislación. Una vez aprobada, se convierte en referéndum público. Y si la propuesta fue creada por poseedores de tokens, aquellos que tienen la mayor cantidad de tokens vinculados que los respaldan se convierten en referéndums públicos.

Cada tipo de propuesta, pública y del consejo, tiene su propia cola en cadena (on-chain queue). Las propuestas viven en sus respectivas colas, y cada 28 días (en Polkadot) la propuesta más respaldada se convertirá en referéndum en la que se puede votar. El mecanismo en cadena (on-chain) que elige la próxima propuesta para convertirse en referéndum alterna entre la cola pública y la del consejo.

El calendario de referéndums sobre Polkadot es cada 28 días. Lo que significa que cada 28 días, la propuesta pública más respaldada o la propuesta del consejo más reciente se convierte en referéndum y se someterá a votación por parte de los poseedores de tokens. A menos que haya un referéndum de emergencia sobre la mesa, solo puede haber un referéndum para votar a la vez. Al alternar las colas cada 28 días, suponiendo que ambas colas estén llenas con un montón de propuestas, cada cola respectiva tendrá su turno cada 56 días. Los referéndums activos se pueden ver mediante exploradores de blockchain, como Polkadot JS Apps o Polkasembly.

Votación

Los titulares de tokens pueden elegir entre varios niveles de apoyo para un referéndum, desde no vincular ningún token que reduce el peso de sus votos o vincular tokens durante un rango de períodos de tiempo para aumentar su poder de voto. Esto crea un incentivo para disuadir la venta de votos y también una forma de permitir que los poseedores de tokens más pequeños aumenten su poder de voto bloqueando tokens por más del monto mínimo requerido. Esto se llama votación por convicción (conviction voting). Según el resultado de la votación, el referéndum se aprobará o fallará. Si se aprueba, se promulgará, lo que significa que la actualización del tiempo de ejecución (runtime upgrade) se incluirá en un próximo bloque.

Votación por Convicción

En pocas palabras, la votación por convicción, también conocida como bloqueo voluntario, es un mecanismo que permite a los poseedores de tokens aumentar su poder de voto al bloquear sus tokens de forma segura en la cadena. Los multiplicadores integrados tienen un mínimo de 0,1x (lo que significa que no hay vínculo) y un máximo de 6x (vinculado durante 896 días). Recuerde, un solo período de bloqueo es igual al calendario de un referéndum, que es de 28 días.

Y la ecuación utilizada para calcular su poder de voto es:

votos = tokens * multiplicador de convicción

Lo que significa que si no bloquea sus tokens, su voto valdrá 1/10 de un voto normal. Si se bloquea por 1 período de votación, al vincular la misma cantidad que el autor de la propuesta, su voto valdrá 1 voto, y si se bloquea por 32 períodos, su voto valdrá 6 veces.

La votación por convicción está ahí para ayudar a proteger y mantener un control y equilibrio para los tenedores de tokens más pequeños, al darles la capacidad de aumentar su poder de voto.

Sesgo de Quórum Adaptativo (Sesgo de Participación)

Podemos pensar en este mecanismo como una palanca que cambia el porcentaje de supermayoría necesario para que se aprueben los referéndums. Su importancia radica en situaciones en las que no existe un respaldo mayoritario claro o en contra de un referéndum. La participación de la votación hará que este mecanismo caiga en dos categorías, sesgo de participación positivo (positive turnout bias) y sesgo de participación negativo (negative turnout bias), que controlan la variable de mayoría simple.

Todas las propuestas públicas utilizan lo que se denomina sesgo de participación positivo, lo que significa que a medida que aumenta la participación (turnout) en el referéndum, disminuye el umbral (threshold) de votos a favor necesarios. El sesgo de participación positivo garantiza que, con una participación más baja, solo se aprueben las propuestas no controvertidas. Por ejemplo, si la participación es del 25%, que es una participación baja, la supermayoría necesaria es de alrededor del 66%. A medida que aumenta la participación, disminuye la supermayoría necesaria. Por ejemplo, si la participación es del 75%, la supermayoría necesaria será del 54%.

Las propuestas del consejo que se aprueban por unanimidad utilizan un sesgo de participación negativa, lo que significa que es más fácil aprobar con una participación baja y requiere que la supermayoría lo niegue.

Cancelando

Hay algunos métodos de cancelación que se pueden utilizar en diferentes puntos de la vida útil de una propuesta:

1. Si hay un acuerdo unánime, el Comité Técnico puede cancelar una propuesta.
2. Si la propuesta se ha convertido en un referéndum y hubo un problema de última hora, como un error en el código de tiempo de ejecución. El Consejo, por mayoría de 2/3 de los votos, puede cancelar el referéndum.

El depósito de una propuesta cancelada se quemará, pero en el pasado hubo propuestas para revertir los tokens quemados si era controvertido.

El Futuro (Gobernanza On-Chain 2.0)

Aunque no es perfecto, el modelo actual ha funcionado bien durante los últimos 2 años. Desde las primeras propuestas, ya había pensamientos dando vueltas sobre cómo se podrían mejorar algunas debilidades en el futuro. La comunidad ha manifestado su preocupación por la baja participación en las votaciones y el hecho de que el Consejo y el Comité Técnico sean una forma central de autoridad.

En los esfuerzos por abordar estos problemas y descentralizar aún más las redes de Polkadot y Kusama, los esfuerzos para disolver el consejo y el comité técnico han sido un enfoque del equipo de desarrollo de Parity Technologies. El código que haría esto posible se fusionó con la base de código de Substrate, pero aún debe probarse en Kusama, auditarse y aprobarse por la comunidad a través de la actualización del tiempo de ejecución. El objetivo de la gobernanza 2.0 es ser un diseño más ágil, inclusivo, seguro y descentralizado.