Gobernanza dual LDO+stETH (continuación)

IntermedioDec 27, 2023
Este artículo presenta la actualización del modelo de gobernanza del proyecto Lido, explica el PAP y cuestiones relacionadas, y analiza cómo ir más allá de la mera votación de tokens de gobernanza.
Gobernanza dual LDO+stETH (continuación)

Esta es la continuación del hilo inicial sobre la doble gobernanza 18. El hilo vinculado contiene un contexto importante, así que léelo si tienes tiempo.

Desde que se propuso la última versión del diseño del mecanismo en esta publicación 5, los contribuyentes del protocolo que trabajan en DG han realizado varias iteraciones para incorporar la retroalimentación recibida y hacer que el mecanismo sea más simple, menos frágil y más eficiente.

Antes de presentar la versión actualizada, permítanme esbozar el problema que intentamos resolver y trazar brevemente la cadena de razonamiento que nos ha llevado a la solución que se propone.

El problema

Actualmente, el código del protocolo Lido y sus parámetros están controlados por Lido DAO mediante la votación del token LDO. El protocolo cobra una tarifa del 5 % de las recompensas de la apuesta y la dirige a la tesorería de DAO (otro 5 % se distribuye a los operadores de nodos que participan en el protocolo).

Si bien los titulares de LDO generalmente deberían estar motivados para mantener el bienestar del protocolo, ya que se refleja en el precio del token LDO, eso no significa necesariamente que los titulares de LDO representen eficientemente a los usuarios del protocolo. Por ejemplo, imaginemos que los titulares de LDO deciden colectivamente aumentar las tarifas del protocolo: si bien esto podría tener un efecto positivo en el bienestar inmediato de los titulares de LDO, va claramente en contra de los intereses de al menos una parte de los usuarios del protocolo.

Esto se puede generalizar como un problema principal-agente (PAP) entre el DAO (el agente) y los usuarios del protocolo (el principal). El problema existe porque los titulares de LDO no tienen exactamente los mismos incentivos que los usuarios.

Además, como destaca Vitalik en su ensayo Más allá de la votación de monedas 9 , el PAP se ve exacerbado por el hecho de que el interés económico en los ingresos del protocolo puede separarse del poder de gobernanza: se podrían sesgar los incentivos de los poseedores de tokens DAO sobornándolos o tome prestado el token de votación de DAO en el mercado abierto para intentar obtener suficiente poder de voto para impulsar un cambio que va en contra de los intereses tanto de la DAO como de los usuarios del protocolo.

La presencia del PAP no es muy buena, pero se puede argumentar que, si los usuarios se dan cuenta de que el agente actual no los representa lo suficientemente bien, siempre pueden abandonar el protocolo y elegir otro agente que esté mejor alineado con sus intereses o incluso decidir eliminarlo. el agente completamente a través de apuestas individuales.

Este es un mecanismo muy importante conocido generalmente como votación presencial. En teoría, debería proteger a los usuarios de los efectos negativos de cualquier desalineación de incentivos entre ellos y la DAO o cualquier ataque a la DAO. Sin embargo, en la práctica y en el caso específico de la apuesta líquida de Ethereum, la eficiencia de la votación presencial es limitada debido a una serie de factores en juego.

El primer factor son los detalles de cómo funciona Ethereum PoS. Para retirar ETH de un validador, hay que esperar hasta que el validador salga por completo y todas las salidas del validador de Ethereum se procesen a través de una única cola con rendimiento limitado. Esto significa que el tiempo necesario para abandonar el protocolo depende de factores externos fuera del protocolo y puede variar en órdenes de magnitud. Esto, a su vez, implica que imponer un bloqueo de tiempo estático a las decisiones de la DAO no puede garantizar que cualquier usuario tenga tiempo suficiente para abandonar el protocolo antes de que la DAO aplique un cambio que no sea de interés para el usuario.

El segundo factor es que una parte importante de los usuarios eligen la apuesta líquida porque quieren redistribuir el capital apostado a otras formas de actividades económicas, lo que da como resultado que los tokens de apuesta líquida (LST) se utilicen ampliamente en DeFi, incluidos los protocolos que requieren tiempo adicional para retirarse (por ejemplo, mercados de préstamos). Esto agrega una dependencia externa más que puede impedir que los usuarios abandonen el protocolo dentro de un período de tiempo predefinido.

