Nuevo artículo de Vitalik: El posible futuro de Ethereum, The Surge

Autor: Vitalik Buterin

Compilación: Karen, Foresight News

Un agradecimiento especial a Justin Drake, Francesco, Hsiao-wei Wang, @antonttc y Georgios Konstantopoulos.

Al principio, el mapa de ruta de Ethereum tenía dos estrategias de escalado. Uno (ver un documento temprano de 2015) es la “Fragmentación” (sharding): cada Nodo solo necesita verificar y almacenar una pequeña parte de las transacciones, en lugar de verificar y almacenar todas las transacciones en la cadena. Cualquier otra red de igual a igual (por ejemplo, BitTorrent) también funciona de esta manera, por lo que ciertamente podemos hacer que la cadena de bloques funcione de la misma manera. La otra es el protocolo de capa 2: estas redes estarán por encima de Ethereum, lo que le permitirá beneficiarse plenamente de su seguridad, al tiempo que mantiene la mayor parte de los datos y cálculos fuera de la cadena principal. El protocolo de capa 2 se refiere a los canales de estado de 2015, el Plasma de 2017 y luego el Rollup de 2019. Rollup es más poderoso que los canales de estado o Plasma, pero requieren una gran cantidad de ancho de banda de datos on-chain. Afortunadamente, para 2019, la investigación de la Fragmentación ya había resuelto el problema de la “disponibilidad de datos” de verificación a gran escala. Como resultado, los dos caminos se fusionaron y obtuvimos un mapa de ruta centrado en Rollup, que sigue siendo la estrategia de escalado de Ethereum hoy en día.

The Surge, versión del mapa de ruta 2023

La hoja de ruta centrada en Rollup propone una simple división de tareas: Ethereum L1 se enfoca en ser una capa base sólida y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo se encuentra en todas partes en la sociedad: la existencia del sistema judicial (L1) no busca la velocidad y eficiencia máximas, sino proteger los contratos y los derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta base sólida para llevar a la humanidad (literalmente o metafóricamente) a Marte.

Este año, la hoja de ruta centrada en Rollup ha dado resultados importantes: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de ETH Workshop L1 ha aumentado significativamente, y varios ETH Workshop Máquina virtual (EVM) Rollups han entrado en la primera fase. Cada L2 existe como una “Fragmentación” con sus propias reglas internas y lógica, y la diversidad y pluralismo de las implementaciones de Fragmentación es ahora una realidad. Pero como hemos visto, hay algunos desafíos únicos para tomar este camino. Por lo tanto, nuestra tarea ahora es completar la hoja de ruta centrada en Rollup y abordar estos problemas manteniendo la robustez y descentralización que caracterizan a ETH L1.

The Surge: Objetivo clave

1. En el futuro, Ethereum puede alcanzar más de 100,000 TPS a través de L2.

2, Mantener la descentralización y la robustez de L1.

3、Al menos algunos L2 han heredado completamente las propiedades fundamentales de Ethereum (Sin confianza, abierto, resistente a la censura);

4. Ethereum debería sentirse como un ecosistema unificado en lugar de 34 cadenas de bloques diferentes.

Contenido de este capítulo

1. La paradoja del triángulo de la escalabilidad
2. Avances adicionales en el muestreo de disponibilidad de datos
3. Compresión de datos
4. Plasma Generalizado
5. Sistema de prueba de nivel 2 maduro
6. Mejora de la interoperabilidad en L2
7. Expandir la ejecución en L1

Paradoja del triángulo de la escalabilidad

El triángulo de la paradoja de la escalabilidad es una idea propuesta en 2017, que sostiene que existe una contradicción entre las tres características de la cadena de bloques: descentralización (específicamente, bajo costo de operación de Nodo), escalabilidad (gran cantidad de transacciones procesadas) y seguridad (los atacantes necesitan dañar una gran parte de los Nodos de la red para hacer que una transacción falle).

Vale la pena señalar que el triángulo de la paradoja no es un teorema y los mensajes que presentan la paradoja del triángulo no vienen con una prueba matemática adjunta. De hecho, ofrece un argumento matemático heurístico: si un Nodo amigable con la descentralización (como una computadora portátil de consumo) puede verificar N transacciones por segundo y tienes una cadena que procesa k*N transacciones por segundo, entonces (i) cada transacción solo puede ser vista por 1/k Nodos, lo que significa que un atacante solo necesita destruir unos pocos Nodos para realizar una transacción maliciosa, o (ii) tus Nodos se volverán poderosos pero tu cadena no será descentralizada. El propósito de este artículo no es demostrar que romper la paradoja del triángulo es imposible; por el contrario, pretende mostrar que romper la paradoja triangular es difícil y requiere salir de alguna manera del marco de pensamiento implícito en el argumento.

