Estoy sentado aquí escribiendo esto en el último día de una interop de desarrolladores de Ethereum en Kenia, donde hicimos una gran cantidad de progreso implementando y puliendo detalles técnicos de importantes mejoras próximas de Ethereum, principalmente PeerDAS, el transición del árbol Verkle y enfoques descentralizados para almacenar la historia en el contexto de EIP 4444. Desde mi propia perspectiva, parece que el ritmo de desarrollo de Ethereum, y nuestra capacidad para enviar características grandes e importantes que mejoren significativamente la experiencia para los operadores de nodos y los usuarios (L1 y L2), está aumentando.

Equipos de clientes de Ethereum trabajando juntos para lanzar la red de desarrollo Pectra.

Dada esta mayor capacidad técnica, una pregunta importante que debemos hacernos es: ¿estamos construyendo hacia los objetivos correctos? Una sugerencia para reflexionar sobre esto es una reciente serie de tweets infelices del desarrollador principal de Geth, Peter Szilagyi, desde hace mucho tiempo.

Estas son preocupaciones válidas. Son preocupaciones que muchas personas en la comunidad de Ethereum han expresado. Son preocupaciones que personalmente he tenido en muchas ocasiones. Sin embargo, tampoco creo que la situación sea tan desesperada como implican los tuits de Peter; más bien, muchas de las preocupaciones ya están siendo abordadas por características del protocolo que ya están en progreso, y muchas otras pueden ser abordadas mediante ajustes muy realistas al plan actual.

Para ver lo que esto significa en la práctica, pasemos por los tres ejemplos que Peter proporcionó uno por uno. El objetivo no es centrarse en Peter específicamente; son preocupaciones que son ampliamente compartidas entre muchos miembros de la comunidad, y es importante abordarlas.

MEV, y dependencia del constructor

En el pasado, los bloques de Ethereum eran creados por mineros, quienes utilizaban un algoritmo relativamente simple para crear bloques. Los usuarios envían transacciones a una red p2p pública a menudo llamada el "mempool" (o "txpool"). Los mineros escuchan el mempool y aceptan transacciones que son válidas y pagan comisiones. Incluyen las transacciones que pueden, y si no hay suficiente espacio, priorizan por las de mayor comisión primero.

Este era un sistema muy simple y amigable hacia la descentralización: como minero, simplemente puedes ejecutar el software predeterminado y obtener los mismos niveles de ingresos por comisiones de un bloque que podrías obtener de granjas de minería altamente profesionales. Sin embargo, alrededor de 2020, las personas comenzaron a explotar lo que se llamaba el valor extraíble por el minero (MEV): ingresos que solo podían obtenerse mediante la ejecución de estrategias complejas que son conscientes de las actividades que ocurren dentro de varios protocolos de defi.

Por ejemplo, considera intercambios descentralizados como Uniswap. Supongamos que en el momento T, la tasa de cambio USD/ETH - en intercambios centralizados y en Uniswap - es $3000. En el momento T+11, la tasa de cambio USD/ETH en intercambios centralizados sube a $3005. Pero Ethereum aún no ha tenido su próximo bloque. En el momento T+12, lo hace. Quien crea el bloque puede hacer que su primera transacción sea una serie de compras en Uniswap, comprando todo el ETH disponible en Uniswap a precios de $3000 a $3004. Esto es ingreso extra, y se llama MEV. Las aplicaciones que no son DEXes tienen sus propios análogos a este problema. Flash Boys 2.0 papelpublicado en 2019 entra en esto en detalle.

Un gráfico del documento Flash Boys 2.0 que muestra la cantidad de ingresos capturables utilizando los tipos de enfoques descritos anteriormente.

El problema es que esto rompe la historia de por qué la minería (o, después de 2022, la propuesta de bloques) puede ser “justa”: ahora, los actores grandes que tienen una mejor capacidad para optimizar este tipo de algoritmos de extracción pueden obtener un mejor rendimiento por bloque.

