El 13 de marzo, se activó la bifurcación dura de Dencun, lo que permite una de las características más esperadas de Ethereum: el proto-danksharding (también conocido como EIP-4844, también conocidos como blobs). Inicialmente, el fork redujo las comisiones de transacción de los rollups en un factor de más de 100, ya que los blobs eran casi gratuitos. En el último día, finalmente vimos cómo los blobs aumentaban en volumen y el mercado de comisiones se activaba a medida que el protocolo de blobscripciones comenzaba a utilizarlos. Los blobs no son gratuitos, pero siguen siendo mucho más baratos que los calldata.

Izquierda: el uso de blobs finalmente se dispara hasta el objetivo de 3 por bloque gracias a las Blobscripciones. Derecha: las tarifas de los blobs están "entrando en modo de descubrimiento de precios" como resultado. Fuente: https://dune.com/0xRob/blobs.

Este hito representa una transición clave en la hoja de ruta a largo plazo de Ethereum: los bloques son el momento en que la escalabilidad de Ethereum dejó de ser un problema de "de cero a uno" y se convirtió en un problema de "de uno a N". A partir de aquí, el trabajo importante de escalado, tanto en el aumento de la cantidad de bloques como en la mejora de la capacidad de los rollups para aprovechar al máximo cada bloque, continuará teniendo lugar, pero será más incremental. Los cambios relacionados con el escalado en el paradigma fundamental de cómo opera Ethereum como ecosistema ya están en gran medida detrás de nosotros. Además, el énfasis ya está cambiando lentamente, y seguirá cambiando lentamente, de los problemas de L1 como PoS y escalabilidad, a problemas más cercanos a la capa de aplicación. La pregunta clave que cubrirá esta publicación es: ¿hacia dónde va Ethereum a partir de aquí?

El futuro de la escalabilidad de Ethereum

Durante los últimos años, hemos visto cómo Ethereum ha ido cambiando lentamente hacia convertirse en un ecosistema centrado en L2. Las principales aplicaciones han comenzado a trasladarse de L1 a L2, los pagos están empezando a basarse en L2 por defecto, y las carteras están empezando a construir su experiencia de usuario en torno al nuevo entorno multi-L2.

Desde el principio, una pieza clave del roadmap centrado en rollups fue la idea de un espacio separado de disponibilidad de datos: una sección especial de espacio en un bloque, al cual la EVM no tendría acceso, que podría contener datos para proyectos de capa 2 como rollups. Debido a que este espacio de datos no es accesible por la EVM, puede ser transmitido por separado de un bloque y verificado por separado de un bloque. Eventualmente, puede ser verificado con una tecnología llamada muestreo de disponibilidad de datos, lo que permite a cada nodo verificar que los datos se publicaron correctamente solo revisando aleatoriamente algunas muestras pequeñas. Una vez implementado esto, el espacio de bloques podría expandirse enormemente; el objetivo final es de 16 MB por ranura (~1.33 MB por segundo).

Muestreo de disponibilidad de datos: cada nodo solo necesita descargar una pequeña parte de los datos para verificar la disponibilidad de todo el conjunto.

EIP-4844 (también conocido como "blobs") no nos proporciona muestreo de disponibilidad de datos. Pero establece la estructura básica de tal manera que a partir de ahora, se puede introducir el muestreo de disponibilidad de datos y aumentar la cantidad de blobs en segundo plano, todo sin la participación de usuarios o aplicaciones. De hecho, el único "hard fork" requerido es un simple cambio de parámetro.

Hay dos vertientes de desarrollo que necesitarán continuar desde aquí:

1. Aumento progresivo de la capacidad de blob, que eventualmente da vida a la visión completa del muestreo de disponibilidad de datos con 16 MB por ranura de espacio de datos
2. Mejorando L2s para hacer un mejor uso del espacio de datos que tenemos

Dando vida a DAS

