Última investigación de Vitalik: ¿Qué cambios necesitan los protocolos LSDFi y la liquidez para mejorar la descentralización y reducir la sobrecarga de consenso?

Este artículo se centrará principalmente en los problemas actuales de los protocolos LSDFi y los pools de liquidez, en particular el riesgo de centralización de los operadores de nodos y la carga de consenso innecesaria.

Autor:Vitalik Buterin

Traducción: bayemon.eth, ChainCatcher

El estado actual del desarrollo de Ethereum puede describirse como uno que incluye una gran cantidad de staking de dos niveles (two-tiered staking), donde este término se refiere a un modelo de staking con dos tipos de participantes.

• Operador de nodo (Node Operator): opera nodos y utiliza su reputación y cierta cantidad de capital propio como garantía.
• Delegador (Delegator): los delegadores apuestan una cantidad determinada de Ethereum, sin un mínimo, y no hay restricciones adicionales sobre otras formas de participación fuera de la garantía.

Este nuevo staking de dos niveles surge a través de pools de staking que proporcionan tokens de staking líquidos (LST) a gran escala. (Rocket Pool y Lido siguen este modelo).

Sin embargo, el staking de dos niveles actual presenta dos defectos:

• Riesgo de centralización de los operadores de nodos: en todos los pools de staking actuales, el mecanismo de selección de operadores de nodos sigue siendo excesivamente centralizado.
• Carga de consenso innecesaria: Ethereum L1 debe verificar alrededor de 800,000 firmas por cada Epoch, lo que representa una carga enorme para un solo slot. Además, dado que los pools de staking líquidos requieren más capital, la red en sí no se beneficia plenamente de esta carga. Por lo tanto, si la red Ethereum puede lograr una descentralización y seguridad razonables sin requerir que cada staker firme en cada slot, la comunidad podría adoptar este tipo de soluciones y reducir efectivamente el número de firmas por slot.

Este artículo describirá soluciones para los dos problemas anteriores, partiendo de la hipótesis de que la mayoría del capital está en manos de quienes no desean gestionar personalmente los nodos de staking en la forma actual, firmar información en cada slot, bloquear depósitos y redistribuir fondos a quienes sufren recortes. En este caso, ¿qué papel pueden desempeñar estas personas para seguir contribuyendo de manera significativa a la descentralización y seguridad de la red?

¿Cómo funciona actualmente el staking de dos niveles?

Actualmente, los dos pools de staking más populares son Lido y RocketPool. En el caso de Lido, las dos partes participantes son:

• Operadores de nodo: elegidos por votación del Lido DAO, lo que significa que en realidad son seleccionados por los poseedores de LDO. Cuando alguien deposita ETH en el sistema de contratos inteligentes de Lido, se crea stETH, que los operadores de nodo pueden usar para el staking (pero debido a que los certificados de retiro están vinculados a la dirección del contrato inteligente, los operadores no pueden retirar libremente).
• Delegadores: cuando alguien deposita ETH en el sistema de contratos inteligentes de Lido, se genera stETH, que los operadores de nodo pueden usar para el staking (pero, de nuevo, los operadores no pueden retirar libremente debido a la vinculación de los certificados de retiro con la dirección del contrato inteligente).

En el caso de Rocket Pool, las partes son:

• Operadores de nodo: cualquiera puede convertirse en operador de nodo simplemente depositando 8 ETH y una cantidad determinada de tokens RPL.
• Delegadores: cuando alguien deposita ETH en el sistema de contratos inteligentes de Rocket Pool, se genera rETH, que los operadores de nodo pueden usar para el staking (también aquí, los operadores no pueden retirar libremente debido a la vinculación de los certificados de retiro con la dirección del contrato inteligente).

El papel de los delegadores

En estos sistemas (o en nuevos sistemas habilitados por posibles cambios de protocolo en el futuro), surge una cuestión clave: ¿cuál es el propósito de establecer delegadores desde la perspectiva del protocolo?

Para comprender el significado profundo de esta pregunta, primero pensemos en el cambio de protocolo mencionado en el post, es decir, limitar la penalización por recorte a 2ETH. Rocket Pool también reduciría el monto de staking de los operadores de nodo a 2ETH, y la cuota de mercado de Rocket Pool aumentaría al 100% (para los stakers y poseedores de ETH, a medida que rETH se vuelve libre de riesgo, casi todos los poseedores de ETH se convertirían en poseedores de rETH o en operadores de nodo).

