El siguiente texto es un artículo traducido al español de Vitalik Buterin. El original puedes leerlo en el siguiente link.

Estoy sentado aquí escribiendo esto en el último día de un encuentro de interop (interoperabilidad) de desarrolladores de Ethereum en Kenia, donde logramos un gran avance implementando y afinando detalles técnicos de importantes mejoras próximas en Ethereum, destacando especialmente PeerDAS, la transición al árbol de Verkle y enfoques descentralizados para almacenar el historial en el contexto de EIP 4444. Desde mi propia perspectiva, siento que el ritmo de desarrollo de Ethereum y nuestra capacidad para entregar características grandes e importantes que mejoran significativamente la experiencia para los operadores de nodos y los usuarios (L1 y L2), está aumentando.

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

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 dan a entender los tuits de Peter; más bien, muchas de estas preocupaciones ya están siendo abordadas por características propias del protocolo de Ethereum, y muchas otras pueden ser abordadas con pequeños ajustes muy realistas, de acuerdo al roadmap actual.

Para saber qué significa esto en la práctica, repasemos los tres ejemplos que Peter proporcionó uno por uno. El objetivo no es centrarse en Peter específicamente; ya que son preocupaciones que comparten muchos miembros de la comunidad y es importante abordarlas.

MEV y su dependencia de los builders

En el pasado, los bloques de Ethereum eran creados por miners, quienes usaban un algoritmo relativamente simple para crear bloques. Los usuarios envían transacciones a una red p2p pública a menudo llamada "mempool" (o "txpool"). Los miners escuchan el mempool y aceptan transacciones que son contadas como válidas y pagan los fees. Se incluyen las transacciones que pueden, y si no hay suficiente espacio, priorizan a los que tengan el fee más alto primero.

Este era un sistema muy simple y amigable hacia la descentralización: como miner, sólo necesitas ejecutar el software predeterminado y puedes obtener los mismos niveles de ingresos por fees de un bloque que podrías obtener de granjas mineras altamente profesionales. Sin embargo, alrededor de 2020, la gente comenzó a explotar lo que se llamaba valor extraíble por el minero (miner extractable value, MEV): ingresos que solo se podrían obtener ejecutando estrategias complejas que son conscientes de las actividades que ocurren dentro de varios protocolos DeFi.

Por ejemplo, considera a exchanges descentralizados como Uniswap. Supone que en el momento T, la tasa de cambio USD/ETH - en exchanges centralizados y en Uniswap - es de $3000. En el momento T+11, la tasa de cambio USD/ETH en exchanges centralizados sube a $3005. Pero Ethereum aún contaba con su siguiente bloque. En el momento T+12, sí. Quien crea el bloque puede hacer que su primera transacción ya sea una serie de compras en Uniswap, comprando todo el ETH disponible en Uniswap a precios de $3000 a $3004. Estos son ingresos adicionales, y se llama MEV. Todas las aplicaciones que no sean DEXes tienen sus propios temas análogos a este problema. El artículo de Flash Boys 2.0 publicado en 2019 habla en detalle sobre esto.

El problema es que esto rompe la idea de por qué la minería (o después del 2022, la proposición de bloques) puede llegar a ser "justa": ahora, los grandes actores que tienen una mejor capacidad para optimizar estos tipos de algoritmos de extracción pueden obtener un mejor rendimiento por bloque.

Desde entonces, ha habido un debate entre dos estrategias, que llamaré minimización de MEV y cuarentena de MEV. La minimización de MEV (MEV minimization) viene en dos formas: (i) trabajar agresivamente en alternativas libres de MEV a Uniswap (por ejemplo, Cowswap), y (ii) construir técnicas dentro del 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 previenen estrategias como ataques de sándwich (”sandwich-attacks”), que colocan transacciones justo antes y después de las operaciones de los usuarios para explotarlas financieramente ("front-running").

La cuarentena de MEV (MEV quarantining) funciona aceptando MEV pero tratando de limitar su impacto en la centralización del staking, separando 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 “terceriza” a builders especializados a través de un protocolo de subasta. Los stakers individuales ahora ya no necesitan preocuparse por optimizar el arbitraje DeFi ellos mismos; simplemente se unen al protocolo de subasta y aceptan la oferta más alta. Esto se llama separación de proponente/constructor (proposer/builder separation, PBS). Este enfoque tiene precedentes en otras industrias: una razón importante por la que los restaurantes pueden seguir siendo tan descentralizados es que a menudo dependen de un conjunto de proveedores bastante concentrado para varias operaciones que sí tienen grandes economías de escala. Hasta ahora, el PBS ha sido razonablemente exitoso para asegurar que los validadores pequeños y los validadores grandes estén en un campo de juego equitativo, al menos en lo que respecta al MEV. Sin embargo, crea otro problema: la tarea de elegir qué transacciones se incluyen se vuelve más concentrada.

