Uno de los mayores riesgos para Ethereum L1 es la centralización de prueba de participación debido a las presiones económicas. Si existen economías de escala en participar en los mecanismos principales de prueba de participación, naturalmente esto llevaría a que los grandes apostadores dominen y los pequeños apostadores abandonen para unirse a los grandes grupos. Esto lleva a un mayor riesgo de ataques del 51%, censura de transacciones y otras crisis. Además del riesgo de centralización, también existen riesgos de extracción de valor: un pequeño grupo capturando valor que de otro modo iría a los usuarios de Ethereum.

Durante el último año, nuestra comprensión de estos riesgos ha aumentado considerablemente. Es bien sabido que hay dos lugares clave en los que existe este riesgo: (i) la construcción de bloques y (ii) la provisión de capital de staking. Los actores más grandes pueden permitirse el lujo de ejecutar algoritmos más sofisticados ("extracción MEV") para generar bloques, lo que les da un mayor ingreso por bloque. Los actores muy grandes también pueden lidiar de manera más efectiva con el inconveniente de tener su capital bloqueado, liberándolo a otros como un token de participación líquida (LST). Además de las preguntas directas de los pequeños frente a los grandes, también está la cuestión de si hay (o habrá) demasiado ETH apostado.

La Plaga, hoja de ruta 2023

Este año ha habido avances significativos en la construcción de bloques, especialmente en la convergencia en "listas de inclusión de comités más alguna solución específica para el ordenamiento" como la solución ideal, así como una investigación significativa sobre economía de participación, que incluye ideas como modelos de participación de dos niveles y reducción de emisión para limitar el porcentaje de ETH apostado.

La Plaga: objetivos clave

• Minimizar los riesgos de centralización en la capa de participación de Ethereum (notablemente, en la construcción de bloques y provisión de capital, también conocidos como MEV y pools de participación)
• Minimizar los riesgos de extracción excesiva de valor de los usuarios

En este capítulo

• Arreglando la tubería de construcción de bloques
• Arreglando la economía de staking
• Soluciones de capa de aplicación

Arreglando el proceso de construcción de bloques

¿Qué problema estamos resolviendo?

Hoy en día, la construcción de bloques de Ethereum se realiza en gran medida a través de la separación extra-protocolo del constructor propser.MEVBoost. Cuando un validador tiene la oportunidad de proponer un bloque, subasta el trabajo de elegir el contenido del bloque a actores especializados llamados constructores. La tarea de elegir el contenido del bloque que maximice los ingresos es muy intensiva en economías de escala: se necesitan algoritmos especializados para determinar qué transacciones incluir, con el fin de extraer el máximo valor posible de los dispositivos financieros en cadena y de las transacciones de los usuarios que interactúan con ellos (esto es lo que se llama "extracción de MEV"). Los validadores se quedan con la tarea relativamente ligera de "tubería tonta" en términos de economías de escala, que consiste en escuchar las ofertas y aceptar la oferta más alta, así como otras responsabilidades como la certificación.

Diagrama estilizado de lo que MEVBoost está haciendo: los constructores especializados asumen las tareas en rojo, y los validadores asumen las tareas en azul.

Hay varias versiones de esto, incluyendo "separación de proponente-constructor“ (PBS) y “separación de atestiguador y proponente” (APS). La diferencia entre estos tiene que ver con detalles refinados sobre qué responsabilidades corresponden a cada uno de los dos actores: aproximadamente, en PBS, los validadores aún proponen bloques pero reciben la carga útil de los constructores, y en APS, toda la ranura se convierte en responsabilidad del constructor. Recientemente, se prefiere APS sobre PBS, porque reduce aún más los incentivos para que los proponentes se coloquen junto a los constructores. Tenga en cuenta que APS solo se aplicaría a bloques de ejecución, que contienen transacciones; los bloques de consenso, que contienen datos relacionados con la prueba de participación, como las certificaciones, seguirían asignándose aleatoriamente a los validadores.

Esta separación de poderes ayuda a mantener a los validadores descentralizados, pero tiene un costo importante: los actores que realizan las tareas "especializadas" pueden volverse fácilmente muy centralizados. Aquí está la construcción de bloques de Ethereum hoy:

