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

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

Inicialmente, había dos estrategias de escalado en la hoja de ruta de ETH. Una de ellas es la “fragmentación”: cada Nodo solo necesita validar y almacenar un pequeño subconjunto de transacciones, en lugar de validar y almacenar todas las transacciones de la cadena. Cualquier otra red peer-to-peer (por ejemplo, BitTorrent) funciona de esta manera, por lo que ciertamente podemos hacer que la cadena de bloques funcione de la misma manera. El otro es el protocolo Layer2: estas redes se ubicarán en la parte superior del cuadrado ETH, lo que les permitirá beneficiarse plenamente de su seguridad mientras mantienen la mayoría de los datos y la computación fuera de la cadena principal. El protocolo de capa 2 se refiere a los canales estatales en 2015, Plasma en 2017 y luego Rollup en 2019. Los rollups son más potentes que los canales de estado o el plasma, pero requieren una gran cantidad de ancho de banda de datos en cadena. Afortunadamente, para 2019, el estudio de Fragmentación había resuelto el problema de verificar la “disponibilidad de datos” a escala. Como resultado, los dos caminos se fusionaron y obtuvimos una hoja de ruta centrada en Rollup que sigue siendo la estrategia de escalado de ETHFANG en la actualidad.

The Surge, 2023 versión del mapa de ruta

La hoja de ruta centrada en Rollup propone una división simple: Ethereum (ETH) L1 se centra en ser una capa base sólida y descentralizada, mientras que L2 se encarga de ayudar a escalar el ecosistema. Este modelo se encuentra en todas partes de la sociedad: la existencia del sistema judicial (L1) no busca la velocidad y eficiencia extrema, sino proteger los contratos y los derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta base sólida y lideran a la humanidad hacia Marte, ya sea literal o metafóricamente.

Este año, el roadmap centrado en Rollup ha logrado avances importantes: con el lanzamiento de los bloques EIP-4844, el ancho de banda de datos de la capa L1 de Ethereum ha aumentado significativamente, y varios Rollup de Máquina virtual de Ethereum (EVM) L2 han entrado en la primera etapa. Cada L2 existe como una ‘Fragmentación’ con sus propias reglas y lógica interna, y la diversidad y pluralidad en la implementación de Fragmentación ahora es una realidad. Sin embargo, como hemos visto, seguir este camino también enfrenta desafíos únicos. Por lo tanto, nuestra tarea actual es completar el roadmap centrado en Rollup y abordar estos problemas, al mismo tiempo que mantenemos la robustez y Descentralización característicos de la capa L1 de Ethereum.

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 heredan completamente las propiedades fundamentales de Ethereum (Sin confianza, abierto, resistente a la censura) ;

4、La red de Ethereum debería sentirse como un ecosistema unificado en lugar de 34 blockchains distintas.

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 L2 maduro

6. Mejora de la interoperabilidad entre L2 cruzados

7. Extensión de ejecución en L1

Paradoja del triángulo de escalabilidad

La paradoja del triángulo de escalabilidad es una idea propuesta en 2017 que sostiene que hay una contradicción entre las tres características de blockchain: descentralización (específicamente, el bajo costo de operar un nodo), escalabilidad (manejo de un gran número de transacciones) y seguridad (un atacante necesita comprometer una gran parte de los nodos de la red para que una transacción falle).

Es importante tener en cuenta que el triángulo de la paradoja no es un teorema, y las publicaciones que lo presentan no vienen con una prueba matemática adjunta. De hecho, proporciona 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 comprometer unos pocos Nodos para llevar a cabo 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, tiene como objetivo demostrar que romper la paradoja triangular es difícil y requiere en cierta medida salir del marco de pensamiento implícito en el argumento.

Durante muchos años, algunas cadenas de alto rendimiento han afirmado a menudo que han resuelto el trilema sin cambiar fundamentalmente la arquitectura, generalmente optimizando el Nodo a través de técnicas de ingeniería de software. Esto es engañoso, ya que correr un Nodo on-chain en estas cadenas es mucho más difícil que correr un Nodo en la cadena de Ether. 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 Ether.