Supongamos que la tasa de retorno para los poseedores de rETH es del 3% (incluyendo recompensas internas del protocolo y tarifas de prioridad + MEV), y la tasa de retorno para los operadores de nodo es del 4%. También supongamos que el suministro total de ETH es de 100 millones.

El resultado del cálculo es el siguiente. Para evitar el cálculo de interés compuesto, calcularemos los rendimientos en base diaria:

Ahora, supongamos que Rocket Pool no existe, entonces el depósito mínimo para cada staker se reduce a 2 ETH, el límite total de liquidez es de 6.25 millones de ETH y la tasa de retorno de los operadores de nodo cae al 1%. Calculemos de nuevo:

Consideremos ambas situaciones desde el punto de vista del coste de ataque. En el primer caso, un atacante no se registraría como delegador, ya que los delegadores en esencia no tienen ningún derecho de retiro, por lo que no tiene sentido. Por lo tanto, usarían todo su ETH para hacer staking y convertirse en operadores de nodo. Para alcanzar 1/3 del total de staking, necesitarían invertir 2.08 millones de Ethereum (lo cual, siendo justos, sigue siendo una cifra considerable). En el segundo caso, el atacante solo necesita invertir capital, y para alcanzar 1/3 del total del pool de staking, también necesitaría invertir 2.08 millones de Ethereum.

Desde la perspectiva de la economía del staking y el coste de ataque, el resultado final en ambos casos es exactamente el mismo. La cuota del suministro total de ETH en manos de los operadores de nodo aumenta un 0.00256% diario, mientras que la de los no operadores de nodo disminuye un 0.00017% diario. El coste de ataque es de 2.08 millones de ETH. Por lo tanto, en este modelo, los delegadores parecen una máquina de Rube Goldberg sin sentido, y una comunidad racional incluso preferiría eliminar al intermediario, reducir drásticamente las recompensas de staking y limitar el total de ETH en staking a 6.25 millones.

Por supuesto, este artículo no aboga por reducir las recompensas de staking a una cuarta parte ni por fijar el límite total de staking en 6.25 millones. Por el contrario, la opinión aquí es que un sistema de staking bien diseñado debería tener una característica clave: los delegadores deben asumir responsabilidades importantes en todo el sistema. Además, si los delegadores actúan correctamente en gran medida debido a la presión de la comunidad y el altruismo, eso está bien; después de todo, esa es la principal fuerza que impulsa hoy la adopción de soluciones de staking descentralizadas y seguras.

Las responsabilidades de los delegadores

Si los delegadores pueden desempeñar un papel significativo en el sistema de staking, ¿cuál podría ser ese papel?

Creo que hay dos tipos de respuestas:

• Elección de delegadores: los delegadores pueden elegir a qué operadores de nodo delegar sus intereses. El "peso" de un operador de nodo en el mecanismo de consenso es proporcional al total de staking delegado a ellos. Actualmente, el mecanismo de elección de delegadores es limitado, es decir, los poseedores de rETH o stETH pueden retirar su ETH y cambiar a otro pool, pero la disponibilidad real de la elección de delegadores podría mejorarse mucho.
• Participación en el mecanismo de consenso: los delegadores pueden optar por desempeñar un papel en el mecanismo de consenso, con una responsabilidad más ligera que la suscripción total y sin largos períodos de salida ni riesgo de recorte, pero aún así pueden servir como contrapeso a los operadores de nodo.

Mejorar el poder de elección de los delegadores

Hay tres formas de mejorar el poder de elección de los delegadores:

• Mejorar las herramientas de votación dentro del pool
• Aumentar la competencia entre pools
• Fijar el poder de representación

Actualmente, votar dentro del pool no es realmente práctico: en Rocket Pool, cualquiera puede ser operador de nodo; en Lido, la votación la deciden los poseedores de LDO, no los de ETH. Lido ha propuesto una gobernanza dual LDO + stETH, donde pueden activar un mecanismo de protección para bloquear nuevas votaciones y evitar la adición o eliminación de operadores de nodo, lo que en cierta medida da voz a los poseedores de stETH. Sin embargo, este poder sigue siendo limitado y podría ser mucho más fuerte.

