Autor: Vitalik, fundador de Ethereum; Compilado por: Deng Tong, Jinse Caijing
Nota: Este artículo es la tercera parte de la serie "Desarrollo futuro del protocolo Ethereum" publicada recientemente por Vitalik, el fundador de Ethereum, titulada "Futuros posibles del protocolo Ethereum, parte 3: La Plaga". La segunda parte se puede ver en Jinse Caijing "Vitalik: ¿Cómo debería evolucionar el protocolo Ethereum en la fase Surge?", la primera parte se puede ver en "¿Qué más se puede mejorar en el PoS de Ethereum?" A continuación se presenta el texto completo de la tercera parte:
Uno de los mayores riesgos que enfrenta Ethereum L1 es la centralización de la prueba de participación debido a la presión económica. Si existe economías de escala al participar en el mecanismo central de prueba de participación, esto naturalmente conducirá a que grandes interesados dominen, mientras que los pequeños interesados se retiren para unirse a grandes grupos de minería. Esto aumenta el riesgo de ataques del 51%, revisión de transacciones y otras crisis. Además del riesgo de centralización, también existe el riesgo de extracción de valor: un pequeño número de personas obtiene el valor que originalmente fluiría hacia los usuarios de Ethereum.
El año pasado, nuestra comprensión de estos riesgos aumentó significativamente. Como es bien sabido, este riesgo existe en dos lugares clave: (i) la construcción de bloques, y (ii) las regulaciones de capital de staking. Los participantes más grandes pueden ejecutar algoritmos más complejos ("extracción de MEV") para generar bloques, lo que les proporciona mayores ingresos por bloque. Los grandes participantes también pueden abordar de manera más efectiva la inconveniencia de tener fondos bloqueados al liberar fondos como tokens de staking líquido (LST) a otros. Además de los problemas directos entre pequeños y grandes stakers, también existe la cuestión de si (o si habrá) un staking excesivo de ETH.
Hoja de ruta de Scourge 2023
Este año, la construcción de la blockchain ha logrado avances significativos, siendo lo más destacado la fusión de "lista de inclusión del comité más algunas soluciones de ordenamiento específicas" como solución ideal, así como una importante investigación sobre la economía de la prueba de participación, incluyendo modelos de staking de dos capas y la reducción de la emisión para limitar el porcentaje de ETH en staking.
Los Objetivos Clave de La Plaga
Minimizar el riesgo de centralización en la capa de staking de Ethereum (especialmente en la construcción de bloques y el suministro de capital, también conocidos como MEV y pools de staking)
Minimizar el riesgo de extraer excesivo valor de los usuarios.
Este artículo se divide en tres partes
Reparar la construcción del bloque (Fixing the block construction pipeline)
Arreglando la economía de staking
Soluciones de capa de aplicación (Application-layer solutions)
Reparar la construcción de bloques
¿Qué problema queremos resolver?
Hoy en día, la construcción de bloques de Ethereum se lleva a cabo principalmente a través de la separación del propser-builder fuera del protocolo de MEVBoost. Cuando los validadores tienen la oportunidad de proponer un bloque, delegan el trabajo de seleccionar el contenido del bloque a participantes especializados llamados constructores. La tarea de seleccionar el contenido del bloque que maximiza los ingresos es intensiva en economías de escala: se requieren algoritmos especializados para determinar qué transacciones incluir, con el fin de extraer el máximo valor posible de las herramientas financieras en la cadena y las transacciones de los usuarios que interactúan con ellas (esto se conoce como "extracción de MEV"). Los validadores se enfrentan a una tarea de "tubería tonta" relativamente ligera en economías de escala, que consiste en escuchar las pujas y aceptar la puja más alta, así como otras responsabilidades como la prueba.
Gráfico programático de lo que está haciendo MEVBoost: los constructores dedicados asumen las tareas rojas, los interesados asumen las tareas azules.
Hay varias versiones, incluyendo "Separación de Proponentes y Constructores" (PBS) y "Separación de Probadores y Proponentes" (APS). La diferencia entre ellas se relaciona con los detalles finos, es decir, qué responsabilidades asume cada uno de los dos participantes: en términos generales, en PBS, los validadores todavía proponen bloques, pero reciben la carga útil del constructor, mientras que en APS, toda la ranura se convierte en responsabilidad del constructor. Recientemente, APS ha sido más favorecido que PBS, ya que reduce aún más el incentivo para que el proponente y el constructor estén en el mismo lugar. Tenga en cuenta que APS solo se aplica a bloques de ejecución que contienen transacciones; los bloques de consenso que contienen datos relacionados con la prueba de participación (por ejemplo, pruebas) seguirán siendo distribuidos aleatoriamente entre los validadores.
Esta separación de poderes ayuda a mantener la descentralización de los validadores, pero tiene un costo importante: los participantes que realizan tareas "especializadas" pueden volverse muy centralizados. Esta es la construcción de bloques de Ethereum hoy.
Dos participantes están eligiendo el contenido de aproximadamente el 88% de los bloques de Ethereum. ¿Qué pasa si estos dos participantes deciden revisar las transacciones? La respuesta no es tan mala como parece: no pueden reorganizar los bloques, por lo que no necesitas en absoluto un 51% de revisión para evitar que las transacciones sean incluidas: necesitas un 100%. Con un mecanismo de revisión del 88%, los usuarios deben esperar en promedio 9 ranuras (técnicamente, un promedio de 114 segundos, en lugar de 6 segundos). Para ciertos casos de uso, esperar algunas transacciones dos minutos o incluso cinco minutos está bien. Pero para otros casos de uso, como en el caso de liquidaciones DeFi, incluso la capacidad de retrasar la inclusión de las transacciones de otros por unos pocos bloques representa un riesgo significativo de manipulación del mercado.
Las estrategias que los constructores de bloques pueden utilizar para maximizar ingresos también pueden tener otros efectos negativos para los usuarios. Un "ataque de sándwich" puede causar que los usuarios que realicen transacciones de tokens sufran pérdidas significativas debido al deslizamiento. Para colapsar estas transacciones introducidas por los ataques, se han incrementado los precios de Gas para otros usuarios.
¿Qué es y cómo funciona?
La solución líder es desglosar aún más la tarea de producción de bloques: delegaremos la tarea de seleccionar transacciones a los proponentes (es decir, los stakers), mientras que los constructores solo podrán elegir el orden e insertar algunas de sus propias transacciones. Esto es lo que quiere lograr la lista de inclusión.
En el tiempo T, un validador seleccionado al azar crea una lista de transacciones, es decir, una lista de transacciones que son válidas en el estado actual de la cadena de bloques en ese momento. En el tiempo T+1, el constructor del bloque (que puede haber sido seleccionado previamente a través de un mecanismo de subasta dentro del protocolo) crea un bloque. Este bloque debe contener cada transacción de la lista, pero pueden elegir el orden y pueden agregar sus propias transacciones.
La propuesta de Lista de Inclusión Obligatoria de Selección de Fork (FOCIL) implica un comité compuesto por múltiples creadores de listas de inclusión para cada bloque. Para retrasar una transacción un bloque, k de los creadores de listas de inclusión entre k (por ejemplo, k = 16) deben revisar la transacción. FOCIL, combinado con el proponente final seleccionado a través de una subasta, necesita incluir la lista de inclusión, pero puede reordenarse y agregar nuevas transacciones, comúnmente conocido como “FOCIL + APS”.
Otra forma de resolver este problema es mediante múltiples proponentes concurrentes (MCP), como BRAID. BRAID intenta evitar dividir el rol de proponente de bloques en partes de baja y alta economía de escala, y en su lugar intenta asignar el proceso de producción de bloques a muchos participantes, de modo que cada proponente solo necesite tener un nivel moderado de complejidad para maximizar sus ingresos. El funcionamiento de MCP es permitir que k proponentes paralelos generen listas de transacciones, y luego utilizar un algoritmo determinista (por ejemplo, ordenar por tarifas de mayor a menor) para seleccionar el orden.
BRAID no busca implementar el software predeterminado de los proponentes de bloques de tubería tonta como el objetivo más adecuado. Las dos razones fáciles de entender por las que no puede hacerlo son:
Ataque de arbitraje de atrasados: Supongamos que el tiempo promedio de presentación del proponente es T, y que el último momento en que podrías presentar y aún ser incluido es aproximadamente T+1. Ahora, supongamos que en un intercambio centralizado, el precio de ETH/USDC sube de 2500 dólares a 2502 dólares entre T y T+1. El proponente puede esperar un segundo más y luego agregar transacciones adicionales para realizar arbitraje en el intercambio descentralizado en la cadena, obteniendo hasta 2 dólares de ganancias por ETH. Los proponentes experimentados con una buena conexión a la red son más capaces de hacer esto.
Flujo de órdenes exclusivo: Los usuarios tienen el incentivo de enviar sus transacciones directamente a un único proponente, para minimizar su vulnerabilidad a transacciones front-running y otros ataques. Los proponentes experimentados tienen una ventaja, ya que pueden establecer infraestructura para aceptar esas transacciones directamente de los usuarios, y cuentan con una reputación más sólida, por lo que los usuarios que envían transacciones a ellos pueden confiar en que el proponente no traicionará y realizará transacciones front-running (esto puede mitigar el uso de hardware confiable, pero el hardware confiable tiene sus propias suposiciones de confianza).
En BRAID, los testigos aún pueden separarse y funcionar como una función de tubería tonta.
Además de estos dos extremos, existe una serie de posibles diseños que se encuentran entre ambos. Por ejemplo, puede subastar roles que solo tienen el derecho de adjuntarse a los bloques, sin derecho a reordenar o anteponer. Incluso puede permitirles adjuntarse o anteponerse, pero no insertar en medio o reordenar. El atractivo de estas técnicas radica en que los ganadores del mercado de subastas pueden estar muy concentrados, por lo que reducir su autoridad tiene muchos beneficios.
encriptación de la memoria
Una tecnología que es crucial para implementar con éxito muchos de estos diseños (específicamente, las versiones BRAID o APS, que tienen estrictas limitaciones sobre la funcionalidad de subastas) es el pool de memoria cifrada. El pool de memoria cifrada es una técnica en la que los usuarios transmiten sus transacciones en forma cifrada, adjuntando algún tipo de prueba de validez, y las transacciones se incluyen en el bloque de forma cifrada, sin que el constructor del bloque conozca su contenido. El contenido de la transacción se publica más tarde.
El principal desafío para implementar un pool de memoria criptográfica es proponer un diseño que asegure que todas las transacciones se revelen más tarde: un simple esquema de "presentar y revelar" no funciona, ya que si la revelación es voluntaria, la elección de revelar o no revelar en sí misma tiene un efecto de "último impulsor" sobre los bloques que pueden ser explotados. Las dos tecnologías principales son (i) descifrado umbral y (ii) cifrado retrasado, que es un primitivo estrechamente relacionado con la función de retraso verificable (VDF).
¿Qué conexiones hay con la investigación existente?
Explicación de la centralización de MEV y constructores:
MEVBoost：
Enshrined PBS (soluciones propuestas temprano para estos problemas):
Lista de lecturas relacionadas con la lista de inclusión de Mike Neuder:
Lista de EIP incluida:
FOCIL：
Demostración de BRAID de Max Resnick:
“La prioridad es lo que necesitas”, autor: Dan Robinson:
Sobre la herramienta y el protocolo de múltiples proponentes:
VDFResearch.org：
Funciones de retardo verificables y ataques (enfoque en la configuración RANDAO, pero también aplicable a la memoria criptográfica):
Captura de boletos de ejecución MEV y descentralización:
APS centralizado:
Listas de múltiples MEV y contenido:
¿Qué más se necesita hacer, qué se debe sopesar?
Podemos considerar todas las opciones anteriores como diferentes formas de dividir los derechos de participación en el stake, ordenadas desde economías de escala más bajas ("dumb-pipe") hasta economías de escala más altas ("especialización amigable"). Antes de 2021, todos estos derechos estaban agrupados en un solo participante:
El problema central es: cualquier poder significativo que aún esté en manos de los interesados, podría convertirse en poder "relacionado con MEV". Deseamos que un grupo de participantes altamente descentralizados posea tanto poder como sea posible; esto significa (i) otorgar una gran cantidad de poder a los interesados, y (ii) asegurar que los interesados estén lo más descentralizados posible, lo que significa que casi no tienen incentivos de integración impulsados por economías de escala. Esta es una tensión difícil de manejar.
Un desafío especial es el MEV de múltiples bloques: en ciertos casos, si el ganador de la subasta de ejecución captura múltiples ranuras consecutivas y no se permite realizar ninguna transacción relacionada con el MEV en bloques fuera del último bloque que controlan, pueden ganar más dinero. Si una lista de inclusión los obliga a hacer esto, entonces pueden intentar eludirla al no publicar ningún bloque en absoluto durante esos períodos de tiempo. Se pueden crear listas de inclusión incondicionales, y si el constructor no las proporciona, esa lista de inclusión se convertirá directamente en un bloque, pero esto hace que la lista de inclusión esté relacionada con el MEV. La solución aquí puede implicar algunos compromisos, incluyendo aceptar algunos incentivos de bajo nivel para sobornar a las personas para que incluyan transacciones en la lista de inclusión.
Podemos ver FOCIL + APS de la siguiente manera. Los stakers continúan teniendo el poder en la parte izquierda del espectro, mientras que la parte derecha del espectro se subasta al mejor postor.
BRAID es completamente diferente. La parte de "validadores" es más grande, pero se divide en dos partes: validadores ligeros y validadores pesados. Al mismo tiempo, dado que las transacciones se ordenan en orden descendente por tarifas prioritarias, la selección en la parte superior del bloque se subasta efectivamente a través del mercado de tarifas, lo que puede considerarse similar a PBS.
Por favor, tenga en cuenta que la seguridad de BRAID depende en gran medida del pool de memoria encriptada; de lo contrario, el mecanismo de subasta de bloque superior es vulnerable a ataques de robo de estrategia (en esencia: copiar las transacciones de otros, intercambiar la dirección del receptor y pagar una alta tarifa del 0.01%). Esta demanda de privacidad pre-incluida es también la razón por la cual la implementación de PBS es tan complicada.
Finalmente, una versión más "radical" de FOCIL + APS, por ejemplo. APS solo determina las opciones al final del bloque como se muestra a continuación:
Las tareas principales restantes son (i) dedicarse a consolidar diversas propuestas y analizar sus consecuencias, y (ii) combinar este análisis con la comprensión de los objetivos de la comunidad de Ethereum, es decir, qué formas de centralización tolerará. Cada propuesta individual también necesita completar algunas tareas, como:
Continuar trabajando en el diseño de la memoria de criptomonedas, y alcanzar un nivel en el que nuestro diseño sea tanto robusto como bastante simple, y parece estar listo para ser incorporado.
Optimizar múltiples diseños de listas incluidas para garantizar que (i) no desperdicie datos, especialmente en el contexto de listas incluidas que contienen blob, y (ii) sea amigable para los validadores sin estado.
Más trabajo sobre el diseño óptimo de subastas APS.
Además, es importante destacar que estas diferentes propuestas no son necesariamente intersecciones incompatibles entre sí. Por ejemplo, la implementación de FOCIL + APS puede ser fácilmente un trampolín para la implementación de BRAID. Una estrategia conservadora efectiva es el enfoque de "esperar", donde primero implementamos una solución en la que los poderes de los stakers están limitados y la mayor parte de los poderes se subastan, y luego, con el tiempo, a medida que comprendemos mejor el funcionamiento del mercado MEV en la red en tiempo real, aumentamos lentamente el poder de los interesados.
En particular, el cuello de botella centralizado del staking es:
Construcción de bloques centralizada (esta sección)
Centralización del staking por razones económicas (próxima sección)
La centralización del staking debido al límite mínimo de 32 ETH (resuelto a través de Orbit u otras tecnologías; consulte las publicaciones sobre la fusión)
Centralización del staking debido a los requisitos de hardware (resuelto en Verge a través de clientes sin estado y el posterior ZK-EVM)
Resolver cualquiera de estos cuatro problemas aumentará los beneficios de resolver cualquier otro problema.
Además, hay interacciones entre el pipeline de construcción de bloques y el diseño de finalización de un solo slot, especialmente al intentar reducir el tiempo de slot. Muchos diseños de pipeline de construcción de bloques terminan aumentando el tiempo de slot. Muchos pipelines de construcción de bloques involucran el rol de los validadores en múltiples etapas del proceso. Por lo tanto, vale la pena considerar simultáneamente el pipeline de construcción de bloques y la finalización de un solo slot.
Reparar la economía de staking
¿Qué problema queremos resolver?
Hoy en día, aproximadamente el 30% de la oferta de Ether está siendo activamente apostada. Esto es suficiente para proteger Ethereum de un ataque del 51%. Si la proporción de ETH apostado se vuelve mayor, los investigadores temen que surjan diferentes situaciones: si casi todo el ETH está apostado, existirán riesgos. Estos riesgos incluyen:
El staking ha pasado de ser una tarea lucrativa para los expertos a ser una responsabilidad para todos los poseedores de ETH. Por lo tanto, los stakers comunes serán menos entusiastas y elegirán el método más sencillo (de hecho, delegando sus tokens al operador centralizado más conveniente).
Si casi todo el ETH está en staking, la credibilidad del mecanismo de reducción se debilitará.
Un único token de liquidez de staking puede apoderarse de la mayor parte de la propiedad, e incluso apoderarse del efecto de red "monetaria" de ETH.
Ethereum emite innecesariamente aproximadamente 1 millón de ETH cada año. En el caso de que un token de staking líquido obtenga un efecto de red dominante, una gran parte de este valor podría ser incluso capturado por LST.
¿Qué es y cómo funciona?
Históricamente, una solución es: si todos inevitablemente hacen staking, y los tokens de staking líquido son inevitables, entonces hagamos que el staking sea amigable para tener tokens de staking líquido que sean, en realidad, desconfianzados, neutrales y lo más descentralizados posible. Un método simple es limitar la penalización por staking a 1/8, lo que haría que 7/8 del ETH en staking no sea reducidle, por lo que sería elegible para ser incluido en el mismo token de staking líquido. Otra opción es crear explícitamente un staking de dos niveles: staking "asumir riesgos" (reducible).
Sin embargo, una crítica a este enfoque es que, económicamente, parece ser equivalente a algo mucho más simple: si la participación se acerca a un límite superior predeterminado, se reduce drásticamente la cantidad emitida. El argumento básico es: si al final entramos en un mundo donde la tasa de retorno de la capa de riesgo es del 3.4% y la tasa de retorno de la capa sin riesgo (en la que todos participan) es del 2.6%, entonces en realidad es lo mismo que el mundo de la participación de ETH donde la tasa de retorno es del 0.8% y solo tener ETH tiene una tasa de retorno del 0%. La dinámica de la capa de riesgo, incluyendo el total de participación y el grado de centralización, es la misma en ambos casos. Así que deberíamos hacer algo simple y reducir la emisión.
La principal refutación a este argumento es si podemos hacer que la "capa sin riesgo" aún tenga alguna función útil y cierto grado de riesgo (por ejemplo, como lo propone Dankrad aquí).
Ambas sugerencias implican un cambio en la curva de emisión; si la cantidad de acciones es demasiado alta, la tasa de retorno será muy baja.
Izquierda: Una propuesta de Justin Drake para ajustar la curva de emisión. Derecha: Otro conjunto de propuestas de Anders Elowsson.
Por otro lado, el staking de dos niveles requiere establecer dos curvas de rendimiento: (i) la tasa de rendimiento del staking "básico" (sin riesgo o de bajo riesgo) y (ii) la prima del staking de riesgo. Hay múltiples formas de establecer estos parámetros: por ejemplo, si establece un parámetro rígido, es decir, que 1/8 de los derechos sean deducibles, entonces la dinámica del mercado determinará la prima de la tasa de rendimiento obtenida por los derechos deducibles.
Otro tema importante aquí es la captura de MEV. Hoy en día, los ingresos de MEV (por ejemplo, arbitraje DEX, sándwich...) fluyen hacia los proponentes, es decir, los que están en staking. Esto es un ingreso completamente "opaco" para el protocolo: el protocolo no puede saber si es un 0.01% de tasa de interés anual, un 1% de tasa de interés anual o un 20% de tasa de interés anual. Desde múltiples perspectivas, la existencia de esta fuente de ingresos es muy inconveniente:
Esta es una fuente de ingresos inestable, ya que cada participante solo puede obtenerla al proponer un bloque, lo que ocurre aproximadamente cada 4 meses. Esto incentivará a las personas a unirse al fondo para obtener ingresos más estables.
Esto provoca una distribución desigual de incentivos: demasiadas propuestas, pocas pruebas.
Esto hace que el límite de participación sea difícil de implementar: incluso si la tasa de retorno "oficial" es cero, solo los ingresos de MEV podrían ser suficientes para impulsar a todos los holders de ETH a hacer staking. Por lo tanto, las propuestas de límite de participación realistas deben hacer que el retorno se acerque a menos infinito. Esto conlleva más riesgos para los stakers, especialmente para los stakers individuales.
Podemos resolver estos problemas al encontrar una manera de hacer que los ingresos de MEV sean claramente visibles en el protocolo y capturarlos. La primera propuesta fue el MEV smoothing de Francesco; hoy en día, se considera comúnmente que cualquier mecanismo que anticipe los derechos de los proponentes de bloques (o, más generalmente, que tenga suficiente poder para capturar casi todo el MEV) puede lograr el mismo objetivo.
¿Qué conexiones hay con la investigación existente?
Emitir wtf：
Endgame economía de staking, caso de posicionamiento:
Atributos de nivel de emisión, Anders Elowsson:
Límite superior del tamaño de configuración del validador:
Reflexiones sobre la idea de la participación múltiple:
Staking de arcoíris:
Propuesta de participación líquida de Dankrad:
MEV smoothing, autor: Francesco:
MEV burn, autor: Justin Drake:
¿Qué más se necesita hacer, qué se debe sopesar?
La tarea principal que queda es o aceptar no tomar ninguna acción y aceptar el riesgo de que casi todo el ETH esté dentro de LST, o finalizar y llegar a un acuerdo sobre los detalles y parámetros de una de las propuestas anteriores. El resumen general de beneficios y riesgos es el siguiente:
¿Cómo interactúa con otras partes de la hoja de ruta?
Un punto de cruce importante está relacionado con el staking individual. Hoy en día, el VPS más barato que puede ejecutar un nodo de Ethereum cuesta alrededor de 60 dólares al mes, principalmente debido al costo del almacenamiento en disco. Para los stakers de 32 ETH (que en el momento de escribir esto son 84,000 dólares), esto reduciría el APY a (60 * 12) / 84000 ~= 0.85%. Si la tasa de retorno total del staking es inferior al 0.85%, entonces para muchas personas en este nivel, el staking individual no es viable.
Si queremos que el staking individual siga siendo viable, esto enfatiza aún más la necesidad de reducir los costos operativos de los nodos, lo cual se logrará en Verge: el estado sin estado eliminará la necesidad de espacio de almacenamiento, lo que por sí mismo puede ser suficiente, y luego la prueba de validez EVM de L1 hará que los costos sean insignificantes.
Por otro lado, la quema de MEV puede considerarse beneficiosa para el staking individual. Aunque reduce los retornos de todos, lo más importante es que disminuye la varianza, haciendo que el staking ya no sea como una lotería.
Finalmente, cualquier cambio en la emisión interactuará con otros cambios fundamentales en el diseño de la participación (como la participación de arcoíris). Una cuestión especialmente digna de atención es que, si los rendimientos de la participación se vuelven muy bajos, esto significa que debemos elegir entre lo siguiente: (i) reducir la severidad de las sanciones, disminuyendo los factores disuasorios contra el mal comportamiento; (ii) mantener una alta severidad de las sanciones, lo que aumentará una serie de situaciones en las que incluso los validadores de buena fe, si desafortunadamente enfrentan problemas técnicos o incluso ataques, podrían inesperadamente obtener rendimientos negativos.
Soluciones de capa de aplicación
La parte anterior se centró en los cambios en Ethereum L1, los cuales pueden abordar riesgos de centralización importantes. Sin embargo, Ethereum no es solo un L1, es un ecosistema que también cuenta con estrategias importantes en la capa de aplicación que pueden ayudar a mitigar los riesgos mencionados. Algunos ejemplos incluyen:
Soluciones de hardware específicas para staking —— Algunas empresas (como Dappnode) están vendiendo hardware diseñado específicamente para operar nodos de staking de la manera más sencilla posible. Una forma de hacer que esta solución sea más efectiva es plantear la pregunta: si un usuario ya ha dedicado esfuerzo para hacer funcionar un dispositivo y conectarlo a Internet, ¿qué otros servicios (para el usuario u otros) podría ofrecer que se beneficiaran de la descentralización? Ejemplos que se me ocurren incluyen (i) ejecutar un máster en leyes alojado localmente por razones de soberanía y privacidad, así como (ii) operar nodos de VPN descentralizada.
Staking en Equipo —— Esta solución de Obol permite a múltiples personas hacer staking juntas en formato M-of-N. Con el tiempo, esto puede volverse cada vez más popular, ya que las pruebas de validez de L1 EVM sin estado y posteriores reducirán los costos de operar más nodos, y los beneficios de que cada participante no necesite preocuparse por estar siempre en línea comenzarán a dominar. Esta es otra forma de reducir el costo cognitivo del staking y asegurar que el staking individual prospere en el futuro.
Airdrop —— Starknet ofrece a los stakers individuales un airdrop. Otros proyectos que deseen tener una comunidad de usuarios descentralizada y con valores alineados también pueden considerar ofrecer airdrops o descuentos a los validadores identificados como posibles poseedores individuales de derechos.
Mercado de construcción de bloques descentralizado —— Utilizando una combinación de ZK, MPC y TEE, se puede crear un constructor de bloques descentralizado que participe y gane en el juego de subastas APS, al tiempo que proporciona privacidad de preconfirmación y garantías contra la censura para sus usuarios. Este es otro camino para mejorar el bienestar de los usuarios en el mundo de APS.
Minimización del MEV en la capa de aplicación —— Una única aplicación puede construirse de manera que “filtre” menos MEV hacia L1, reduciendo así el incentivo de los creadores de bloques para crear algoritmos especializados para recopilar MEV. Una estrategia simple pero general es que el contrato coloque todas las operaciones entrantes en una cola y las ejecute en el siguiente bloque, subastando los derechos de anticipación, aunque esto no es conveniente y perjudica la composibilidad. Otros métodos más complejos incluyen realizar más trabajo fuera de la cadena, como lo hace Cowswap. Los oráculos también pueden rediseñarse para minimizar el valor que se puede extraer de ellos.
Un agradecimiento especial a Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes y Max Resnick por sus comentarios y revisiones, así como a la discusión de la comunidad de ethstakers.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Vitalik: El objetivo clave de la fase The Scourge de Ethereum
Autor: Vitalik, fundador de Ethereum; Compilado por: Deng Tong, Jinse Caijing
Nota: Este artículo es la tercera parte de la serie "Desarrollo futuro del protocolo Ethereum" publicada recientemente por Vitalik, el fundador de Ethereum, titulada "Futuros posibles del protocolo Ethereum, parte 3: La Plaga". La segunda parte se puede ver en Jinse Caijing "Vitalik: ¿Cómo debería evolucionar el protocolo Ethereum en la fase Surge?", la primera parte se puede ver en "¿Qué más se puede mejorar en el PoS de Ethereum?" A continuación se presenta el texto completo de la tercera parte:
Uno de los mayores riesgos que enfrenta Ethereum L1 es la centralización de la prueba de participación debido a la presión económica. Si existe economías de escala al participar en el mecanismo central de prueba de participación, esto naturalmente conducirá a que grandes interesados dominen, mientras que los pequeños interesados se retiren para unirse a grandes grupos de minería. Esto aumenta el riesgo de ataques del 51%, revisión de transacciones y otras crisis. Además del riesgo de centralización, también existe el riesgo de extracción de valor: un pequeño número de personas obtiene el valor que originalmente fluiría hacia los usuarios de Ethereum.
El año pasado, nuestra comprensión de estos riesgos aumentó significativamente. Como es bien sabido, este riesgo existe en dos lugares clave: (i) la construcción de bloques, y (ii) las regulaciones de capital de staking. Los participantes más grandes pueden ejecutar algoritmos más complejos ("extracción de MEV") para generar bloques, lo que les proporciona mayores ingresos por bloque. Los grandes participantes también pueden abordar de manera más efectiva la inconveniencia de tener fondos bloqueados al liberar fondos como tokens de staking líquido (LST) a otros. Además de los problemas directos entre pequeños y grandes stakers, también existe la cuestión de si (o si habrá) un staking excesivo de ETH.
Hoja de ruta de Scourge 2023
Este año, la construcción de la blockchain ha logrado avances significativos, siendo lo más destacado la fusión de "lista de inclusión del comité más algunas soluciones de ordenamiento específicas" como solución ideal, así como una importante investigación sobre la economía de la prueba de participación, incluyendo modelos de staking de dos capas y la reducción de la emisión para limitar el porcentaje de ETH en staking.
Los Objetivos Clave de La Plaga
Este artículo se divide en tres partes
Reparar la construcción de bloques
¿Qué problema queremos resolver?
Hoy en día, la construcción de bloques de Ethereum se lleva a cabo principalmente a través de la separación del propser-builder fuera del protocolo de MEVBoost. Cuando los validadores tienen la oportunidad de proponer un bloque, delegan el trabajo de seleccionar el contenido del bloque a participantes especializados llamados constructores. La tarea de seleccionar el contenido del bloque que maximiza los ingresos es intensiva en economías de escala: se requieren algoritmos especializados para determinar qué transacciones incluir, con el fin de extraer el máximo valor posible de las herramientas financieras en la cadena y las transacciones de los usuarios que interactúan con ellas (esto se conoce como "extracción de MEV"). Los validadores se enfrentan a una tarea de "tubería tonta" relativamente ligera en economías de escala, que consiste en escuchar las pujas y aceptar la puja más alta, así como otras responsabilidades como la prueba.
Gráfico programático de lo que está haciendo MEVBoost: los constructores dedicados asumen las tareas rojas, los interesados asumen las tareas azules.
Hay varias versiones, incluyendo "Separación de Proponentes y Constructores" (PBS) y "Separación de Probadores y Proponentes" (APS). La diferencia entre ellas se relaciona con los detalles finos, es decir, qué responsabilidades asume cada uno de los dos participantes: en términos generales, en PBS, los validadores todavía proponen bloques, pero reciben la carga útil del constructor, mientras que en APS, toda la ranura se convierte en responsabilidad del constructor. Recientemente, APS ha sido más favorecido que PBS, ya que reduce aún más el incentivo para que el proponente y el constructor estén en el mismo lugar. Tenga en cuenta que APS solo se aplica a bloques de ejecución que contienen transacciones; los bloques de consenso que contienen datos relacionados con la prueba de participación (por ejemplo, pruebas) seguirán siendo distribuidos aleatoriamente entre los validadores.
Esta separación de poderes ayuda a mantener la descentralización de los validadores, pero tiene un costo importante: los participantes que realizan tareas "especializadas" pueden volverse muy centralizados. Esta es la construcción de bloques de Ethereum hoy.
Dos participantes están eligiendo el contenido de aproximadamente el 88% de los bloques de Ethereum. ¿Qué pasa si estos dos participantes deciden revisar las transacciones? La respuesta no es tan mala como parece: no pueden reorganizar los bloques, por lo que no necesitas en absoluto un 51% de revisión para evitar que las transacciones sean incluidas: necesitas un 100%. Con un mecanismo de revisión del 88%, los usuarios deben esperar en promedio 9 ranuras (técnicamente, un promedio de 114 segundos, en lugar de 6 segundos). Para ciertos casos de uso, esperar algunas transacciones dos minutos o incluso cinco minutos está bien. Pero para otros casos de uso, como en el caso de liquidaciones DeFi, incluso la capacidad de retrasar la inclusión de las transacciones de otros por unos pocos bloques representa un riesgo significativo de manipulación del mercado.
Las estrategias que los constructores de bloques pueden utilizar para maximizar ingresos también pueden tener otros efectos negativos para los usuarios. Un "ataque de sándwich" puede causar que los usuarios que realicen transacciones de tokens sufran pérdidas significativas debido al deslizamiento. Para colapsar estas transacciones introducidas por los ataques, se han incrementado los precios de Gas para otros usuarios.
¿Qué es y cómo funciona?
La solución líder es desglosar aún más la tarea de producción de bloques: delegaremos la tarea de seleccionar transacciones a los proponentes (es decir, los stakers), mientras que los constructores solo podrán elegir el orden e insertar algunas de sus propias transacciones. Esto es lo que quiere lograr la lista de inclusión.
En el tiempo T, un validador seleccionado al azar crea una lista de transacciones, es decir, una lista de transacciones que son válidas en el estado actual de la cadena de bloques en ese momento. En el tiempo T+1, el constructor del bloque (que puede haber sido seleccionado previamente a través de un mecanismo de subasta dentro del protocolo) crea un bloque. Este bloque debe contener cada transacción de la lista, pero pueden elegir el orden y pueden agregar sus propias transacciones.
La propuesta de Lista de Inclusión Obligatoria de Selección de Fork (FOCIL) implica un comité compuesto por múltiples creadores de listas de inclusión para cada bloque. Para retrasar una transacción un bloque, k de los creadores de listas de inclusión entre k (por ejemplo, k = 16) deben revisar la transacción. FOCIL, combinado con el proponente final seleccionado a través de una subasta, necesita incluir la lista de inclusión, pero puede reordenarse y agregar nuevas transacciones, comúnmente conocido como “FOCIL + APS”.
Otra forma de resolver este problema es mediante múltiples proponentes concurrentes (MCP), como BRAID. BRAID intenta evitar dividir el rol de proponente de bloques en partes de baja y alta economía de escala, y en su lugar intenta asignar el proceso de producción de bloques a muchos participantes, de modo que cada proponente solo necesite tener un nivel moderado de complejidad para maximizar sus ingresos. El funcionamiento de MCP es permitir que k proponentes paralelos generen listas de transacciones, y luego utilizar un algoritmo determinista (por ejemplo, ordenar por tarifas de mayor a menor) para seleccionar el orden.
BRAID no busca implementar el software predeterminado de los proponentes de bloques de tubería tonta como el objetivo más adecuado. Las dos razones fáciles de entender por las que no puede hacerlo son:
En BRAID, los testigos aún pueden separarse y funcionar como una función de tubería tonta.
Además de estos dos extremos, existe una serie de posibles diseños que se encuentran entre ambos. Por ejemplo, puede subastar roles que solo tienen el derecho de adjuntarse a los bloques, sin derecho a reordenar o anteponer. Incluso puede permitirles adjuntarse o anteponerse, pero no insertar en medio o reordenar. El atractivo de estas técnicas radica en que los ganadores del mercado de subastas pueden estar muy concentrados, por lo que reducir su autoridad tiene muchos beneficios.
encriptación de la memoria
Una tecnología que es crucial para implementar con éxito muchos de estos diseños (específicamente, las versiones BRAID o APS, que tienen estrictas limitaciones sobre la funcionalidad de subastas) es el pool de memoria cifrada. El pool de memoria cifrada es una técnica en la que los usuarios transmiten sus transacciones en forma cifrada, adjuntando algún tipo de prueba de validez, y las transacciones se incluyen en el bloque de forma cifrada, sin que el constructor del bloque conozca su contenido. El contenido de la transacción se publica más tarde.
El principal desafío para implementar un pool de memoria criptográfica es proponer un diseño que asegure que todas las transacciones se revelen más tarde: un simple esquema de "presentar y revelar" no funciona, ya que si la revelación es voluntaria, la elección de revelar o no revelar en sí misma tiene un efecto de "último impulsor" sobre los bloques que pueden ser explotados. Las dos tecnologías principales son (i) descifrado umbral y (ii) cifrado retrasado, que es un primitivo estrechamente relacionado con la función de retraso verificable (VDF).
¿Qué conexiones hay con la investigación existente?
Explicación de la centralización de MEV y constructores:
MEVBoost：
Enshrined PBS (soluciones propuestas temprano para estos problemas):
Lista de lecturas relacionadas con la lista de inclusión de Mike Neuder:
Lista de EIP incluida:
FOCIL：
Demostración de BRAID de Max Resnick:
“La prioridad es lo que necesitas”, autor: Dan Robinson:
Sobre la herramienta y el protocolo de múltiples proponentes:
VDFResearch.org：
Funciones de retardo verificables y ataques (enfoque en la configuración RANDAO, pero también aplicable a la memoria criptográfica):
Captura de boletos de ejecución MEV y descentralización:
APS centralizado:
Listas de múltiples MEV y contenido:
¿Qué más se necesita hacer, qué se debe sopesar?
Podemos considerar todas las opciones anteriores como diferentes formas de dividir los derechos de participación en el stake, ordenadas desde economías de escala más bajas ("dumb-pipe") hasta economías de escala más altas ("especialización amigable"). Antes de 2021, todos estos derechos estaban agrupados en un solo participante:
El problema central es: cualquier poder significativo que aún esté en manos de los interesados, podría convertirse en poder "relacionado con MEV". Deseamos que un grupo de participantes altamente descentralizados posea tanto poder como sea posible; esto significa (i) otorgar una gran cantidad de poder a los interesados, y (ii) asegurar que los interesados estén lo más descentralizados posible, lo que significa que casi no tienen incentivos de integración impulsados por economías de escala. Esta es una tensión difícil de manejar.
Un desafío especial es el MEV de múltiples bloques: en ciertos casos, si el ganador de la subasta de ejecución captura múltiples ranuras consecutivas y no se permite realizar ninguna transacción relacionada con el MEV en bloques fuera del último bloque que controlan, pueden ganar más dinero. Si una lista de inclusión los obliga a hacer esto, entonces pueden intentar eludirla al no publicar ningún bloque en absoluto durante esos períodos de tiempo. Se pueden crear listas de inclusión incondicionales, y si el constructor no las proporciona, esa lista de inclusión se convertirá directamente en un bloque, pero esto hace que la lista de inclusión esté relacionada con el MEV. La solución aquí puede implicar algunos compromisos, incluyendo aceptar algunos incentivos de bajo nivel para sobornar a las personas para que incluyan transacciones en la lista de inclusión.
Podemos ver FOCIL + APS de la siguiente manera. Los stakers continúan teniendo el poder en la parte izquierda del espectro, mientras que la parte derecha del espectro se subasta al mejor postor.
BRAID es completamente diferente. La parte de "validadores" es más grande, pero se divide en dos partes: validadores ligeros y validadores pesados. Al mismo tiempo, dado que las transacciones se ordenan en orden descendente por tarifas prioritarias, la selección en la parte superior del bloque se subasta efectivamente a través del mercado de tarifas, lo que puede considerarse similar a PBS.
Por favor, tenga en cuenta que la seguridad de BRAID depende en gran medida del pool de memoria encriptada; de lo contrario, el mecanismo de subasta de bloque superior es vulnerable a ataques de robo de estrategia (en esencia: copiar las transacciones de otros, intercambiar la dirección del receptor y pagar una alta tarifa del 0.01%). Esta demanda de privacidad pre-incluida es también la razón por la cual la implementación de PBS es tan complicada.
Finalmente, una versión más "radical" de FOCIL + APS, por ejemplo. APS solo determina las opciones al final del bloque como se muestra a continuación:
Las tareas principales restantes son (i) dedicarse a consolidar diversas propuestas y analizar sus consecuencias, y (ii) combinar este análisis con la comprensión de los objetivos de la comunidad de Ethereum, es decir, qué formas de centralización tolerará. Cada propuesta individual también necesita completar algunas tareas, como:
Además, es importante destacar que estas diferentes propuestas no son necesariamente intersecciones incompatibles entre sí. Por ejemplo, la implementación de FOCIL + APS puede ser fácilmente un trampolín para la implementación de BRAID. Una estrategia conservadora efectiva es el enfoque de "esperar", donde primero implementamos una solución en la que los poderes de los stakers están limitados y la mayor parte de los poderes se subastan, y luego, con el tiempo, a medida que comprendemos mejor el funcionamiento del mercado MEV en la red en tiempo real, aumentamos lentamente el poder de los interesados.
En particular, el cuello de botella centralizado del staking es:
Resolver cualquiera de estos cuatro problemas aumentará los beneficios de resolver cualquier otro problema.
Además, hay interacciones entre el pipeline de construcción de bloques y el diseño de finalización de un solo slot, especialmente al intentar reducir el tiempo de slot. Muchos diseños de pipeline de construcción de bloques terminan aumentando el tiempo de slot. Muchos pipelines de construcción de bloques involucran el rol de los validadores en múltiples etapas del proceso. Por lo tanto, vale la pena considerar simultáneamente el pipeline de construcción de bloques y la finalización de un solo slot.
Reparar la economía de staking
¿Qué problema queremos resolver?
Hoy en día, aproximadamente el 30% de la oferta de Ether está siendo activamente apostada. Esto es suficiente para proteger Ethereum de un ataque del 51%. Si la proporción de ETH apostado se vuelve mayor, los investigadores temen que surjan diferentes situaciones: si casi todo el ETH está apostado, existirán riesgos. Estos riesgos incluyen:
¿Qué es y cómo funciona?
Históricamente, una solución es: si todos inevitablemente hacen staking, y los tokens de staking líquido son inevitables, entonces hagamos que el staking sea amigable para tener tokens de staking líquido que sean, en realidad, desconfianzados, neutrales y lo más descentralizados posible. Un método simple es limitar la penalización por staking a 1/8, lo que haría que 7/8 del ETH en staking no sea reducidle, por lo que sería elegible para ser incluido en el mismo token de staking líquido. Otra opción es crear explícitamente un staking de dos niveles: staking "asumir riesgos" (reducible).
Sin embargo, una crítica a este enfoque es que, económicamente, parece ser equivalente a algo mucho más simple: si la participación se acerca a un límite superior predeterminado, se reduce drásticamente la cantidad emitida. El argumento básico es: si al final entramos en un mundo donde la tasa de retorno de la capa de riesgo es del 3.4% y la tasa de retorno de la capa sin riesgo (en la que todos participan) es del 2.6%, entonces en realidad es lo mismo que el mundo de la participación de ETH donde la tasa de retorno es del 0.8% y solo tener ETH tiene una tasa de retorno del 0%. La dinámica de la capa de riesgo, incluyendo el total de participación y el grado de centralización, es la misma en ambos casos. Así que deberíamos hacer algo simple y reducir la emisión.
La principal refutación a este argumento es si podemos hacer que la "capa sin riesgo" aún tenga alguna función útil y cierto grado de riesgo (por ejemplo, como lo propone Dankrad aquí).
Ambas sugerencias implican un cambio en la curva de emisión; si la cantidad de acciones es demasiado alta, la tasa de retorno será muy baja.
Izquierda: Una propuesta de Justin Drake para ajustar la curva de emisión. Derecha: Otro conjunto de propuestas de Anders Elowsson.
Por otro lado, el staking de dos niveles requiere establecer dos curvas de rendimiento: (i) la tasa de rendimiento del staking "básico" (sin riesgo o de bajo riesgo) y (ii) la prima del staking de riesgo. Hay múltiples formas de establecer estos parámetros: por ejemplo, si establece un parámetro rígido, es decir, que 1/8 de los derechos sean deducibles, entonces la dinámica del mercado determinará la prima de la tasa de rendimiento obtenida por los derechos deducibles.
Otro tema importante aquí es la captura de MEV. Hoy en día, los ingresos de MEV (por ejemplo, arbitraje DEX, sándwich...) fluyen hacia los proponentes, es decir, los que están en staking. Esto es un ingreso completamente "opaco" para el protocolo: el protocolo no puede saber si es un 0.01% de tasa de interés anual, un 1% de tasa de interés anual o un 20% de tasa de interés anual. Desde múltiples perspectivas, la existencia de esta fuente de ingresos es muy inconveniente:
Podemos resolver estos problemas al encontrar una manera de hacer que los ingresos de MEV sean claramente visibles en el protocolo y capturarlos. La primera propuesta fue el MEV smoothing de Francesco; hoy en día, se considera comúnmente que cualquier mecanismo que anticipe los derechos de los proponentes de bloques (o, más generalmente, que tenga suficiente poder para capturar casi todo el MEV) puede lograr el mismo objetivo.
¿Qué conexiones hay con la investigación existente?
Emitir wtf：
Endgame economía de staking, caso de posicionamiento:
Atributos de nivel de emisión, Anders Elowsson:
Límite superior del tamaño de configuración del validador:
Reflexiones sobre la idea de la participación múltiple:
Staking de arcoíris:
Propuesta de participación líquida de Dankrad:
MEV smoothing, autor: Francesco:
MEV burn, autor: Justin Drake:
¿Qué más se necesita hacer, qué se debe sopesar?
La tarea principal que queda es o aceptar no tomar ninguna acción y aceptar el riesgo de que casi todo el ETH esté dentro de LST, o finalizar y llegar a un acuerdo sobre los detalles y parámetros de una de las propuestas anteriores. El resumen general de beneficios y riesgos es el siguiente:
¿Cómo interactúa con otras partes de la hoja de ruta?
Un punto de cruce importante está relacionado con el staking individual. Hoy en día, el VPS más barato que puede ejecutar un nodo de Ethereum cuesta alrededor de 60 dólares al mes, principalmente debido al costo del almacenamiento en disco. Para los stakers de 32 ETH (que en el momento de escribir esto son 84,000 dólares), esto reduciría el APY a (60 * 12) / 84000 ~= 0.85%. Si la tasa de retorno total del staking es inferior al 0.85%, entonces para muchas personas en este nivel, el staking individual no es viable.
Si queremos que el staking individual siga siendo viable, esto enfatiza aún más la necesidad de reducir los costos operativos de los nodos, lo cual se logrará en Verge: el estado sin estado eliminará la necesidad de espacio de almacenamiento, lo que por sí mismo puede ser suficiente, y luego la prueba de validez EVM de L1 hará que los costos sean insignificantes.
Por otro lado, la quema de MEV puede considerarse beneficiosa para el staking individual. Aunque reduce los retornos de todos, lo más importante es que disminuye la varianza, haciendo que el staking ya no sea como una lotería.
Finalmente, cualquier cambio en la emisión interactuará con otros cambios fundamentales en el diseño de la participación (como la participación de arcoíris). Una cuestión especialmente digna de atención es que, si los rendimientos de la participación se vuelven muy bajos, esto significa que debemos elegir entre lo siguiente: (i) reducir la severidad de las sanciones, disminuyendo los factores disuasorios contra el mal comportamiento; (ii) mantener una alta severidad de las sanciones, lo que aumentará una serie de situaciones en las que incluso los validadores de buena fe, si desafortunadamente enfrentan problemas técnicos o incluso ataques, podrían inesperadamente obtener rendimientos negativos.
Soluciones de capa de aplicación
La parte anterior se centró en los cambios en Ethereum L1, los cuales pueden abordar riesgos de centralización importantes. Sin embargo, Ethereum no es solo un L1, es un ecosistema que también cuenta con estrategias importantes en la capa de aplicación que pueden ayudar a mitigar los riesgos mencionados. Algunos ejemplos incluyen:
Un agradecimiento especial a Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes y Max Resnick por sus comentarios y revisiones, así como a la discusión de la comunidad de ethstakers.