Sin embargo, la combinación de muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar que una cierta cantidad de datos esté disponible y que se hayan ejecutado una cierta cantidad de pasos de cálculo con solo descargar una pequeña cantidad de datos y realizar una cantidad mínima de cálculos. SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un modelo sutil de confianza few-of-N, pero conserva las características fundamentales de una cadena no escalable, es decir, que incluso un ataque del 51% no puede obligar a la red a aceptar 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 monitoreo de una manera compatible a los usuarios. En los años 2017-2019, cuando solo teníamos 01928374656574839201 como medio para expandir la capacidad de cálculo, el Plasma estaba muy limitado en cuanto a la ejecución segura, pero con la proliferación de SNARKs (argumentos de conocimiento cero concisos no interactivos), la arquitectura de Plasma se ha vuelto más factible para escenarios de uso más amplios que nunca.

Further Progress in Data Availability Sampling

¿Qué problema estamos resolviendo?

El 13 de marzo de 2024, cuando Dencun se actualice y esté en línea, habrá alrededor de 3 blobs de aproximadamente 125 kB cada uno en cada slot de 12 segundos en la cadena de bloques de Ethereum, o un ancho de banda disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de transacción se publiquen directamente en la cadena, la TPS máxima de Rollup de ERC20 en Ethereum será de: 375000 / 12 / 180 = 173.6 TPS.

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

Este es un gran avance para la cadena L1 de Ether, pero no es suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por ranura, lo que, junto con las mejoras en la compresión de datos de Rollup, dará lugar a ~58000 TPS.

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

PeerDAS es una implementación relativamente simple de ‘1D sampling’. En Ethereum, cada blob es un polinomio de 4096 veces en el campo primo de 253 bits. Transmitimos las partes del polinomio, donde cada parte contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier conjunto de 4096 (según los parámetros propuestos actualmente: cualquier conjunto de 64 de 128 posibles muestras) puede recuperar el blob.

El principio de funcionamiento de PeerDAS es hacer que cada cliente escuche una pequeña subred, donde el i-ésimo subred transmite cualquier blob de la i-ésima muestra, y solicita otros blobs en subredes diferentes a través de pares en la red p2p global (quienes escucharán subredes diferentes). La versión más conservadora, SubnetDAS, solo utiliza el mecanismo de subred, sin consultas adicionales 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 un «1D muestreo» considerablemente: si aumentamos el número máximo de fragmentos a 256 (objetivo 128), podríamos alcanzar el objetivo de 16 MB, mientras que la disponibilidad de datos del muestreo sería de 16 muestras por Nodo * 128 fragmentos * 512 bytes por muestra de fragmento = 1 MB de ancho de banda de datos por ranura. Esto solo está dentro de nuestros límites de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no podrán realizar muestreos. Podríamos optimizar esto hasta cierto punto al reducir la cantidad de fragmentos y aumentar el tamaño de los fragmentos, pero esto aumentaría el costo de reconstrucción.

Por lo tanto, finalmente queremos ir un paso más allá y realizar un muestreo 2D (2D sampling), este método no solo realiza un muestreo aleatorio dentro del blob, sino también entre los blobs. Utilizando las propiedades lineales del compromiso KZG, ampliamos un conjunto de blobs en un bloquear con un nuevo conjunto de blobs virtuales que codifican redundante mente la misma información.

Por lo tanto, finalmente queremos ir un paso más allá y realizar un muestreo 2D, no solo dentro del blob, sino también entre los bloques de manera aleatoria. Las propiedades lineales de compromiso KZG se utilizan para expandir una lista de nuevos bloques virtuales que contienen codificación redundante de la misma información en un bloquear.

2D muestreo. Fuente de datos: a16z crypto

