Autor original: Vitalik

Compilación original: Deng Tong, Golden Finance

Mientras estoy sentado aquí escribiendo esto en el último día de Ethereum Developer Interop en Kenia, hemos logrado grandes avances en la implementación y resolución de los detalles técnicos de importantes mejoras futuras de Ethereum, en particular PeerDAS, la transición del árbol Verkle y los métodos descentralizados para almacenar el historial. en el contexto de EIP 4444. Desde mi propia perspectiva, el ritmo de desarrollo de Ethereum y nuestra capacidad para ofrecer funciones grandes e importantes que mejoran significativamente la experiencia de los operadores de nodos y los usuarios (L1 y L2) aumentan constantemente.

El equipo de clientes de Ethereum trabaja en conjunto para ofrecer Pectra devnet

Dado el aumento de las capacidades tecnológicas, una pregunta importante que cabe plantearse es: ¿estamos avanzando hacia los objetivos correctos? Una serie reciente de tweets descontentos del veterano desarrollador central de Geth, Peter Szilagyi, nos hizo pensar en esto:

Estas preocupaciones son válidas. Esta es una preocupación expresada por muchos en la comunidad Ethereum. Personalmente me he preocupado muchas veces por estos temas. Sin embargo, tampoco creo que la situación sea tan desesperada como sugiere el tweet de Peter. En cambio, muchos problemas ya se están abordando a través de funciones de protocolo en curso, mientras que muchos otros podrían abordarse con ajustes muy reales a la hoja de ruta actual.

Para entender lo que esto significa en la práctica, revisemos los tres ejemplos que ofrece Peter. Estos problemas son preocupaciones comunes entre muchos miembros de la comunidad y es importante abordarlos.

MEV y dependencias del constructor

En el pasado, los bloques de Ethereum eran creados por mineros, que utilizaban algoritmos relativamente simples para crear bloques. Los usuarios envían transacciones a una red p2p pública, a menudo denominada "mempool" (o "txpool"). Los mineros escuchan el mempool, aceptan transacciones válidas y pagan tarifas. Incluyen las transacciones que se pueden realizar y, si no hay suficiente espacio, se priorizan por orden de tarifa más alta.

Es un sistema muy simple y compatible con la descentralización: como minero, simplemente ejecuta el software predeterminado y obtiene el mismo nivel de ingresos por tarifas de un bloque que obtendría de una granja minera altamente profesional. Sin embargo, alrededor de 2020, la gente comenzó a aprovechar el llamado valor extraíble minero (MEV): ingresos que solo se pueden obtener ejecutando estrategias complejas que comprendan las actividades que tienen lugar dentro de varios protocolos defi.

Por ejemplo, considere un intercambio descentralizado como Uniswap. Supongamos que en el momento T, el tipo de cambio USD/ETH en los intercambios centralizados y Uniswap es de $3000. En T+11, el tipo de cambio USD/ETH en el intercambio centralizado aumentó a $3,005. Pero Ethereum aún no tiene el siguiente bloque. En el momento T+12, este es efectivamente el caso. Quien haya creado el bloque, su primera transacción podría ser una serie de compras en Uniswap para comprar todo el ETH disponible en Uniswap por entre $3000 y $3004. Se trata de un ingreso adicional, llamado MEV. Otras aplicaciones además de DEX tienen problemas similares. El artículo Flash Boys 2.0 publicado en 2019 detalla esto en detalle.

El gráfico del documento Flash Boys 2.0 muestra la cantidad de ingresos que se pueden obtener utilizando cada uno de los métodos anteriores.

El problema es que esto rompe la razón por la que la minería (o las propuestas de bloques posteriores a 2022) pueden ser "justas": ahora, los grandes jugadores con mejores capacidades para optimizar dichos algoritmos de extracción pueden obtener más buenos rendimientos en cada bloque.