Dos actores están eligiendo el contenido de aproximadamente el 88% de los bloques de Ethereum. ¿Qué pasa si esos dos actores deciden censurar una transacción? La respuesta no es tan mala como podría parecer: no pueden reorganizar bloques, por lo que no necesitas un 51% de censura para evitar que una transacción se incluya en absoluto: necesitas el 100%. Con un 88% de censura, un usuario necesitaría esperar un promedio de 9 ranuras para ser incluido (técnicamente, un promedio de 114 segundos, en lugar de 6 segundos). Para algunos casos de uso, esperar dos o incluso cinco minutos para ciertas transacciones está bien. Pero para otros casos de uso, como las liquidaciones de DeFi, incluso la capacidad de retrasar la inclusión de la transacción de otra persona por algunos bloques es un riesgo significativo de manipulación del mercado.

Las estrategias que los creadores de bloques pueden emplear para maximizar los ingresos también pueden tener otras consecuencias negativas para los usuarios. A “ataque sandwichPodría hacer que los usuarios que realizan intercambios de tokens sufran pérdidas significativas debido al deslizamiento. Las transacciones introducidas para realizar estos ataques obstruyen la cadena, aumentando los precios del gas para otros usuarios.

¿Qué es esto y cómo funciona?

La solución principal es desglosar aún más la tarea de producción de bloques: le damos la tarea de elegir las transacciones al proponente (es decir, un staker), y el constructor solo puede elegir el orden e insertar algunas transacciones propias. Esto es lo que listas de inclusiónbuscar hacer.

En el momento T, un validador seleccionado al azar crea una lista de inclusión, una lista de transacciones válidas dadas el estado actual de la cadena de bloques en ese momento. En el momento T+1, un constructor de bloques, posiblemente elegido a través de un mecanismo de subasta en el protocolo con antelación, crea un bloque. Se requiere que este bloque incluya cada transacción en la lista de inclusión, pero pueden elegir el orden y pueden agregar sus propias transacciones.

Las propuestas de listas de inclusión forzadas por bifurcación (FOCIL, por sus siglas en inglés) involucran un comité de múltiples creadores de listas de inclusión por bloque. Para retrasar una transacción en un bloque, k de k creadores de listas de inclusión (por ejemplo, k = 16 ) tendrían que censurar la transacción. La combinación de FOCIL con un proponente final elegido por subasta que debe incluir las listas de inclusión, pero que puede reordenar y agregar nuevas transacciones, a menudo se denomina "FOCIL + APS".

Un enfoque diferente para el problema son esquemas de proponentes múltiples concurrentes (MCP) como BRAID. BRAID busca evitar dividir el papel del proponente de bloques en una parte de baja economía de escala y una parte de alta economía de escala, y en su lugar intenta distribuir el proceso de producción de bloques entre muchos actores, de manera que cada proponente solo necesita tener una cantidad media de sofisticación para maximizar sus ingresos. MCP funciona haciendo que k proponentes paralelos generen listas de transacciones, y luego utilizando un algoritmo determinista (por ejemplo, ordenar por tarifa de mayor a menor) para elegir el orden.

BRAID no busca alcanzar el objetivo de que los proponentes de bloques de tuberías tontas que ejecutan software predeterminado sean óptimos. Dos razones fáciles de entender por las cuales no puede hacerlo son:

1. Ataques de arbitraje de último momento: supongamos que el tiempo promedio en que los proponentes presentan es T, y el último momento posible en el que puedes presentar y aún ser incluido es alrededor de T+1. Ahora, supongamos que en los intercambios centralizados, el precio de ETH/USDC se mueve de $2500 a $2502 entre T y T+1. Un proponente puede esperar un segundo adicional y agregar una transacción adicional para arbitrar en los intercambios descentralizados en cadena, reclamando hasta $2 por ETH en ganancias. Los proponentes sofisticados que están muy bien conectados a la red tienen más capacidad para hacer esto.
2. Flujo de orden exclusivo: los usuarios tienen el incentivo de enviar transacciones directamente a un único proponente, para minimizar su vulnerabilidad al frontrunning y otros ataques. Los proponentes sofisticados tienen una ventaja porque pueden configurar infraestructura para aceptar estas transacciones directas de los usuarios, y tienen reputaciones más sólidas, por lo que los usuarios que les envían transacciones pueden confiar en que el proponente no los traicionará ni los adelantará (esto se puede mitigar con hardware confiable, pero luego el hardware confiable tiene suposiciones de confianza propias)