Es crucial destacar que la ampliación de los compromisos de cómputo no requiere un blob, por lo que este enfoque es amigable para 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 de una dimensión (1D DAS) también es fundamentalmente amigable para la construcción de bloques distribuidos.

¿Cuáles son los enlaces con investigaciones existentes?

1. Publicación original que introduce la disponibilidad de datos (2018):

2. Documento de seguimiento:

3. Sobre el artículo de explicación de DAS, paradigma:

4. Disponibilidad 2D con la promesa de KZG:

PeerDAS en 5.ethresear.ch: y el documento:

6.EIP-7594:

SubnetDAS en ethresear.ch 7:

8.2D Diferencias sutiles en la recuperabilidad del muestreo:

¿Qué más queda por hacer? ¿Qué otras consideraciones hay?

A continuación viene la implementación y el lanzamiento de PeerDAS. Luego, se seguirá incrementando la cantidad de blobs en PeerDAS, al mismo tiempo que se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, esto es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajos académicos para estandarizar la interacción de PeerDAS y otras versiones de DAS, así como la seguridad en la regla de elección de bifurcación, entre otros temas.

En etapas futuras más distantes, necesitaremos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos eventualmente cambiar de KZG a una alternativa cuánticamente segura y sin configuración confiable. Actualmente, no está claro cuáles de las soluciones candidatas son amigables para la construcción de Bloquear distribuido. Incluso con el uso de la costosa técnica de ‘fuerza bruta’ utilizando STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que, aunque técnicamente, el tamaño de un STARK es O(log(n) * log(log(n)) hash value (utilizando STIR), en realidad, un STARK es casi tan grande como el blob completo.

Mi camino real a largo plazo es:

1. Implementar el ideal 2D DAS;

2. Persiste en el uso de 1D DAS, sacrifica la eficiencia de la banda de muestreo para mantener la simplicidad y la robustez a expensas de un límite de datos más bajo.

3.（Hard pivot）放弃 DA，完全接受 Plasma 作为我们seguir的主要 Layer2 架构。

Por favor, tenga en cuenta que incluso si decidimos escalar directamente en la capa L1, esta opción también es posible. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, el Bloquear L1 se volverá muy grande, y los clientes desearán tener 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 se reducirá o al menos habrá una latencia, y si Plasma se usa ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos para la construcción de protocolos y mecanismos de Bloquear distribuido: aunque en teoría es amigable con la reconstrucción distribuida, en la práctica debe combinarse con la propuesta de inclusión de paquetes y el mecanismo de selección de forks 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 la transferencia de ERC20. Incluso con un muestreo ideal de la disponibilidad de datos, esto también limita la escalabilidad del protocolo de capa. Con 16 MB por ranura, obtenemos:

16000000 / 12 / 180 = 7407 TPS

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

¿Qué es esto 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:

Firma agregada: Cambiamos de la firma ECDSA a la firma BLS, que tiene la característica de que varias firmas pueden combinarse en una sola firma que puede demostrar la validez de todas las firmas originales. En la capa L1, debido a que incluso con la agregación, el costo de verificación es alto, no se considera utilizar la firma BLS. Sin embargo, en entornos como L2, donde los datos son escasos, tiene sentido utilizar la firma BLS. La característica de agregación de ERC-4337 proporciona una forma de implementar esta funcionalidad.

Reemplazar DIRECCIÓN con punteros: si hemos utilizado previamente una DIRECCIÓN, podemos reemplazar los 20 bytes de DIRECCIÓN por un puntero de 4 bytes que apunte a una posició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. Las tarifas base máximas y las tarifas prioritarias también son similares. Por lo tanto, podemos utilizar un formato decimal flotante personalizado para representar la mayoría de los valores de moneda.

¿Cuáles son los enlaces con investigaciones existentes?

1. Explorar sequence.xyz:

2. Optimización de los datos de calldata L2 del contrato:

3. Los Rollups basados en prueba de validez (también conocidos como ZK rollups) difieren en estado de publicación en lugar de en transacciones:

4.BLS Billetera - Implementación de agregación BLS a través de ERC-4337:

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

Lo siguiente que tenemos que hacer es implementar realmente el plan mencionado anteriormente. Las consideraciones principales 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. Puede ser reemplazado por el encapsulamiento ZK-SNARK de otros esquemas de firma.

2、La compresión dinámica (por ejemplo, reemplazar con punteros DIRECCIÓN) hará que el código del cliente se vuelva más complejo.

3、Publicar las diferencias de estado en la cadena en lugar de las transacciones, Soltar la auditabilidad y hacer que muchos software (por ejemplo, explorador de la blockchain) no funcione.

¿Cómo interactuar con otras partes del roadmap?

Usando ERC-4337 y finalmente incorporándolo parcialmente en L2 EVM, se 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 blobs de 16 MB y compresión de datos, 58,000 TPS no serían suficientes para satisfacer completamente las necesidades de alta demanda de consumidores para pagos, redes sociales Descentralización u otros campos de alta banda ancha, especialmente cuando comenzamos a considerar la privacidad, lo que 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 off-chain y utiliza un interesante modelo de seguridad: 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 off-chain y coloque las raíces de Merkle de estos Bloques on-chain (a diferencia de Rollup, que colocaría Bloques completos on-chain). Para cada Bloque, el operador enviará a cada usuario una rama de Merkle para demostrar qué cambios han ocurrido en sus activos, o si no ha habido cambios. Los usuarios pueden extraer sus activos proporcionando la rama de Merkle. Es importante destacar que esta rama no tiene que tener como raíz el estado más reciente. Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo el estado disponible más reciente. Si un usuario presenta una rama inválida (por ejemplo, extrayendo activos que ya han sido enviados a otra persona, o si el operador crea activos de la nada), se puede utilizar el mecanismo de desafío on-chain para determinar la vesting legítima de los activos.

Gráfico de la cadena Plasma Cash. Las transacciones que gastan 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 tiene actualmente 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 pagos y no podían escalarse de manera efectiva. Sin embargo, si exigimos que cada raíz sea verificada con SNARK, Plasma se volverá mucho más poderoso. Cada juego de desafío puede ser considerablemente simplificado, ya que excluimos la mayoría de las posibles vías para el fraude del operador. Al mismo tiempo, se abren nuevas vías para que la tecnología de Plasma se expanda a una gama más amplia de clases de activos. Finalmente, en ausencia de fraude por parte del operador, los usuarios pueden retirar fondos de inmediato sin tener que esperar una semana de período de desafío.

Un método (no el único) para crear una cadena EVM Plasma: construir un árbol UTXO paralelo utilizando ZK-SNARK que refleje los cambios de saldo realizados por EVM y defina una asignación única del “mismo token” en diferentes momentos históricos. A continuación, se puede construir una estructura Plasma sobre él.

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

Otro tipo de estructura es una combinación de Plasma/Rollup, como Intmax. Estas estructuras colocan una cantidad mínima de datos en la cadena (por ejemplo, 5 bytes) por cada usuario, lo que permite obtener ciertas características intermedias entre Plasma y Rollup: en el caso de Intmax, se puede lograr una alta escalabilidad y privacidad, aunque teóricamente también se limita a aproximadamente 16,000,000 / 12 / 5 = 266,667 TPS incluso en una capacidad de 16 MB.

¿Qué enlaces están relacionados con la investigación existente?

1. Documento original de Plasma:

2. Plasma Cash:

3. Flujo de efectivo de Plasma Cashflow:

4.Intmax (2023):

¿Qué más necesito hacer? ¿Qué consideraciones hay?

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 excluyentes: cualquier Validium puede mejorar su seguridad al incorporar las características de Plasma en su mecanismo de salida. El enfoque de la investigación se centra en obtener las mejores propiedades para EVM (considerando las necesidades de confianza, los costos de gas L1 en el peor de los casos y la capacidad para resistir ataques DoS), así como en estructuras de aplicación alternativas. Además, en comparación con Rollup, Plasma tiene una mayor complejidad conceptual, lo que requiere una investigación y construcción de marcos generales más sólidos para abordar directamente este desafío.

La principal consideración al utilizar un diseño basado en Plasma es que dependen más de los operadores y son más difíciles de basar, aunque el diseño híbrido Plasma/Rollup generalmente puede evitar esta debilidad.

¿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 capacidades de disponibilidad de datos de alto rendimiento. Mover la actividad a L2 también puede reducir la presión de MEV en L1.

Sistema de prueba de L2 maduro

¿Qué problema estamos resolviendo?

En la actualidad, 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 prueba (optimista o de validez). En algunos casos, el sistema de prueba 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) Optimism y Arbitrum son dos Rollup completos de EVM que implementan una parte del hito de la primera fase sin confianza. La razón por la cual los Rollup no han avanzado más es porque hay preocupaciones sobre la existencia de errores en el código. Necesitamos Rollup sin confianza, así que debemos enfrentar y solucionar este problema.