Mi opinión sobre esto siempre ha sido que la minimización de MEV es buena y debemos perseguirla (¡yo personalmente uso Cowswap de forma regular!) - aunque los mempools encriptados tienen muchos desafíos, pero la minimización de MEV probablemente será insuficiente; el MEV no disminuirá a cero, ni siquiera cerca de cero. Por lo tanto, necesitamos algún tipo de cuarentena de MEV también. 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 builders el menor poder posible, mientras seguimos permitiéndoles asumir el rol de optimizar el arbitraje y otras formas de recolección de MEV?

Si los builders tienen el poder de excluir transacciones de un bloque por completo, pueden surgir ataques con bastante facilidad. Supone que tienes una posición de deuda colateralizada (collateralized debt position, CDP) en un protocolo DeFi, respaldada por un activo cuyo precio está bajando rápidamente. Por ende, hay que aumentar el monto de tu colateral o salir de ese CDP. Los builders maliciosos podrían intentar coludirse para negarse a incluir tu transacción, retrasándola hasta que los precios caigan lo suficiente como para que puedan liquidar forzosamente tu CDP. Si eso sucede, tendrías que pagar una gran penalización, y los builders obtendrían una gran parte de ella. Entonces, ¿cómo podemos evitar que los constructores excluyan transacciones y se lleven a cabo estos tipos de ataques?

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

Las listas de inclusión permiten a los proponentes de bloques (es decir, los stakers) elegir las transacciones que deben ir en el bloque. Los builders aún pueden reordenar transacciones o insertar las suyas propias, pero deben incluir las transacciones del proponente. Eventualmente, las listas de inclusión se modificaron para restringir el siguiente bloque en lugar del bloque actual. En cualquier caso, eliminan la capacidad del constructor de expulsar transacciones del bloque por completo.

Lo anterior fue un rabbit hole con un fondo complicado. Pero el MEV es un tema complicado; incluso la descripción anterior omite muchos matices importantes. Como dice el viejo adagio, "puede que no estés buscando MEV, pero el MEV te está buscando a ti". Los researchers de Ethereum ya están bastante alineados en el objetivo de "minimizar la caja de cuarentena", reduciendo el daño que los builders podrían provocar (por ejemplo, excluyendo o retrasando transacciones como una forma de atacar aplicaciones específicas) tanto como sea posible.

Dicho esto, creo que podemos ir aún más lejos. Históricamente, las listas de inclusión a menudo se han concebido como una "característica especial al margen": normalmente, no pensarías en ellas, pero por si acaso los builders maliciosos comienzan a hacer cosas locas, te brindan un "camino alternativo". Esta actitud se refleja en las decisiones de diseño actuales: en el 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 la forma en que pensamos sobre las listas de inclusión: pensar en la lista de inclusión como el bloque, y pensar en el rol del constructor como una función al margen de agregar algunas transacciones para recolectar MEV. ¿Qué pasa si son los builders los que tienen el límite de gas de 2.1 millones?

Creo que las ideas en esta dirección - realmente empujando la caja de cuarentena para que sea lo más pequeña posible - son muy interesantes, y estoy a favor de ir en esa dirección. Esto es un cambio con respecto a la "filosofía de la era 2021": en la filosofía de la era 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 los mercados de fees ERC-4337. En esta nueva filosofía, las partes de validación de transacciones de ERC-4337 tendrían que ser consagradas en el protocolo. Afortunadamente, el equipo de ERC-4337 ya está cada vez más a favor de esta dirección.

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

Staking Líquido

Hoy en día, los solo stakers constituyen un porcentaje relativamente pequeño de todo el staking en Ethereum, y la mayoría del staking lo realizan varios proveedores: algunos operadores centralizados y otros DAOs, como Lido y RocketPool.

He realizado mi propia investigación: varias encuestas [1] [2], sondeos, conversaciones en persona, haciendo la pregunta "¿por qué tú, específicamente tú, no estás haciendo staking en solitario hoy?". Para mí, un ecosistema robusto de solo staking es por lejos, mi resultado preferido para el staking en Ethereum y una de las mejores cosas de Ethereum es que realmente tratamos de apoyar un ecosistema robusto 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 haciendo solo staking citan como su razón principal el mínimo de 32 ETH.