En BRAID, los atestadores todavía se pueden separar y ejecutar como una funcionalidad de tubería tonta.

Además de estos dos extremos, hay un espectro de diseños posibles en el medio. Por ejemplo, se podría subastar un rol que sólo tenga el derecho de agregar a un bloque, y no de reordenar o agregar al principio. Incluso se les podría permitir agregar al principio o al final, pero no insertar en el medio o reordenar. La atracción de estas técnicas es que los ganadores del mercado de subastas son probablementesermuy concentradoy, por lo tanto, hay mucho beneficio en reducir su autoridad.

mempools encriptados

Una tecnología que es crucial para la implementación exitosa de muchos de estos diseños (específicamente, BRAID o una versión de APS donde hay límites estrictos en la capacidad que se subasta) son los mempools encriptados. Los mempools encriptados son una tecnología donde los usuarios transmiten sus transacciones en forma encriptada, junto con algún tipo de prueba de su validez, y las transacciones se incluyen en bloques en forma encriptada, sin que el constructor del bloque conozca el contenido. El contenido de las transacciones se revela más tarde.

El principal desafío en la implementación de mempools cifrados es idear un diseño que garantice que las transacciones no se revelen más tarde: un esquema simple de "compromiso y revelación" no funciona, porque si revelar es voluntario, el acto de elegir revelar o no revelar es en sí mismo una especie de influencia de "último jugador" en un bloque que podría ser explotado. Las dos técnicas principales para esto son (i)descifrado de umbral, y (ii) retrasar la encriptación, un primitivo estrechamente relacionado con funciones de retraso verificables (VDFs).

¿Cuáles son algunos enlaces a investigaciones existentes?

• Explicación sobre MEV y la centralización de los constructores: https://vitalik.eth.limo/general/2024/05/17/decentralization.html#mev-and-builder-dependence
• MEVBoost: https://github.com/flashbots/mev-boost
• PBS consagrado (una solución propuesta anteriormente a estos problemas):https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710
• Lista de lecturas relacionadas con la lista de inclusiones de Mike Neuder:https://gist.github.com/michaelneuder/dfe5699cb245bc99fbc718031c773008
• Lista de inclusión EIP: https://eips.ethereum.org/EIPS/eip-7547
• FOCIL: https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870
• Presentación sobre BRAID por Max Resnick:https://www.youtube.com/watch?v=mJLERWmQ2uw
• "La prioridad es todo lo que necesitas", por Dan Robinson: https://www.paradigm.xyz/2024/06/priority-is-all-you-need
• En dispositivos y protocolos de múltiples proponentes: https://hackmd.io/xz1UyksETR-pCsazePMAjw
• VDFresearch.org: https://vdfresearch.org/
• Funciones de retraso verificables y ataques (se centra en la configuración RANDAO, pero también es aplicable a los mempools cifrados):https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365
• Captura de MEV y descentralización en los tickets de ejecución: https://www.arxiv.org/pdf/2408.11255
• Centralización en APS: https://arxiv.org/abs/2408.03116
• Multi-block MEV y listas de inclusión: https://x.com/%5fcharlienoyes/status/1806186662327689441

¿Qué queda por hacer y cuáles son los compromisos?

Podemos pensar en todos los esquemas anteriores como diferentes formas de dividir la autoridad involucrada en el staking, dispuestas en un espectro desde economías de escala más bajas ("tubería tonta") hasta economías de escala más altas ("amigable con la especialización"). Antes de 2021, todas estas autoridades estaban agrupadas en un solo actor:

El núcleo de la cuestión es el siguiente: cualquier autoridad significativa que permanezca en manos de los validadores, es una autoridad que podría resultar relevante para el MEV. Queremos que un conjunto altamente descentralizado de actores tenga la mayor autoridad posible; esto implica (i) otorgar mucha autoridad a los validadores y (ii) asegurarse de que los validadores sean lo más descentralizados posible, lo que significa que tengan pocos incentivos impulsados por economías de escala para consolidarse. Esta es una tensión difícil de manejar.