¿Qué es y cómo funciona?

En primer lugar, vamos a repasar el sistema de “escenario” que se introdujo inicialmente en este documento.

Fase 0: Los usuarios deben poder ejecutar Nodo y sincronizar la cadena. Si la verificación es completamente confiable / centralizada, eso está bien también.

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, la parte de bloqueo del quórum del comité (es decir, el 26%+) debe estar fuera de la empresa principal que construye el Rollup. Se permite el uso de un mecanismo de actualización más débil (por ejemplo, DAO), pero debe tener una latencia suficientemente larga para que los usuarios puedan retirar sus fondos antes de que se aprueben las actualizaciones maliciosas.

Fase 2: Debe haber un sistema de prueba (sin confianza) para garantizar que solo se acepten transacciones válidas. El comité 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 post-estados diferentes para el mismo bloque (o no acepta ningún contenido durante un período de tiempo suficientemente largo, como una semana). Se permite el uso de mecanismos de actualización, pero deben tener una latencia prolongada.

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

1. Verificación formal: podemos utilizar matemáticas y tecnología informática modernas para demostrar (optimistic y validity) que el sistema de demostración solo acepta Bloquear que cumple con la especificación EVM. Estas tecnologías han existido durante décadas, pero avances recientes (como Lean 4) las han hecho más prácticas, y los avances en la demostración asistida por IA pueden acelerar aún más esta tendencia.

