En los primeros 2 años de existencia del protocolo Livepeer, el equipo central de desarrollo responsable de la creación de la primera versión del protocolo también asumió la responsabilidad de actualizar el protocolo para cumplir mejor los requisitos de las aplicaciones de transmisión de video. Por el momento, la gobernanza del protocolo es impulsada por el equipo central de desarrollo como el BDFL (dictador benevolente de por vida). Para hacer realidad la visión de la infraestructura pública de transmisión de video que puede satisfacer las necesidades de todas las aplicaciones de transmisión de video en todo el mundo, es crucial que la gobernanza del protocolo sea impulsada por las partes interesadas que hacen posible la infraestructura en primer lugar.
Un sistema de gobierno ideal distribuirá el poder a las partes interesadas que contribuyen y permiten la existencia del protocolo, lo que les permite cambiar de forma autónoma las reglas y parámetros del protocolo. Diseñar un sistema de este tipo que satisfaga las necesidades de las partes interesadas en cada posible escenario futuro en un solo momento es una tarea hercúlea y probablemente poco práctico.
Sin embargo, como comunidad, aún podemos esforzarnos hacia ese sistema estableciendo una colección de herramientas, procesos sociales y normas sociales junto con un sistema técnico extensible que pueda adaptarse a las necesidades futuras. En lugar de pensar en la gobernanza de protocolos como un problema que debe resolverse en un solo punto en el tiempo, podemos pensar en la gobernanza de protocolos como un proyecto que requiere mantenimiento y mejora continua a lo largo del tiempo. Con esta mentalidad, podemos establecer hitos de gobernanza incrementales: cada uno de estos hitos mejoraría la capacidad de las partes interesadas para ejercer su voz e influir en la evolución del protocolo.
En el resto de esta propuesta haré lo siguiente:
Describa los hitos en una propuesta de hoja de ruta de gobierno Describa los componentes del primer hito que se centra en la descentralización del conocimiento, LIP y encuestas
1. Descentralización del conocimiento, LIP y encuestas
Los objetivos para este hito son:
Disperse el conocimiento del protocolo de manera que una porción más grande de la comunidad sea capaz de evaluar propuestas técnicas y económicas para cambiar las reglas y parámetros del protocolo Formalizar el proceso LIP (Propuesta de Mejora de Livepeer) a medida que la comunidad acepta el proceso para crear, discutir y evaluar técnicas y propuestas económicas Crear una aplicación de sondeo que permita a los titulares de tokens señalar su aprobación / desaprobación de los LIP
Este hito establecerá una colección de herramientas, procesos sociales y normas sociales que comenzarán a dar a los interesados una mayor voz en la gobernanza del protocolo. Si bien en esta etapa las partes interesadas seguirán dependiendo de los desarrolladores principales para ejecutar cambios en el protocolo y salvaguardar el valor del usuario si se descubre un error de protocolo, estas herramientas, procesos y normas ayudarán a las partes interesadas a comprender mejor por qué y cómo se tomó una decisión, creando así una mayor transparencia y hacer que los desarrolladores principales sean más responsables ante otras partes interesadas.
A corto plazo, los artefactos creados en este hito permitirán los pasos iniciales para que las partes interesadas expresen sus preferencias y opiniones para influir en las decisiones de cambio de protocolo. Después de este hito, estos artefactos continuarán siendo útiles para llevar a la comunidad a la conversación sobre mejoras en la estructura de gobernanza del protocolo y también como bloques de construcción para un diálogo comunitario rico y reflexivo que es un componente crucial de cualquier estructura de gobernanza efectiva.
2. Sistema de gobierno extensible
Los objetivos para este hito son:
Implemente un sistema de gobernanza técnicamente extensible que pueda usarse para actualizar los parámetros y el código de los contratos inteligentes de protocolo. Debe haber un camino claro para actualizar el sistema de gobernanza para dar a las partes interesadas el control sobre el sistema
Por el momento, un multisig propiedad de un desarrollador principal tiene privilegios de administrador en el contrato del Controlador, lo que le da a los desarrolladores principales la capacidad de actualizar el código y los parámetros del contrato. Un sistema de gobierno técnicamente extensible podría:
Habilite las reglas en cadena sobre cómo se pueden actualizar los códigos / parámetros. Por el momento, no hay protecciones exigibles en la cadena para las partes interesadas porque el código / parámetros pueden ser actualizados inmediatamente por el equipo central. Un ejemplo de una posible regla requiere un retraso de tiempo para todas las actualizaciones de código / parámetro para dar a todos los interesados una visión clara de las actualizaciones pendientes y también para permitir que los interesados que no estén de acuerdo con una actualización salgan (es decir, no enlacen y liquiden los tokens apilados) antes de ejecución de una actualización en cadena. Facilite actualizaciones más complejas de los contratos al permitir que múltiples actualizaciones de código / parámetro se agrupen en una sola acción en cadena. Esto puede reducir la complejidad y el número de pasos necesarios para una actualización de protocolo que consta de múltiples propuestas. La actualización de Streamflow requirió muchas acciones en cadena que tuvieron que ejecutarse secuencialmente. Para estos tipos de actualizaciones importantes planificadas, agrupar la ejecución de un conjunto de propuestas en una sola acción en cadena puede simplificar el proceso de actualización. Facilitar futuros cambios en la estructura de gobierno. Un contrato de gobierno reemplazaría al equipo central actual de múltiples diseños como el "propietario" del contrato del Controlador. Si bien el contrato de gobernanza seguirá otorgando privilegios al equipo central multisig para realizar actualizaciones de código / parámetro en este hito, las reglas en cadena (ver el primer punto anterior) determinarán cómo / cuándo se pueden realizar estas actualizaciones. Luego, en el siguiente hito, el contrato de gobierno puede otorgar privilegios para realizar actualizaciones de código / parámetro a un contrato de votación vinculante.
La motivación detrás de este hito no es implementar inmediatamente un sofisticado sistema de votación vinculante, sino más bien establecer la base técnica que permita la implementación de una variedad de sofisticados sistemas de votación vinculante en el futuro.
3. Sistema de votación vinculante
Los objetivos para este hito son:
Actualice el sistema de gobierno para utilizar un sistema de votación vinculante para aprobar o rechazar cambios en los contratos inteligentes de protocolo
Este hito permitirá a las partes interesadas coordinar los cambios en el protocolo sin ningún privilegio especial otorgado a los desarrolladores principales. Hay un amplio espacio de diseño para sistemas de votación vinculantes. Algunas áreas interesantes de exploración incluyen:
Reglas de ponderación en un sistema de votación con token
1T1V (1 token 1 voto) es un mecanismo popular ya que ofrece resistencia a Sybil al asignar un costo (de adquirir tokens) a la votación, pero hay espacio para experimentar cómo ponderar las tenencias de tokens de una cuenta. Por ejemplo, la votación por convicción calcula los pesos de los votos en función del tiempo en que una cuenta se compromete a votar. Dado que la delegación de estaca ya es un concepto de primera clase en el protocolo, también podría usarse en un sistema de votación para permitir que los delegadores deleguen su peso de voto a los orquestadores
Propuesta de prevención de spam
Si no hay costo para la creación de propuestas, entonces un atacante podría enviar correo no deseado al sistema de gobierno con propuestas que los titulares de tokens necesitarían votar constantemente. Un enfoque para la prevención del correo no deseado es asignar un costo a la creación de propuestas. Este es el enfoque utilizado en la gobernanza del cosmos
Ejecución demorada garantizada
En lugar de requerir un voto por cada cambio de protocolo en la cadena, podría haber una garantía para cada cambio propuesto que se ponga en cola para su ejecución después de un retraso de tiempo. Antes del final de la demora, cualquiera puede impugnar la propuesta presentando su propia garantía que desencadenaría una votación que determinaría si la propuesta es aceptada (el retador pierde su garantía) o rechazada (el proponente pierde su garantía). El mecanismo crea un proceso de vía rápida que no requiere un voto para propuestas no contenciosas y al mismo tiempo permite que las partes interesadas que se preocupan profundamente por una propuesta activen un voto para propuestas contenciosas La publicación del blog de los Acuerdos de Aragón ilustra este concepto en el contexto de los acuerdos formados entre miembros una organización autónoma descentralizada (DAO)
Estas ideas de diseño, entre otras, se pueden explorar con la participación abierta de las partes interesadas para determinar el diseño de sistema de votación vinculante más apropiado para este hito.
4. Futuro
El hito anterior será la primera vez cuando las partes interesadas podrán tener un control autónomo total sobre los cambios en los contratos inteligentes del protocolo. Sin embargo, el sistema implementado como parte del hito anterior probablemente todavía tendrá que cambiar con el tiempo. Hay una serie de mecanismos interesantes para explorar, como la futarquía y la votación cuadrática. Todos estos mecanismos serán posibles de experimentar y dependerá de las partes interesadas decidir cuáles se adaptan mejor a las necesidades de gobernanza del protocolo.
Descentralización del conocimiento.
La descentralización del conocimiento es crítica para un sistema de gobernanza que funcione bien porque las partes interesadas deben poder evaluar los méritos y riesgos de las propuestas técnicas y económicas para tomar una decisión informada sobre si se debe hacer un cambio de protocolo o no. Si una sola parte posee todo el conocimiento sobre las implicaciones técnicas y económicas de un cambio, entonces el sistema de gobernanza no facultará a las partes interesadas para ejercer su voz, independientemente de cuán técnicamente / teóricamente suenen las mecánicas del sistema.
Hoy, el equipo de desarrollo central es el centro de creación de conocimiento de protocolo. Sin embargo, ese conocimiento no está bien disperso en la comunidad de partes interesadas. Si bien cualquier esfuerzo para dispersar el conocimiento a más partes interesadas será un proyecto continuo, podemos comenzar el proceso en este primer hito con una iniciativa de educación pública. Ejemplos de proyectos potenciales para esta iniciativa son:
Una serie de educación accesible que explica cómo funciona el proceso de gobernanza de protocolo en este primer hito. Más uso del foro y del repositorio de investigación de Github para compartir ideas y revisión por pares informal. Una serie de publicaciones técnicas de blog sobre cómo funcionan ciertas características del protocolo.
Labios
Las propuestas de mejora de Livepeer (LIP) describen estándares y especificaciones para cambios en el protocolo. El objetivo original del proceso LIP era servir como el proceso estándar mediante el cual se crearía, debatiría e implementaría un cambio en el protocolo. Sin embargo, desde la creación del proceso, los únicos participantes en el proceso han sido desarrolladores principales y el proceso no se utilizó en absoluto para la actualización del protocolo Streamflow.
En el futuro, el proceso LIP puede garantizar que las partes interesadas comprendan el ciclo de vida de las propuestas técnicas y económicas. El proceso proporcionará pautas para crear y discutir propuestas. Sin pautas para las propuestas, la comunidad se vería inundada de propuestas de baja calidad que obstaculizarían la capacidad de las partes interesadas de tener debates de alta calidad sobre los méritos y riesgos de las propuestas. El proceso debe producir LIP que puedan considerarse para adopción y que puedan ser objeto de encuestas como se describe a continuación.
Votación
Una aplicación de sondeo para los titulares de tokens le daría al equipo de desarrollo central acceso a otra señal de la comunidad además de las señales enviadas por aquellos que participan en el proceso de LIP. Si bien los tokenholders son solo un subconjunto de interesados en la comunidad, son un gran subconjunto de la comunidad, por lo que es importante comprender sus preferencias.
Algunas propiedades deseables para la aplicación de sondeo incluyen:
Auditable Un tercero debe poder auditar los resultados de una encuesta para establecer la confianza de que los votos se tabularon correctamente. Esto ayudará a establecer la legitimidad en torno a los resultados de una encuesta. Fuente abierta. Si bien esta aplicación será utilizada principalmente por los desarrolladores principales en este hito para agregar las preferencias de los tokenholders, la esperanza es que eventualmente pueda ser implementada por cualquier miembro de la comunidad que desee proponer una encuesta sobre una propuesta. Además, una base de código de código abierto también ayuda con la auditabilidad. La solicitud debe proporcionar la información necesaria para que un titular de token tome una decisión informada al emitir un voto. Esto podría incluir el texto de la propuesta en sí junto con un resumen de los méritos, riesgos y enlaces a las discusiones relevantes.
En esta propuesta, describí un conjunto inicial de hitos para una hoja de ruta de gobernanza y detalles de alto nivel para el primer hito, que incluyen:
Una iniciativa de educación pública para ayudar a descentralizar el conocimiento Una renovación para un proceso LIP formalizado para crear, debatir y crear consenso en torno a propuestas técnicas y económicas Una aplicación de encuestas que se puede utilizar para medir el sentimiento de los tokens de accionistas sobre una propuesta particular al decidir si adoptarla o no
Pronto habrá más detalles sobre los diseños para los primeros proyectos importantes. Mientras tanto, ¡todos los comentarios son bienvenidos!