El último artículo extenso de Vitalik: Después de la actualización de Cancún, ¿dónde está el camino para la expansión de Ethereum?

Autor: Vitalik Buterin

Compilado por: jk, Odaily Planet Daily

El 13 de marzo, se activó el hard fork Dencun, haciendo posible una de las características tan esperadas de Ethereum: proto-danksharding (también conocido como EIP-4844, también conocido como blobs). Inicialmente, la bifurcación redujo las tarifas de transacción para acumulaciones en más de 100 veces, ya que los blobs eran prácticamente gratuitos. Durante el último día, finalmente vimos un aumento en el volumen de blobs, y los mercados de tarifas se activaron a medida que los protocolos de blobs comenzaron a usarlos. Los blobs no son gratuitos, pero siguen siendo mucho más baratos que los calldata.

Izquierda: Gracias a Blobions, el uso de blobs finalmente alcanzó el objetivo de 3 por bloque. Derecha: Con esto viene la tarifa blob “ingresando al modo de descubrimiento de precios”. Fuente: Rob/blobs.

Este hito representa un cambio clave en la hoja de ruta a largo plazo de Ethereum: con los blobs, el escalamiento de Ethereum ya no es un problema de “cero a uno”, sino un problema de “uno a muchos”. A partir de aquí, continuará un importante trabajo de escalamiento, ya sea aumentando la cantidad de blobs o aumentando la capacidad de los paquetes acumulativos para utilizar cada blob, pero será más incremental. Los cambios de escala relacionados con cambios fundamentales en la forma en que opera Ethereum como ecosistema están cada vez más atrás. Además, el enfoque ha cambiado lentamente y seguirá cambiando lentamente de los problemas de nivel 1, como PoS, y la ampliación a problemas más cercanos a la capa de aplicación. La pregunta clave que explorará este artículo es: ¿Adónde irá Ethereum a continuación?

El futuro del escalado de Ethereum

En los últimos años, hemos sido testigos de la transformación gradual de Ethereum en un ecosistema centrado en L2. Las principales aplicaciones comenzaron a pasar de L1 a L2, los pagos comenzaron a basarse en L2 de forma predeterminada y las billeteras comenzaron a construir su experiencia de usuario en torno al nuevo entorno multi-L2.

Una parte clave de la hoja de ruta centrada en Rollup desde el principio ha sido el concepto de espacio de disponibilidad de datos independiente: una porción especial de espacio dentro de un bloque, inaccesible para el EVM, que puede almacenar datos para proyectos de segundo nivel, como los rollups. Dado que el EVM no puede acceder a este espacio de datos, se puede transmitir por separado desde un bloque y verificar por separado. En última instancia, se puede verificar mediante una técnica llamada muestreo de disponibilidad de datos, que permite a cada nodo verificar que los datos se publicaron correctamente verificando aleatoriamente varias muestras pequeñas. Una vez implementado, el espacio del blob se puede ampliar significativamente; el objetivo final es 16 MB por ranura (aproximadamente 1,33 MB/segundo).

Muestreo de disponibilidad de datos: cada nodo solo necesita descargar una pequeña porción de los datos para verificar la disponibilidad de los datos generales.

EIP-4844 (es decir, blobs) no nos proporciona muestreo de disponibilidad de datos. Pero sí configura el marco básico de tal manera que desde aquí se puede introducir el muestreo de disponibilidad de datos y aumentar la cantidad de blobs detrás de escena, todo sin la participación del usuario o la aplicación. De hecho, el único “hard fork” necesario es un simple cambio de parámetro.

A partir de aquí, las dos direcciones en las que será necesario continuar el desarrollo son:

1. Aumente gradualmente la capacidad del blob y finalmente obtenga una vista panorámica del muestreo de disponibilidad de datos, proporcionando 16 MB de espacio de datos para cada intervalo de tiempo;
2. Mejorar L2 para utilizar mejor el espacio de datos que tenemos.

Hacer realidad el DAS