Desde entonces ha habido un debate entre dos estrategias, a las que llamaré minimización de MEV y cuarentena de MEV. La minimización de MEV se presenta en dos formas: (i) trabajar de forma agresiva en alternativas libres de MEV a Uniswap (por ejemplo, Cowswap) y (ii) implementar técnicas en el protocolo, como mempools encriptados, que reduzcan la información disponible para los productores de bloques, y por lo tanto reduzcan los ingresos que pueden capturar. En particular, los mempools encriptados evitan estrategias como los ataques sandwich, que colocan transacciones justo antes y después de las operaciones de los usuarios para explotarlos financieramente ("front-running").

La cuarentena de MEV funciona aceptando MEV, pero tratando de limitar su impacto en la centralización del staking al separar el mercado en dos tipos de actores: los validadores son responsables de atestiguar y proponer bloques, pero la tarea de elegir el contenido del bloque se externaliza a constructores especializados a través de un protocolo de subasta. Los apostadores individuales ya no necesitan preocuparse por optimizar el arbitraje de defi ellos mismos; simplemente se unen al protocolo de subasta y aceptan la oferta más alta. Esto se llama separación de proponentes/constructores (PBS). Este enfoque tiene precedentes en otras industrias: una de las razones principales por las que los restaurantes pueden permanecer tan descentralizados es que a menudo confían en un conjunto bastante concentrado de proveedores para diversas operaciones que tienen grandes economías de escala. Hasta ahora, PBS ha tenido un éxito razonable al garantizar que los pequeños validadores y los grandes validadores estén en un campo de juego justo, al menos en lo que respecta a MEV. Sin embargo, crea otro problema: la tarea de elegir qué transacciones se incluyen se vuelve más concentrada.

Mi punto de vista siempre ha sido que la minimización de MEV es buena y debemos seguirla (¡personalmente uso Cowswap regularmente!) - aunque las mempools encriptadas tienen muchos desafíos, pero la minimización de MEV probablemente no será suficiente; MEV no bajará a cero, ni siquiera cerca de cero. Por lo tanto, también necesitamos algún tipo de cuarentena de MEV. Esto crea una tarea interesante: ¿cómo hacemos que la "caja de cuarentena de MEV" sea lo más pequeña posible? ¿Cómo damos a los constructores el menor poder posible, al tiempo que los mantenemos capaces de absorber el papel de optimizar el arbitraje y otras formas de recopilación de MEV?

Si los constructores tienen el poder de excluir transacciones de un bloque por completo, pueden surgir ataques con bastante facilidad. Supongamos que tienes un posición de deuda garantizada (CDP)en un protocolo defi, respaldado por un activo cuyo precio está cayendo rápidamente. Desea aumentar su garantía o salir del CDP. Los constructores maliciosos podrían intentar coludir para rechazar incluir su transacción, retrasándola hasta que los precios caigan lo suficiente como para liquidar su CDP por la fuerza. Si eso sucede, tendría que pagar una gran penalización y los constructores obtendrían una gran parte de la misma. Entonces, ¿cómo podemos evitar que los constructores excluyan transacciones y lleven a cabo este tipo de ataques?

Aquí es donde entran las listas de inclusión.

Fuente: esta publicación de ethresear.ch.

Las listas de inclusión permiten a los proponentes de bloques (es decir, los validadores) elegir transacciones que deben ir en el bloque. Los constructores aún pueden reordenar transacciones o insertar las suyas, pero deben incluir las transacciones del proponente. Eventualmente, las listas de inclusión fueron modificadaspara restringir el siguiente bloque en lugar del bloque actual. En cualquier caso, le quitan la capacidad al constructor de enviar transacciones fuera del bloque por completo.

Todo lo anterior fue un profundo agujero de conejo de antecedentes complicados. Pero MEV es un problema complicado; incluso la descripción anterior pasa por alto muchas sutilezas importantes. Como dice el viejo adagio, "puede que no estés buscando MEV, pero MEV te está buscando a ti". Los investigadores de Ethereum ya están bastante alineados en el objetivo de "minimizar la caja de cuarentena", reduciendo al máximo el daño que los constructores pueden hacer (por ejemplo, excluyendo o retrasando transacciones como una forma de atacar aplicaciones específicas)

