Autor: Vitalik, fundador de Ethereum; Compilador: Deng Tong, Golden Finance;
Nota: Este artículo es la tercera parte de la serie de artículos "Posibles futuros del protocolo Ethereum, parte 3: El Azote" publicado recientemente por Vitalik, el fundador de Ethereum. Para la segunda parte, consulte "Vitalik: Cómo debería desarrollarse el protocolo Ethereum durante la etapa The Surge" de Golden Finance, y para la primera parte, consulte "Qué más se puede mejorar en Ethereum PoS". El siguiente es el texto completo de la tercera parte:
Un agradecimiento especial a Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes y Max Resnick por sus comentarios y reseñas, así como a la comunidad de ethstakers por las discusiones.
Uno de los mayores riesgos que enfrenta Ethereum L1 es la centralización de la Prueba de Participación debido a las presiones económicas. Si existen economías de escala al participar en el mecanismo principal de prueba de participación, esto naturalmente conducirá a que las grandes partes interesadas dominen y las pequeñas partes interesadas salgan para unirse a los grandes grupos mineros. Esto resulta en un mayor riesgo de ataques del 51%, censura 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 grupo de personas captura valor que de otro modo iría a parar a los usuarios de Ethereum.
Nuestra comprensión de estos riesgos ha aumentado significativamente durante el año pasado. Se sabe que este riesgo existe en dos lugares clave: (i) construcción de bloques y (ii) regulaciones de capital de participación. Los jugadores más grandes pueden ejecutar algoritmos más complejos ("extracción MEV") para generar bloques, lo que les brinda mayores ingresos por bloques. Los grandes jugadores también pueden resolver de manera más efectiva los inconvenientes de los fondos bloqueados entregándolos a otros como Liquid Staked Tokens (LST). Más allá de la cuestión inmediata de los pequeños frente a los grandes apostadores, también está la cuestión de si se apostará (o se apostará) demasiado ETH.
Hoja de ruta de la Plaga 2023
Este año se ha visto un progreso significativo en la construcción de bloques, en particular la convergencia de "listas de inclusión de comités más algunas soluciones de pedidos específicas" como la solución ideal, y una investigación significativa sobre la economía de la prueba de participación, incluidas dos capas, etc. el modelo de participación y reducir la emisión para limitar el porcentaje de ETH apostado.
Camino de construcción de bloques de refuerzo
¿Qué problema estamos tratando de resolver?
Hoy en día, la construcción de bloques de Ethereum se realiza principalmente a través de la separación fuera de protocolo entre propser y builder de MEVBoost. Cuando a los validadores se les da la oportunidad de proponer un bloque, asignan la tarea de seleccionar el contenido del bloque a actores especializados llamados constructores. La tarea de seleccionar contenido en bloque que maximice los ingresos requiere economías de escala: se requieren algoritmos especializados para determinar qué transacciones incluir para extraer el mayor valor posible de las transacciones de los instrumentos financieros en cadena y de los usuarios que interactúan con ellos. (Esto se llama "extracción MEV"). Los validadores se enfrentan a la tarea “tonta” de escuchar las ofertas y aceptar la oferta más alta, con economías de escala relativamente ligeras, además de otras responsabilidades como la certificación.
Diagrama estilizado de lo que está haciendo MEVBoost: los constructores dedicados asumen tareas en rojo, las partes interesadas asumen tareas en azul.
Hay varias versiones, incluida la "Separación proponente-constructor" (PBS) y la "Separación probador-proponente" (APS). La diferencia entre ellos tiene que ver con los detalles detallados de qué responsabilidades recaen en cuál de los dos participantes: en términos generales, en PBS, el validador todavía propone el bloque pero recibe la carga útil del constructor, mientras que en APS, todo el espacio se convierte en responsabilidad del constructor. Recientemente, APS se ha visto favorecido sobre PBS porque reduce aún más el incentivo para que los proponentes coubiquen con los constructores. Tenga en cuenta que APS solo se aplica a los bloques de ejecución que contienen transacciones; los bloques de consenso que contienen datos relacionados con la prueba de participación (por ejemplo, pruebas) aún se asignarán 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 tareas “especializadas” pueden volverse muy centralizados fácilmente. Aquí está la construcción del bloque Ethereum de hoy:
Dos participantes seleccionan el contenido de aproximadamente el 88% de los bloques de Ethereum. ¿Qué pasa si estos dos participantes deciden revisar la transacción? La respuesta no es tan mala como parece: no pueden reorganizar bloques, por lo que no se necesita ninguna censura del 51% para evitar que se incluyan transacciones: se necesita el 100%. Con una moderación del 88%, los usuarios tuvieron que esperar un promedio de 9 espacios (técnicamente, el promedio fue de 114 segundos, no de 6 segundos). Para algunos casos de uso, está bien esperar dos minutos o incluso cinco minutos para determinadas transacciones. Pero para otros casos de uso, como en la compensación de DeFi, incluso poder retrasar unos pocos bloques la inclusión de transacciones de otras personas supone un riesgo importante de manipulación del mercado.
Las estrategias que los creadores de bloques pueden utilizar para maximizar los ingresos también pueden tener otros impactos negativos en los usuarios. Un "ataque sándwich" puede hacer que los usuarios que intercambian tokens sufran pérdidas significativas debido al deslizamiento. Las transacciones introducidas para permitir que estos ataques obstruyan la cadena aumentan el precio del gas para otros usuarios.
¿Qué es y cómo funciona?
La solución principal es descomponer aún más la tarea de producción de bloques: devolvemos la tarea de seleccionar transacciones al proponente (es decir, al apostador), mientras que el constructor solo puede elegir ordenar e insertar algunas de sus propias transacciones. Eso es lo que intenta hacer la lista contenedora.
En el momento T, un participante seleccionado al azar crea una lista de inclusión, una lista de transacciones que son válidas en el estado actual de la cadena de bloques en ese momento. En el momento T+1, el constructor de bloques (posiblemente seleccionado de antemano mediante un mecanismo de subasta dentro del protocolo) crea un bloque. El bloque debe contener todas las transacciones en la lista de inclusión, pero pueden elegir el orden y agregar sus propias transacciones.
La propuesta de la Lista de inclusión obligatoria de Fork Choice (FOCIL) implica un comité de múltiples creadores de listas de inclusión por bloque. Para que una transacción se retrase en un bloque, k de los k creadores de la lista de inclusión (por ejemplo, k = 16) deben revisar la transacción. La combinación de FOCIL y el proponente final seleccionado a través de la subasta debe incluir la lista de inclusión, pero se puede reordenar y agregar nuevas transacciones, a menudo denominadas "FOCIL + APS".
Otra forma de resolver este problema es un esquema de proponentes múltiples concurrentes (MCP), como BRAID. BRAID intenta 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 cambio, intenta distribuir el proceso de producción de bloques entre muchos participantes de modo que cada proponente participante solo necesite tienen un nivel moderado de complejidad pueden maximizar sus ingresos. MCP funciona haciendo que k proponentes paralelos generen una lista de transacciones y luego utilicen un algoritmo determinista (por ejemplo, ordenar por tarifa de mayor a menor) para seleccionar el orden.
BRAID no busca lograr el objetivo de ejecutar el proponente de bloques de tubería tonta del software predeterminado de manera óptima. Dos razones fáciles de entender por las que no puede hacer esto son:
Ataque de arbitraje del segundo actor: suponga que el tiempo promedio para que los proponentes envíen es T, y la última vez que puede enviar y aún ser incluido es aproximadamente T+1. Ahora, supongamos que en el intercambio centralizado, el precio ETH/USDC va de $2500 a $2502 entre T y T+1. Los proponentes pueden esperar un segundo más y agregar transacciones adicionales para arbitrar intercambios descentralizados en cadena, obteniendo hasta $2 de ganancia por ETH. Los proponentes sofisticados que están bien conectados a sus redes están mejor equipados para hacerlo.
Flujo de pedidos exclusivo: los usuarios tienen un incentivo para enviar transacciones directamente a un único proponente para minimizar su vulnerabilidad a ataques frontales y de otro tipo. Los proponentes experimentados tienen una ventaja porque pueden construir la infraestructura para aceptar estas transacciones directamente de los usuarios y tienen una reputación más sólida, por lo que los usuarios que les envían transacciones pueden confiar en que el proponente no desertará ni se adelantará a la transacción (esto se puede mitigar). utilizando hardware confiable, pero el hardware confiable tiene sus propios supuestos de confianza).
En BRAID, el probador aún se puede desconectar y ejecutar como una función de tubería tonta.
Más allá de estos dos extremos, existe una variedad de diseños posibles en el medio. Por ejemplo, podrías subastar personajes que sólo tienen derecho a adjuntarse a bloques, pero no a reordenarse o al frente. Incluso puede agregarlos o colocarlos al frente, pero no insertarlos ni reordenarlos. El atractivo de estas técnicas es que los ganadores en los mercados de subastas pueden estar muy concentrados, por lo que reducir su autoridad tiene muchos beneficios.
Grupo de memoria cifrado
Una tecnología que es fundamental para la implementación exitosa de muchos de estos diseños (específicamente, las versiones BRAID o APS donde existen severas restricciones en la funcionalidad de subasta) son los grupos de memoria cifrados. Crypto mempool es una tecnología en la que los usuarios transmiten sus transacciones en forma cifrada, junto con algún tipo de prueba de validez, y la transacción se incluye en un bloque en forma cifrada sin que el creador del bloque conozca su contenido. Los detalles de la transacción se anunciarán más adelante.
El principal desafío al implementar un mempool criptográfico es idear un diseño que garantice que todas las transacciones se divulguen posteriormente: un simple esquema de "enviar y divulgar" no funcionará, porque si la divulgación es voluntaria, el acto de elegir revelar o no revelar es en sí mismo una influencia de "último movimiento" sobre los bloques que pueden ser explotados. Las dos técnicas principales son (i) descifrado de umbral y (ii) cifrado retardado, una primitiva estrechamente relacionada con la función de retardo verificable (VDF).
¿Cuáles son las conexiones con la investigación existente?
MEV y la descentralización del constructor explicadas: https://vitalik.eth.limo/general/2024/05/17/decentralization.html#mev-and-builder-dependence
MEVBoost: https://github.com/flashbots/mev-boost
PBS consagrado (una de las primeras soluciones propuestas a estos problemas): https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710
Lista de inclusión de Mike Neuder Lista de lecturas relacionadas: https://gist.github.com/michaelneuder/dfe5699cb245bc99fbc718031c773008
Contiene una lista de 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
Demostración de BRAID de Max Resnick: https://www.youtube.com/watch?v=mJLERWmQ2uw
“La prioridad es todo lo que necesitas” de Dan Robinson: https://www.paradigm.xyz/2024/06/priority-is-all-you-need
Acerca del protocolo y el dispositivo de múltiples propuestas: https://hackmd.io/xz1UyksETR-pCsazePMAjw
VDFResearch.org: https://vdfresearch.org/
Funciones de retardo y ataques verificables (centrados en la configuración de RANDAO, pero también aplicables a grupos de memoria cifrados): https://ethresear.ch/t/verABLE-delay-functions-and-attacks/2365
MEV realiza captura y descentralización de tickets: https://www.arxiv.org/pdf/2408.11255
Centralización de APS: https://arxiv.org/abs/2408.03116
MEV multibloque y lista de inclusión: https://x.com/_charlienoyes/status/1806186662327689441
¿Qué más hay que hacer? ¿Qué concesiones hay que hacer?
Podemos pensar en todos los escenarios anteriores como diferentes formas de dividir la autoridad para participar en las apuestas, dispuestas a lo largo de un espectro que va desde economías de escala más bajas (“dumb-pipe”) hasta economías de escala más altas (“favorables a la especialización”). Antes de 2021, todos estos permisos estaban agrupados en un solo actor:
El dilema central es el siguiente: cualquier poder significativo que permanezca en manos de las partes interesadas puede terminar convirtiéndose en un poder “relacionado con el MEV”. Queremos que un conjunto de actores altamente descentralizado tenga el mayor poder posible; esto significa (i) poner mucho poder en manos de las partes interesadas y (ii) garantizar que las partes interesadas estén lo más descentralizadas posible, lo que significa que casi están allí. No existen incentivos de consolidación impulsados por economías de escala. Ésta es una tensión difícil de afrontar.
Un desafío especial es el MEV multibloque: en algunos casos, los ganadores de la subasta de ejecución que capturan múltiples espacios seguidos no pueden hacer nada relacionado con MEV en bloques que no sean el último bloque que controlan, pueden ganar más dinero. Si la lista de inclusión los obliga a hacer esto, entonces pueden intentar evitarlo no publicando ningún bloqueo durante estos momentos. Se podría hacer una lista de inclusión incondicional que simplemente se convertiría en un bloque si el constructor no proporcionara una, pero esto hace que la lista de inclusión sea dependiente de MEV. La solución aquí puede implicar algún compromiso, incluida la aceptación de 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 interesados siguen teniendo poder sobre la parte izquierda del espectro, mientras que la parte derecha del espectro se subasta al mejor postor.
TRENZADA es completamente diferente. La sección "Partes interesadas" es más grande, pero está dividida en dos partes: participantes ligeros y participantes pesados. Al mismo tiempo, dado que las transacciones se ordenan en orden descendente de tarifas de prioridad, la selección en la parte superior del bloque en realidad se subasta a través del mercado de tarifas, un esquema que puede considerarse similar al PBS.
Tenga en cuenta que la seguridad de BRAID depende en gran medida del mempool cifrado; de lo contrario, el mecanismo de subasta superior del bloque es vulnerable a ataques de robo de políticas (esencialmente: copiar las transacciones de otras personas, intercambiar direcciones de destinatarios y pagar tarifas elevadas del 0,01%). Esta necesidad de privacidad pre-inclusiva es también la razón por la que PBS es tan complicado de implementar.
Finalmente, una versión más “agresiva” de FOCIL + APS, p.e. La opción de APS para determinar solo el final de un bloque es la siguiente:
Las principales tareas pendientes son (i) trabajar para solidificar las diversas propuestas y analizar sus consecuencias, y (ii) combinar este análisis con una comprensión de los objetivos de la comunidad Ethereum, es decir, qué formas de centralización tolerará. Cada propuesta individual también requiere algo de trabajo, como por ejemplo:
Continuar trabajando en el diseño del grupo de memoria criptográfica y llegar al punto en que nuestro diseño sea robusto y bastante simple y parezca estar listo para su inclusión.
Optimice el diseño de múltiples listas de inclusión para garantizar que (i) no se desperdicie ningún dato, especialmente en el contexto de listas de inclusión que contienen blobs, y (ii) sea amigable con los validadores sin estado.
Más trabajo sobre el diseño óptimo de subastas para APS.
Además, es importante señalar que estas diferentes propuestas no son necesariamente bifurcaciones en el camino mutuamente incompatibles. Por ejemplo, implementar FOCIL + APS podría servir fácilmente como un trampolín para implementar BRAID. Una estrategia conservadora efectiva es un enfoque de "esperar y ver", donde primero implementamos una solución donde los permisos de los participantes están restringidos y una gran parte de los permisos se subastan, y luego, con el tiempo, a medida que operamos el mercado MEV en la red en vivo de aprender más, aumentando lentamente el poder de las partes interesadas.
En particular, los obstáculos centralizados de las apuestas son:
Centralización de la construcción de bloques (esta sección)
Centralización de apuestas por razones económicas (siguiente sección)
Centralización de participación debido a un mínimo de 32 ETH (resuelto por Orbit u otras tecnologías; consulte la publicación sobre consolidación)
Centralización de apuestas debido a requisitos de hardware (abordado en Verge con clientes sin estado y posteriormente ZK-EVM)
Resolver cualquiera de estos cuatro problemas aumenta la rentabilidad de resolver cualquiera de los otros problemas.
Además, existe una interacción entre el proceso de construcción de bloques y el diseño final de una sola ranura, especialmente cuando se intenta reducir los tiempos de las ranuras. Muchos diseños de tuberías de construcción en bloques terminan agregando tiempos de ranura. Muchas tuberías de construcción de bloques implican el papel de un probador en múltiples pasos del proceso. Por lo tanto, vale la pena considerar tanto el proceso de construcción del bloque como la finalidad de una sola ranura.
Arreglar la economía de las apuestas
¿Qué problema estamos tratando de resolver?
Hoy en día, aproximadamente el 30% del suministro de ETH está apostado activamente. Esto es suficiente para proteger a Ethereum de un ataque del 51%. Si la proporción de ETH apostada aumenta, a los investigadores les preocupa que pueda surgir un escenario diferente: si se apuesta casi todo el ETH, surgirían riesgos. Estos riesgos incluyen:
El stake pasó de ser una tarea rentable para los expertos a convertirse en responsabilidad de todos los poseedores de ETH. Por lo tanto, el apostador promedio estará menos entusiasmado y elegirá la forma más fácil (de hecho, delegando sus tokens al operador centralizado más conveniente).
Si se apuesta casi todo el ETH, el mecanismo de reducción se vuelve menos creíble
Un único token de participación líquida podría hacerse cargo de la mayor parte de la participación e incluso del efecto de red "monetario" del propio ETH.
Ethereum emite innecesariamente alrededor de 1 millón de ETH adicionales cada año. En el caso de que un token de apuesta líquida obtenga efectos de red dominantes, LST puede incluso capturar una parte significativa de ese valor.
¿Qué es y cómo funciona?
Históricamente, una clase de soluciones ha sido: si apostar es inevitable para todos, y la liquidez de los tokens de apuestas es inevitable, entonces hagamos que las apuestas sean amigables para tener algo que en realidad sea un token de apuesta de liquidez neutral, neutral y máximamente descentralizado. Un enfoque simple sería limitar la penalización por apuesta a 1/8, lo que haría que 7/8 del ETH apostado no sean deducibles y, por lo tanto, elegibles para ser colocados en los mismos tokens de apuesta líquidos. Otra opción es crear explícitamente dos niveles de participación: participación "con riesgo" (reducible).
Sin embargo, una crítica a este enfoque es que parece ser el equivalente económico de algo mucho más simple: reducir drásticamente la emisión si el capital se acerca a un límite predeterminado. El argumento básico es: si terminamos en un mundo donde la capa que toma riesgos rinde un 3,4% y la capa libre de riesgo (todos participan) rinde un 2,6%, ese es efectivamente el mismo mundo que apostar ETH con un rendimiento del 0,8%. la tasa de retorno por tener solo ETH es del 0%. La dinámica del nivel de toma de riesgos, incluido el monto total apostado y el grado de centralización, es la misma en ambos casos. Entonces deberíamos hacer lo simple y emitir menos.
La principal objeción a este argumento es si podemos tener una "capa libre de riesgo" que todavía tenga algún papel útil y cierto grado de riesgo (por ejemplo, como propone Dankrad aquí).
Ambas sugerencias significarían cambiar la curva de emisión de modo que si el monto del capital es demasiado alto, los rendimientos serán extremadamente bajos.
Izquierda: Una propuesta de Justin Drake para ajustar la curva de distribución. Derecha: Otro conjunto de propuestas de Anders Elowsson.
Por otro lado, las apuestas de dos niveles requieren establecer dos curvas de recompensa: (i) la tasa de rendimiento de las apuestas “básicas” (libres de riesgo o de bajo riesgo), y (ii) la prima por las apuestas riesgosas. Hay varias formas de establecer estos parámetros: por ejemplo, si establece un parámetro estricto de que 1/8 de su capital es recortable, entonces la dinámica del mercado determinará la prima en los rendimientos obtenidos sobre el capital recortable.
Otro tema importante aquí es la captura MEV. Hoy en día, los ingresos MEV (por ejemplo, arbitraje DEX, sándwich...) fluyen hacia los proponentes, es decir, los participantes. Se trata de ingresos que son completamente "opacos" para el protocolo: el protocolo no tiene forma de saber si es una TAE del 0,01%, una TAE del 1% o una TAE del 20%. La existencia de este flujo de ingresos es inconveniente desde múltiples perspectivas:
Se trata de un flujo de ingresos inestable, ya que cada parte interesada sólo lo obtiene cuando propone un bloque, que ahora ocurre aproximadamente cada 4 meses. Esto incentiva a las personas a unirse al grupo para obtener ingresos más estables.
Conduce a una distribución desequilibrada de los incentivos: demasiadas propuestas, muy pocas pruebas.
Esto hace que sea difícil hacer cumplir los límites de participación: incluso si la tasa de rendimiento "oficial" es cero, los ingresos de MEV por sí solos pueden ser suficientes para impulsar a todos los titulares de ETH a apostar. Por lo tanto, una propuesta realista de tope de capital tendría que llevar los rendimientos cerca del infinito negativo. Esto conlleva más riesgos para los apostadores, especialmente para los apostadores individuales.
Podemos resolver estos problemas encontrando una manera de hacer que los ingresos de MEV sean claramente visibles en el protocolo y capturarlos. La primera propuesta fue la suavización de MEV de Francesco; hoy en día se acepta generalmente que cualquier mecanismo que las subastas bloqueen los derechos de los proponentes por adelantado (o, más generalmente, que tenga suficiente poder para capturar casi todos los MEV) puede lograr el mismo objetivo.
¿Cuáles son las conexiones con la investigación existente?
Problema wtf: https://issuance.wtf/
Economía del juego final, caso de focalización: https://ethresear.ch/t/endgame-stake-economics-a-case-for-targeting/18751
Propiedades a nivel de emisión, Anders Elowsson: https://ethresear.ch/t/properties-of-issuance-level-consensus-incentives-and-variability-across-pottial-reward-curves/18448
Límite de tamaño de configuración del validador: https://notes.ethereum.org/@vbuterin/single_slot_finality?type=view#Economic-capping-of-total-deposits
Reflexiones sobre la idea del stake multicapa: https://notes.ethereum.org/@vbuterin/stake_2023_10?type=view
Estaca arcoíris: https://ethresear.ch/t/unbundling-stake-towards-rainbow-stake/18683
Propuesta de participación líquida de Dankrad: https://notes.ethereum.org/Pcq3m8B8TuWnEsuhKwCsFg
Suavizado MEV, autor: Francesco: https://ethresear.ch/t/committee-driven-mev-smoothing/10408
Quema de MEV, autor: Justin Drake: https://ethresear.ch/t/mev-burn-a-simple-design/15590
¿Qué más hay que hacer, qué concesiones hay que hacer?
La principal tarea restante es aceptar no tomar ninguna medida y aceptar el riesgo de que casi todo ETH esté en LST, o finalizar y acordar los detalles y parámetros de una de las propuestas anteriores. Un resumen aproximado de los beneficios y riesgos es el siguiente:
¿Cómo interactúa con otras partes de la hoja de ruta?
Un punto de cruce importante se relaciona con las apuestas en solitario. Hoy en día, el VPS más barato que puede ejecutar un nodo Ethereum cuesta alrededor de $60 por mes, principalmente debido a los costos de almacenamiento en el disco duro. Para un apostador de 32 ETH ($84,000 al momento de escribir este artículo), esto reduciría el APY en (60 * 12) / 84000 ~= 0,85%. Si el rendimiento total de la apuesta es inferior al 0,85%, entonces apostar por sí solo no es factible para muchas personas en este nivel.
Esto enfatiza aún más la necesidad de reducir los costos operativos del nodo si queremos que el scking en solitario siga siendo viable, lo que se hará en Verge: stateless eliminará los requisitos de espacio de almacenamiento, que pueden ser suficientes por sí solos, y luego la prueba L1 EVM. La falta de validez hará que el costo sea insignificante.
Por otro lado, se podría decir que la quema de MEV ayuda con las apuestas individuales. Si bien reduce los retornos de todos, lo más importante es que reduce la variación, lo que hace que apostar sea menos una lotería.
Finalmente, cualquier cambio en la emisión interactuará con otros cambios fundamentales en el diseño de apuestas (por ejemplo, apuestas arcoíris). Una preocupación particular es si los rendimientos de las apuestas se vuelven muy bajos, lo que significa que tenemos que elegir entre (i) reducir las sanciones y reducir los desincentivos por mal comportamiento (ii) mantener sanciones más altas aumentará el número de situaciones en las que incluso los validadores bien intencionados pueden hacerlo; reciben inesperadamente retornos negativos si desafortunadamente encuentran problemas técnicos o incluso ataques.
Soluciones de capa de aplicación
La sección anterior destaca los cambios en Ethereum L1 que abordan importantes riesgos de centralización. Sin embargo, Ethereum es más que solo una L1, es un ecosistema y existen importantes estrategias de capa de aplicación que pueden ayudar a mitigar los riesgos anteriores. Algunos ejemplos incluyen:
Soluciones de hardware de replanteo especializadas: algunas empresas, como Dappnode, venden hardware diseñado específicamente para hacer que operar un nodo de replanteo sea lo más fácil posible. Una forma de hacer que esta solución sea más efectiva es hacer la siguiente pregunta: si un usuario ya se ha esforzado para que una caja funcione y esté conectada a Internet, ¿qué otros servicios puede proporcionar (al usuario o a otros) que se beneficiarían de la descentralización? ? Los ejemplos que me vienen a la mente incluyen (i) ejecutar LLM alojados localmente por razones de soberanía propia y privacidad, y (ii) nodos que ejecutan VPN descentralizadas.
Squad Stake: esta solución de Obol permite que varias personas realicen apuestas juntas en un formato M de N. Es probable que esto se vuelva más popular con el tiempo, ya que la prueba de efectividad de EVM L1 sin estado y posterior reducirá la sobrecarga de ejecutar más nodos y los beneficios de que cada participante no tenga que preocuparse por estar siempre en línea comiencen a tomar posesión del estado. Esta es otra forma de reducir la sobrecarga cognitiva de las apuestas y garantizar que las apuestas en solitario prosperen en el futuro.
Lanzamientos aéreos: Starknet ofrece lanzamientos aéreos a apostadores individuales. Otros proyectos que buscan tener una base de usuarios descentralizada y alineada con valores también pueden considerar ofrecer lanzamientos aéreos o descuentos a validadores identificados como posibles partes interesadas individuales.
Mercado de creación de bloques descentralizado: utilizando una combinación de ZK, MPC y TEE, es posible crear un constructor de bloques descentralizado que pueda participar y ganar el juego de subasta APS, pero al mismo tiempo proporcionar privacidad previamente confirmada y resistencia a la censura para garantizar su usuario. Esta es otra vía para mejorar el bienestar de los usuarios en el mundo APS.
Minimización de MEV en la capa de aplicación: las aplicaciones individuales se pueden crear de manera que "filtren" menos MEV a L1, lo que reduce el incentivo para que los constructores de bloques creen algoritmos especializados para recopilar MEV. Una estrategia simple pero común es que el contrato ponga en cola todas las operaciones entrantes y las ejecute en el siguiente bloque, y subaste el derecho a saltar la cola, aunque sea inconveniente y rompa la componibilidad. Otros enfoques más sofisticados incluyen hacer más trabajo fuera de la cadena, p. Tal como lo hace Cowswap. Los oráculos también se pueden rediseñar para minimizar el valor que el oráculo puede extraer.