2. De aquellas personas que citan otras razones, la más mencionada 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" (hot private keys) y la pérdida de la capacidad de participar simultáneamente en protocolos DeFi. Estas son preocupaciones significativas pero en menor escala.

Hay dos preguntas clave que la investigación sobre staking debe resolver:

1. ¿Cómo resolvemos estas preocupaciones?

2. Si a pesar de haber soluciones efectivas para la mayoría de estas preocupaciones, la mayoría de las personas aún no quieren hacer solo staking, ¿cómo mantenemos al 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. Los árboles Verkle en conjunto con EIP-4444 permiten que los nodos de staking funcionen con requisitos de disco duro muy bajos. Además, permiten que estos nodos se sincronicen casi instantáneamente, lo que simplifica enormemente 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, de estas propuestas) en formas de concebir un conjunto de validadores mucho más grande (habilitando mínimos de staking mucho más pequeños) mientras se reduce al mismo tiempo la sobrecarga de los nodos de consenso. Estas ideas pueden implementarse como parte de la finalidad de una sola ranura. Hacer esto también haría que los clientes ligeros sean más seguros, ya que podrían verificar el conjunto completo de firmas en lugar de depender de los comités de sincronización).

3. Las optimizaciones continuas de los clientes de Ethereum siguen reduciendo el costo y la dificultad de ejecutar un nodo validador, a pesar de la creciente historia.

4. La investigación sobre la limitación de sanciones podría potencialmente mitigar las preocupaciones en torno al riesgo de las claves privadas, y hacer posible que los stakers hagan staking de su ETH simultáneamente en protocolos DeFi si así lo desean.

5. Las credenciales de retiro 0x01 permiten a los stakers establecer una dirección de ETH como su dirección de retiro. Esto hace que los pools de staking descentralizados sean más viables, dándoles una ventaja sobre los pools de staking centralizados.

Sin embargo y una vez más, hay más que podríamos hacer. Teóricamente, es posible permitir que los validadores retiren mucho más rápido: Casper FFG sigue siendo seguro incluso si el conjunto de validadores cambia en un pequeño porcentaje cada vez que finaliza (es decir, una vez por época). Por lo tanto, podríamos reducir el período de retiro mucho más si nos esforzamos en ello. Si quisiéramos reducir significativamente el tamaño del depósito mínimo, podríamos tomar una decisión difícil de compensar en otras direcciones, por ejemplo, si aumentamos el tiempo de finalidad 4 veces, eso permitiría una disminución del tamaño del depósito mínimo en 4 veces. La finalidad de una sola ranura luego limpiaría esto al ir más allá del modelo de "cada staker participa en cada época".

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

Requerimientos de hardware de los nodos

Muchas de las preguntas clave en la descentralización de Ethereum terminan reduciéndose a una pregunta que ha definido la política de blockchain durante una década: ¿qué tan accesible queremos que sea la gestión de 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 laptop que estoy usando para escribir esta publicación, tengo un nodo reth que ocupa 2,1 terabytes, lo que ya es el resultado de una heroica ingeniería y optimización de software. Necesitaba comprar un disco duro adicional de 4 TB para colocarlo en mi laptop y almacenar este nodo. Todos queremos que ejecutar un nodo sea más fácil. 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 de un nodo podrían eventualmente disminuir a menos de cien gigabytes, y tal vez a casi cero si eliminamos por completo la responsabilidad del almacenamiento del historial (quizás solo para los nodos que no son de participación). Los ZK-EVM de tipo 1 eliminarían la necesidad de que tú ejecutes el cálculo EVM, ya que en su lugar podría simplemente verificar una prueba de que la ejecución fue correcta. En mi mundo ideal, agrupamos todas estas tecnologías juntas, e incluso las wallets de extensión del navegador 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.

Todo esto es conocido y comprendido, incluso por personas que expresan preocupaciones sobre el tamaño de los nodos de Ethereum. Sin embargo, existe una preocupación importante: si nos estamos apartando de 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 no válidos, ¿no va en contra de los principios de Ethereum depender demasiado de ellos?

Una versión a muy 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 necesita? Una respuesta común es: ciertamente hay suficientes actores grandes (por ejemplo, exploradores de bloques, intercambios, capas 2) que tienen el incentivo para conservar esos datos, y en comparación con los 100 petabytes almacenados por Wayback Machine, la cadena Ethereum es pequeña. Así que es ridículo pensar que alguna historia realmente se perderá.