Un desafío particular es el MEV multi-bloque: en algunos casos, los ganadores de las subastas de ejecución pueden ganar aún más dinero si capturan múltiples ranuras seguidas y no permiten ninguna transacción relevante de MEV en bloques que no sean el último que controlan. Si las listas de inclusión los obligan a hacerlo, pueden intentar evitarlo no publicando ningún bloque en absoluto durante esas ranuras. Se podrían hacer listas de inclusión incondicionales, que se convierten directamente en el bloque si el constructor no proporciona uno, pero esto...hace que la lista de inclusión sea relevante para el MEV. La solución aquí puede implicar algún compromiso que implique aceptar un bajo grado de incentivo para sobornar a las personas para que incluyan transacciones en una lista de inclusión, y esperando que no sea lo suficientemente alto como para llevar a la externalización masiva.

Podemos ver FOCIL + APS de la siguiente manera. Los validadores continúan teniendo la autoridad en la parte izquierda del espectro, mientras que la parte derecha del espectro se subasta al postor más alto.

BRAID es bastante diferente. La pieza del "staker" es más grande, pero se divide en dos piezas: stakers ligeros y stakers pesados. Mientras tanto, debido a que las transacciones se ordenan en orden decreciente de la tarifa de prioridad, la elección en la parte superior del bloque se subasta de facto a través del mercado de tarifas, en un esquema que se puede ver como análogo aenshrined PBS.

Tenga en cuenta que la seguridad de BRAID depende en gran medida de mempools encriptados; de lo contrario, el mecanismo de subasta en la parte superior del bloque se vuelve vulnerable a los ataques de robo de estrategias (esencialmente: copiar transacciones de otras personas, intercambiar la dirección del destinatario y pagar una tarifa un 0,01% más alta). Esta necesidad de privacidad previa a la inclusión es también la razón por la que el PBS consagrado es tan difícil de implementar.

Finalmente, las versiones más 'agresivas' de FOCIL + APS, por ejemplo, la opción en la que APS solo determina el final del bloque, se ven así:

La principal tarea restante es (i) trabajar en la consolidación de las diversas propuestas y analizar sus consecuencias, y (ii) combinar este análisis con una comprensión de los objetivos de la comunidad de Ethereum en cuanto a qué formas de centralización tolerará. También hay trabajo por hacer en cada propuesta individual, como:

• Continuando el trabajo en los diseños de mempool encriptados, y llegando al punto en el que tenemos un diseño que es robusto y razonablemente simple, y plausiblemente listo para su inclusión.
• Optimizando el diseño de varias listas de inclusión para asegurarse de que (i) no desperdicie datos, especialmente en el contexto de listas de inclusión que cubren blobs, y (ii) sea amigable para los validadores sin estado.
• Más trabajo en el diseño de subasta óptimo para APS.

Además, vale la pena señalar que estas diferentes propuestas no son necesariamente bifurcaciones incompatibles entre sí. Por ejemplo, implementar FOCIL + APS podría servir fácilmente como un trampolín para implementar BRAID. Una estrategia conservadora válida sería un enfoque de "esperar y ver" donde primero implementamos una solución en la que la autoridad de los stakers esté limitada y la mayor parte de la autoridad se subaste, y luego aumentamos gradualmente la autoridad de los stakers a medida que aprendemos más sobre el funcionamiento del mercado de MEV en la red en vivo.

¿Cómo interactúa con otras partes del roadmap?

Existen interacciones positivas entre resolver un cuello de botella de centralización de staking y resolver los demás. Para dar una analogía, imagina un mundo donde comenzar tu propia empresa requiere cultivar tu propia comida, fabricar tus propias computadoras y tener tu propio ejército. En este mundo, solo podrían existir unas pocas empresas. Resolver uno de los tres problemas ayudaría a la situación, pero solo un poco. Resolver dos problemas ayudaría más del doble que resolver uno. Y resolver los tres sería mucho más de tres veces más útil: si eres un emprendedor en solitario, o se resuelven los 3/3 problemas o no tienes ninguna oportunidad.

En particular, los cuellos de botella de centralización para el staking son:

• Centralización de la construcción de bloques (esta sección)
• Centralización de staking por razones económicas (siguiente sección)
• Centralización de staking debido al mínimo de 32 ETH (solucionado con Orbit u otras técnicas; ver el post en el Fusionar)
• Centralización del staking debido a los requisitos de hardware (resuelto en Verge, con clientes sin estado y luego ZK-EVMs)