Desde entonces, ha habido un debate continuo entre dos estrategias, que yo llamo minimización de MEV y aislamiento de MEV. La minimización de MEV se presenta de dos formas: (i) desarrollar activamente alternativas libres de MEV a Uniswap (por ejemplo, Cowswap) y (ii) crear tecnología dentro del protocolo, como grupos de memoria criptográfica que reducen la información disponible para los productores de bloques, reduciendo así sus ingresos. que se puede obtener. En particular, los mempools cifrados previenen estrategias como los ataques sándwich, que colocan transacciones antes y después de las transacciones de los usuarios para explotarlas económicamente (“front-running”).

La segregación MEV funciona aceptando MEV pero tratando de limitar su impacto en la centralización de apuestas dividiendo el mercado en dos tipos de participantes: los validadores son responsables de probar y proponer bloques, pero la tarea de seleccionar el contenido del bloque se realiza a través de un protocolo de subasta. Los apostadores individuales ahora ya no necesitan preocuparse por optimizar el arbitraje DeFi; simplemente se unen al protocolo de subasta y aceptan la oferta más alta; Esto se llama separación entre proponente y constructor (PBS). Este enfoque tiene precedentes en otras industrias: una de las principales razones por las que los restaurantes han podido permanecer tan descentralizados es que tienden a depender de un conjunto bastante centralizado de proveedores para sus diversas operaciones, que sí tienen enormes economías de escala. Hasta ahora, PBS ha tenido bastante éxito en garantizar que los validadores grandes y pequeños estén en igualdad de condiciones, al menos en lo que respecta a MEV. Sin embargo, crea otro problema: la tarea de elegir qué transacciones incluir se vuelve más centralizada.

Mi opinión al respecto siempre ha sido que la minimización de MEV es buena y deberíamos perseguirla (¡yo personalmente uso mucho Cowswap!). Aunque existen muchos desafíos con los mempools cifrados, la minimización de MEV puede no ser suficiente; incluso cerca de cero. Entonces también necesitamos algún tipo de aislamiento MEV. Esto nos lleva a una tarea interesante: ¿Cómo conseguimos que la "caja de aislamiento MEV" sea lo más pequeña posible? ¿Cómo podemos dar a los constructores la menor cantidad de poder posible y al mismo tiempo permitirles absorber los efectos del arbitraje de optimización y otras formas de recopilación de MEV?

Si el constructor tiene el poder de excluir completamente las transacciones del bloque, pueden ocurrir ataques fácilmente. Supongamos que tiene una posición de deuda garantizada (CDP) en un protocolo defi, respaldada por un activo cuyo precio está cayendo rápidamente. Quiere agregar garantía o salir del CDP. Los constructores maliciosos pueden intentar confabularse para rechazar operaciones que lo incluyan, retrasando así las operaciones hasta que el precio baje lo suficiente como para forzar la liquidación de su CDP. Si esto sucede, tendrá que pagar una multa considerable y el constructor se quedará con una gran parte. Entonces, ¿cómo evitamos que los constructores excluyan transacciones y completen este tipo de ataque?

Aquí es donde entran las listas incluidas.

Fuente: ethresear.ch

La lista de inclusión permite a los proponentes del bloque (es decir, las partes interesadas) seleccionar las transacciones necesarias para ingresar al bloque. Los constructores aún pueden reordenar transacciones o insertar sus propias transacciones, pero deben incluir las transacciones del proponente. Finalmente, se modificó la lista de inclusión para restringir el siguiente bloque en lugar del bloque actual. En cualquier caso, le quitan la capacidad al constructor de sacar las transacciones completamente del bloque.

MEV es un problema complejo; incluso la descripción anterior pasa por alto muchos matices importantes. Como dice el refrán: "Puede que no estés buscando MEV, pero MEV te está buscando a ti". Los investigadores de Ethereum han sido muy consistentes en trabajar hacia el objetivo de "minimizar la contención", minimizando el daño que los constructores pueden causar (por ejemplo, excluyendo o retrasando transacciones como una forma de atacar una aplicación específica).