El tercer factor surge de la asimetría de información entre la mayoría pasiva y la minoría activa y educada de usuarios: evaluar correctamente todos los riesgos asociados con una decisión de gobernanza particular, incluidos los riesgos de cola, requiere el conocimiento que la mayoría de los usuarios no posee. Comunicar los posibles efectos adversos de una decisión de DAO a través de la capa social requiere tiempo adicional, lo que reduce la probabilidad de que la mayoría pasiva abandone el protocolo antes de que la decisión sea ejecutable.

Lido DAO ha establecido una serie de protocolos de gobernanza para reducir la asimetría de la información (por ejemplo, el marco GOOSE, el grupo de subgobernanza de operadores de nodos, el marco LIP, el compromiso para el número mínimo de auditorías de cualquier cambio de código de la red principal), pero todos son acuerdos de capa social entre los actuales titulares de LDO y, por lo tanto, no pueden proteger de un ataque externo al DAO.

Hacia la solución

La solución definitiva al problema es la minimización de la gobernanza y la eventual osificación del código y los parámetros del protocolo. No hay riesgo de gobernanza si no se gobierna nada.

Minimizar gradualmente el alcance de la gobernanza es algo que los contribuyentes del protocolo ven como una necesidad en los próximos años. Sin embargo, hasta que la especificación de Ethereum se osifique, la capacidad de actualización del código solo se puede reducir hasta cierto punto (p. ej. consulte EIP-7002 5, EIP-7251 6). Además, cualquier código inmutable debe verificarse formalmente a nivel de código de bytes para excluir la posibilidad de que un error del compilador produzca una vulnerabilidad no reparable.

También está la capa de fungibilidad del protocolo que sirve como motor de evaluación de riesgo/recompensa y distribuye ETH entre diferentes subconjuntos de validadores de una manera que equilibra el rendimiento y los riesgos del conjunto de validadores resultante. Los riesgos aquí incluyen los riesgos de cola que crea el conjunto de validadores para la red Ethereum, por ejemplo censurabilidad y riesgos de corte correlacionados. Hay investigaciones en curso (consulte este informe 6 para ver la última iteración) sobre si el protocolo puede estimar estos riesgos con la ayuda de un dispositivo de oráculo no confiable que trae la información requerida a la cadena, pero es un esfuerzo a largo plazo y aún no está claro cómo el resultado deseado puede lograrse en la práctica. Hasta que el protocolo implemente un mecanismo tan poco confiable, tiene que haber cierta gobernanza en la capa de fungibilidad.

Otro área potencial de investigación es buscar formas de introducir una aceptación explícita de nuevas versiones de códigos y conjuntos de parámetros para los titulares e integraciones de stETH. Aún no está claro si se puede hacer sin romper la fungibilidad de LST y la fragmentación de liquidez resultante que, dado que la liquidez es uno de los principales factores que impulsa a los usuarios a LST, destruiría la competitividad del protocolo frente a otros proveedores de participación líquida descentralizados y centralizados. Sin embargo, es una dirección de investigación interesante.

Ahora que hemos establecido que el protocolo tendrá que vivir con algún tipo de gobernanza al menos en el mediano plazo, veamos cómo podemos minimizar <a href="https://notes.ethereum.org/@mikeneuder/magnitude -y-direccion">el riesgos que crea esta gobernanza 1 .

Gobernanza dual

Como se destacó en la primera sección, el problema general se puede descomponer en 1) la presencia del PAP y 2) la eficiencia limitada del voto presencial. Entonces, lo ideal sería introducir algún mecanismo que mejore tanto la alineación entre la DAO y los usuarios del protocolo como la eficiencia de la votación presencial.

Ahí es donde llegamos al diseño de gobernanza dual propuesto. Tiene como objetivo las siguientes mejoras:

  1. Brinde a los interesados una forma de señalar de manera creíble su desacuerdo con la DAO y el compromiso de abandonar el protocolo si la DAO no coopera para resolver el conflicto de incentivos.
  2. Proporcionar un dispositivo de negociación entre los participantes y el DAO.
  3. Introducir un bloqueo de tiempo dinámico extendido en las decisiones de DAO que puede ser activado por una minoría activa de participantes y prolongado a medida que participan más participantes.
  4. Mejore la eficiencia de la votación presencial al permitir que los participantes salgan del protocolo sin estar sujetos a decisiones DAO nuevas y pendientes.