Durante muchos años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, generalmente mediante la optimización de Nodo a través de técnicas de ingeniería de software. Esto siempre es engañoso, ya que correr Nodo on-chain es mucho más difícil que correr Nodo en Ethereum. Este artículo explorará por qué es así y por qué la ingeniería de software del cliente L1 por sí sola no puede escalar Ethereum.

Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs realmente resuelve la paradoja triangular: permite a los clientes verificar que una cierta cantidad de datos está disponible y que se ejecuta una cierta cantidad de pasos de cálculo en situaciones en las que solo descargan una pequeña cantidad de datos y realizan una cantidad mínima de cálculos. SNARKs no requiere confianza. El muestreo de disponibilidad de datos tiene un modelo de confianza sutil few-of-N, pero conserva las características fundamentales de una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar que la red acepte bloques malos.

Otra forma de resolver el dilema de los tres problemas es la arquitectura de Plasma, que utiliza tecnología ingeniosa para transferir la responsabilidad de la disponibilidad de los datos de vigilancia de manera compatible a los usuarios. En los años 2017-2019, cuando solo teníamos el medio de prueba de fraude para expandir la capacidad de cálculo, Plasma estaba muy limitado en la ejecución segura, pero con la creciente popularidad de SNARKs (argumentos de conocimiento cero concisos no interactivos), la arquitectura de Plasma se vuelve más viable para escenarios de uso más amplios que antes.

Avances adicionales en el muestreo de la disponibilidad de datos

¿Qué problema estamos resolviendo?

El 13 de marzo de 2024, cuando Dencun se actualice y esté en línea, hay alrededor de 3 bloques de aproximadamente 125 kB cada 12 segundos en la cadena de bloques de la zona ETH, o un ancho de banda disponible de aproximadamente 375 kB por cada bloque. Suponiendo que los datos de transacción se publiquen directamente on-chain, entonces una transferencia de ERC20 es de aproximadamente 180 bytes, por lo que la TPS máxima de Rollup en la zona ETH es: 375000 / 12 / 180 = 173.6 TPS

Si agregamos el calldata de Ethereum (valor teórico máximo: 30 millones de gas por slot / 16 gas por byte = 1,875,000 bytes por slot), se convierte en 607 TPS. Con PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionaría de 463 a 926 TPS para el calldata.

Este es un gran avance para Ether L1, pero no es suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es tener 16 MB por cada slot, lo que nos proporcionaría aproximadamente 58000 TPS si se combina con mejoras en la compresión de datos de Rollup.

¿Qué es esto? ¿Cómo funciona?

PeerDAS es una implementación relativamente simple de ‘1D sampling’. En el ETH bloques, cada blob es un polinomio de 4096 grados en el 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 (cualquier 64 de los 128 posibles muestras según los parámetros propuestos) puede recuperar el blob.

El funcionamiento de PeerDAS consiste en hacer que cada cliente escuche una pequeña subred, donde la subred i transmite cualquier muestra i del blob y solicita los blobs de otras subredes necesarios preguntando a los pares en la red global p2p que escuchan diferentes subredes. La versión más conservadora, SubnetDAS, utiliza solo el mecanismo de subred sin consultar adicionalmente a la capa de pares. La propuesta actual es que los Nodos que participan en la Prueba de participación utilicen SubnetDAS, mientras que otros Nodos (es decir, clientes) utilicen PeerDAS.

En teoría, podríamos expandir la escala de ‘1D sampling’ a un tamaño bastante grande: si aumentamos el número máximo de blobs a 256 (objetivo 128), podríamos alcanzar el objetivo de 16 MB, con una disponibilidad de datos muestreados de 16 muestras por Nodo * 128 blobs * 512 bytes por muestra de cada blob = ancho de banda de 1 MB por ranura. Esto apenas entra en nuestro rango de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no podrán realizar muestreos. Podríamos optimizar esto en cierta medida reduciendo la cantidad de blobs y aumentando el tamaño de los mismos, pero esto aumentaría el costo de reconstrucción.

Por lo tanto, al final queremos ir un paso más allá y realizar un muestreo 2D (muestreo 2D), este método no solo realiza un muestreo aleatorio dentro del blob, sino también entre los blobs. Utilizando la propiedad lineal de compromiso KZG, ampliamos un conjunto de bloques en un Bloquear mediante un conjunto de nuevos bloques virtuales que codifican redundante mente la misma información.

Por lo tanto, finalmente queremos ir un paso más allá y hacer un muestreo 2D, que no solo está dentro del blob, sino que también se realiza un muestreo aleatorio entre blobs. Las propiedades lineales prometidas por KZG se utilizan para expandir una colección de blobs en un Bloquear, que contiene una nueva lista virtual de blobs redundantes codificando la misma información.

Muestreo 2D. Fuente: a16z crypto