Sin embargo, este argumento se refiere a la dependencia de un pequeño número de grandes actores. En mi taxonomía de modelos de confianza, es una suposición de 1 de N, pero N es bastante pequeña. Esto tiene sus riesgos finales. Una cosa que podríamos hacer en su lugar es almacenar el historial antiguo en una red peer-to-peer, donde cada nodo solo almacena un pequeño porcentaje de los datos. Este tipo de red aún haría suficientes copias para garantizar la solidez: habría miles de copias de cada dato, y en el futuro podríamos usar codificación de borrado (de manera realista, poniendo el historial en blobs estilo EIP-4844, que ya tienen codificación de borrado incorporada) para aumentar aún más la robustez.

Durante mucho tiempo, este trabajo ha estado en un segundo plano; Portal Network existe, pero, siendo realistas, no ha recibido el nivel de atención acorde con su importancia en el futuro de Ethereum. Afortunadamente, ahora hay un gran interés en impulsar la inversión de muchos más recursos en una versión minimizada de Portal que se centre en el almacenamiento distribuido y la accesibilidad de la historia. Se debe aprovechar este impulso y debemos hacer un esfuerzo concertado para implementar pronto EIP-4444, junto con una sólida red descentralizada de igual a igual para almacenar y recuperar historia antigua.

Para los states y ZK-EVM, este tipo de enfoque distribuido es más difícil. Para construir un bloque eficiente, simplemente hay que tener el estado completo. En este caso, personalmente estoy a favor de un enfoque pragmático: definimos y respetamos cierto nivel de requisitos de hardware necesarios para tener un "nodo que lo haga todo", que es más alto que el costo (idealmente cada vez menor) de simplemente validar la cadena, pero aún lo suficientemente bajo como para ser asequible para los aficionados. Nos basamos en una suposición de 1 de N, donde nos aseguramos de que N sea bastante grande. Por ejemplo, podría ser una computadora portátil de consumo de alta gama.

Es probable que la ZK-EVM proving sea la pieza más complicada, y es probable que los ZK-EVM provers en tiempo real requieran un hardware considerablemente más robusto que un nodo de archivo, incluso con avances como Binius y, en el peor de los casos, con gas multidimensional. Podríamos trabajar duro en una red de prueba distribuida, donde cada nodo asuma la responsabilidad de probar, por ejemplo un uno por ciento de la ejecución de un bloque, y luego el productor del bloque solo necesita agregar las cien pruebas al final. Los árboles de agregación de pruebas podrían ayudar más. Pero si esto no funciona bien, entonces otro compromiso sería permitir que los requisitos de hardware de la prueba aumenten, pero asegurarse de que un "nodo que 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 es cierto que el pensamiento de Ethereum de la era 2021 se sintió demasiado cómodo con esto de apartar 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. Estos sistemas suelen funcionar bien en el caso medio, pero fallan catastróficamente en el peor de los casos.

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 stateless, las mitigaciones de MEV, la finalidad de una sola ranura y conceptos similares ya van mucho más allá en esta dirección. Hace un año, se consideró seriamente la idea de realizar un muestreo de data availability aprovechando los piggy backing on relays como los nodos semicentralizados. Este año, hemos ido más allá de la necesidad de hacer tales cosas, con un progreso sorprendentemente sólido en PeerDAS.

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. Helios ha logrado grandes avances al darle a Ethereum un "cliente ligero real". Ahora, debemos incluirlo de forma predeterminada en las wallets 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 protocolos de Layer 2. Si Ethereum está escalando a través de una hoja de ruta centrada en rollups, las Layer 2 deben obtener las mismas garantías de seguridad y descentralización que la Layer 1. En un mundo centrado en rollups, hay muchas otras cosas que deberíamos tomar más en serio. Los bridges entre L2 descentralizados y eficientes son un ejemplo entre 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 subprotocolo descentralizado dedicado. He aquí una propuesta mía sobre cómo se podría hacer esto.

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 adelante". No creo que Ethereum deba ser uno de esos proyectos. Ethereum L1 puede y ciertamente debe ser una base layer sólida para proyectos de Layer 2 que adoptan un enfoque de hiperescala, utilizando Ethereum como columna vertebral para la descentralización y la seguridad. Incluso un enfoque centrado en Layer 2 requiere que la propia capa 1 tenga suficiente escalabilidad para manejar una cantidad significativa de operaciones. Pero debemos tener un profundo respeto por las propiedades que hacen que Ethereum sea único y continuar trabajando para mantener y mejorar esas propiedades a medida que Ethereum escale.