En esta nota se puede encontrar una descripción general del diseño del mecanismo propuesto y algunas ideas para futuras investigaciones sobre la minimización de riesgos de gobernanza: <a href="https://hackmd.io/ @skozin /r17mlW2la"">https://hackmd. io/@skozin/r17mlW2la 37 .

Cabe señalar que los participantes no son la única categoría de usuarios del protocolo; También hay operadores de nodos. Una posible dirección de investigación futura es buscar formas de mejorar también la eficiencia de la votación presencial por parte de los operadores de nodos, por ejemplo. permitir que un subconjunto de participantes y operadores de nodos coordinen un protocolo y una bifurcación DAO al redirigir las credenciales de retiro del validador a un nuevo contrato (actualmente no admitido por la capa de consenso).

Otra dirección de investigación futura es explorar la gobernanza híbrida y sin tokens 2.

Próximos pasos

A partir de aquí, deben suceder varias cosas antes de que se finalice el diseño, lo que dará como resultado una Propuesta de mejora de Lido (LIP) más formal que se presentará para votación de DAO y el documento de Registro de decisiones de arquitectura (ADR) asociado:

  1. Evaluar la solidez del mecanismo propuesto mediante escenarios y modelado de ataques.
  2. Evaluar la practicidad del mecanismo mediante la creación de prototipos del código.
  3. Recopilar los comentarios de la comunidad.

Este hilo tiene como objetivo lograr 3 mientras los contribuyentes del protocolo trabajan en 1 y 2 (ambos están actualmente en progreso), por lo que cualquier comentario es muy apreciado.

Es importante resaltar que, aunque la gobernanza dual es (en mi opinión) un paso importante para reducir los riesgos de gobernanza del protocolo, de ninguna manera es el paso final. Algunas de las ideas para futuras mejoras se pueden encontrar en el documento de diseño del mecanismo vinculado anteriormente, e invito a todos los interesados a discutir esas y otras posibles mejoras publicando un tema en este foro.

Descargo de responsabilidad:

  1. Este artículo se reimprime de [lido]. Todos los derechos de autor pertenecen al autor original [skozin]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
  2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
  3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.

Gobernanza dual LDO+stETH (continuación)

IntermedioDec 27, 2023
Este artículo presenta la actualización del modelo de gobernanza del proyecto Lido, explica el PAP y cuestiones relacionadas, y analiza cómo ir más allá de la mera votación de tokens de gobernanza.
Gobernanza dual LDO+stETH (continuación)

Esta es la continuación del hilo inicial sobre la doble gobernanza 18. El hilo vinculado contiene un contexto importante, así que léelo si tienes tiempo.

Desde que se propuso la última versión del diseño del mecanismo en esta publicación 5, los contribuyentes del protocolo que trabajan en DG han realizado varias iteraciones para incorporar la retroalimentación recibida y hacer que el mecanismo sea más simple, menos frágil y más eficiente.

Antes de presentar la versión actualizada, permítanme esbozar el problema que intentamos resolver y trazar brevemente la cadena de razonamiento que nos ha llevado a la solución que se propone.

El problema

Actualmente, el código del protocolo Lido y sus parámetros están controlados por Lido DAO mediante la votación del token LDO. El protocolo cobra una tarifa del 5 % de las recompensas de la apuesta y la dirige a la tesorería de DAO (otro 5 % se distribuye a los operadores de nodos que participan en el protocolo).

Si bien los titulares de LDO generalmente deberían estar motivados para mantener el bienestar del protocolo, ya que se refleja en el precio del token LDO, eso no significa necesariamente que los titulares de LDO representen eficientemente a los usuarios del protocolo. Por ejemplo, imaginemos que los titulares de LDO deciden colectivamente aumentar las tarifas del protocolo: si bien esto podría tener un efecto positivo en el bienestar inmediato de los titulares de LDO, va claramente en contra de los intereses de al menos una parte de los usuarios del protocolo.

Esto se puede generalizar como un problema principal-agente (PAP) entre el DAO (el agente) y los usuarios del protocolo (el principal). El problema existe porque los titulares de LDO no tienen exactamente los mismos incentivos que los usuarios.