La competencia entre pools ya existe hoy, pero es relativamente débil. El principal desafío es que los tokens de staking de pools más pequeños tienen menor liquidez, es más difícil ganarse la confianza y tienen menos apoyo de aplicaciones.

Podemos mejorar los dos primeros problemas limitando la cantidad de penalización a una cantidad pequeña, por ejemplo, 2 o 4 ETH. Luego, el ETH restante puede depositarse y retirarse de inmediato de forma segura, permitiendo que el intercambio bidireccional siga siendo válido para pools de staking pequeños. Podemos mejorar el tercer problema creando un contrato de emisión total para gestionar los LST (similar a ERC-4337 y ERC-6900 para wallets), de modo que podamos garantizar que cualquier token de staking emitido a través de ese contrato sea seguro.

Actualmente, no existe poder de representación fijo en el protocolo, pero este tipo de situación podría darse en el futuro. Implicaría una lógica similar a las ideas anteriores, pero implementada a nivel de protocolo. Para conocer las ventajas y desventajas de fijar cosas, consulte este artículo.

Estas ideas son mejoras sobre el estado actual, pero las ventajas que pueden ofrecer son limitadas. La gobernanza por votación de tokens tiene problemas, y en última instancia, cualquier forma de elección de delegador no incentivada es solo una forma de votación por tokens; esta siempre ha sido mi principal objeción a la prueba de participación delegada. Por lo tanto, también vale la pena considerar formas de participación en el consenso más sólidas.

Participación en el consenso

Incluso sin considerar los problemas actuales del staking líquido, los métodos actuales de staking independiente también tienen limitaciones. Supongamos que se utiliza single-slot finality; en el mejor de los casos, cada slot podría manejar entre 100,000 y 1,000,000 de firmas BLS. Incluso usando SNARKs recursivos para agregar firmas, para la trazabilidad de las firmas, cada una debe tener un campo de bits de participante. Si Ethereum se convierte en una red a escala global, incluso el almacenamiento completamente descentralizado de campos de bits no es suficiente: 16 MB por slot solo admiten unos 64 millones de stakers.

Desde este punto de vista, tiene sentido dividir el staking en una capa de mayor complejidad y posibilidad de recorte, y una capa de menor complejidad. La capa de alta complejidad se activa en cada slot, pero puede tener solo 10,000 participantes, mientras que la de baja complejidad solo se activa ocasionalmente. La capa de baja complejidad puede estar completamente exenta de recortes, o se puede asignar aleatoriamente la oportunidad de participar y ser objeto de recorte durante algunos slots.

En la práctica, esto puede lograrse aumentando el límite superior de saldo de los validadores y luego aumentando el umbral de saldo (por ejemplo, 2048 ETH) para determinar qué validadores existentes entran en la capa de mayor o menor complejidad.

A continuación, algunas sugerencias sobre cómo podrían funcionar estos roles de staking de bajo monto:

• En cada slot, se seleccionan aleatoriamente 10,000 pequeños stakers que pueden firmar lo que consideren que representa el contenido de ese slot. Se utiliza a estos pequeños stakers como entrada para ejecutar la regla de selección de bifurcación LMD GHOST. Si la selección de bifurcación impulsada por los pequeños stakers y la impulsada por los operadores de nodo difieren, el cliente del usuario no aceptará ningún bloque como final y mostrará un error. Esto obliga a la comunidad a intervenir para resolver la situación.
• Los delegadores pueden enviar transacciones para anunciar a la red que están en línea y dispuestos a actuar como pequeños stakers durante la próxima hora. Los mensajes enviados por los nodos (bloques o pruebas) requieren la firma tanto del nodo como de un delegador seleccionado aleatoriamente para confirmar el mensaje del nodo.
• Los delegadores pueden enviar transacciones para anunciar a la red que están en línea y dispuestos a actuar como pequeños stakers durante la próxima hora. En cada época, se seleccionan 10 delegadores aleatorios como proveedores de listas de inclusión (inclusion list provider) y 10,000 delegadores más como votantes. Estos se seleccionan antes del slot k y se les da una ventana de k slots para publicar en la cadena un mensaje confirmando que están en línea. Cada proveedor de lista de inclusión seleccionado que confirme puede publicar una lista de inclusión; para cada lista de inclusión, debe incluirse la transacción de esa lista o el voto de al menos 1 votante seleccionado que indique que la lista no está disponible; de lo contrario, el bloque se considera inválido.