2. Multi-provers: Crear múltiples sistemas de prueba y depositar fondos en estos sistemas de prueba junto con un comité de seguridad (o con otras herramientas de confianza, como TEE, que tienen supuestos de confianza). Si los sistemas de prueba están de acuerdo, el comité de seguridad no tiene poder; si no lo están, el comité de seguridad solo puede elegir entre uno de ellos, no puede imponer unilateralmente su respuesta.

El gráfico programático de los 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 investigaciones existentes?

1. Semántica de K de EVM (trabajo de verificación formal desde 2017):

2. Discurso sobre la idea de la prueba múltiple (2022):

3. Plan to use multi-proof:

¿Qué más necesito hacer? ¿Qué consideraciones hay?

Para la Verificación formal, el trabajo es enorme. Necesitamos crear una versión de verificación formal completa del probador SNARK de EVM. Este es un proyecto extremadamente complejo, aunque ya hemos comenzado. Hay un truco que puede simplificar en gran medida esta tarea: podemos crear un probador SNARK verificado formalmente para una Máquina virtual mínima (como RISC-V o Cairo) y luego implementar EVM en esa Máquina virtual mínima (y formalmente demostrar su equivalencia con otras especificaciones de Máquina virtual ETH).

Para las pruebas de múltiples pruebas, todavía hay dos partes principales que no están completas. En primer lugar, necesitamos tener suficiente confianza en al menos dos sistemas de prueba diferentes, asegurándonos de que sean seguros y de que si tienen problemas, estos problemas sean diferentes e independientes (por lo tanto, no ocurrirían al mismo tiempo). En segundo lugar, necesitamos tener una gran 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 hacerlo muy pequeño, simplemente almacenando los fondos en un contrato de seguro múltiple (Safe multisig) que actúa como firmante para los diferentes sistemas de prueba, 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 soltar la presión de MEV en L1.

