Anoche volví a leer la parte de operaciones de gobernanza de @SignOfficial , en realidad al principio no tenía la intención de leerlo a fondo. Pensé que ya entendía “gobernanza” en web3: propuestas, votación, ejecución — piezas que se repiten en la mayoría de los sistemas. Si hay alguna diferencia, solo es una mejor UI, gas más barato o añadir algunas capas de delegación. Después de leer demasiados proyectos, casi asumo que la gobernanza es algo que ya es “suficientemente bueno”, no es un lugar con muchas innovaciones fundamentales.
Pero hay un pequeño detalle que me hizo detenerme más tiempo del que pensaba.
No es una característica específica, sino la forma en que describen la gobernanza como un tipo de “operación” directamente vinculada a los datos — y no solo como un proceso de toma de decisiones. Al principio pasé rápidamente por esa parte, porque sonaba un poco abstracto. Pero cuanto más leía, comenzaba a notar algo que no encajaba con la forma en que había imaginado la gobernanza hasta ahora.
Si miras rápidamente, la gobernanza en esta parte todavía tiene elementos familiares: se crean propuestas, los usuarios firman, los datos se validan y, finalmente, se registra un estado. No hay nada demasiado nuevo en la superficie. Pero lo que encuentro más notable es cómo todo este proceso no se empaqueta en un módulo separado, sino que se coloca dentro del mismo sistema con esquema, atestación y consulta.
Al principio pensé que esto era solo una forma de organizar la documentación. Pero al leer más de cerca, comencé a darme cuenta de que estaban tratando de difuminar la línea entre “acción de gobernanza” y “primitivo de datos”.
Una propuesta, de esta manera, no es solo una sugerencia. Es una forma de datos estructurados, con un esquema claro, que puede ser verificado, consultado y combinado con otros datos. La votación no es solo una acción en cadena, sino que se convierte en una serie de atestaciones que pueden ser procesadas como cualquier otro dato dentro del sistema.
Parece pequeño, pero este punto me hizo detenerme.
Porque si lo miras desde este ángulo, la gobernanza ya no es una “capa superior”. Se convierte en parte de la capa de datos. Y esto conlleva una consecuencia bastante interesante: todo lo relacionado con la gobernanza — desde propuestas, votos, hasta ejecución — puede consultarse, compilarse y reutilizarse de manera mucho más flexible.
Al principio pensé: “ok, entonces solo es una mejor indexación de datos”. Pero luego me di cuenta de que, si no hay un sistema de esquema y atestación lo suficientemente sólido, esto es casi inviable. La mayoría de los sistemas actuales almacenan los resultados de la gobernanza, no almacenan su “significado” de una manera reutilizable.
Aquí, $SIGN parece estar tratando de hacer lo contrario.
Comienzan definiendo los datos primero: qué es un esquema, quién tiene derecho a validar, dónde se almacenan los datos — y luego permiten que la gobernanza “funcione sobre” esos primitivos. Esto hace que la gobernanza ya no sea un proceso rígido, sino un conjunto de operaciones que pueden ser compuestas.
Si falta esta capa, la gobernanza a menudo se encuentra atrapada dentro de cada protocolo. Un DAO A no puede entender o usar fácilmente los resultados de gobernanza de un DAO B, a menos que haya una capa de adaptador específica. Pero si la gobernanza se presenta como datos con un significado semántico claro, entonces, en teoría, podría compartirse y reutilizarse entre sistemas.
Aquí es donde empiezo a verlo tocar una capa más profunda.
He visto muchos proyectos intentar mejorar la gobernanza aumentando la participación (delegación, incentivos) o optimizando la ejecución (automatización, bloqueo temporal, multisig). Pero la mayoría todavía mantiene la suposición de que la gobernanza es una “caja negra”: introduces una propuesta y recibes un resultado.
Aquí parece que están tratando de romper esa caja y convertir todo el proceso en una forma de datos abiertos.
Por supuesto, si se mira más de cerca, este enfoque también plantea muchas preguntas. Por ejemplo: cuando todo se convierte en datos consultables, ¿quién definirá el esquema estándar? Si cada protocolo define su propio esquema, el problema de la interoperabilidad vuelve a ser el mismo. Pero si hay un estándar común, surgen preguntas sobre el control y la flexibilidad.
Lo que encuentro interesante es que Sign no intenta resolver completamente estas preguntas en la documentación. Solo proporcionan un conjunto de herramientas para construir, sin imponer un modelo de gobernanza específico. Esto suena razonable, pero también significa que la parte más difícil — la convergencia hacia un estándar — se deja de lado.
Otro punto que veo como “en la dirección correcta”, aunque no muy destacado, es cómo hacen que la capa de consulta se convierta en una parte central. Si la gobernanza es datos, entonces la capacidad de consultar esos datos es casi tan importante como crearlos. Esto abre la posibilidad de construir capas de análisis, compilación o incluso meta-gobernanza en diferentes sistemas.
Pero al mismo tiempo, también revela un problema familiar: muy pocas personas realmente construyen sobre la capa de consulta. La mayoría de los desarrolladores solo se preocupan por escribir datos, no por leer y reutilizarlos. Así que, aunque el diseño sea razonable, la adopción sigue siendo una gran incógnita.
También he notado que separan bastante bien entre almacenamiento y verificación. Esto no es nuevo, pero en el contexto de la gobernanza, tiene un significado diferente. Permite que los datos de gobernanza existan independientemente de donde sean verificados. Si una cadena tiene problemas, los datos aún pueden ser verificados en otro lugar. Puede parecer un caso límite, pero si se piensa en el contexto de la gobernanza multi-chain o cross-chain, se convierte en un factor importante.
Sin embargo, sigo siendo un poco cauteloso con toda esta dirección.
No es que el diseño tenga problemas evidentes, sino porque he visto demasiados sistemas que son “correctos desde el punto de vista arquitectónico” pero que nunca se convierten en estándares. La gobernanza es especialmente sensible a los efectos de red: un modelo solo tiene valor cuando suficiente gente lo utiliza. Y convencer a los protocolos de abandonar su sistema de gobernanza actual para pasar a una nueva forma de representar datos no es una tarea sencilla.
Quizás la parte más difícil no radica en construir primitivos como esquemas o atestaciones, sino en hacer que otros acepten que esta es la forma correcta de proceder.
Al principio pensé que estaba leyendo una parte de la documentación bastante “logística”, como operaciones para la gobernanza. Pero cuanto más leía, más me parecía un intento de redefinir la gobernanza desde la perspectiva de los datos — no como algo que ocurre después de que el sistema está en marcha, sino como algo que se integra desde el principio.
No estoy seguro de a dónde llevará este enfoque. Parece razonable a nivel de diseño, pero hay demasiadas variables en cuanto a adopción, estándares y cómo interactúan otros sistemas con él.
Quizás esta sea una de las direcciones que necesitaré seguir un tiempo más, solo para ver si convertir la gobernanza en una forma de datos puede realmente cambiar la forma en que operan los sistemas… o si al final volverá a los patrones antiguos que he visto demasiadas veces.