Dicho esto, creo que podemos ir aún más lejos. Históricamente, las listas de inclusión a menudo han sido concebidas como una característica especial “al margen”: normalmente, no pensarías en ellas, pero en caso de que los constructores malintencionados comiencen a hacer cosas locas, te ofrecen un “segundo camino”. Esta actitud se refleja en las decisiones de diseño actuales: en la EIP actual, el límite de gas de una lista de inclusión es de alrededor de 2.1 millones. Pero podemos hacer un cambio filosófico en cómo pensamos acerca de las listas de inclusión: piensa en la lista de inclusión como si fuera el bloque, y piensa en el rol del constructor como una función aparte de agregar algunas transacciones para recolectar MEV. ¿Y si son los constructores los que tienen el límite de gas de 2.1 millones?

Creo que las ideas en esta dirección, realmente presionando para que la caja de cuarentena sea lo más pequeña posible, son realmente interesantes, y estoy a favor de seguir en esa dirección. Esto es un cambio de la filosofía de la “era de 2021”: en la filosofía de la era de 2021, estábamos más entusiasmados con la idea de que, dado que ahora tenemos constructores, podemos “sobrecargar” su funcionalidad y hacer que sirvan a los usuarios de maneras más complicadas, por ejemplo, apoyando mercados de tarifas ERC-4337En esta nueva filosofía, las partes de validación de transacciones de ERC-4337 tendrían que estar consagradas en el protocolo. Afortunadamente, el equipo de ERC-4337 ya es @yoav/AA-roadmap-May-2024#Native-AA---a-modular-roadmap">a cada vez más cálido sobre esta dirección.

Resumen: El pensamiento de MEV ya ha estado volviendo en la dirección de empoderar a los productores de bloques, incluyendo darles la autoridad para garantizar directamente la inclusión de las transacciones de los usuarios. Las propuestas de abstracción de cuentas ya están volviendo en la dirección de eliminar la dependencia de los relayers centralizados e incluso de los bundlers. Sin embargo, hay un buen argumento de que no estamos yendo lo suficientemente lejos, y pienso que la presión que empuja el proceso de desarrollo a ir más lejos en esa dirección es muy bienvenida.

Participación en liquidez

Hoy en día, los validadores individuales representan un porcentaje relativamente pequeño de todo el Ether que se apuesta, y la mayoría de la apuesta la realizan varios proveedores, algunos operadores centralizados y otros DAOs, como Lido y RocketPool.

He hecho mi propia investigación - diversas encuestas[1] [2], encuestas, conversaciones en persona, haciendo la pregunta “¿por qué no estás - específicamente tú - haciendo solo staking hoy?” Para mí, un ecosistema sólido de solo staking es de lejos mi resultado preferido para el staking de Ethereum, y una de las mejores cosas de Ethereum es que realmente intentamos apoyar un ecosistema sólido de solo staking en lugar de simplemente rendirnos a la delegación. Sin embargo, estamos lejos de ese resultado. En mis encuestas y sondeos, hay algunas tendencias consistentes:

1. La gran mayoría de las personas que no están apostando en solitario citan como su razón principal el mínimo de 32 ETH.
2. De aquellos que citan otras razones, la más alta es el desafío técnico de ejecutar y mantener un nodo validador.
3. La pérdida de disponibilidad instantánea de ETH, los riesgos de seguridad de las claves privadas "calientes" y la pérdida de capacidad para participar simultáneamente en protocolos de defi, son preocupaciones significativas pero menores.

Las principales razones por las que la gente no está apostando en solitario, según las encuestas de Farcaster.

Hay dos preguntas clave para que la investigación sobre participación las resuelva:

1. ¿Cómo solucionamos estas preocupaciones?
2. Si, a pesar de soluciones efectivas a la mayoría de estas preocupaciones, la mayoría de las personas todavía no quieren hacer stake en solitario, ¿cómo mantenemos el protocolo estable y robusto contra ataques a pesar de ese hecho?

Muchos elementos de investigación y desarrollo en curso están dirigidos precisamente a resolver estos problemas:

1. árboles VerklemásEIP-4444permiten que los nodos de staking funcionen con requisitos de disco duro muy bajos. Además, permiten que los nodos de staking se sincronicen casi al instante, simplificando en gran medida el proceso de configuración, así como operaciones como cambiar de una implementación a otra. También hacen que los clientes ligeros de Ethereum sean mucho más viables, al reducir el ancho de banda de datos necesario para proporcionar pruebas para cada acceso al estado.
2. Investigación (por ejemplo, estas propuestas)en formas de permitir un conjunto de validadores mucho más grande (permitiendo mínimos de participación mucho más pequeños) al mismo tiempo que se reduce la sobrecarga del nodo de consenso. Estas ideas se pueden implementar como parte de finalidad de una sola ranura. Hacer esto también hace que los clientes ligeros sean más seguros, ya que podrían verificar el conjunto completo de firmas en lugar de depender de comités de sincronización)
3. Las optimizaciones continuas del cliente Ethereum siguen reduciendo el costo y la dificultad de ejecutar un nodo validador, a pesar del crecimiento de la historia.
4. Investigación sobre penalties cappingpodría potencialmente mitigar las preocupaciones en torno al riesgo de la clave privada, y hacer posible que los validadores apuesten simultáneamente su ETH en protocolos defi si así lo desean.
5. 0x01 Credenciales de retiropermitir a los validadores establecer una dirección ETH como su dirección de retiro. Esto hace que las agrupaciones de validación descentralizadas sean más viables, dándoles una ventaja contra las agrupaciones de validación centralizadas.

Sin embargo, una vez más, hay más que podríamos hacer. Es teóricamente posible permitir que los validadores retiren mucho más rápido: Casper FFG sigue siendo seguro incluso si el conjunto de validadores cambia en unos pocos por ciento cada vez que se finaliza (es decir, una vez por época). Por lo tanto, podríamos reducir mucho más el período de retiro si nos esforzamos en ello. Si quisiéramos reducir en gran medida el tamaño mínimo del depósito, podríamos tomar la dura decisión de compensar en otras direcciones, por ejemplo, si aumentamos el tiempo de finalización en 4 veces, eso permitiría un@VitalikButerin/parametrizando-casper-la-decentralización-finalidad-tiempo-overhead-tradeoff-3f2011672735"\u003e4x disminución del tamaño mínimo de depósito. La finalidad de un solo slot limpiaría esto más adelante al moverse más allá del modelo de "cada validador participa en cada época" por completo.

Otra parte importante de toda esta cuestión es la economía del staking. Una pregunta clave es: ¿queremos que el staking sea una actividad relativamente de nicho, o queremos que todos o casi todos apuesten todo su ETH? Si todos están apostando, entonces ¿cuál es la responsabilidad que queremos que todos asuman? Si las personas terminan simplemente delegando esta responsabilidad porque son perezosas, eso podría llevar a la centralización. Aquí hay preguntas filosóficas importantes y profundas. Respuestas incorrectas podrían llevar a Ethereum por un camino de centralización y "recreando el sistema financiero tradicional con pasos adicionales"; respuestas correctas podrían crear un ejemplo brillante de un ecosistema exitoso con un amplio y diverso conjunto de apostadores individuales y grupos de staking altamente descentralizados. Estas son preguntas que tocan la economía y valores fundamentales de Ethereum, y por lo tanto necesitamos una participación más diversa aquí.

Requisitos de hardware de los nodos

Muchas de las preguntas clave en la descentralización de Ethereum terminan siendo una pregunta que ha definido la política de blockchaindurante una década: ¿Qué tan accesible queremos que sea ejecutar un nodo, y cómo?

Hoy en día, ejecutar un nodo es difícil. La mayoría de la gente no lo hace. En la computadora portátil que estoy usando para escribir esta publicación, tengo un rethnodo, y ocupa 2.1 terabytes, ya es el resultado de una ingeniería de software heroica y optimización. Necesité comprar un disco duro adicional de 4 TB para ponerlo en mi computadora portátil para almacenar este nodo. Todos queremos que ejecutar un nodo sea más fácil. En mi mundo ideal, las personas podrían ejecutar nodos en sus teléfonos.