La siguiente etapa probablemente sea una versión simplificada de DAS llamadaPeerDASEn PeerDAS, cada nodo almacena una fracción significativa (por ejemplo, 1/8) de todos los datos de blob, y los nodos mantienen conexiones con muchos pares en la red p2p. Cuando un nodo necesita muestrear un fragmento específico de datos, le solicita a uno de los pares que sabe que es responsable de almacenar ese fragmento.

Si cada nodo necesita descargar y almacenar 1/8 de todos los datos, entonces PeerDAS nos permite escalar teóricamente los bloques por 8x (bueno, en realidad 4x, porque perdemos 2x por la redundancia del código de borrado). PeerDAS se puede implementar con el tiempo: podemos tener una etapa donde los validadores profesionales continúan descargando bloques completos, y los validadores individuales solo descargan 1/8 de los datos.

Además de esto, EIP-7623(o alternativas como2D precios) se puede usar para establecer límites más estrictos en el tamaño máximo de un bloque de ejecución (es decir, las "transacciones regulares" en un bloque), lo que hace que sea más seguro aumentar tanto el destino de blob como el límite de gas L1. A largo plazo, más complicado protocolos DAS 2Dnos permitirá llegar hasta el final y aumentar aún más el espacio del blob.

Mejorando L2s

Hay cuatro lugares clave en los que los protocolos de capa 2 hoy pueden mejorar.

1. Utilizando bytes de manera más eficiente con compresión de datos

Mi esquema-en-una-imagen de compresión de datoscontinúa estando disponible aquí;

Ingenuamente, una transacción ocupa alrededor de 180 bytes de datos. Sin embargo, existen una serie de técnicas de compresión que se puede utilizarpara reducir este tamaño en varias etapas; con compresión óptima, potencialmente podríamos llegar a menos de 25 bytes por transacción.

1. Técnicas de datos optimistas que aseguran L2s solo utilizando el L1 en situaciones excepcionales

Plasmaes una categoría de técnicas que te permite obtener seguridad equivalente a rollup para algunas aplicaciones mientras se mantiene los datos en L2 en el caso normal. 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 las construcciones mucho más simples que Plasma pueden mejorar enormemente en elvalidiumsde hoy. Las L2 que no estén dispuestas a poner todos sus datos en la cadena deberían explorar tales técnicas.

1. Continuar mejorando en las restricciones relacionadas con la ejecución

Una vez que se activó la bifurcación Dencun, haciendo que los rollups configurados para usar los blobs que introdujo sean 100 veces más baratos. uso en el Baserollup se disparó de inmediato:

Esto a su vez llevó a Base a alcanzar su propio límite interno de gas, causando tarifas para aumentar inesperadamente. Esto ha llevado a darse cuenta de forma más extensa de que el espacio de datos de Ethereum no es lo único que necesita escalarse: los rollups también necesitan escalarse internamente.

Parte de esto es la paralelización; los rollups podrían implementaralgo como EIP-648. Pero igual de importante esalmacenamiento, y efectos de interacciónentre computación y almacenamiento. Este es un desafío de ingeniería importante para rollups.

1. Continuar mejorando la seguridad

Todavía estamos lejos de un mundo donde los rollups estén verdaderamente protegidos por código. De hecho, según l2beatsolo estos cinco, de los cuales solo Arbitrum es completo EVM, han llegado inclusolo que he llamado "etapa 1".

Esto necesita ser abordado de frente. Si bien actualmente no estamos en el punto en el que podamos estar lo suficientemente seguros del código complejo de un verificador de EVM optimista o basado en SNARK, estamos absolutamente en el punto en el que podemos llegar a la mitad del camino, y tener consejos de seguridad que pueden revertir el comportamiento del código solo con un umbral alto (por ejemplo, propuse 6-de-8; Arbitrum está haciendo 9-de-12).

Los estándares del ecosistema deben volverse más estrictos: hasta ahora, hemos sido permisivos y aceptado cualquier proyecto siempre y cuando afirme estar "en un camino hacia la descentralización". Para fin de año, creo que nuestros estándares deberían aumentar y solo deberíamos considerar un proyecto como un rollup si realmente ha alcanzado al menos la etapa 1.