Estos pequeños nodos de staking tienen en común que no necesitan participar activamente en cada slot, e incluso pueden hacer todo el trabajo como nodos ligeros. Por lo tanto, el despliegue de nodos solo requiere verificar la capa de consenso, y los operadores de nodo pueden hacerlo a través de aplicaciones o extensiones de navegador, que en su mayoría son pasivas y requieren muy poco en términos de computación, hardware o conocimientos técnicos, ni siquiera tecnologías avanzadas como ZK-EVM.

Estos "pequeños roles" también comparten un objetivo común: evitar que una mayoría del 51% de operadores de nodo censuren transacciones. El primer y segundo método también evitan que la mayoría participe en la reversión de la finalidad. El tercero se centra más directamente en la censura, pero es más susceptible a la selección de la mayoría de operadores de nodo.

Estas ideas están escritas desde la perspectiva de implementar soluciones de staking de dos niveles en el protocolo, pero también pueden implementarse como funciones de pools de staking. A continuación, algunas ideas de implementación concretas:

1. Desde la perspectiva del protocolo, cada validador puede establecer dos claves de staking: una clave de staking persistente P y una dirección de Ethereum vinculada que puede ser llamada, y emitir una clave de staking rápida Q. El seguimiento de la información de firma de selección de bifurcación por parte del nodo se representa con P, y la información firmada se representa con Q. Si los resultados almacenados de PQ no coinciden, no se acepta la finalidad de ningún bloque, y el pool de liquidez se encarga de seleccionar representantes aleatoriamente.
2. El protocolo puede permanecer básicamente igual, pero la clave pública del validador para ese periodo se establecerá como P+Q. Tenga en cuenta que, para el recorte, dos mensajes sujetos a recorte pueden tener diferentes claves Q, pero tendrán la misma clave P; el diseño de recorte debe manejar esta situación.
3. La clave Q solo puede usarse en el protocolo para firmar y verificar listas de inclusión en los bloques. En este caso, Q puede ser un contrato inteligente en lugar de una sola clave, por lo que el pool de staking puede usarlo para implementar una lógica de votación más compleja, aceptando listas de inclusión de proveedores seleccionados aleatoriamente o suficientes votos que indiquen que la lista de inclusión no está disponible.

Conclusión

Si se implementa correctamente, un ajuste fino en el diseño de la prueba de participación puede resolver dos problemas a la vez:

• Ofrecer a quienes hoy no tienen los recursos o la capacidad para realizar prueba de participación independiente la oportunidad de participar en la prueba de participación, conservando más poder en sus manos: incluyendo (i) el poder de elegir qué nodos apoyar y (ii) la capacidad de participar activamente en el consenso de una manera más ligera pero aún significativa que operar un nodo completo de prueba de participación. No todos los participantes elegirán una o ambas opciones, pero cualquier participante que elija una o ambas tendrá una mejora significativa respecto a la situación actual.
• Reducir el número de firmas que la capa de consenso de Ethereum necesita procesar en cada slot, incluso bajo un sistema de finalidad de slot único, reduciéndolo a una cantidad pequeña como 10,000. Esto también ayudará a la descentralización, facilitando que cualquiera ejecute un nodo validador.

Para estas soluciones, se pueden encontrar métodos para abordar los problemas en diferentes niveles de abstracción: los permisos otorgados a los usuarios dentro del protocolo de prueba de participación, la elección de los usuarios entre protocolos de prueba de participación y el establecimiento dentro del protocolo. Esta elección debe considerarse cuidadosamente, y generalmente es mejor optar por el establecimiento mínimo viable para minimizar la complejidad del protocolo y el grado de cambio en la economía del protocolo, al tiempo que se logran los objetivos deseados.

Agradecimientos especiales a Mike Neuder, Justin Drake y otros por sus comentarios y revisión. Véase también: artículos anteriores sobre temas similares de Mike Neuder, Dankrad Feist y arixon.eth.