Además, como destaca Vitalik en su ensayo Más allá de la votación de monedas 9 , el PAP se ve exacerbado por el hecho de que el interés económico en los ingresos del protocolo puede separarse del poder de gobernanza: se podrían sesgar los incentivos de los poseedores de tokens DAO sobornándolos o tome prestado el token de votación de DAO en el mercado abierto para intentar obtener suficiente poder de voto para impulsar un cambio que va en contra de los intereses tanto de la DAO como de los usuarios del protocolo.

La presencia del PAP no es muy buena, pero se puede argumentar que, si los usuarios se dan cuenta de que el agente actual no los representa lo suficientemente bien, siempre pueden abandonar el protocolo y elegir otro agente que esté mejor alineado con sus intereses o incluso decidir eliminarlo. el agente completamente a través de apuestas individuales.

Este es un mecanismo muy importante conocido generalmente como votación presencial. En teoría, debería proteger a los usuarios de los efectos negativos de cualquier desalineación de incentivos entre ellos y la DAO o cualquier ataque a la DAO. Sin embargo, en la práctica y en el caso específico de la apuesta líquida de Ethereum, la eficiencia de la votación presencial es limitada debido a una serie de factores en juego.

El primer factor son los detalles de cómo funciona Ethereum PoS. Para retirar ETH de un validador, hay que esperar hasta que el validador salga por completo y todas las salidas del validador de Ethereum se procesen a través de una única cola con rendimiento limitado. Esto significa que el tiempo necesario para abandonar el protocolo depende de factores externos fuera del protocolo y puede variar en órdenes de magnitud. Esto, a su vez, implica que imponer un bloqueo de tiempo estático a las decisiones de la DAO no puede garantizar que cualquier usuario tenga tiempo suficiente para abandonar el protocolo antes de que la DAO aplique un cambio que no sea de interés para el usuario.

El segundo factor es que una parte importante de los usuarios eligen la apuesta líquida porque quieren redistribuir el capital apostado a otras formas de actividades económicas, lo que da como resultado que los tokens de apuesta líquida (LST) se utilicen ampliamente en DeFi, incluidos los protocolos que requieren tiempo adicional para retirarse (por ejemplo, mercados de préstamos). Esto agrega una dependencia externa más que puede impedir que los usuarios abandonen el protocolo dentro de un período de tiempo predefinido.

El tercer factor surge de la asimetría de información entre la mayoría pasiva y la minoría activa y educada de usuarios: evaluar correctamente todos los riesgos asociados con una decisión de gobernanza particular, incluidos los riesgos de cola, requiere el conocimiento que la mayoría de los usuarios no posee. Comunicar los posibles efectos adversos de una decisión de DAO a través de la capa social requiere tiempo adicional, lo que reduce la probabilidad de que la mayoría pasiva abandone el protocolo antes de que la decisión sea ejecutable.

Lido DAO ha establecido una serie de protocolos de gobernanza para reducir la asimetría de la información (por ejemplo, el marco GOOSE, el grupo de subgobernanza de operadores de nodos, el marco LIP, el compromiso para el número mínimo de auditorías de cualquier cambio de código de la red principal), pero todos son acuerdos de capa social entre los actuales titulares de LDO y, por lo tanto, no pueden proteger de un ataque externo al DAO.

Hacia la solución

La solución definitiva al problema es la minimización de la gobernanza y la eventual osificación del código y los parámetros del protocolo. No hay riesgo de gobernanza si no se gobierna nada.

Minimizar gradualmente el alcance de la gobernanza es algo que los contribuyentes del protocolo ven como una necesidad en los próximos años. Sin embargo, hasta que la especificación de Ethereum se osifique, la capacidad de actualización del código solo se puede reducir hasta cierto punto (p. ej. consulte EIP-7002 5, EIP-7251 6). Además, cualquier código inmutable debe verificarse formalmente a nivel de código de bytes para excluir la posibilidad de que un error del compilador produzca una vulnerabilidad no reparable.

También está la capa de fungibilidad del protocolo que sirve como motor de evaluación de riesgo/recompensa y distribuye ETH entre diferentes subconjuntos de validadores de una manera que equilibra el rendimiento y los riesgos del conjunto de validadores resultante. Los riesgos aquí incluyen los riesgos de cola que crea el conjunto de validadores para la red Ethereum, por ejemplo censurabilidad y riesgos de corte correlacionados. Hay investigaciones en curso (consulte este informe 6 para ver la última iteración) sobre si el protocolo puede estimar estos riesgos con la ayuda de un dispositivo de oráculo no confiable que trae la información requerida a la cadena, pero es un esfuerzo a largo plazo y aún no está claro cómo el resultado deseado puede lograrse en la práctica. Hasta que el protocolo implemente un mecanismo tan poco confiable, tiene que haber cierta gobernanza en la capa de fungibilidad.