Después de esto, podemos avanzar con cautela hacia la etapa 2: un mundo donde los rollups estén verdaderamente respaldados por código, y un consejo de seguridad solo puede intervenir si el código 'discrepa de manera comprobable consigo mismo' (por ejemplo, acepta dos raíces de estado incompatibles, o dos implementaciones diferentes dan respuestas distintas). Un camino hacia hacer esto de manera segura esutilizar múltiples implementaciones de probadores.

¿Qué significa esto para el desarrollo de Ethereum en un sentido más amplio?

En una presentación en ETHCC en verano de 2022, Hice una presentación describiendo el estado actual del desarrollo de Ethereum como una curva en S: estamos entrando en un período de transición muy rápida, y después de esa transición rápida, el desarrollo volverá a desacelerarse a medida que el L1 se solidifica y el desarrollo se centra nuevamente en el usuario y la capa de aplicación.

Hoy, yo sostendría que estamos decididamente en el lado derecho de desaceleración de esta curva en S. Hasta hace dos semanas, los dos cambios más grandes en la cadena de bloques de Ethereum - el cambio a prueba de participación y la reestructuración a bloques - ya están detrás de nosotros. Otros cambios siguen siendo significativos (por ejemplo, Árboles Verkle, finalidad de una sola ranura, abstracción de cuenta en protocolo), pero no son drásticos en la misma medida que la prueba de participación y el particionamiento lo son. En 2022, Ethereum era como un avión reemplazando sus motores en pleno vuelo. En 2023, estaba reemplazando sus alas. La transición al árbol Verkle es la principal que queda realmente significativa (y ya tenemos redes de prueba para eso); las demás son más como reemplazar una aleta de cola.

El objetivo de EIP-4844 era hacer un único cambio grande y puntual, para establecer los rollups para una estabilidad a largo plazo. Ahora que los blobs están fuera, una actualización futura a un danksharding completo con blobs de 16 MB, e incluso cambiar la criptografía aSTARKs sobre un campo de goldilocks de 64 bits, puede ocurrir sin necesidad de ninguna acción adicional por parte de rollups y usuarios. También refuerza un precedente importante: que el proceso de desarrollo de Ethereum se ejecuta de acuerdo con una hoja de ruta bien establecida y comprendida desde hace mucho tiempo, y las aplicaciones (incluidas las L2) que se construyen teniendo en cuenta 'el nuevo Ethereum' 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 etapa de formación: el objetivo ha sido poner en marcha Ethereum L1, y las aplicaciones han estado ocurriendo en su mayoría dentro de un pequeño grupo de entusiastas. Muchos han argumentado que la falta de aplicaciones a gran escala en los últimos diez años demuestra que las criptomonedas son inútiles. Siempre he argumentado en contra de esto: prácticamente todas las aplicaciones de criptomonedas que no son especulación financiera dependen de tarifas bajas, por lo que mientras tengamos tarifas altas, ¡no deberíamos sorprendernos de que veamos principalmente especulación financiera!

Ahora que tenemos blobs, esta restricción clave que nos ha estado frenando todo este tiempo está empezando a desaparecer. Las tarifas son finalmente mucho más bajas; mi declaración de hace siete años queInternet del dinero no debe costar más de cinco centavos por transacciónfinalmentehaciéndose realidad. No estamos completamente fuera del bosque: las tarifas aún pueden aumentar si el uso crece demasiado rápido, y debemos seguir trabajando arduamente para escalar los bloques (y escalar los rollups por separado) aún más en los próximos años. Pero estamos viendo la luz al final del... err... oscuro bosque.

Lo que esto significa para los desarrolladores es simple: ya no tenemos excusa. Hasta hace unos años, nos estábamos poniendo un estándar bajo, construyendo aplicaciones que claramente no eran utilizables a gran escala, siempre y cuando funcionaran como prototipos y fueran razonablemente descentralizadas. Hoy en día, tenemos todas las herramientas que necesitaremos, e incluso la mayoría de las herramientas que alguna vez tendremos, para construir aplicaciones que sean simultáneamente ciberpunky fácil de usar. Y así deberíamos salir y hacerlo.