Como mencioné anteriormente, EIP-4444 y los árboles Verkle son dos tecnologías clave que nos acercan a este ideal. Si ambos se implementan, los requisitos de hardware de un nodo podrían disminuir plausiblemente a menos de cien gigabytes eventualmente, y tal vez a cerca de cero si eliminamos por completo la responsabilidad de almacenamiento de historial (quizás solo para nodos no validadores).Tipo 1 ZK-EVMseliminaría la necesidad de ejecutar la computación de EVM usted mismo, ya que en su lugar podría simplemente verificar una prueba de que la ejecución fue correcta. En mi mundo ideal, apilamos todas estas tecnologías juntas, e incluso las carteras de extensión del navegador de Ethereum (por ejemplo, Metamask, Rabby) tienen un nodo incorporado que verifica estas pruebas, realiza muestreos de disponibilidad de datos, y está satisfecho de que la cadena sea correcta.

La visión descrita anteriormente se llama a menudo "The Verge".

Todo esto es conocido y entendido, incluso por las personas que plantean preocupaciones sobre el tamaño del nodo de Ethereum. Sin embargo, hay una preocupación importante: si estamos descargando la responsabilidad de mantener el estado y proporcionar pruebas, ¿no es eso un vector de centralización? Incluso si no pueden hacer trampa proporcionando datos inválidos, ¿no va en contra de los principios de Ethereum volverse demasiado dependiente de ellos?

Una versión muy cercana a corto plazo de esta preocupación es la incomodidad de muchas personas hacia EIP-4444: si los nodos regulares de Ethereum ya no necesitan almacenar el historial antiguo, ¿quién lo hace? Una respuesta común es: ciertamente hay suficientes actores importantes (por ejemplo, exploradores de bloques, exchanges, capas 2) que tienen el incentivo para retener esos datos, y en comparación con los 100 petabytes almacenados por la Máquina del Tiempo de Wayback, la cadena Ethereum es pequeña. Por lo tanto, es ridículo pensar que realmente se perderá algún historial.

Sin embargo, este argumento se basa en la dependencia de un pequeño número de actores importantes. En mi taxonomía de modelos de confianza, es una suposición de 1-de-N, pero el N es bastante pequeño. Esto tiene sus riesgos. Una cosa que podríamos hacer en su lugar es almacenar la historia antigua en una red peer-to-peer, donde cada nodo solo almacena un pequeño porcentaje de los datos. Este tipo de red seguiría haciendo suficientes copias para garantizar la robustez: habría miles de copias de cada fragmento de datos, y en el futuro podríamos usar codificación por borrado (realísticamente, poniendo la historia enEIP-4844bloques de estilo, que ya tienen codificación de borrado incorporada) para aumentar aún más la robustez.

Los bloques tienen codificación de borrado dentro de los bloques y entre los bloques. La forma más sencilla de crear almacenamiento ultra resistente para toda la historia de Ethereum bien podría ser simplemente colocar bloques de beacon y ejecución en bloques.Fuente de la imagen: codex.storage

Durante mucho tiempo, este trabajo ha estado en segundo plano; Portal Networkexiste, pero realísticamente no ha recibido el nivel de atención acorde con su importancia en el futuro de Ethereum. Afortunadamente, ahora hay un fuerte interés en el impulso hacia poner muchos más recursos en una versión minimizada de Portal que se centra en el almacenamiento distribuido y la accesibilidad de la historia. Este impulso debería ser aprovechado, y deberíamos hacer un esfuerzo concertado para implementar EIP-4444 pronto, junto con una red descentralizada y robusta de pares para almacenar y recuperar la historia antigua.

Para los estados y ZK-EVMs, este tipo de enfoque distribuido es más difícil. Para construir un bloque eficiente, simplemente tienes que tener el estado completo. En este caso, personalmente prefiero un enfoque pragmático: definimos y nos ceñimos a cierto nivel de requisitos de hardware necesarios para tener un 'nodo que lo hace todo', que es mayor que el costo (idealmente en disminución) de simplemente validar la cadena, pero aún lo suficientemente bajo como para ser asequible para los aficionados. Confiamos en una suposición de 1 de N, donde nos aseguramos de que el N sea bastante grande. Por ejemplo, esto podría ser una computadora portátil de consumo de alta gama.