Dicho esto, creo que podemos llegar más lejos. Históricamente, las listas de inclusión a menudo se consideraban una "característica de caso especial": por lo general, no pensarías en ellas, pero en caso de que un constructor malicioso comience a hacer locuras, te darán una "segunda ruta". Esta actitud se refleja en las decisiones de diseño actuales: en el EIP actual, el límite de gas para las listas de inclusión es de aproximadamente 2,1 millones. Pero podemos hacer un cambio filosófico en nuestra forma de pensar sobre las listas de inclusión: pensar en las listas de inclusión como bloques y el papel del constructor como una función auxiliar que agrega algunas transacciones para recopilar MEV. ¿Qué pasa si el constructor tiene un límite de gasolina de 2,1 millones?

Creo que la idea de esta dirección (presionar realmente para que la caja de aislamiento sea lo más pequeña posible) es muy interesante y estoy a favor de ir en esa dirección. Este es un cambio con respecto a la "filosofía 2021": en la filosofía 2021, estamos más entusiasmados con la idea de que, dado que ahora tenemos constructores, podemos "sobrecargar" su funcionalidad y permitirles brindar servicios de usuario de formas más complejas, por ejemplo. . Apoyando el mercado de tarifas ERC-4337. En esta nueva filosofía, la parte de verificación de transacciones de ERC-4337 debe incorporarse al protocolo. Afortunadamente, el equipo ERC-4337 se ha mostrado cada vez más entusiasmado en esta dirección.

Resumen: El pensamiento MEV ha vuelto a la dirección de empoderar a los productores de bloques, lo que incluye otorgarles el poder de garantizar directamente la inclusión de las transacciones de los usuarios. Las propuestas de abstracción de cuentas han vuelto a la dirección de eliminar la dependencia de retransmisores centralizados o incluso paquetes. Sin embargo, se puede argumentar que no hemos ido lo suficientemente lejos, y creo que la presión para impulsar el proceso de desarrollo en esta dirección es muy bienvenida.

Apuesta de liquidez

Hoy en día, los apostadores individuales representan un porcentaje relativamente pequeño de todas las apuestas de Ethereum, y la mayor parte de las apuestas las realizan una variedad de proveedores: algunos operadores centralizados y otros DAO como Lido y RocketPool.

Hice mi propia investigación: varias encuestas, encuestas, conversaciones cara a cara, haciendo la pregunta "¿Por qué usted, especialmente usted, no apuesta solo hoy?" Para mí, hasta ahora, uno poderoso. El ecosistema de apuestas es mi resultado preferido para apostar en Ethereum, y una de las mejores cosas de Ethereum es que en realidad tratamos de respaldar un ecosistema de apuestas separado y fuerte en lugar de simplemente sucumbir a la delegación. Sin embargo, todavía estamos lejos de este resultado. En mis encuestas y sondeos, hay algunas tendencias consistentes:

La gran mayoría de las personas que no apuestan individualmente citan el mínimo de 32 ETH como su razón principal.

De quienes citaron otras razones, la mayor fue el desafío técnico de ejecutar y mantener nodos de validación.

La pérdida de disponibilidad instantánea de ETH, los riesgos de seguridad de las claves privadas "calientes" y la pérdida de la capacidad de participar en protocolos DeFi simultáneamente son problemas importantes pero menores.

Una encuesta de Farcaster reveló las principales razones por las que la gente no apuesta individualmente.

La investigación sobre apuestas debe abordar dos preguntas clave:

¿Cómo abordamos estas preocupaciones?

Aunque existen soluciones válidas para la mayoría de los problemas, si la mayoría de la gente todavía no quiere apostar sola, ¿cómo podemos mantener el protocolo estable y robusto contra ataques a pesar de esto?