Resolver cualquiera de los cuatro aumenta las ganancias al resolver cualquiera de los otros.

Además, hay interacciones entre el proceso de construcción de bloques y el diseño de finalidad de ranura única, especialmente en el contexto de tratar de reducir los tiempos de ranura. Muchos diseños de proceso de construcción de bloques terminan aumentando los tiempos de ranura. Muchos procesos de construcción de bloques involucran roles para los atestiguadores en múltiples pasos del proceso. Por esta razón, puede valer la pena pensar en los procesos de construcción de bloques y la finalidad de ranura única simultáneamente.

Corrigiendo la economía del staking

¿Qué problema estamos resolviendo?

Hoy, alrededor del 30% del suministro de ETH está staking activamenteEsto es mucho más que suficiente para proteger Ethereum de los ataques del 51%. Si el porcentaje de ETH apostado crece mucho más, los investigadores temen un escenario diferente: los riesgos que surgirían si casi todo el ETH se apuesta. Estos riesgos incluyen:

• El staking pasa de ser una tarea rentable para especialistas a ser un deber para todos los titulares de ETH. Por lo tanto, el apostador promedio sería mucho menos entusiasta y elegiría el enfoque más fácil (delegar realísticamente sus tokens al operador centralizado que ofrezca la mayor conveniencia).
• La credibilidad del mecanismo de recorte se debilita si casi todo el ETH está apostado
• Un solo token de participación líquida podría tomar la mayor parte de la participación e incluso tomar los efectos de red de 'dinero' de ETH mismo
• Ethereum emitiendo innecesariamente un extra ~1m ETH/año. En el caso en que un token de participación líquida obtenga un efecto de red dominante, una gran parte de este valor podría incluso ser capturada por el LST.

¿Qué es y cómo funciona?

Históricamente, una clase de solución ha sido: si se considera inevitable que todos participen, y es inevitable un token de participación líquida, entonces hagamos que la participación sea amigable para tener un token de participación líquida que sea realmente confiable, neutral y maximamente descentralizado. Una forma sencilla de hacer esto es limitar las penalizaciones de participación, por ejemplo, al 1/8, lo que haría que 7/8 del ETH apostado no sea sujeto a sanciones, y por lo tanto elegible para ser incluido en el mismo token de participación líquida. Otra opción es crear explícitamente dos niveles de participación"riesgo-soportante" (slashable) staking, que de alguna manera estaría limitado, por ejemplo, a 1/8 de todo ETH, y staking "sin riesgo" (intransferible), en el que todos podrían participar.

Sin embargo, una crítica de este enfoque es que @vbuterin/staking_2023_10?type=view">parece económicamente equivalente a algo mucho más simple: reducir masivamente la emisión si la participación se acerca a un límite predefinido. El argumento básico es: si terminamos en un mundo donde el nivel de riesgo tiene rendimientos del 3.4% y el nivel libre de riesgo (en el que participa todo el mundo) tiene rendimientos del 2.6%, en realidad es lo mismo que un mundo donde apostar ETH tiene rendimientos del 0.8% y simplemente mantener ETH no tiene rendimientos. La dinámica del nivel de riesgo, incluyendo tanto la cantidad total apostada como la centralización, sería la misma en ambos casos. Y así deberíamos hacer simplemente lo simple y reducir la emisión.

El principal contraargumento a esta línea de argumentación sería si pudiéramos hacer que el "nivel sin riesgo" todavía tenga algún papel útil y algún nivel de riesgo (por ejemplo, como ).propuesto por Dankrad aquí).

Ambas de estas líneas de propuestas implican cambiar la curva de emisión, de una manera que hace que los rendimientos sean prohibitivamente bajos si la cantidad de participación se vuelve demasiado alta.

Izquierda: una propuesta para una curva de emisión ajustada, por Justin Drake. Derecha: otro conjunto de propuestas, por Anders Elowsson.

