El posible futuro de Ethereum: The Surge

La hoja de ruta de Ethereum tenía inicialmente dos estrategias de escalado: fragmentación y protocolos Layer 2. A medida que la investigación avanzó, estos dos caminos se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de expansión actual de Ethereum.

El mapa de ruta centrado en Rollup propone una división de trabajo simple: Ethereum L1 se enfoca en convertirse en una capa base fuerte y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema. Este modelo es común en la sociedad: la existencia del sistema judicial (L1) no es para buscar eficiencia, sino para proteger los contratos y los derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta base sólida, impulsando el desarrollo humano.

Este año, la hoja de ruta centrada en Rollup ha logrado avances importantes: el lanzamiento de los blobs EIP-4844 ha aumentado significativamente el ancho de banda de datos de Ethereum L1, y múltiples Rollups EVM han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas y lógica, y la diversidad en la implementación de fragmentos se ha convertido en una realidad. Sin embargo, este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar la hoja de ruta centrada en Rollup, resolver estos problemas, al mismo tiempo que mantenemos la robustez y descentralización inherentes a Ethereum L1.

The Surge: Objetivos clave

1. En el futuro, Ethereum podrá alcanzar más de 100,000 TPS a través de L2;
2. Mantener la descentralización y robustez de L1;
3. Al menos algunos L2 heredan completamente las propiedades fundamentales de Ethereum: ( confiable, abierto, resistente a la censura );
4. Ethereum debería sentirse como un ecosistema unificado, no como 34 cadenas de bloques diferentes.

Paradoja del triángulo de la escalabilidad

La paradoja del triángulo de escalabilidad sostiene que hay una contradicción entre las tres características de descentralización, escalabilidad y seguridad de la blockchain. No es un teorema, sino un punto de vista heurístico. A lo largo de los años, algunas cadenas de alto rendimiento han afirmado haber resuelto la paradoja ternaria, pero esto suele ser engañoso.

Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos de cálculo se ejecutan correctamente, descargando solo una pequeña cantidad de datos y realizando muy pocos cálculos.

Otra forma de resolver el dilema de los tres caminos es la arquitectura Plasma, que transfiere la responsabilidad de monitorear la disponibilidad de datos a los usuarios de manera compatible con los incentivos. Con la proliferación de SNARKs, la arquitectura Plasma se vuelve más viable para una gama más amplia de escenarios de uso.

Avances adicionales en el muestreo de disponibilidad de datos

¿Qué problema estamos resolviendo?

Después de la actualización Dencun el 13 de marzo de 2024, Ethereum tendrá 3 blobs de aproximadamente 125 kB por slot cada 12 segundos, o un ancho de banda de datos disponible por slot de aproximadamente 375 kB. Suponiendo que los datos de transacción se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el máximo TPS de Rollup en Ethereum es de 173.6 TPS.

Al agregar el calldata de Ethereum, se convierte en 607 TPS. Usando PeerDAS, el número de blobs puede aumentar a 8-16, lo que proporcionará 463-926 TPS para el calldata.

Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Nuestro objetivo a medio plazo es de 16 MB por slot y, si se combinan con las mejoras en la compresión de datos de Rollup, se logrará aproximadamente ~58000 TPS.

¿Qué es? ¿Cómo funciona?

PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de 4096 grados en un campo primo de 253 bits. Transmitimos las partes del polinomio, donde cada parte contiene 16 valores de evaluación en 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier conjunto de 4096 puede recuperar el blob.

El principio de funcionamiento de PeerDAS es permitir que cada cliente escuche una pequeña cantidad de subredes, donde la i-ésima subred transmite la i-ésima muestra de cualquier blob y solicita otros blobs en subredes necesarias preguntando a pares en la red p2p global. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subred sin consultas adicionales al nivel de pares. La propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos utilicen PeerDAS.

Desde un punto de vista teórico, podemos escalar el "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256, entonces podemos alcanzar el objetivo de 16 MB, y en el muestreo de disponibilidad de datos, cada nodo necesita solo 1 MB de ancho de banda por cada slot. Esto está apenas dentro de nuestro rango de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.

Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, que no solo se realiza dentro del blob, sino también entre los blobs. Aprovechando la propiedad lineal del compromiso KZG, expandimos el conjunto de blobs dentro de un bloque mediante un conjunto de nuevos blobs virtuales que codifican redundantemente la misma información.