Muchos proyectos de investigación y desarrollo en curso tienen como objetivo abordar precisamente estas cuestiones:

Los árboles Verkle junto con EIP-4444 permiten que los nodos de replanteo se ejecuten con requisitos de disco duro muy bajos. Además, permiten que los nodos de replanteo se sincronicen casi instantáneamente, lo que simplifica enormemente cosas como la configuración y el cambio de una implementación a otra. También hacen que los clientes ligeros de Ethereum sean más viables al reducir el ancho de banda de datos requerido para proporcionar pruebas para el acceso de cada estado.

Investigue métodos (como estas propuestas) para permitir conjuntos de validadores más grandes (lo que permite mínimos de participación más pequeños) y al mismo tiempo reducir la sobrecarga del nodo de consenso. Estas ideas se pueden implementar como parte de la finalidad de una sola ranura. Hacerlo también hará que los clientes ligeros sean más seguros, ya que podrán verificar el conjunto completo de firmas en lugar de depender de comités de sincronización).

A pesar de su creciente historia, las optimizaciones continuas del cliente Ethereum continúan reduciendo el costo y la dificultad de ejecutar un nodo validador.

La investigación sobre los límites de penalización puede aliviar las preocupaciones sobre el riesgo de la clave privada y permitir a los participantes apostar simultáneamente su ETH en protocolos DeFi si así lo desean.

0x 01 El certificado de retiro permite al apostador establecer la dirección ETH como dirección de retiro. Esto hace que los grupos de apuestas descentralizados sean más factibles, lo que les otorga una ventaja sobre los grupos de apuestas centralizados.

Sin embargo, todavía podemos hacer más. En teoría, a los validadores se les puede permitir retirarse más rápido: incluso si el conjunto de validadores cambia en unos pocos puntos porcentuales cada vez que se finaliza (es decir, una vez por época), Casper FFG seguirá estando seguro. Entonces, si trabajamos duro, podemos acortar significativamente el ciclo. Si quisiéramos reducir significativamente el tamaño mínimo del depósito, podríamos tomar la difícil decisión de negociar en otras direcciones. Por ejemplo, si aumentamos el tiempo de finalización 4 veces, entonces el tamaño mínimo del depósito disminuirá 4 veces. La finalidad de una sola ranura resolverá más adelante este problema yendo completamente más allá del modelo de "cada participante participa en cada época".

Otra parte importante de todo este tema es la economía de las apuestas. Una pregunta clave es: ¿queremos que apostar se convierta en una actividad relativamente especializada, o queremos que todos, o casi todos, apuesten todo su ETH? Si todos están apostando, ¿qué responsabilidad queremos que tengan todos? Si la gente termina simplemente delegando responsabilidades por pereza, esto puede conducir en última instancia a la centralización. Aquí hay cuestiones filosóficas importantes y profundas. La respuesta incorrecta podría llevar a Ethereum por el camino de la centralización y "recrear el sistema financiero tradicional con pasos adicionales"; la respuesta correcta podría crear un ejemplo brillante de un ecosistema exitoso con partes interesadas independientes amplias y diversas y un grupo de apuestas altamente descentralizado. Estos problemas involucran la economía y los valores centrales de Ethereum, por lo que necesitamos una participación más diversa.

Requisitos de hardware del nodo

Muchas de las cuestiones clave que rodean la descentralización de Ethereum se reducen en última instancia a una pregunta que ha definido una década de blockchain: ¿Con qué facilidad queremos ejecutar nodos y cómo lo hacemos posible?

Ejecutar un nodo es difícil hoy en día. La mayoría de la gente no hace esto. En la computadora portátil que estoy usando para escribir este artículo, tengo un nodo reth que ocupa 2,1 TB, que ya es el resultado de una heroica ingeniería y optimización de software. Necesito comprar un disco duro adicional de 4 TB para colocarlo en mi computadora portátil y almacenar el nodo. Todos queremos facilitar la ejecución de nodos. En mi mundo ideal, la gente podría ejecutar nodos en sus teléfonos.