Mejoras en la interoperabilidad de L2

¿Qué problema estamos resolviendo?

Un desafío importante que enfrenta el ecosistema L2 en la actualidad es la dificultad para que los usuarios naveguen en él. Además, los métodos más sencillos a menudo vuelven a introducir suposiciones de confianza, como la interacción centralizada entre cadenas, los clientes RPC, etc. Necesitamos hacer que usar el ecosistema L2 se sienta como usar un ecosistema unificado de Ethereum.

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

Las mejoras en la interoperabilidad L2 cruzada tienen muchas categorías. En teoría, centrarse en Ethereum con Rollup y ejecutar Fragmentación L1 es lo mismo. El ecosistema L2 actual de Ethereum todavía tiene estas deficiencias en la práctica en comparación con el estado ideal:

1. DIRECCIÓN específica de la cadena: La DIRECCIÓN debe contener información de la cadena (L1, Optimism, Arbitrum, etc.). Una vez logrado esto, el proceso de envío inter-L2 se puede lograr simplemente colocando la DIRECCIÓN en el campo ‘Enviar’, en este momento la billetera puede manejar internamente cómo realizar el envío (incluyendo el uso del protocolo de interacción cross-chain).

2、Solicitud de pago en cadenas específicas: Debería ser fácil y estandarizado crear mensajes con el formato ‘enviar X cantidad de token Y en la cadena Z hacia mí’. Esto es especialmente útil en dos escenarios: (i) pagos entre personas o entre personas y servicios comerciales; (ii) solicitud de fondos por parte de una DApp.

3. Intercambio e interacción cross-chain y pago de gas: debería haber un protocolo abierto y estandarizado para expresar la interacción cross-chain, como ‘Enviaré 1 ETH a la persona que me envió 0.9999 ETH en Arbitrum (en Optimism)’ y ‘Enviaré 0.0001 ETH a la persona que incluyó esta transacción en Arbitrum (en Optimism)’. ERC-7683 es un intento de abordar lo primero, mientras que RIP-7755 es un intento de abordar lo segundo, aunque ambos tienen un alcance más amplio que estos casos de uso específicos.

4. cliente ligero: Los usuarios deben poder verificar de manera efectiva la cadena con la que están interactuando, en lugar de confiar únicamente en el proveedor RPC. Helios de a16z crypto puede lograr esto (para ETH en sí), pero necesitamos extender esta confianza a L2. ERC-3668 (CCIP-read) es una estrategia para lograr este objetivo.

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

1、Keystore  Billetera: Hoy en día, si desea actualizar el Contrato inteligente Billetera de control Llave secreta, debe actualizarlo en todas las cadenas en las que exista la Billetera. Keystore  Billetera es una tecnología que permite que Llave secreta exista solo en un lugar (ya sea en L1 o posiblemente en L2 en el futuro), y luego cualquier L2 que tenga una copia de Billetera puede leer Llave secreta de ella. Esto significa que la actualización solo necesita hacerse una vez. Para mejorar la eficiencia, Keystore  Billetera requiere que L2 tenga una forma estandarizada de leer la información en L1 sin costo; hay dos propuestas para esto, que son L1SLOAD y REMOTESTATICCALL.

El funcionamiento de Keystore Billetera