Muchos están respondiendo al desafío. La billetera Daimo se describe explícitamente como Venmo en Ethereum, con el objetivo de combinar la conveniencia de Venmo con la descentralización de Ethereum. En el ámbito social descentralizado, Farcaster está haciendo un buen trabajo al combinar una descentralización genuina (por ejemplo, ver esta guíasobre cómo construir su propio cliente alternativo) con una excelente experiencia de usuario. A diferencia de las olas de hype anteriores de 'fi social', el usuario promedio de Farcaster no está ahí para apostar, pasando la prueba clave para que una aplicación cripto sea verdaderamente sostenible.

Esta publicación fue enviada en el cliente principal de Farcaster,Warpcast, y esta captura de pantalla fue tomada desde el Farcaster alternativo +LenteclienteFirefly.

Estos son éxitos en los que necesitamos basarnos y ampliar a otras esferas de aplicación, incluida la identidad, la reputación y la gobernanza.

Las aplicaciones construidas o mantenidas hoy en día deben ser diseñadas teniendo en cuenta Ethereum en la década de 2020

El ecosistema de Ethereum todavía tiene una gran cantidad de aplicaciones que operan en torno a un flujo de trabajo fundamentalmente “Ethereum de la década de 2010”. La mayoría de la actividad de ENS todavía está en la capa 1. La mayoría de la emisión de tokens ocurre en la capa 1, sin una consideración seria para asegurar que los tokens puenteados en las capas 2 estén disponibles (por ejemplo, ver este fan de la criptomoneda ZELENSKYY) apreciando las donaciones continuas de la moneda a Ucrania pero quejándose de que las tarifas de L1 lo hacen demasiado caro). Además de la escalabilidad, también estamos rezagados en privacidad: POAPstodos son públicamente en cadena, probablemente la elección correcta para algunos casos de uso pero muy subóptima para otros. La mayoría de los DAOs, y Subvenciones de Gitcoin, aún utilizan votaciones totalmente transparentes en cadena, lo que las hace altamente vulnerable al soborno(incluidas las distribuciones aéreas retroactivas), y esto ha demostrado distorsionar fuertemente los patrones de contribución. Hoy en día, ZK-SNARKs han existido durante años, y sin embargo muchas aplicaciones ni siquiera han empezado ausarlos correctamente.

Estos son todos equipos trabajadores que tienen que manejar grandes bases de usuarios existentes, por lo que no les reprocho por no actualizar simultáneamente a la última ola de tecnología. Pero pronto, esta actualización debe ocurrir. 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 solo un ecosistema financiero. Es un reemplazo de pila completa para gran parte de la "tecnología centralizada", e incluso proporciona algunas cosas que la tecnología centralizada no hace (por ejemplo, aplicaciones relacionadas con la gobernanza). Y necesitamos construir teniendo en cuenta este ecosistema más amplio.

Conclusiones

• Ethereum está en proceso de un cambio decisivo de una era de 'progreso L1 muy rápido' a una era donde el progreso L1 seguirá siendo muy significativo, pero algo más suave y menos disruptivo para las aplicaciones.
• Todavía necesitamos terminar la escalabilidad. Este trabajo será más en segundo plano, pero sigue siendo importante.
• Los desarrolladores de aplicaciones ya no están construyendo prototipos; estamos construyendo herramientas para que las usen millones de personas. En todo el ecosistema, necesitamos reajustar completamente las mentalidades en consecuencia.
• Ethereum se ha actualizado de ser simplemente un ecosistema financiero a un conjunto de tecnología descentralizada mucho más completo e independiente. En todo el ecosistema, necesitamos ajustar completamente las mentalidades en consecuencia también.

Descargo de responsabilidad：

1. Este artículo está reimpreso de [Vitalik], Todos los derechos de autor pertenecen al autor original [Vitalik]. Si hay objeciones a esta reimpresión, por favor contacta al Gate Learnequipo, y lo resolverán rápidamente.
2. Responsabilidad de exención de responsabilidad: Las opiniones expresadas en este artículo son únicamente las 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.