La siguiente etapa puede ser una versión simplificada de DAS llamada PeerDAS. En PeerDAS, cada nodo almacena una porción significativa (por ejemplo, 1/8) del total de datos del blob y los nodos mantienen conexiones con muchos pares en la red p2p. Cuando un nodo necesita muestrear un dato específico, le pregunta a uno de los pares que se sabe que es responsable de almacenar ese dato.

Si cada nodo necesita descargar y almacenar 1/8 de todos los datos, entonces PeerDAS, en teoría, nos permite aumentar el tamaño de los blobs en 8x (en realidad, 4x, ya que perdemos 2x debido a la redundancia de la codificación de borrado). PeerDAS se puede implementar con el tiempo: podríamos tener una fase en la que los participantes profesionales continúen descargando blobs completos, mientras que los participantes individuales solo descarguen 1/8 de los datos.

Además de esto, EIP-7623 (o alternativas como precios 2D) podrían usarse para establecer límites más estrictos en el tamaño máximo de los bloques de ejecución (es decir, “transacciones regulares” en un bloque), lo que permitiría aumentar los objetivos de blobs y el gas L1. La tapa se vuelve más segura. A largo plazo, protocolos DAS 2D más complejos nos permitirán mejorar en todos los ámbitos y aumentar aún más el espacio blob.

Mejorar el rendimiento de L2

Hoy en día, los protocolos de Capa 2 (L2) se pueden mejorar de cuatro formas clave.

1. Utilice bytes de manera más eficiente mediante la compresión de datos

Mi diagrama general de compresión de datos todavía se puede ver aquí;

Hablando ingenuamente, una transacción ocupa unos 180 bytes de datos. Sin embargo, existe una variedad de técnicas de compresión que pueden reducir este tamaño en varias etapas; al optimizar la compresión, eventualmente podemos reducir la cantidad de datos por transacción a menos de 25 bytes.

** 2. Utilice la tecnología de datos optimista de L1 únicamente en circunstancias especiales para garantizar la seguridad de L2 **

Plasma es una clase de tecnología que le permite mantener datos en L2 en circunstancias normales y al mismo tiempo proporciona una seguridad equivalente a Rollup para algunas aplicaciones. Para los EVM, Plasma no puede proteger todas las monedas. Pero las construcciones inspiradas en Plasma pueden proteger la mayoría de las monedas. Y una compilación mucho más simple que Plasma podría mejorar enormemente los validiums actuales. Las L2 que no estén dispuestas a poner todos sus datos en cadena deberían explorar dicha tecnología.

3. Continuar mejorando las restricciones relacionadas con la ejecución

Una vez que se activa el hard fork de Dencun, el costo de configurar paquetes acumulativos para usar los blobs que introduce se reduce en un factor de 100. El resumen básico experimentó un aumento inmediato en el uso:

Esto, a su vez, hizo que Base alcanzara su límite interno de gas, lo que provocó un aumento inesperado en las tarifas. Esto lleva a un reconocimiento más amplio de que el espacio de datos de Ethereum no es el único que necesita expandirse: los paquetes acumulativos internos también deben expandirse.

Parte de esto es la paralelización; los paquetes acumulativos pueden lograr algo similar a EIP-648. Pero igualmente importante es el almacenamiento y la interacción entre computación y almacenamiento. Este es un importante desafío de ingeniería para los rollups.

4. Continuar mejorando la seguridad

Todavía estamos lejos de un mundo en el que los paquetes acumulativos estén realmente protegidos por código. De hecho, según l2 beat, sólo uno de estos cinco, sólo Arbitrum, soporta totalmente EVM, llegando incluso a lo que yo llamo “etapa uno”.

Esto debe abordarse de frente. Si bien todavía no tenemos suficiente confianza en el código para un validador EVM sofisticado, optimista o basado en SNARK, definitivamente somos capaces de llegar a la mitad del camino y contamos con comités de seguridad que pueden intervenir en umbrales altos (por ejemplo, lo que estoy haciendo). (proponer es 6 de 8; Arbitrum está ejecutando 9 de 12) para cambiar el comportamiento del código.