La demostración de ZK-EVM probablemente sea la parte más complicada, y es probable que los demostradores de ZK-EVM en tiempo real requieran hardware considerablemente más potente que un nodo de archivo, incluso conavances como Binius, y peor caso límite con gas multidimensionalPodríamos trabajar arduamente en una red de pruebas distribuida, donde cada nodo asume la responsabilidad de demostrar, por ejemplo, el uno por ciento de la ejecución de un bloque, y luego el productor de bloques solo necesita agregar los cien comprobantes al final. Los árboles de agregación de pruebas podrían ayudar aún más. Pero si esto no funciona bien, entonces otro compromiso sería permitir que los requisitos de hardware de la demostración sean más altos, pero asegurarse de que un 'nodo que lo hace todo' pueda verificar los bloques de Ethereum directamente (sin una prueba), lo suficientemente rápido como para participar efectivamente en la red.

Conclusiones

Creo que en realidad es cierto que la idea de Ethereum de la era 2021 se volvió demasiado cómoda al descargar responsabilidades a un pequeño número de actores a gran escala, siempre y cuando existiera algún tipo de mecanismo de mercado o sistema de prueba de conocimiento cero para obligar a los actores centralizados a comportarse honestamente. Tales sistemas a menudo funcionan bien en el caso promedio, pero fallan catastróficamente en el peor de los casos.

No estamos haciendo esto.

Al mismo tiempo, creo que es importante enfatizar que las propuestas actuales del protocolo Ethereum ya se han alejado significativamente de ese tipo de modelo y toman mucho más en serio la necesidad de una red verdaderamente descentralizada. Las ideas en torno a los nodos sin estado, las mitigaciones de MEV, la finalidad de un solo slot y conceptos similares, ya están mucho más avanzadas en esta dirección. Hace un año, la idea de realizar muestreos de disponibilidad de datos mediante el aprovechamiento de retransmisiones como nodos semicentralizados fue considerada seriamente. Este año, hemos avanzado más allá de la necesidad de hacer tales cosas, con un progreso sorprendentemente robusto enPeerDAS.

Pero hay mucho que podríamos hacer para avanzar en esta dirección, en los tres ejes de los que hablé anteriormente, así como en muchos otros ejes importantes.Heliosha avanzado mucho en darle a Ethereum un "cliente ligero real". Ahora, necesitamos que se incluya por defecto en las carteras de Ethereum, y hacer que los proveedores de RPC proporcionen pruebas junto con sus resultados para que puedan ser validados, y extender la tecnología de cliente ligero a los protocolos de capa 2. Si Ethereum está escalando a través de un roadmap centrado en rollups, los protocolos de capa 2 necesitan tener las mismas garantías de seguridad y descentralización que la capa 1. En un mundo centrado en rollups, hay muchas otras cosas en las que deberíamos tomar más en serio; puentes cruzados descentralizados y eficientes entre L2 son un ejemplo de muchos. Muchas dapps obtienen sus registros a través de protocolos centralizados, ya que el escaneo de registros nativo de Ethereum se ha vuelto demasiado lento. Podríamos mejorar esto con un sub-protocolo descentralizado dedicado;@vbuterin/parallel_post_state_roots">aquí hay una propuesta mía de cómo podría hacerse.

Hay un número casi ilimitado de proyectos blockchain que apuntan al nicho de "podemos ser súper rápidos, pensaremos en la descentralización más tarde". No creo que Ethereum deba ser uno de esos proyectos. Ethereum L1 puede y definitivamente debería ser una base sólida para proyectos de capa 2 que adopten un enfoque de hiperescala, utilizando Ethereum como columna vertebral para la descentralización y la seguridad. Incluso un enfoque centrado en la capa 2 requiere que la capa 1 misma tenga la escalabilidad suficiente para manejar un número significativo de operaciones. Pero debemos tener un profundo respeto por las propiedades que hacen que Ethereum sea único, y seguir trabajando para mantener y mejorar esas propiedades a medida que Ethereum escala.

Descargo de responsabilidad：

1. Este artículo ha sido 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 al Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente 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 Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.