Por otro lado, el staking de dos niveles requiere establecer dos curvas de retorno: (i) la tasa de retorno para el staking "básico" (libre de riesgo o de bajo riesgo), y (ii) la prima por el staking que asume riesgos. Hay diferentes formas de establecer estos parámetros: por ejemplo, si se establece un parámetro estricto en el que el 1/8 del stake es susceptible de ser recortado, entonces la dinámica del mercado determinará la prima sobre la tasa de retorno que recibe el stake susceptible de ser recortado.

Otro tema importante aquí es la captura de MEV. Hoy en día, los ingresos de MEV (p. ej. Arbitraje DEX, sándwiches...) va a los proponentes, es decir. Stakers. Se trata de ingresos que son completamente "opacos" para el protocolo: el protocolo no tiene forma de saber si es de 0,01% TAE, 1% TAE o 20% TAE. La existencia de este flujo de ingresos es muy inconveniente desde múltiples ángulos:

1. Es una fuente de ingresos volátil, ya que cada apostador individual solo lo recibe cuando propone un bloque, lo cual sucede una vez cada ~4 meses hoy en día. Esto crea un incentivo para unirse a grupos para obtener ingresos más estables.
2. Conduce a una asignación desequilibrada de incentivos: demasiado para proponer, muy poco para atestar.
3. Hace que el límite de participación sea muy difícil de implementar: incluso si la tasa de rendimiento "oficial" es cero, los ingresos de MEV por sí solos pueden ser suficientes para llevar a todos los titulares de ETH a participar. Como resultado, una propuesta realista de límite de participación tendría que tener rendimientos que se acerquen al infinito negativo, como por ejemplo.@vbuterinLa finalidad de una sola ranura / Ver tipo#económico-límite-de-depósitos-totales propuesto aquí, esto, como es obvio, crea más riesgo para los validadores, especialmente los validadores solitarios.

Podemos resolver estos problemas encontrando una forma de hacer que los ingresos por MEV sean legibles para el protocolo y capturándolos. La propuesta más temprana fue Suavizado de MEV de Francesco; hoy en día, se entiende ampliamente que cualquier mecanismo para subastar los derechos de proponente de bloque (o, más generalmente, la autoridad suficiente para capturar casi todo el MEV) con anticipación logra el mismo objetivo.

¿Cuáles son algunos enlaces a investigaciones existentes?

• Issuance.wtf: https://issuance.wtf/
• Economía de apuestas de fin de juego, un caso para apuntar:https://ethresear.ch/t/endgame-staking-economics-a-case-for-targeting/18751
• Propiedades del nivel de emisión, Anders Elowsson: https://ethresear.ch/t/properties-of-issuance-level-consensus-incentives-and-variability-across-potential-reward-curves/18448
• Límite de tamaño del conjunto de validadores: @vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits"">https://notes.ethereum.org/@vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits
• Pensamientos sobre ideas de participación multinivel: @vbuterin/staking_2023_10?type=view"">https://notes.ethereum.org/@vbuterin/staking_2023_10?type=view
• Rainbow staking:https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
• La propuesta de staking líquido de Dankrad:https://notes.Ethereum.org/Pcq3m8B8TuWnEsuhKwCsFg
• Suavizado de MEV, por Francesco:https://ethresear.ch/t/committee-driven-mev-smoothing/10408
• Quema de MEV, por Justin Drake: https://ethresear.ch/t/mev-burn-a-simple-design/15590

¿Qué queda por hacer y cuáles son los compromisos?

La tarea principal restante es o bien acordar no hacer nada y aceptar los riesgos de que casi todo ETH esté dentro de LSTs, o finalizar y ponernos de acuerdo en los detalles y parámetros de una de las propuestas anteriores. Un resumen aproximado de los beneficios y riesgos es:

¿Cómo interactúa con otras partes del roadmap?

Un punto importante de intersección tiene que ver con el staking en solitario. Hoy en día, los VPS más baratos que pueden ejecutar un nodo Ethereum cuestan alrededor de $ 60 por mes, principalmente debido a los costos de almacenamiento en el disco duro. Para un staker de 32 ETH ($ 84,000 en el momento de escribir este artículo), esto disminuye el APY en (60 * 12) / 84000 ~= 0.85% . Si los rendimientos totales del staking caen por debajo del 0,85%, el staking en solitario será inviable para muchas personas en estos niveles.