Otro área potencial de investigación es buscar formas de introducir una aceptación explícita de nuevas versiones de códigos y conjuntos de parámetros para los titulares e integraciones de stETH. Aún no está claro si se puede hacer sin romper la fungibilidad de LST y la fragmentación de liquidez resultante que, dado que la liquidez es uno de los principales factores que impulsa a los usuarios a LST, destruiría la competitividad del protocolo frente a otros proveedores de participación líquida descentralizados y centralizados. Sin embargo, es una dirección de investigación interesante.

Ahora que hemos establecido que el protocolo tendrá que vivir con algún tipo de gobernanza al menos en el mediano plazo, veamos cómo podemos minimizar <a href="https://notes.ethereum.org/@mikeneuder/magnitude -y-direccion">el riesgos que crea esta gobernanza 1 .

Gobernanza dual

Como se destacó en la primera sección, el problema general se puede descomponer en 1) la presencia del PAP y 2) la eficiencia limitada del voto presencial. Entonces, lo ideal sería introducir algún mecanismo que mejore tanto la alineación entre la DAO y los usuarios del protocolo como la eficiencia de la votación presencial.

Ahí es donde llegamos al diseño de gobernanza dual propuesto. Tiene como objetivo las siguientes mejoras:

  1. Brinde a los interesados una forma de señalar de manera creíble su desacuerdo con la DAO y el compromiso de abandonar el protocolo si la DAO no coopera para resolver el conflicto de incentivos.
  2. Proporcionar un dispositivo de negociación entre los participantes y el DAO.
  3. Introducir un bloqueo de tiempo dinámico extendido en las decisiones de DAO que puede ser activado por una minoría activa de participantes y prolongado a medida que participan más participantes.
  4. Mejore la eficiencia de la votación presencial al permitir que los participantes salgan del protocolo sin estar sujetos a decisiones DAO nuevas y pendientes.

En esta nota se puede encontrar una descripción general del diseño del mecanismo propuesto y algunas ideas para futuras investigaciones sobre la minimización de riesgos de gobernanza: <a href="https://hackmd.io/ @skozin /r17mlW2la"">https://hackmd. io/@skozin/r17mlW2la 37 .

Cabe señalar que los participantes no son la única categoría de usuarios del protocolo; También hay operadores de nodos. Una posible dirección de investigación futura es buscar formas de mejorar también la eficiencia de la votación presencial por parte de los operadores de nodos, por ejemplo. permitir que un subconjunto de participantes y operadores de nodos coordinen un protocolo y una bifurcación DAO al redirigir las credenciales de retiro del validador a un nuevo contrato (actualmente no admitido por la capa de consenso).

Otra dirección de investigación futura es explorar la gobernanza híbrida y sin tokens 2.

Próximos pasos

A partir de aquí, deben suceder varias cosas antes de que se finalice el diseño, lo que dará como resultado una Propuesta de mejora de Lido (LIP) más formal que se presentará para votación de DAO y el documento de Registro de decisiones de arquitectura (ADR) asociado:

  1. Evaluar la solidez del mecanismo propuesto mediante escenarios y modelado de ataques.
  2. Evaluar la practicidad del mecanismo mediante la creación de prototipos del código.
  3. Recopilar los comentarios de la comunidad.

Este hilo tiene como objetivo lograr 3 mientras los contribuyentes del protocolo trabajan en 1 y 2 (ambos están actualmente en progreso), por lo que cualquier comentario es muy apreciado.

Es importante resaltar que, aunque la gobernanza dual es (en mi opinión) un paso importante para reducir los riesgos de gobernanza del protocolo, de ninguna manera es el paso final. Algunas de las ideas para futuras mejoras se pueden encontrar en el documento de diseño del mecanismo vinculado anteriormente, e invito a todos los interesados a discutir esas y otras posibles mejoras publicando un tema en este foro.

Descargo de responsabilidad:

  1. Este artículo se reimprime de [lido]. Todos los derechos de autor pertenecen al autor original [skozin]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
  2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
  3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.
Empieza ahora
¡Regístrate y recibe un bono de
$100
!
Crea tu cuenta