Los estándares del ecosistema deben volverse más estrictos: hasta ahora, hemos sido tolerantes y hemos aceptado cualquier proyecto que pretenda estar “en el camino hacia la descentralización”. Para finales de año, creo que nuestros estándares deberían elevarse y solo deberíamos considerar como proyectos acumulativos aquellos proyectos que hayan alcanzado al menos la etapa uno.

Después de esto, podemos avanzar con cautela hacia la segunda etapa: un resumen verdaderamente respaldado por el código, y un comité de seguridad sólo si el código “obviamente se contradice” (por ejemplo, acepta dos raíces estatales incompatibles o dos diferentes. Un mundo donde puedes intervenga sólo si da respuestas diferentes). Un camino hacia este objetivo de forma segura es utilizar múltiples probadores.

¿Qué significa esto para el desarrollo de Ethereum?

En ETHCC en el verano de 2022, presenté un informe que describía el estado actual del desarrollo de Ethereum como una curva en S: Estamos entrando en un período de transición muy rápido, después del cual, a medida que se consolida L1 y el desarrollo se vuelve a centrar en los usuarios y en la aplicación. capa, el desarrollo se ralentizará nuevamente.

Hoy, diría que estamos claramente en la parte derecha de esta curva en desaceleración. Hace dos semanas, se completaron los dos cambios más importantes en la cadena de bloques Ethereum: el cambio a prueba de participación y la refactorización en blobs. Los cambios futuros seguirán siendo importantes (por ejemplo, árboles Verkle, finalidad de un solo espacio, abstracción de cuentas dentro del protocolo), pero serán menos dramáticos que la prueba de participación y la fragmentación. En 2022, Ethereum es como un avión que cambia de motor en pleno vuelo. En 2023 reemplazó sus alas. La transición del árbol Verkle es el principal cambio restante realmente importante (ya tenemos una red de prueba); los otros son más como reemplazar el alerón trasero.

El objetivo de EIP-4844 es realizar un gran cambio único para establecer la estabilidad a largo plazo de los paquetes acumulativos. Ahora que los blobs están disponibles, futuras actualizaciones a danksharding completo con blobs de 16 MB, o incluso convertir el cifrado a ricitos de oro de 64 bits para STARK en el campo, pueden ocurrir sin la necesidad de resúmenes ni ninguna otra acción por parte del usuario. También refuerza un precedente importante: el proceso de desarrollo de Ethereum se ejecuta de acuerdo con una hoja de ruta conocida y de larga data, y las aplicaciones creadas con el “nuevo Ethereum” en mente (incluido L2) obtienen un entorno estable a largo plazo.

¿Qué significa esto para las aplicaciones y los usuarios?

Los primeros diez años de Ethereum han sido en gran medida una fase de capacitación: el objetivo siempre ha sido hacer despegar Ethereum L1, y la adopción se produjo principalmente entre un pequeño grupo de personas entusiastas. Muchos argumentan que la falta de adopción masiva durante la última década demuestra que las criptomonedas son inútiles. Siempre he estado en contra de la idea de que casi todas las aplicaciones criptográficas de especulación no financiera se basan en tarifas bajas, por lo que cuando nos enfrentamos a tarifas altas no debería sorprendernos que lo que veamos principalmente sea especulación financiera.

Ahora que tenemos manchas, esta limitación clave que nos ha estado frenando comienza a desaparecer. Las tarifas finalmente han bajado significativamente; mi afirmación de hace siete años de que Internet del dinero no debería costar más de cinco centavos por transacción finalmente se ha hecho realidad. Aún no estamos completamente fuera de peligro: si el uso crece demasiado rápido, las tarifas aún pueden aumentar y tendremos que seguir trabajando para escalar los blobs (y los rollups por separado) durante los próximos años. Pero vemos la luz al final del túnel… eh… bosque oscuro.

Para los desarrolladores esto significa una cosa sencilla: ya no tenemos excusas. Hasta hace unos años, nos poníamos un listón bajo, creando aplicaciones que eran claramente inutilizables a escala, siempre que funcionaran como prototipos y estuvieran razonablemente descentralizadas. Hoy en día, tenemos todas las herramientas que necesitamos, y de hecho la mayoría de las herramientas que tendremos alguna vez, para crear aplicaciones que sean a la vez cypherpunk y fáciles de usar. Entonces deberíamos salir y hacerlo.