Si queremos que el staking en solitario siga siendo viable, esto pone aún más énfasis en la necesidad de reducir los costos de operación del nodo, lo cual se hará en el Verge: la falta de estado eliminará los requisitos de espacio de almacenamiento, lo que puede ser suficiente por sí solo, y luego las pruebas de validez de L1 EVM harán que los costos sean completamente triviales.

Por otro lado, la quema de MEV ayuda, discutiblemente, al staking en solitario. Aunque disminuye los rendimientos para todos, disminuye más importante la varianza, haciendo que el staking sea menos parecido a una lotería.

Finalmente, cualquier cambio en la emisión interactúa con otros cambios fundamentales en el diseño de staking (por ejemplo, staking arcoíris). Un punto particular de preocupación es que si los rendimientos del staking se vuelven muy bajos, esto significa que tenemos que elegir entre (i) hacer que las penalizaciones también sean bajas, reduciendo los desincentivos contra el mal comportamiento, y (ii) mantener las penalizaciones altas, lo que aumentaría el conjunto de circunstancias en las que incluso los validadores bien intencionados terminan accidentalmente con rendimientos negativos si tienen problemas técnicos o incluso ataques.

Soluciones de capa de aplicación

Las secciones anteriores se centraron en los cambios en el nivel 1 de Ethereum que pueden resolver importantes riesgos de centralización. Sin embargo, Ethereum no es solo un nivel 1, es un ecosistema, y también hay estrategias importantes a nivel de aplicación que pueden ayudar a mitigar los riesgos mencionados anteriormente. Algunos ejemplos incluyen:

• Soluciones especializadas de hardware de participación: algunas empresas, como Dappnode, están vendiendo hardware que está diseñado específicamente para que sea lo más fácil posible operar un nodo de staking. Una forma de hacer esta solución más efectiva es hacer la siguiente pregunta: si un usuario ya está haciendo el esfuerzo de tener una caja funcionando y conectada a Internet 24/7, ¿qué otros servicios podría proporcionar (al usuario o a otros) que se beneficien de la descentralización? Algunos ejemplos que vienen a la mente incluyen (i) ejecutar LLMs alojados localmente, por razones de soberanía y privacidad, y (ii) ejecutar nodos para una VPN descentralizada.
• Squad staking - estosolución de Obolpermite que varias personas apuesten juntas en un formato M-de-N. Esto probablemente se volverá cada vez más popular con el tiempo, ya que la falta de estado y posteriormente las pruebas de validez de L1 EVM reducirán los costos operativos de ejecutar más nodos, y el beneficio de que cada participante individual tenga que preocuparse mucho menos por estar en línea todo el tiempo comienza a dominar. Esta es otra forma de reducir la carga cognitiva de la apuesta y garantizar que la apuesta en solitario prospere en el futuro.
• Airdrops: Starknet dio un airdrop a los stakers individuales. Otros proyectos que deseen tener un conjunto descentralizado y alineado con valores de usuarios también pueden considerar dar airdrops o descuentos a validadores que se identifiquen como probablemente siendo apostadores individuales.
• Mercados de construcción de bloques descentralizados - utilizando una combinación de ZK, MPC y TEEs, es posible crear un constructor de bloques descentralizado que participe y gane en el juego de subastas APS, pero al mismo tiempo brinde privacidad previa a la confirmación y garantías de resistencia a la censura a sus usuarios. Este es otro camino hacia la mejora del bienestar de los usuarios en un mundo APS.
• Minimización de MEV en la capa de aplicación: las aplicaciones individuales pueden construirse de manera que "filtren" menos MEV a L1, reduciendo el incentivo para que los constructores de bloques creen algoritmos especializados para recopilarlo. Una estrategia simple que es universal, aunque inconveniente y rompedora de composibilidad, es que el contrato ponga todas las operaciones entrantes en una cola y las ejecute en el próximo bloque, y subaste el derecho a saltar la cola. Otros enfoques más sofisticados incluyen hacer más trabajo fuera de la cadena, por ejemplo, como Intercambio de vacasOráculos también pueden ser rediseñados para minimizarvalor extraíble del oráculo.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [Vitalik Buterin], Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo, y ellos lo manejarán rápidamente.
2. Renuncia de responsabilidad: Las opiniones y puntos de vista 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 son realizadas por el equipo de Aprende gate. A menos que se mencione lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.