Como escribí anteriormente, los árboles EIP-4444 y Verkle son dos tecnologías clave que nos acercan a este ideal. Si se implementan ambos, los requisitos de hardware del nodo pueden eventualmente reducirse a menos de cien gigabytes, o más cerca de cero si eliminamos por completo la responsabilidad del almacenamiento del historial (probablemente solo para nodos que no son de participación). El ZK-EVM tipo 1 eliminará la necesidad de ejecutar los cálculos EVM usted mismo, ya que puede simplemente verificar la prueba de que la ejecución fue correcta. En mi mundo ideal, agrupamos todas estas tecnologías juntas, e incluso las billeteras de extensión del navegador Ethereum (por ejemplo, Metamask, Rabby) tienen un nodo incorporado para verificar estas pruebas, realizar muestreos de disponibilidad de datos y asegurarse de que la cadena sea correcta.

Esta visión a menudo se conoce como "The Verge".

Todo esto es bien conocido y comprendido, incluso por aquellos que han expresado su preocupación por el tamaño de los nodos de Ethereum. Sin embargo, existe una preocupación importante: si eliminamos la responsabilidad de mantener el estado y proporcionar pruebas, ¿no se trata de un vector centralizado? Incluso si no pueden hacer trampa proporcionando datos no válidos, ¿no va en contra de los principios de Ethereum confiar demasiado en ellos?

Una versión más reciente de esta preocupación es la incomodidad que muchos sienten con EIP-4444: si los nodos regulares de Ethereum ya no necesitan almacenar el historial antiguo, ¿quién lo necesita? Una respuesta común es: debe haber suficientes actores grandes (por ejemplo, exploradores de bloques, intercambios, Capa 2) con un incentivo para conservar estos datos, y la cadena Ethereum es pequeña en comparación con los 100 petabytes almacenados por Wayback Machine. Así que la idea de que cualquier historia se pierda es absurda.

Sin embargo, este argumento se basa en un pequeño número de grandes actores. En mi clasificación de modelos de confianza, este es un supuesto de 1 en N, pero N es muy pequeño. Esto tiene sus riesgos finales. Una cosa que podemos hacer es almacenar el historial antiguo en una red peer-to-peer, donde cada nodo solo almacena una pequeña porción de los datos. Una red de este tipo aún se replicaría lo suficiente como para garantizar la solidez: habría miles de copias de cada dato y, en el futuro, podríamos usar codificación de borrado (de hecho, al poner el historial en blobs estilo EIP-4844). codificación de borrado incorporada) para mejorar aún más la estabilidad.

Los blobs tienen codificación de borrado dentro y entre blobs. La forma más sencilla de proporcionar almacenamiento ultraestable para toda la historia de Ethereum es probablemente colocar balizas y bloques de ejecución en blobs. Fuente de la imagen: codex.storage

Este trabajo ha pasado a un segundo plano durante mucho tiempo. Portal Network existe, pero en realidad no recibe el nivel de atención acorde con su importancia para el futuro de Ethereum. Afortunadamente, ahora hay impulso para poner más recursos en una versión mínima del portal centrada en el almacenamiento distribuido y la accesibilidad histórica. Deberíamos aprovechar esto y trabajar juntos para implementar EIP-4444 lo antes posible, junto con una sólida red descentralizada de igual a igual para almacenar y recuperar el historial antiguo.

Para Stateful y ZK-EVM, este enfoque distribuido es más difícil. Para construir un bloque eficiente, solo necesita tener un estado completo. En este caso, personalmente prefiero adoptar un enfoque pragmático: definimos e insistimos en un cierto nivel de requisitos de hardware necesarios para tener un "nodo que lo haga todo", que es más alto que el de un simple nodo validador (idealmente con un costo reducido constantemente). cadena, pero aún lo suficientemente bajo como para que los entusiastas se lo puedan permitir. Nos basamos en el supuesto de 1 en N, asegurando que N sea razonablemente grande.​