Es importante destacar que la expansión de los compromisos de cálculo no requiere un blob, por lo que este enfoque es amigable con la construcción de bloques distribuidos. Los nodos que construyen bloques solo necesitan tener un compromiso de blob KZG y pueden depender del muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos. El muestreo de disponibilidad de datos unidimensionales (1D DAS) también es fundamentalmente amigable con la construcción de bloques distribuidos.

¿Cuáles son los enlaces con la investigación existente?

1. Publicación original que introduce la disponibilidad de datos (2018):
2. Seguimiento del documento:
3. Sobre el artículo de explicación de DAS, paradigma:
4. Usabilidad 2D con la promesa de KZG:
5. PeerDAS en ethresear.ch: y documentos:
6. EIP-7594:
7. SubnetDAS en ethresear.ch:
8. Diferencias sutiles en la recuperabilidad en el muestreo 2D:

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

A continuación se completará la implementación y el lanzamiento de PeerDAS. Luego, se irá aumentando gradualmente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, esto es un proceso gradual. Al mismo tiempo, también esperamos más trabajos académicos para regular PeerDAS y otras versiones de DAS, así como su interacción con la seguridad de las reglas de elección de bifurcación.

En una etapa futura más distante, necesitaremos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos eventualmente migrar de KZG a una alternativa cuánticamente segura y sin configuración de confianza. En este momento, no está claro qué candidatos son amigables para la construcción de Bloquear distribuido. Incluso con el uso de la costosa técnica de “fuerza bruta”, es insuficiente generar prueba de validez para reconstruir filas y columnas, ya que, aunque técnicamente, el tamaño de un STARK es O(log(n) * log(log(n)) hash (usando STIR), en realidad, un STARK es casi tan grande como el blob completo.

Mi camino real a largo plazo es:

1. Implementar el DAS 2D ideal;
2. Al seguir utilizando 1D DAS, sacrificamos la eficiencia del ancho de banda de muestreo en favor de la simplicidad y la robustez, aceptando un límite de datos más bajo.
3. Abandonar DA y aceptar por completo que Plasma sea nuestra principal arquitectura de Layer2 seguira01928374656574839201.

Por favor, tenga en cuenta que incluso si decidimos escalar directamente en la capa L1, esta opción sigue existiendo. 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 desearán un método eficiente para verificar su corrección, por lo que tendremos que utilizar tecnologías similares a Rollup (como ZK-EVM y DAS) en la capa L1.

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

Si se implementa la compresión de datos, la demanda de 2D DAS disminuirá o al menos habrá una latencia, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos para la construcción de protocolos y mecanismos de Bloquear distribuidos: aunque DAS es teóricamente amigable para la reconstrucción distribuida, esto requiere combinarse en la práctica con propuestas de inclusión de paquetes y mecanismos de selección de fork en su entorno.

Compresión de datos

¿Qué problema estamos resolviendo?

Cada transacción en Rollup ocupará una gran cantidad de espacio de datos on-chain: aproximadamente 180 bytes para transferir ERC20. Incluso con muestreo ideal de disponibilidad de datos, esto también limita la escalabilidad del protocolo de capa. Con cada ranura de 16 MB, obtenemos: 01928374656574839201

16000000 / 12 / 180 = 7407 TPS

¿Qué pasaría si pudiéramos resolver no solo los problemas del numerador, sino también los problemas del denominador, y permitir que cada transacción en Rollup ocupe menos bytes en la cadena?

¿Qué es y cómo funciona?

En mi opinión, la mejor explicación es esta imagen de hace dos años:

En la compresión de bytes cero, se reemplaza cada secuencia larga de bytes cero con dos bytes para indicar cuántos bytes cero hay. Además, aprovechamos las propiedades específicas de la transacción:

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

Usar punteros en lugar de DIRECCIÓN: si hemos usado previamente una DIRECCIÓN, podemos reemplazar los 20 bytes de la DIRECCIÓN por un puntero de 4 bytes que apunte a una ubicación en el historial.

Serialización personalizada de valores de transacción: la mayoría de los valores de transacción tienen pocos dígitos, por ejemplo, 0.25 ETH se representa como 250,000,000,000,000,000 wei. Los cargos por transacción básicos máximos y los cargos por prioridad también son similares. Por lo tanto, podemos usar un formato decimal flotante personalizado para representar la mayoría de los valores monetarios.

¿Cuáles son los enlaces con la investigación existente?

1. Explora sequence.xyz:
2. Contrato optimizado L2 Calldata:
3. Rollups basados en prueba de validez (también conocidos como ZK rollups) publican diferencias de estado en lugar de transacciones:
4. BLS Billetera - implementación de BLS agregado a través de ERC-4337:

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

Lo siguiente que hay que hacer es implementar el plan mencionado anteriormente. Las principales consideraciones incluyen:

1、Cambiar a la firma BLS requiere un gran esfuerzo y puede ser Soltar compatible con chips de hardware confiables que pueden mejorar la seguridad. Se puede reemplazar con envolturas ZK-SNARK de otros esquemas de firma.

2. La compresión dinámica (por ejemplo, reemplazar con pointers) hará que el código del cliente sea más complejo.

3. Publicar las diferencias de estado en la cadena en lugar de en las transacciones reduce la audibilidad y hace que muchos software (por ejemplo, el explorador de la blockchain) no funcione.

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

Utilizando ERC-4337, y finalmente incorporándolo parcialmente en L2 EVM, puede acelerar significativamente la implementación de la tecnología de agregación. Colocar parte del contenido de ERC-4337 en L1 puede acelerar su implementación en L2.

Plasma Generalizado

¿Qué problema estamos resolviendo?

Incluso con un blob de 16 MB y compresión de datos, 58,000 TPS puede que no sea suficiente para satisfacer por completo las necesidades de los consumidores en pagos, redes sociales Descentralización u otros campos de alta capacidad de ancho de banda, especialmente cuando comenzamos a considerar la privacidad, lo cual podría Soltar la escalabilidad de 3 a 8 veces. Para escenarios de alta volumen y bajo valor, una opción actual es utilizar Validium, que almacena datos fuera de la cadena (off-chain) y utiliza un modelo de seguridad interesante: los operadores no pueden robar los fondos de los usuarios, pero pueden congelar temporal o permanentemente los fondos de todos los usuarios. Pero podemos hacerlo mejor.

¿Qué es y cómo funciona?

Plasma es una solución de escalado que implica que un operador publique bloques en off-chain y coloque las raíces de Merkle de estos bloques en on-chain (a diferencia de Rollup, que coloca bloques completos en on-chain). Para cada bloque, el operador envía a cada usuario una rama de Merkle para demostrar qué cambios (o falta de cambios) han ocurrido en sus activos. Los usuarios pueden recuperar sus activos proporcionando la rama de Merkle. Es importante destacar que esta rama no tiene que tener la raíz más actualizada. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo el estado más actualizado disponible. Si un usuario envía una rama inválida (por ejemplo, recuperando activos que ya han enviado a otra persona o creando activos de la nada), la legalidad de la inversión puede ser determinada mediante el mecanismo de desafío on-chain.

Gráfico de la cadena Plasma Cash. Las transacciones de gastar la moneda i se colocan en la posición i del árbol. En este ejemplo, supongamos que todos los árboles anteriores son válidos, sabemos que Eve actualmente tiene el Token 1, David tiene el Token 4 y George tiene el Token 6.

Las primeras versiones de Plasma solo podían manejar casos de uso de pago y no pudieron ser efectivamente promovidas. Sin embargo, si requerimos que cada raíz sea verificada mediante SNARK, entonces Plasma será mucho más poderosa. Cada juego de desafío puede ser significativamente simplificado ya que se excluyen la mayoría de las posibles vías de trampa del operador. Al mismo tiempo, se abren nuevas vías para expandir la tecnología de Plasma a una amplia variedad de tipos de activos. Finalmente, en caso de que el operador no haga trampa, los usuarios pueden retirar su dinero de forma inmediata sin tener que esperar una semana de período de desafío.

Un método (no el único método) para crear una cadena EVM Plasma: construir un árbol UTXO paralelo utilizando ZK-SNARK, que refleja los cambios de saldo realizados en EVM y define un mapeo único de ‘Token’ en diferentes puntos temporales del historial. Luego, se puede construir una estructura de Plasma sobre él.

Una idea clave es que el sistema Plasma no necesita ser perfecto. Incluso si solo puedes proteger un subconjunto de activos (por ejemplo, solo Tokens que no se han movido en la última semana), ya has mejorado significativamente la situación actual del EVM altamente escalable (es decir, Validium).

Otro tipo de estructura es una combinación de Plasma/Rollup, como Intmax. Estas estructuras colocan una cantidad muy pequeña de datos de cada usuario en la cadena (por ejemplo, 5 bytes), lo que les permite obtener algunas características entre Plasma y Rollup: en el caso de Intmax, se puede lograr una escalabilidad y privacidad muy altas, aunque teóricamente limitado a alrededor de 266,667 TPS incluso en una capacidad de 16 MB.

¿Cuáles son los enlaces relacionados con las investigaciones existentes?

1. Documento original de Plasma:
2. Plasma Cash:
3. Flujo de efectivo de Plasma Cashflow:
4. Intmax (2023):

¿Qué más se necesita hacer? ¿Qué consideraciones hay que tener en cuenta?

La tarea principal restante es implementar el sistema Plasma en aplicaciones de producción reales. Como se mencionó anteriormente, Plasma y Validium no son opciones mutuamente excluyentes: cualquier Validium puede mejorar sus propiedades de seguridad al incorporar características de Plasma en su mecanismo de salida. El enfoque de la investigación es obtener las mejores propiedades para EVM (considerando requisitos de confianza, costo de gas L1 en el peor de los casos y capacidad para resistir ataques DoS), así como estructuras de aplicaciones alternativas. Además, en comparación con Rollup, Plasma es más complejo conceptualmente, lo que requiere investigación y construcción de un marco general más sólido para abordarlo directamente.

La principal consideración al utilizar Plasma Design es su mayor dependencia de los operadores y su mayor dificultad en base, aunque generalmente se puede evitar esta debilidad mediante el diseño híbrido de Plasma/Rollup.

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

Cuanto más efectiva sea la solución de Plasma, menos presión habrá en L1 para tener una alta capacidad de disponibilidad de datos de alto rendimiento. Mover la actividad a L2 también puede reducir la presión MEV en L1.

Sistema de prueba de nivel 2 maduro

¿Qué problema estamos resolviendo?

Actualmente, la mayoría de los Rollup no son en realidad Sin confianza. Existe un comité de seguridad que tiene la capacidad de anular el comportamiento del sistema de pruebas (optimistas o de validez). En algunos casos, el sistema de pruebas ni siquiera funciona o, incluso si lo hace, solo tiene funciones de ‘consulta’. Los Rollup más avanzados incluyen: (i) algunos Rollup específicos de aplicaciones Sin confianza, como FUEL; (ii) hasta la fecha de redacción de este artículo, Optimism y Arbitrum son dos implementaciones de Rollup EVM completo que han logrado un hito parcial Sin confianza llamado ‘Fase 1’. La falta de progreso en los Rollup se debe a la preocupación por los errores en el código. Necesitamos Rollup Sin confianza, por lo que debemos enfrentar y resolver este problema.

¿Qué es y cómo funciona?

En primer lugar, repasemos el sistema ‘stage’ presentado inicialmente en este artículo.

Fase 0: El usuario debe ser capaz de ejecutar Nodo y sincronizar la cadena. Si la verificación es completamente confiable / centralizada, no hay problema.

Fase 1: Debe haber un sistema de prueba (no confiable) que garantice que solo se acepten transacciones válidas. Se permite un comité de seguridad que puede anular el sistema de prueba, pero se requiere un umbral de votación del 75%. Además, una parte del comité de quórum-bloqueo (es decir, 26%+) debe estar fuera de la empresa principal encargada de construir Rollup. Se permite el uso de un mecanismo de actualización más débil (por ejemplo, DAO), pero debe tener una latencia lo suficientemente larga para que los usuarios puedan retirar sus fondos antes de que se apruebe una actualización maliciosa.

Fase 2: Debe haber un sistema de prueba (sin confianza) para garantizar que solo se acepten transacciones válidas. La Comisión de Seguridad solo permite intervenciones cuando hay errores demostrables en el código, por ejemplo, si dos sistemas de prueba redundantes son inconsistentes entre sí, o si un sistema de prueba acepta dos estados posteriores diferentes para el mismo Bloquear (o no acepta ningún contenido durante un período lo suficientemente largo, como una semana). Se permite el uso de mecanismos de actualización, pero debe tener una latencia muy larga.

Nuestro objetivo es alcanzar la fase 2. El principal desafío de alcanzar la fase 2 es obtener suficiente confianza y demostrar que el sistema es realmente digno de confianza. Hay dos métodos principales para lograr esto:

1. Verificación formal：我们可以使用现代数学和计算技术来证明（optimistic 和 validity）证明系统只接受通过 EVM 规范的 Bloquear。这些技术已经存在了几十年，但最近的进步（如 Lean 4）使它们更加实用，而 AI 辅助证明的进步可能会进一步加速这一趋势。
2. Multi-provers: Crear múltiples sistemas de prueba y depositar fondos en estos sistemas de prueba y en el comité de seguridad (o en otras herramientas de confianza, como TEE). Si los sistemas de prueba están de acuerdo, el comité de seguridad no tendrá poder; si no están de acuerdo, el comité de seguridad solo podrá elegir entre uno de ellos, no imponer unilateralmente su respuesta.

El gráfico de programación de múltiples probadores combina un sistema de prueba optimista, un sistema de prueba de validez y un comité de seguridad.

¿Cuáles son los enlaces con la investigación existente?

1. Semántica K de EVM (trabajo de verificación formal desde 2017):
2. Discurso sobre el concepto de múltiples pruebas (2022):
3. El proyecto Taiko utiliza pruebas múltiples:

¿Qué más se necesita hacer? ¿Qué consideraciones hay que tener en cuenta?

Para la Verificación formal, el trabajo es muy grande. Necesitamos crear una versión formal verificada del SNARK completo del EVM. Este es un proyecto extremadamente complejo, aunque ya hemos comenzado. Hay un truco que puede simplificar enormemente esta tarea: podemos crear un verificador de SNARK formal para una Máquina virtual minimizada (por ejemplo, RISC-V o Cairo), luego implementar EVM en esa Máquina virtual minimizada (y demostrar formalmente su equivalencia con otras especificaciones de Máquina virtual de Ethereum).

Para las pruebas de múltiples, todavía hay dos partes principales que no se han completado. En primer lugar, necesitamos tener suficiente confianza en al menos dos sistemas de prueba diferentes, asegurándonos de que cada uno sea bastante seguro por sí mismo y de que, si surgen problemas, estos sean distintos e independientes (por lo tanto, no surgirán al mismo tiempo). En segundo lugar, necesitamos tener un alto grado de confianza en la lógica subyacente del sistema de prueba combinado. Esta parte del código debe ser mucho más pequeña. Hay algunas formas de hacer que sea muy pequeña, simplemente almacenando fondos en un contrato de multi-firma seguro en el que los representantes de los diferentes sistemas de prueba actúen como firmantes, pero esto aumentará el costo de gas en la cadena. Necesitamos encontrar un equilibrio entre eficiencia y seguridad.

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

Mover la actividad a L2 puede aliviar la presión de MEV en L1.

Mejoras de interoperabilidad L2

¿Qué problema estamos resolviendo?

Uno de los principales desafíos que enfrenta el ecosistema L2 hoy en día es la dificultad que tienen los usuarios para navegar en él. Además, los métodos más simples a menudo vuelven a introducir suposiciones de confianza: interacción cross-chain centralizada, clientes RPC, etc. Necesitamos que usar el ecosistema L2 se sienta como usar un sistema unificado de Ethereum.

¿Qué es? ¿Cómo funciona?

Las mejoras de interoperabilidad L2 cruzada tienen muchas categorías. En teoría, Ethereum centrado en Rollup es lo mismo que la fragmentación L1. El ecosistema actual de L2 de Ethereum está lejos del estado ideal en la práctica debido a estos problemas:

1、La DIRECCIÓN de la cadena específica debe contener información de la cadena (L1, Optimism, Arbitrum, etc.). Una vez logrado esto, el proceso de envío a través de L2 se puede lograr simplemente colocando la DIRECCIÓN en el campo de ‘enviar’, en este momento la Billetera puede manejar internamente cómo realizar el envío (incluido el uso del protocolo de Interacción cross-chain).

2. Solicitudes de pago en cadenas específicas: debe ser capaz de crear fácilmente y estandarizar mensajes en forma de ‘envíame X cantidad de tokens Y en la cadena Z’. Esto se aplica principalmente a dos escenarios: (i) pagos entre personas o entre personas y servicios comerciales; (ii) solicitudes de fondos de DApp.

3、Intercambio cross-chain y pago de gas: debe existir un protocolo estándar abierto para expresar las operaciones de intercambio cross-chain, como “enviaré 1 ether a la persona que me envió 0.9999 ether en Arbitrum (en Optimism)” y “enviaré 0.0001 ether a la persona que incluyó esta transacción en Arbitrum (en Optimism)”. ERC-7683 es un intento para lo primero, mientras que RIP-7755 es un intento para lo segundo, a pesar de que ambos tienen un alcance más amplio que estos casos de uso específicos.

4、cliente ligero：Los usuarios deben poder verificar de forma efectiva la cadena con la que interactúan, en lugar de simplemente confiar en el proveedor de RPC. Helios de a16z crypto puede lograr esto (para la propia red ETH), pero necesitamos extender esta confianza cero a L2. ERC-3668 (CCIP-read) es una estrategia para lograr este objetivo.

¿Cómo actualiza su cliente ligero su vista de la cadena de encabezados de Ethereum? Una vez que tenga la cadena de encabezados, puede usar pruebas de Merkle para verificar cualquier objeto de estado. Una vez que tenga el objeto de estado L1 correcto, puede usar pruebas de Merkle (y, si desea verificar la preconfirmación, también puede usar firmas) para verificar cualquier objeto de estado en L2. Helios ya ha logrado lo primero. La ampliación a lo segundo es un desafío de estandarización.

1、Keystore  Billetera：如今，如果你想更新控制你的 Contrato inteligente Billetera的 Llave secreta，你必须在该 Billetera存在的所有 N 条链上都进行更新。Keystore  Billetera是一种技术，它允许 Llave secreta只存在于一个地方（要么在 L1 上，要么以后可能在 L2 上），然后任何拥有 Billetera副本的 L2 都可以从中读取 Llave secreta。这意味着更新只需进行一次。为了提高效率，Keystore  Billetera要求 L2 具有一种标准化的方式来无成本地读取 L1 上的信息；对此有两个提案，分别是 L1SLOAD 和 REMOTESTATICCALL。

Cómo funciona el keystore Billetera

2. Un concepto más radical de ‘puente de Token compartido’: imagina un mundo en el que todos los L2 son prueba de validez Rollup y cada ranura se envía a la cadena ETH. Incluso en este mundo, mover un activo de un L2 a otro en su estado original todavía requiere retirar y depositar, lo que implica pagar una gran cantidad de tarifas de gas L1. Una forma de resolver este problema es crear un Rollup compartido extremadamente simple que solo mantenga un registro de qué L2 posee cada tipo de Token y cuánto saldo tiene, y permita actualizar estos saldos a través de una serie de operaciones de envío entre L2 iniciadas por cualquier L2. Esto permitiría transferencias entre L2 sin tener que pagar tarifas de gas L1 cada vez, ni tener que utilizar tecnologías como ERC-7683 basadas en proveedores de liquidez.

3、Combinación sincrónica: permite llamadas sincrónicas entre L2 específicos y L1 o entre múltiples L2. Esto ayuda a mejorar la eficiencia financiera del protocolo de Finanzas descentralizadas. El primero puede lograrse sin ninguna coordinación cruzada de L2; el segundo requiere compartir la secuencia. La tecnología basada en Rollup se aplica automáticamente a todas estas tecnologías.

¿Cuáles son los enlaces con la investigación existente?

**链特定 DIRECCIÓN：ERC-3770：

**ERC-7683:

**RIP-7755:

**Scroll keystore  Billetera设计式样：

**Helios:

**ERC-3668 (a veces denominado CCIP Read):

La propuesta de ‘Pre-Committed (Shared) Proof-of-Stake’ presentada por Justin Drake:

**L1SLOAD (RIP-7728):

**REMOTESTATICCALL en Optimism:

**AggLayer, que incluye la idea de un puente de tokens compartido:

¿Qué más se necesita hacer? ¿Qué consideraciones hay que tener en cuenta?

Muchos de los ejemplos anteriores enfrentan el dilema de cuándo estandarizar y qué capas estandarizar. Si la estandarización es demasiado temprana, podría arraigarse una solución inferior. Si la estandarización es demasiado tardía, podría resultar en una fragmentación innecesaria. En algunos casos, existe tanto una solución a corto plazo, que es menos robusta pero más fácil de implementar, como una solución a largo plazo que es la ‘correcta’ pero que llevará años para realizarse.

Estas tareas no son solo problemas técnicos, también son (incluso posiblemente principalmente) problemas sociales que requieren la cooperación de L2 y Billetera, así como de L1.

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

La mayoría de estas propuestas son de naturaleza “de nivel superior”, por lo que tienen poco impacto en consideraciones a nivel L1. Una excepción es el orden compartido, que tiene un impacto significativo en el valor máximo extraíble (MEV).

Escalado de la ejecución en L1

¿Qué problema estamos resolviendo?

Si L2 se vuelve muy escalable y exitoso, pero L1 sigue pudiendo manejar solo una cantidad muy pequeña de volumen, entonces Ethereum podría enfrentar muchos riesgos:

1. La situación económica de los activos ETH se volverá más inestable, lo que a su vez afectará la seguridad a largo plazo de la red.

2. Muchos L2 se benefician de estar estrechamente vinculados a un ecosistema financiero altamente desarrollado en L1. Si este ecosistema se debilita significativamente, los incentivos para convertirse en L2 en lugar de ser un L1 independiente se debilitarán.

3. L2 llevará mucho tiempo alcanzar la misma seguridad que L1.

4. Si L2 falla (por ejemplo, debido a comportamiento malicioso o desaparición del operador), los usuarios aún necesitan recuperar sus activos a través de L1. Por lo tanto, L1 debe ser lo suficientemente potente como para ocasionalmente manejar el trabajo complejo y caótico de L2.

Por estas razones, seguir expandiendo L1 en sí mismo y asegurarse de que pueda seguir acomodando cada vez más casos de uso es muy valioso.

¿Qué es? ¿Cómo funciona?

La forma más simple de escalar es aumentar directamente el límite de gas. Sin embargo, esto puede llevar a la centralización de L1 y debilitar otra característica importante de Ethereum, la credibilidad de ser una capa base sólida. Existe controversia sobre hasta qué punto es sostenible simplemente aumentar el límite de gas, lo que también variará según qué otras tecnologías se implementen para hacer que la validación de Bloquear más grande sea más fácil (por ejemplo, caducidad histórica, sin estado, prueba de validez EVM de L1). Otra área importante que requiere mejoras continuas es la eficiencia del software del cliente de Ethereum, que es mucho mayor en la actualidad que hace cinco años. Una estrategia efectiva para aumentar el límite de gas de L1 implicará acelerar el desarrollo de estas tecnologías de validación.

1. EOF: un nuevo formato de bytecode de EVM que es más amigable para el análisis estático y que permite una implementación más rápida. Teniendo en cuenta estas mejoras de eficiencia, el bytecode de EOF puede obtener una tarifa de gas más baja.
2. Precios de gas multidimensionales: se establecen costos y límites básicos diferentes para cálculos, datos y almacenamiento, lo que permite aumentar la capacidad promedio de ETH L1 sin aumentar la capacidad máxima (evitando así nuevos riesgos de seguridad).
3. Soltar costos de gas específicos para códigos de operación y precompilación: en el pasado, hemos aumentado varias veces los costos de gas de ciertas operaciones con precios demasiado bajos para evitar ataques de denegación de servicio. Un poco más que se puede hacer es reducir el costo de gas de los códigos de operación de Soltar con precios demasiado altos. Por ejemplo, la suma es mucho más barata que la multiplicación, pero actualmente los códigos de operación ADD y MUL tienen el mismo costo. Podemos reducir el costo de ADD en Soltar e incluso reducir el costo de operaciones más simples como PUSH. EOF está más optimizado en general en este aspecto.
4. EVM-MAX y SIMD: EVM-MAX es una propuesta que permite realizar cálculos eficientes de números grandes nativos como un módulo independiente de EVM. A menos que se exporte de manera intencional, los valores calculados por EVM-MAX solo pueden ser accedidos por otros códigos de operación de EVM-MAX. Esto permite tener un mayor espacio para optimizar el almacenamiento de estos valores. SIMD (instrucción única, múltiples datos) es una propuesta que permite ejecutar eficientemente la misma instrucción en un arreglo de valores. Ambas propuestas juntas pueden crear un potente coprocesador al lado de EVM, que se puede utilizar para realizar operaciones de encriptación de manera más eficiente. Esto es especialmente útil para protocolos de privacidad y sistemas de protección L2, lo que ayudará en la escalabilidad de las capas L1 y L2.

Estas mejoras se discutirán en detalle en futuros artículos de Splurge.

Finalmente, la tercera estrategia es Rollups nativos (o Rollups consagrados): en esencia, crear múltiples réplicas de EVM que funcionen en paralelo, lo que resulta en un modelo equivalente al que puede ofrecer Rollup, pero más integrado en el protocolo.

¿Cuáles son los enlaces con la investigación existente?

1. Mapa de ruta de expansión de la capa L1 de Polynya ETH:
2. Precios de Gas multidimensional:
3. EIP-7706:
4. EOF:
5. EVM-MAX:
6. SIMD:
7. rollups nativos:
8. Entrevista a Max Resnick sobre el valor de la expansión de L1:
9. Justin Drake habla sobre la expansión utilizando SNARK y Rollups nativos:

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

La extensión L1 tiene tres estrategias que se pueden realizar de forma independiente o en paralelo:

1. Mejorar la tecnología (como el código del cliente, el cliente sin estado, el historial expirado) para hacer que L1 sea más fácil de verificar y luego aumentar el límite de gas.
2. Aumentar el costo de operación específico de Soltar sin aumentar el riesgo en el peor de los casos, aumentando la capacidad promedio;
3. Rollups nativos (es decir, creando N copias paralelas de EVM).

Al comprender estas diferentes tecnologías, descubriremos que cada una tiene sus propias compensaciones. Por ejemplo, los Rollups nativos tienen muchas de las mismas debilidades en cuanto a composición que los Rollups normales: no puedes enviar una sola transacción para ejecutar operaciones en varios Rollups, como lo harías con un contrato en el mismo L1 (o L2). Aumentar el límite de gas debilitará otros beneficios que se pueden lograr mediante la simplificación de la verificación L1, como aumentar la proporción de usuarios que verifican nodos y aumentar el número de apostadores SOLO. Dependiendo de la forma en que se implemente, hacer que operaciones específicas en la Máquina Virtual Ethereum (EVM) sean más baratas podría aumentar la complejidad general de la EVM.

Una pregunta importante que cualquier hoja de ruta de escalabilidad L1 debe responder es: ¿Cuáles son las visiones finales de L1 y L2 respectivamente? Claramente, es absurdo tener todo en L1: los posibles casos de uso podrían involucrar cientos de miles de transacciones por segundo, lo que haría imposible verificar L1 por completo (a menos que adoptemos Rollup nativo). Pero realmente necesitamos algunos principios rectores para asegurarnos de no caer en una situación en la que aumentar el límite de gas 10 veces cause un daño significativo a la descentralización de Ethereum L1.

Una perspectiva sobre la división del trabajo entre L1 y L2

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

Atraer a más usuarios a L1 no solo significa mejorar la escalabilidad, sino también mejorar otros aspectos de L1. Esto significa que más MEV se quedará en L1 (en lugar de ser solo un problema de L2), por lo tanto, la necesidad de manejar MEV de manera explícita se volverá más urgente. Esto aumentará enormemente el valor del tiempo de slot rápido en L1. Al mismo tiempo, esto también depende en gran medida del funcionamiento fluido de la validación de L1 (the Verge).

Recomendado para leer: “Vitalik nuevo artículo: El posible futuro de Ethereum, the Merge”