Es crucial que la expansión del compromiso de cálculo no requiera un blob, por lo que esta solución es fundamentalmente amigable con la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG del blob, y pueden confiar en la muestra de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos. La muestra de disponibilidad de datos unidimensional (1D DAS) también es esencialmente amigable con la construcción de bloques distribuidos.

¿Qué más se necesita hacer? ¿Qué consideraciones hay?

A continuación se completará la implementación y el lanzamiento de PeerDAS. Después, se aumentará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, este es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajo académico para regular PeerDAS y otras versiones de DAS y su interacción con problemas de seguridad relacionados con las reglas de selección de bifurcaciones.

En etapas más avanzadas en el futuro, necesitaremos hacer más trabajo para determinar la versión ideal del 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa que sea cuánticamente segura y que no requiera una configuración de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos.

El camino de realidad a largo plazo que creo es:

1. Implementar el DAS 2D ideal;
2. Seguir utilizando 1D DAS, sacrificando la eficiencia del ancho de banda de muestreo, aceptando un límite de datos más bajo por simplicidad y robustez.
3. Abandonar DA y aceptar completamente Plasma como nuestra principal arquitectura Layer2 de interés.

Por favor, tenga en cuenta que incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción también existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo que tendremos que utilizar en la capa L1 las mismas tecnologías que Rollup( como ZK-EVM y DAS).

¿Cómo interactuar con otras partes del mapa de ruta?

Si se realiza la compresión de datos, la demanda de DAS 2D disminuirá, o al menos se retrasará. Si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos para los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica esto necesita combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación.

Compresión de datos

¿Qué problema estamos resolviendo?

Cada transacción en un Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad de los protocolos de capa. Cada slot 16 MB, obtenemos:

16000000 / 12 / 180 = 7407 TPS

¿Qué pasaría si pudiéramos resolver no solo el problema de los numeradores, sino también el problema de los denominadores, y hacer que cada transacción en el Rollup ocupe menos bytes en la cadena?

¿Qué es y cómo funciona?

En la compresión de ceros, se reemplaza cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos las propiedades específicas de las transacciones:

Agregación de firmas: hemos cambiado de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, la cual puede probar la validez de todas las firmas originales. En la capa L1, debido a que incluso con la agregación, el costo computacional de verificación es alto, no se considera el uso de firmas BLS. Sin embargo, en un entorno como L2 donde los datos son escasos, el uso de firmas BLS tiene sentido. La característica de agregación de ERC-4337 proporciona un camino para lograr esta funcionalidad.

Reemplazar direcciones con punteros: Si se ha utilizado una dirección anteriormente, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunta a una posición en el historial.

Serialización personalizada de valores de transacción: La mayoría de los dígitos de los valores de transacción son pocos, por ejemplo, 0.25 ETH se representa como 250,000,000,000,000,000 wei. La tarifa base máxima y la tarifa de prioridad son similares. Por lo tanto, podemos usar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.

¿Qué más se necesita hacer, cuáles son las consideraciones?

Lo que se debe hacer a continuación es implementar realmente el plan anterior. Las principales compensaciones incluyen:

1. Cambiar a firmas BLS requiere un gran esfuerzo y reducirá la compatibilidad con chips de hardware confiables que pueden mejorar la seguridad. Se puede utilizar un encapsulado ZK-SNARK de otros esquemas de firma como sustituto.

2. Compresión dinámica ( Por ejemplo, reemplazar direcciones ) con punteros hará que el código del cliente se vuelva complejo.

3. Publicar las diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos softwares (, como los exploradores de bloques ), no funcionen.

¿Cómo interactuar con otras partes del roadmap?

Adoptar ERC-4337 y finalmente incorporar parte de su contenido en el EVM de L2 puede acelerar considerablemente el despliegue de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su despliegue en L2.

Plasma Generalizado

¿Qué problema estamos resolviendo?

Incluso con un blob de 16 MB y compresión de datos, 58,000 TPS puede no ser suficiente para satisfacer completamente las demandas de pagos de consumidores, redes sociales descentralizadas u otros campos de alta banda ancha, especialmente cuando comenzamos a considerar factores de privacidad, lo que podría reducir la escalabilidad de 3 a 8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, actualmente