2. Concepto más agresivo de ‘puente de Token compartido’: Imagina un mundo donde todos los L2 son prueba de validez Rollup y cada slot se presenta a la red Ethereum. Incluso en este mundo, mover activos de un L2 a otro L2 en su estado nativo requeriría retirar y depositar, lo que implicaría pagar una gran cantidad de gas en L1. Una forma de abordar este problema es crear un Rollup compartido extremadamente simple que solo mantenga qué L2 tiene cada tipo de Token y cuánto saldo tiene, permitiendo que estos saldos se actualicen en lotes a través de una serie de operaciones de transferencia entre L2 iniciadas por cualquier L2. Esto haría que las transferencias entre L2 no requieran pagar tarifas de gas L1 en cada transferencia, ni depender de tecnologías basadas en proveedores de liquidez como ERC-7683.

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 entre L2 cruzados; 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 investigaciones existentes?

1. Dirección específica de la cadena: ERC-3770:

2. ERC-7683:

3.RIP-7755:

4. Diseño de estilo de Billetera de archivo de clave:

5.Helios:

6.ERC-3668（a veces conocido como lectura CCIP）：

7. Propuesta de ‘preconfirmación (compartida)’ presentada por Justin Drake:

8.L1SLOAD (RIP-7728):

9.REMOTESTATICCALL en Optimism:

10. AggLayer, que incluye la idea de un puente de tokens compartidos:

¿Qué más necesito hacer? ¿Qué consideraciones hay?

Muchos de los ejemplos anteriores se enfrentan a un dilema de estándares de cuándo estandarizar y qué capas estandarizar. Si estandariza demasiado pronto, puede afianzar una mala solución. Si estandariza demasiado tarde, puede crear una fragmentación innecesaria. En algunos casos, hay una solución a corto plazo con atributos más débiles que es más fácil de implementar, y una solución a largo plazo que es “en última instancia correcta” pero que tarda años en lograrse.

Estas tareas no son sólo problemas técnicos, también son (e incluso pueden ser principalmente) problemas sociales que requieren la colaboración de L2, Billetera y L1.

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

La mayoría de estas propuestas son estructuras 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 altamente escalable y exitoso, pero L1 aún puede manejar solo una cantidad muy pequeña de volumen, podría haber muchos riesgos para Ethereum.

1、La situación económica de los activos de ETH se volverá aún 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 ecosistemas financieros altamente desarrollados en L1, por lo que si este ecosistema se debilita considerablemente, el incentivo para convertirse en L2 (en lugar de ser independiente L1) disminuirá.

3. L2 tomará mucho tiempo para lograr la misma seguridad que L1.

4. Si L2 falla (por ejemplo, debido a la conducta maliciosa o desaparición del operador), los usuarios todavía necesitan recuperar sus activos a través de L1. Por lo tanto, L1 debe ser lo suficientemente poderoso como para manejar ocasionalmente el trabajo de finalización altamente 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 esto? ¿Cómo funciona?

La forma más simple de expandirse es aumentar directamente el límite de gas. Sin embargo, esto puede llevar a una centralización de L1, lo que debilitaría otra característica importante de ETH L1: la confiabilidad como una capa base sólida. Existe controversia sobre hasta qué punto es sostenible aumentar simplemente el límite de gas, y esto también variará según la implementación de otras tecnologías que faciliten la validación de bloques más grandes (por ejemplo, caducidad histórica, sin estado, prueba de validez L1 EVM). Otra cosa importante que debe mejorarse constantemente es la eficiencia del software del cliente de ETH, que es mucho mayor que hace cinco años. Una estrategia efectiva de aumento del límite de gas en L1 implicará acelerar el desarrollo de estas tecnologías de validación.

1.EOF: un nuevo formato de bytecode EVM que es más amigable para el análisis estático y permite una implementación más rápida. Teniendo en cuenta estas mejoras de eficiencia, el bytecode EOF puede obtener un costo de gas más bajo.

2. Precios de gas multidimensional: establece costos y límites básicos diferentes para cálculos, datos y almacenamiento, lo que puede aumentar la capacidad promedio de la capa 1 de Ethereum (L1) sin aumentar su capacidad máxima (evitando así nuevos riesgos de seguridad).