Las pruebas ZK-EVM son probablemente la parte más complicada, los probadores ZK-EVM en tiempo real probablemente requerirán hardware más potente que los nodos de archivo, incluso con avances como Binius y, en el peor de los casos, límites en Gas multidimensional. Podríamos trabajar en una red de prueba distribuida, donde cada nodo asume la responsabilidad de probar, digamos: el uno por ciento de la ejecución de un bloque, y luego el productor del bloque solo necesita agregar cien pruebas al final. Demuestre que los árboles agregados pueden ayudar aún más. Pero si esto no funciona bien, entonces otro compromiso sería permitir que los requisitos de hardware para las pruebas sean mayores, pero garantizar que los "nodos que lo hacen todo" puedan validar directamente los bloques de Ethereum (sin pruebas) lo suficientemente rápido como para ser eficientes. Participar en la red.

Resumir

Creo que el pensamiento de Ethereum en la era 2021 realmente se ha acostumbrado a transferir la responsabilidad a un pequeño número de grandes actores, siempre que exista algún tipo de mecanismo de mercado o sistema de prueba de conocimiento cero para obligar a los actores centralizados a actuar con honestidad. Estos sistemas suelen funcionar bien en circunstancias normales, pero pueden fallar catastróficamente en el peor de los casos.

Al mismo tiempo, creo que es importante enfatizar que las propuestas actuales del protocolo Ethereum se han alejado significativamente de este modelo y se han tomado mucho más en serio la necesidad de una red verdaderamente descentralizada. Las ideas en torno a los nodos sin estado, la mitigación de MEV, la finalidad de una sola ranura y conceptos similares han ido más allá en esta dirección. Hace un año, se consideró seriamente la idea de muestrear la disponibilidad de datos a través de relés como nodos semicentralizados. Este año, ya no tenemos que hacer estas cosas y PeerDAS ha logrado avances sorprendentemente fuertes.

Pero hay mucho que podemos hacer para avanzar en esta dirección, en las tres cuestiones centrales que mencioné anteriormente, y en muchas otras cuestiones importantes. Helios ha logrado grandes avances al proporcionar un "verdadero cliente ligero" para Ethereum. Ahora necesitamos incluirlo de forma predeterminada en las billeteras Ethereum y hacer que los proveedores de RPC proporcionen pruebas y sus resultados para que puedan verificarse y extender la tecnología de cliente ligero a protocolos de capa 2. Si Ethereum escala a través de una hoja de ruta centrada en Rollup, la Capa 2 debe obtener las mismas garantías de seguridad y descentralización que la Capa 1. Hay muchas otras cosas en un mundo centrado en Rollup que deberíamos tomar más en serio; los puentes cruzados L2 descentralizados y eficientes son uno de muchos ejemplos. Muchas dapps obtienen sus registros a través de protocolos centralizados porque el escaneo de registros nativo de Ethereum se ha vuelto demasiado lento. Podemos mejorar esto con subprotocolos descentralizados dedicados; esta es una de mis sugerencias sobre cómo hacerlo.

Hay una cantidad casi infinita de proyectos de blockchain dirigidos al mercado de "podemos ser súper rápidos y pensaremos en la descentralización más adelante". No creo que Ethereum deba unirse a este tren. Ethereum L1 puede y ciertamente debe ser una capa base sólida para proyectos de capa 2 que adopten un enfoque de hiperescala, utilizando Ethereum como la columna vertebral de la descentralización y la seguridad. Incluso un enfoque centrado en la Capa 2 requiere que la Capa 1 sea lo suficientemente escalable para manejar grandes volúmenes de operaciones. Pero debemos respetar profundamente las características que hacen que Ethereum sea único y continuar trabajando para mantener y mejorar estas características a medida que Ethereum escala.