Mucha gente está a la altura de este desafío. Daimo Wallet se describe claramente a sí mismo como Venmo en Ethereum, con el objetivo de combinar la conveniencia de Venmo con la descentralización de Ethereum. En el mundo de las redes sociales descentralizadas, Farcaster hace un gran trabajo al combinar una verdadera descentralización (por ejemplo, consulte esta guía sobre cómo crear su propio cliente alternativo) con una excelente experiencia de usuario. A diferencia de las locuras anteriores de las “finanzas sociales”, el usuario promedio de Farcaster no está ahí para apostar, pasando una prueba clave para una aplicación criptográfica verdaderamente sostenible.

Esta publicación se envió a través del cliente principal de Farcaster, Warpcast, y esta captura de pantalla es del cliente alternativo Farcaster + Lens, Firefly.

Estos éxitos son lo que necesitamos aprovechar y extender a otras áreas de aplicación, incluidas la identidad, la reputación y la gobernanza.

Las aplicaciones creadas o mantenidas hoy deberían tener el Ethereum de la década de 2020 como modelo

El ecosistema Ethereum todavía tiene una gran cantidad de aplicaciones que operan en torno a un flujo de trabajo que es fundamentalmente el “Ethereum de la década de 2010”. La mayor parte de la actividad de ENS todavía ocurre en la primera capa (L1). La mayor parte de la emisión de tokens también ocurre en la primera capa, sin que se piense seriamente en garantizar que los tokens puente estén disponibles en la segunda capa (L2) (por ejemplo, vea este fanático de ZELENSKYY memecoin aplaudiendo las donaciones en curso de la moneda a Ucrania, pero quejándose sobre las tarifas L1 lo hace demasiado caro). Además de la escalabilidad, también estamos atrasados en privacidad: todos los POAP están expuestos en la cadena, lo que puede ser la opción correcta para algunos casos de uso, pero muy subóptima para otros. La mayoría de las DAO y Gitcoin Grants todavía utilizan votaciones en cadena totalmente transparentes, lo que las hace muy susceptibles al soborno (incluidos los lanzamientos aéreos posteriores al evento), que se ha demostrado que distorsiona gravemente los patrones de contribución. Hoy en día, los ZK-SNARK existen desde hace muchos años, pero muchas aplicaciones aún no han empezado a utilizarlos correctamente.

Estos son equipos que trabajan duro y tienen que lidiar con una gran base de usuarios existente, por lo que no los culpo por no actualizarse a la última tecnología al mismo tiempo. Pero pronto será necesario que esta actualización se realice. Aquí hay algunas diferencias clave entre un flujo de trabajo de Ethereum fundamentalmente de la década de 2010 y un flujo de trabajo de Ethereum fundamentalmente de la década de 2020:

Básicamente, Ethereum ya no es sólo un ecosistema financiero. Es una alternativa completa a la “tecnología centralizada” en la mayoría de las áreas, e incluso ofrece algunas cosas que la tecnología centralizada no puede (por ejemplo, aplicaciones relacionadas con la gobernanza). Necesitamos construir teniendo en mente este ecosistema más amplio.

en conclusión

Ethereum está atravesando una transición decisiva de una era de “rápido progreso de L1” a una era en la que el progreso de L1 seguirá siendo significativo, pero un poco más modesto y menos disruptivo para las aplicaciones.

Todavía tenemos que completar la expansión. Este trabajo se realizará más entre bastidores, pero sigue siendo importante.

Los desarrolladores de aplicaciones ya no se limitan a crear prototipos; estamos creando herramientas para que las utilicen millones de personas. En todo el ecosistema, debemos ajustar completamente nuestra mentalidad en consecuencia.

Ethereum ha evolucionado de “simplemente” un ecosistema financiero a una pila de tecnología descentralizada independiente más completa. En todo el ecosistema, debemos ajustar nuestra mentalidad al respecto por completo en consecuencia.