3. Soltar costos de gas para códigos de operación específicos y precompilados - Históricamente, hemos aumentado varias veces los costos de gas de ciertas operaciones que tenían precios demasiado bajos para evitar ataques de denegación de servicio. Podríamos hacer un poco más soltando los costos de gas de los códigos de operación con precios demasiado altos en Soltar. Por ejemplo, la suma es mucho más barata que la multiplicación, pero actualmente los códigos de operación ADD y MUL cuestan lo mismo. Podríamos soltar el costo de ADD e incluso reducir el costo de operaciones más simples como PUSH. En general, EOF está más optimizado en este aspecto.

4.EVM-MAX y SIMD: EVM-MAX es una propuesta que permite realizar cálculos de números grandes de forma más eficiente como un módulo separado de EVM. A menos que se exporten intencionalmente, los valores calculados por EVM-MAX solo pueden ser accedidos por otras operaciones de EVM-MAX. Esto permite tener un mayor espacio para optimizar el almacenamiento de estos valores. SIMD (instrucción única, datos múltiples) es una propuesta que permite ejecutar eficientemente la misma instrucción en matrices de valores. Ambos juntos pueden crear un coprocesador potente junto a EVM que se puede utilizar para implementar la encriptación de manera más eficiente. Esto es especialmente útil para protocolos de privacidad y sistemas de protección L2, por lo que contribuirá a la escalabilidad de L1 y L2.

Estas mejoras se discutirán más detalladamente en futuros artículos de Splurge.

Finalmente, la tercera estrategia son los Rollups nativos (o rollups consagrados): básicamente, se crean múltiples copias paralelas de EVM que generan un modelo equivalente al que puede proporcionar Rollup, pero integrado de manera más nativa en el protocolo.

¿Cuáles son los enlaces con investigaciones existentes?

1. El plan de expansión de Polynya para ETH L1:

2. Precios de Gas multidimensional:

3.EIP-7706:

4.EOF:

5.EVM-MAX:

6. SIMD:

7. Rollups nativos:

8. Max Resnick entrevista sobre el valor de la expansión L1:

9.Justin Drake habla sobre la expansión con SNARK y Rollups nativos:

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

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

1. Mejorar la tecnología (por ejemplo, código de cliente, cliente sin estado, historial caducado) para hacer que L1 sea más fácil de verificar y luego aumentar el límite de gas.

2. Reducir el costo de operación específico, aumentar la capacidad promedio sin aumentar el riesgo en el peor de los casos;

3. Rollups nativos (es decir, N réplicas paralelas del 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 términos de 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 en L1, como aumentar la proporción de usuarios que verifican nodos y el número de solos apostadores. Dependiendo de la implementación, hacer que operaciones específicas en la EVM (Máquina virtual de Ethereum) sean más baratas puede aumentar la complejidad general de la EVM.

Una pregunta importante que cualquier hoja de ruta de escalabilidad de L1 debe responder es: ¿cuáles son las visiones finales de L1 y L2 respectivamente? Obviamente, es absurdo colocar todo en L1: los posibles casos de uso podrían implicar cientos de miles de transacciones por segundo, lo que haría imposible para L1 verificar completamente (a menos que adoptemos el enfoque de Rollup nativo). Sin embargo, realmente necesitamos algunos principios rectores para asegurarnos de no caer en una situación en la que aumentar el límite de gas por 10 dañe gravemente la Descentralización de Ethereum L1.

Un punto de vista 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 permanecerá en L1 (en lugar de ser solo un problema de L2), por lo que la necesidad de abordar MEV de manera clara se volverá más urgente. Esto aumentará enormemente el valor del tiempo de ranura rápida en L1. Al mismo tiempo, esto también depende en gran medida de la verificación fluida en L1 (the Verge).

Lecturas relacionadas: “Nuevo artículo de Vitalik: ¿En qué aspectos puede mejorar PoS en Ethereum? ¿Cómo se puede lograr?”

Enlace al artículo original