Autor original: Vitalik Buterin

Compilación original: Karen, Foresight News

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

Inicialmente, había dos estrategias de escalamiento en la hoja de ruta de Ethereum. Uno (ver un artículo anterior de 2015) es la "fragmentación": 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 peer-to-peer (como BitTorrent) funciona de esta manera, por lo que ciertamente podemos hacer que las cadenas de bloques funcionen de la misma manera. El otro son los protocolos de Capa 2: estas redes se ubicarán sobre Ethereum, lo que les permitirá beneficiarse plenamente de su seguridad y al mismo tiempo mantener la mayoría de los datos y los cálculos fuera de la cadena principal. Los protocolos de capa 2 se refieren a canales estatales en 2015, Plasma en 2017 y luego Rollup en 2019. Los rollups son más poderosos que los canales estatales o Plasma, pero requieren una gran cantidad de ancho de banda de datos en cadena. Afortunadamente, en 2019, la investigación sobre fragmentación resolvió el problema de verificar la “disponibilidad de datos” a escala. Como resultado, los dos caminos convergieron y obtuvimos una hoja de ruta centrada en Rollup que sigue siendo la estrategia de escalamiento de Ethereum en la actualidad.

The Surge, edición de hoja de ruta 2023

La hoja de ruta centrada en Rollup propone una división del trabajo simple: Ethereum L1 se centra en ser una capa base poderosa y descentralizada, mientras que L2 tiene la tarea de ayudar a escalar el ecosistema. Este modelo es omnipresente en la sociedad: el sistema judicial (L1) existe no para perseguir la supervelocidad y la eficiencia, sino para proteger los contratos y los derechos de propiedad, y los empresarios (L2) construyen sobre esta base sólida Construir para llevar a la humanidad a (literal y figurativamente) ) Marte.

Este año, la hoja de ruta centrada en rollups ha logrado resultados importantes: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos Ethereum L1 ha aumentado significativamente y múltiples rollups de Ethereum Virtual Machine (EVM) han entrado en la primera fase. Cada L2 existe como un "fragmento" con sus propias reglas y lógica internas. La diversidad y diversificación de los métodos de implementación de fragmentación ahora se han convertido en una realidad. Pero, como hemos visto, seguir este camino también conlleva algunos desafíos únicos. Por lo tanto, nuestra tarea ahora es completar la hoja de ruta centrada en Rollup y abordar estos problemas manteniendo la solidez y la descentralización que caracteriza a Ethereum L1.

La oleada: objetivos 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 solidez de L1;

3. Al menos parte de la L2 hereda completamente los atributos centrales 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

• El triángulo de la escalabilidad

• Mayores avances en el muestreo de disponibilidad de datos

• Compresión de datos

• Plasma generalizado

• Sistema de prueba maduro L2

• Mejoras en la interoperabilidad entre L2

• Extender la ejecución en L1

El triángulo de la escalabilidad

El Triángulo de Escalabilidad es una idea propuesta en 2017 que sostiene que existe una contradicción entre tres propiedades de blockchain: descentralización (más específicamente: bajo costo de ejecutar nodos), escalabilidad (procesar una gran cantidad de transacciones) y seguridad (un atacante necesitaría comprometer una gran parte de los nodos de la red para provocar que falle una sola transacción).

Vale la pena señalar que la paradoja del triángulo no es un teorema y la publicación que presenta la paradoja del triángulo no viene con una prueba matemática. Proporciona un argumento matemático heurístico: si un nodo compatible con la descentralización (por ejemplo, una computadora portátil de consumo) puede validar N transacciones por segundo y usted tiene una cadena que procesa k*N transacciones por segundo, entonces (i) cada transacción solo puede ser visto por 1/k nodos, lo que significa que un atacante solo necesita comprometer unos pocos nodos para realizar una transacción maliciosa, o (ii) su nodo se volverá poderoso y usted La cadena no estará descentralizada. El propósito de este artículo nunca fue demostrar que romper la Paradoja del Triángulo es imposible; más bien, pretendía mostrar que romper el Trilema es difícil y que requiere cierto grado de pensamiento fuera del marco del argumento.

A lo largo de los años, algunas cadenas de alto rendimiento han afirmado a menudo que han resuelto el trilema sin cambiar fundamentalmente su arquitectura, a menudo aplicando técnicas de ingeniería de software para optimizar los nodos. Esto siempre es engañoso, ejecutar un nodo en estas cadenas es mucho más difícil que ejecutar un 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 SNARK resuelve la paradoja del triángulo: permite al cliente verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos computacionales está disponible, mientras solo descarga una pequeña cantidad de datos y realiza una cantidad muy pequeña de cálculo ejecutado correctamente. Los SNARK no son confiables. El muestreo de disponibilidad de datos tiene un modelo sutil de confianza de unos pocos de N, pero conserva la propiedad fundamental de las cadenas no escalables, es decir, que ni siquiera un ataque del 51% puede forzar que la red acepte bloques defectuosos.

Otra solución al trilema es la arquitectura Plasma, que utiliza técnicas inteligentes para trasladar al usuario la responsabilidad de monitorear la disponibilidad de datos de una manera compatible con incentivos. Ya entre 2017 y 2019, cuando solo teníamos pruebas de fraude como medio para expandir la potencia informática, Plasma era muy limitado en términos de ejecución de seguridad, pero con la popularidad de los SNARK (argumentos sucintos no interactivos de conocimiento cero), Plasma La arquitectura es más Una gama más amplia de casos de uso se ha vuelto más factible.

Mayores avances en el muestreo de disponibilidad de datos

¿Qué problema estamos resolviendo?

Cuando la actualización de Dencun entre en funcionamiento el 13 de marzo de 2024, la cadena de bloques Ethereum tendrá tres blobs de aproximadamente 125 kB por ranura de 12 segundos, o aproximadamente 375 kB de ancho de banda de datos disponible por ranura. Suponiendo que los datos de la transacción se publican directamente en la cadena, una transferencia ERC 20 es de aproximadamente 180 bytes, por lo que el TPS máximo de Rollup en Ethereum es: 375000/12/180 = 173,6 TPS

Si sumamos los datos de llamada de Ethereum (máximo teórico: 30 millones de gas por ranura / 16 gas por byte = 1.875.000 bytes por ranura), esto se convierte en 607 TPS. Con PeerDAS, la cantidad de blobs se puede aumentar a 8-16, lo que proporcionaría 463-926 TPS para datos de llamadas.

Esta es una mejora significativa con respecto a Ethereum L1, pero no suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es 16 MB por ranura, lo que, combinado con mejoras en la compresión de datos acumuladas, dará como resultado ~58 000 TPS.

¿qué es? ¿Cómo funciona?

PeerDAS es una implementación relativamente simple de "muestreo 1D". En Ethereum, cada blob es un polinomio de grado 4096 sobre un campo principal de 253 bits. Transmitimos acciones polinómicas, donde cada acción contiene 16 evaluaciones en 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores evaluados, 4096 cualesquiera (según los parámetros propuestos actualmente: 64 cualesquiera de 128 muestras posibles) pueden recuperar el blob.

PeerDAS funciona haciendo que cada cliente escuche una pequeña cantidad de subredes, donde la i-ésima subred transmite la i-ésima muestra de cualquier blob, y pidiendo a los pares en la red p2p global que escucharán en diferentes subredes que soliciten blobs en otras subredes que necesita. Una versión más conservadora, SubnetDAS, utiliza sólo el mecanismo de subred sin interrogación adicional de la capa de intercambio de tráfico. 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, podemos escalar bastante un "muestreo 1D": si aumentamos el número máximo de blobs a 256 (apuntando a 128), entonces podemos alcanzar el objetivo de 16 MB sin disponibilidad de datos, muestreando 16 muestras por nodo * 128 blobs * 512 bytes por muestra por blob = 1 MB de ancho de banda de datos por ranura. Esto apenas está dentro de nuestro rango de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden realizar muestras. Podemos optimizar esto un poco reduciendo la cantidad de blobs y aumentando el tamaño del blob, pero esto encarecerá la reconstrucción.

Así que, en última instancia, queremos ir un paso más allá y realizar un muestreo 2D, que es un muestreo aleatorio no solo dentro de los blobs, sino también entre blobs. Aprovechando las propiedades de linealidad de los compromisos KZG, el conjunto de blobs en un bloque se expande mediante un nuevo conjunto de blobs virtuales que codifican de forma redundante la misma información.

Entonces, en última instancia, queremos ir un paso más allá y hacer muestreo 2D, que es un muestreo aleatorio no solo dentro de los blobs, sino también entre blobs. La propiedad lineal de los compromisos KZG se utiliza para expandir el conjunto de blobs en un bloque con una lista de nuevos blobs virtuales que codifican de forma redundante la misma información.

Muestreo 2D. Fuente: criptografía a16z

Fundamentalmente, calcular la escala de compromisos no requiere blobs, por lo que el esquema es fundamentalmente compatible con la construcción de bloques distribuidos. Los nodos que realmente construyen los bloques solo necesitan tener el compromiso blob KZG y pueden confiar en el muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad del bloque de datos. El muestreo de disponibilidad de datos unidimensional (1D DAS) también es inherentemente amigable para la construcción de bloques distribuidos.

¿Cuáles son los vínculos con la investigación existente?

• Publicación original sobre disponibilidad de datos (2018): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

• Documento de seguimiento: https://arxiv.org/abs/1809.09044

• Artículo explicativo sobre DAS, paradigma: https://www.paradigm.xyz/2022/08/das

• Disponibilidad 2D con compromisos KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081

• PeerDAS en ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 y en papel: https://eprint.iacr.org/ 2024/1362

• EIP-7594: https://eips.ethereum.org/EIPS/eip-7594

• ethresear.ch Más información sobre SubnetDAS: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169

• Matices de la recuperación de datos en muestreo 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

¿Qué más hay que hacer? ¿Cuáles son las compensaciones?

Lo siguiente es completar la implementación y el lanzamiento de PeerDAS. A partir de ahí, fue un proceso gradual de aumentar la cantidad de blobs en PeerDAS mientras se observaba cuidadosamente la red y se mejoraba el software para garantizar la seguridad. Mientras tanto, esperamos ver más trabajo académico que estandarice PeerDAS y otras versiones de DAS y su interacción con cuestiones como la seguridad de las reglas de elección de bifurcación.

En etapas posteriores en el futuro, necesitaremos trabajar más para identificar la versión ideal de DAS 2D y demostrar sus propiedades de seguridad. También esperamos eventualmente alejarnos de KZG hacia una alternativa que sea segura desde el punto de vista cuántico y que no requiera una configuración confiable. Actualmente, no sabemos qué candidatos son amigables con la construcción de bloques distribuidos. Incluso el uso de costosas técnicas de "fuerza bruta", incluso el uso de STARK recursivos para generar pruebas de validez para reconstruir filas y columnas, no es suficiente porque, aunque técnicamente un STARK es un valor hash O(log(n) * log(log(n)) (usando STIR), pero en realidad STARK es casi tan grande como toda la masa.

Mi camino realista a largo plazo es:

1. Implementar DAS 2D ideal;

2. Siga con 1D DAS, sacrifique la eficiencia del ancho de banda de muestreo y acepte límites de datos más bajos para lograr simplicidad y solidez.

3. (Pivote duro) Abandonar DA y adoptar plenamente Plasma como la arquitectura principal de Capa 2 en la que nos centramos.

Tenga en cuenta que esta opción existe incluso si decidimos escalar la ejecución directamente en la capa L1. Esto se debe a que si la capa L1 va a manejar una gran cantidad de TPS, los bloques L1 se volverán muy grandes y el cliente querrá una forma eficiente de verificar su corrección, por lo que tendremos que usar Rollup (como ZK) en el Capa L1 -EVM y DAS) misma tecnología.

¿Cómo interactúo con otras partes de la hoja de ruta?

La necesidad de DAS 2D se reducirá, o al menos se retrasará, si se implementa la compresión de datos, y se reducirá aún más si Plasma se utiliza ampliamente. DAS también plantea desafíos para los protocolos y mecanismos de construcción de bloques distribuidos: si bien DAS es teóricamente amigable para la reconstrucción distribuida, en la práctica esto debe combinarse con la propuesta de lista de inclusión y el mecanismo de elección de bifurcación que la rodea.

Compresión de datos

¿Qué problema estamos resolviendo?

Cada transacción en Rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia ERC 20 requiere aproximadamente 180 bytes. Incluso con un muestreo ideal de disponibilidad de datos, esto limita la escalabilidad del protocolo Layer. 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, de modo que cada transacción en un resumen ocupe menos bytes en la cadena?

¿Qué es y cómo funciona?

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

En la compresión de bytes cero, cada secuencia larga de bytes cero se reemplaza con dos bytes, lo que indica cuántos bytes cero hay. Yendo un paso más allá, explotamos propiedades específicas de las transacciones:

Agregación de firmas: cambiamos de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que se pueden combinar varias firmas en una sola firma que puede demostrar la validez de todas las firmas originales. En la capa L1, las firmas BLS no se consideran debido al alto costo computacional de la verificación, incluso con agregación. Pero en un entorno con escasez de datos como L2, tiene sentido utilizar firmas BLS. La naturaleza agregada de ERC-4337 proporciona una manera de lograr esta funcionalidad.

Reemplazo de direcciones con punteros: si una dirección se ha utilizado antes, podemos reemplazar la dirección de 20 bytes con 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 muy pocos dígitos, por ejemplo, 0,25 ETH se representa como 250, 000, 000, 000, 000, 000 wei. La tarifa de manejo base máxima y la tarifa de manejo prioritario también son similares. Por lo tanto, podemos utilizar un formato de punto flotante decimal personalizado para representar la mayoría de los valores monetarios.

¿Cuáles son los vínculos con la investigación existente?

• Explora secuencia.xyz: https://sequence.xyz/blog/compressing-calldata

• Contrato de optimización de datos de llamadas L2: https://github.com/ScopeLift/l2-optimizooooors

• Los rollups basados ​​en pruebas de validez (también conocidos como rollups ZK) publican diferencias de estado en lugar de transacciones: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2 -data -huella-en-l1/9975

• BLS Wallet: agregación de BLS a través de ERC-4337: https://github.com/getwax/bls-wallet

¿Qué más hay que hacer y cuáles son las compensaciones?

Lo principal que debe hacer a continuación es implementar la solución anterior. Las principales compensaciones incluyen:

1. Cambiar a firmas BLS requiere mucho esfuerzo y reduce la compatibilidad con chips de hardware confiables que mejoran la seguridad. En su lugar, se pueden utilizar envoltorios ZK-SNARK de otros esquemas de firma.

2. La compresión dinámica (por ejemplo, reemplazar direcciones con punteros) complicará el código del cliente.

3. Publicar diferencias de estado en la cadena en lugar de transacciones reducirá la auditabilidad y hará que muchos software (como los exploradores de bloques) no puedan funcionar.

¿Cómo interactúo con otras partes de la hoja de ruta?

La adopción de ERC-4337 y, eventualmente, la incorporación de partes del mismo en L2 EVM puede acelerar significativamente el despliegue de tecnologías convergentes. Colocar partes 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 pueden no ser suficientes para satisfacer plenamente las necesidades de pagos de los consumidores, redes sociales descentralizadas u otras áreas de gran ancho de banda, especialmente cuando comenzamos a considerar consideraciones de privacidad, que pueden hacer que la escalabilidad se reduzca en 3-8 veces. Para escenarios de aplicaciones de alto volumen de transacciones y bajo valor, una opción actual es usar Validium, que mantiene los datos fuera de la cadena y adopta un modelo de seguridad interesante: los operadores no pueden robar los fondos de los usuarios, pero pueden congelar temporal o permanentemente todos los fondos de los usuarios. Pero podemos hacerlo mejor.

¿Qué es y cómo funciona?

Plasma es una solución escalable que implica que un operador publique bloques fuera de la cadena y coloque las raíces Merkle de esos bloques en la cadena (a diferencia de Rollup, que coloca bloques completos en la cadena). Para cada bloque, el operador envía a cada usuario una sucursal de Merkle para demostrar qué ha cambiado o no ha cambiado en los activos de ese usuario. Los usuarios pueden retirar sus activos proporcionando una bifurcación de Merkle. Es importante destacar que esta rama no tiene que estar rooteada en el estado más reciente. Por lo tanto, incluso si hay un problema con la disponibilidad de datos, los usuarios aún pueden recuperar sus activos obteniendo el último estado disponible para ellos. Si un usuario comete una rama no válida (por ejemplo, retira un activo que ya envió a otra persona, o el propio operador crea un activo de la nada), la propiedad legal del activo se puede determinar mediante un desafío en cadena. mecanismo.

Diagrama de cadena de efectivo de plasma. Una transacción que cuesta la moneda i se coloca en la i-ésima posición del árbol. En este ejemplo, suponiendo que todos los árboles anteriores sean válidos, sabemos que Eve actualmente posee la ficha 1, David posee la ficha 4 y George posee la ficha 6.

Las primeras versiones de Plasma solo podían manejar casos de uso de pagos y no podían promocionarse más de manera efectiva. Sin embargo, Plasma se vuelve mucho más poderoso si requerimos que cada raíz sea verificada con SNARK. Cada juego de desafío se puede simplificar enormemente porque eliminamos la mayoría de las formas posibles para que los operadores hagan trampa. Al mismo tiempo, se abren nuevos caminos que permitirán que la tecnología Plasma se expanda a una gama más amplia de clases de activos. Finalmente, siempre que el operador no haga trampa, los usuarios pueden retirar fondos inmediatamente sin tener que esperar un período de desafío de una semana.

Una forma (no la única) de crear una cadena de plasma EVM: use ZK-SNARK para construir un árbol UTXO paralelo que refleje los cambios de equilibrio realizados por EVM y defina el "mismo token" en diferentes puntos de la historia. . Luego se pueden construir estructuras de plasma encima.

Una idea clave es que los sistemas de plasma no necesitan ser perfectos. Incluso si solo puede proteger un subconjunto de activos (por ejemplo, solo tokens que no se han movido durante la semana pasada), ha mejorado enormemente el estado actual del EVM hiperescalable (es decir, Validium).

Otro tipo de estructura es una híbrida Plasma/Rollup, como por ejemplo Intmax. Estas construcciones colocan una cantidad muy pequeña de datos por usuario en la cadena (por ejemplo, 5 bytes) y, al hacerlo, logran algunas propiedades entre Plasma y Rollup: en el caso de Intmax, puede lograr una escalabilidad y privacidad muy altas, aunque incluso con 16 MB de capacidad, teóricamente está limitado a aproximadamente 16.000.000/12/5 = 266.667 TPS.

¿Cuáles son los vínculos con la investigación existente?

• Artículo original sobre Plasma: https://plasma.io/plasma-deprecated.pdf

• Efectivo de plasma: https://ethresear.ch/t/efectivo-de-plasma-plasma-con-una-verificación-de-datos-por-usuario-mucho-menos/1298

• Flujo de efectivo de Plasma: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view# -Salir

• Intmáx (2023): https://eprint.iacr.org/2023/1082

¿Qué más hay que hacer? ¿Cuáles son las compensaciones?

La principal tarea pendiente es poner el sistema Plasma en uso práctico en producción. Como se mencionó anteriormente, Plasma versus Validium no es una opción: cualquier Validium puede mejorar sus propiedades de seguridad al menos hasta cierto punto incorporando características de Plasma en su mecanismo de salida. El enfoque de la investigación es obtener lo mejor para las propiedades de EVM. (considerado en términos de requisitos de confianza, costos de gas L1 en el peor de los casos y la capacidad de resistir ataques DoS), así como estructuras alternativas específicas de la aplicación. Además, Plasma es conceptualmente más complejo que Rollup, lo que requiere abordarlo directamente. investigar y construir mejores marcos generales.

La principal desventaja del uso de diseños Plasma es que dependen más del operador y son más difíciles de basar, aunque los diseños híbridos Plasma/Rollup a menudo evitan esta debilidad.

¿Cómo interactúo con otras partes de la hoja de ruta?

Cuanto más eficiente sea la solución Plasma, menos presión habrá sobre la L1 para tener capacidades de disponibilidad de datos de alto rendimiento. Mover actividades a L2 también reduce la presión MEV en L1.

Sistema de prueba maduro L2

¿Qué problema estamos resolviendo?

Actualmente, la mayoría de los Rollups no son realmente sin confianza. Existe un comité de seguridad que tiene la capacidad de anular (optimista o de validez) el comportamiento del sistema. En algunos casos, el sistema de certificación ni siquiera funciona o, si lo hace, sólo tiene una función de "asesoramiento". Los paquetes acumulativos de última generación incluyen: (i) algunos paquetes acumulativos de aplicaciones específicas sin confianza, como Fuel; (ii) al momento de escribir este artículo, Optimism y Arbitrum son dos que han logrado un hito parcial sin confianza conocido como "Fase 1" Resumen completo de EVM. La razón por la que Rollup no logró avanzar más se debió a preocupaciones sobre errores en el código. Necesitamos un Rollup sin confianza, por lo que tenemos que afrontar este problema de frente y resolverlo.

¿Qué es y cómo funciona?

Primero, revisemos el sistema de "etapas" presentado originalmente en este artículo.

Fase 0: los usuarios deben poder ejecutar el nodo y sincronizar la cadena. Si la verificación es totalmente confiable/centralizada, también está bien.

Fase 1: Debe haber un sistema de prueba (sin confianza) para garantizar que solo se aceptarán transacciones válidas. Se permite un comité de seguridad que pueda anular el sistema de certificación, pero debe haber un umbral de votación del 75%. Además, la parte del comité que bloquea el quórum (es decir, más del 26 %) debe estar fuera de la empresa principal que crea el Rollup. Se permite un mecanismo de actualización más débil (como el DAO), pero debe tener un retraso lo suficientemente largo como para que, si aprueba una actualización maliciosa, los usuarios puedan retirar sus fondos antes de que entren en funcionamiento.

Fase 2: Debe haber un sistema de prueba (sin confianza) para garantizar que solo se aceptarán transacciones válidas. El comité de seguridad sólo puede intervenir si, por ejemplo, hay errores demostrables en el código. Si dos sistemas de prueba redundantes son inconsistentes entre sí, o si un sistema de prueba acepta dos raíces post-estado diferentes para el mismo bloque (o no acepta nada durante un período de tiempo suficientemente largo, como una semana). El mecanismo de actualización está permitido, pero debe tener un gran retraso.

Nuestro objetivo es llegar a la Fase 2. El principal desafío para llegar a la etapa 2 es ganar suficiente confianza para demostrar que el sistema es lo suficientemente confiable. Hay dos formas principales de hacer esto:

• Verificación formal: podemos utilizar técnicas matemáticas y informáticas modernas para demostrar (optimista y válida) que el sistema solo acepta bloques que pasan la especificación EVM. Estas tecnologías existen desde hace décadas, pero avances recientes (como Lean 4) las han hecho más prácticas, y los avances en las pruebas asistidas por IA pueden acelerar aún más esta tendencia.

• Probadores múltiples: cree múltiples sistemas de prueba e invierta dinero en estos sistemas de prueba con comités de seguridad (u otros dispositivos con suposiciones de confianza, como TEE). Si el sistema de pruebas está de acuerdo, el comité de seguridad no tiene poder; si no, el comité de seguridad sólo puede elegir entre uno u otro, y no puede imponer unilateralmente su propia respuesta.

Gráfico estilizado de múltiples probadores, que combina un sistema de prueba optimista, un sistema de prueba de validez y un comité de seguridad.

¿Cuáles son los vínculos con la investigación existente?

• Semántica EVM K (trabajo de verificación formal de 2017): https://github.com/runtimeverification/evm-semantics

• Conferencia sobre la idea de pruebas múltiples (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI

• Taiko planea utilizar pruebas múltiples: https://docs.taiko.xyz/core-concepts/multi-proofs/

¿Qué más hay que hacer? ¿Cuáles son las compensaciones?

Para la verificación formal, la carga de trabajo es enorme. Necesitamos crear una versión verificada formalmente de todo el probador SNARK para EVM. Este es un proyecto extremadamente complejo, aunque ya hemos empezado a trabajar en él. Hay un truco que simplifica enormemente esta tarea: podemos crear un probador SNARK formalmente verificado para una máquina virtual mínima (como RISC-V o Cairo), y luego implementar el EVM en esta máquina virtual mínima (y una prueba formal de su equivalencia). a otras especificaciones de la máquina virtual Ethereum).

Hay dos partes principales de la prueba múltiple que aún no se han completado. En primer lugar, debemos tener suficiente confianza en al menos dos sistemas de prueba diferentes, tanto para garantizar que cada uno de ellos sea razonablemente seguro como para garantizar que, si algo sale mal con ellos, los problemas sean diferentes y no estén relacionados (para que no suceden simultáneamente. Ocurre un problema). En segundo lugar, debemos tener un grado muy alto de confianza en la lógica subyacente del sistema de prueba de fusiones. Esta parte del código es mucho menor. Hay formas de hacerlo muy pequeño, simplemente almacenando los fondos en un contrato multifirma seguro con contratos que representen a cada sistema de prueba como firmantes, pero esto aumentará el costo del gas en la cadena. Necesitamos encontrar algún equilibrio entre eficiencia y seguridad.

¿Cómo interactúo con otras partes de la hoja de ruta?

Mover la actividad a L2 reduce la presión MEV en L1.

Mejoras en la interoperabilidad entre L2

¿Qué problema estamos resolviendo?

Un desafío importante al que se enfrenta el ecosistema L2 actual es la dificultad que tienen los usuarios para navegar dentro de él. Además, los enfoques más sencillos suelen reintroducir supuestos de confianza: cadenas cruzadas centralizadas, clientes RPC, etc. Necesitamos hacer que el uso del ecosistema L2 sea como usar un ecosistema Ethereum unificado.

¿Qué es?

Hay muchas categorías de mejoras de interoperabilidad entre L2. En teoría, Ethereum centrado en Rollup es lo mismo que ejecutar el fragmento L1. El ecosistema actual de Ethereum L2 todavía tiene estas deficiencias respecto al estado ideal en la práctica:

1. Dirección de una cadena específica: La dirección debe contener información de la cadena (L1, Optimismo, Arbitrum...). Una vez logrado esto, el proceso de envío entre L2 se puede implementar simplemente colocando la dirección en el campo "enviar", momento en el cual la billetera puede manejar cómo enviar por sí sola en segundo plano (incluido el uso de protocolos entre cadenas). .

2. Solicitudes de pago específicas de la cadena: debería ser fácil y estandarizado crear mensajes del tipo "Envíame X tokens de tipo Y en la cadena Z". Esto tiene dos escenarios de aplicación principales: (i) ya sea pago entre personas o pago entre personas y servicios comerciales (ii) DApp que solicita fondos;

3. Intercambio entre cadenas y pago de gas: debe haber un protocolo abierto estandarizado para expresar operaciones entre cadenas, como "Enviaré 1 Ethereum a la persona que me envió 0,9999 Ethereum en Arbitrum (en Optimismo)" y " Enviaré 0,0001 Ether (en Optimism) a la persona que incluyó esta transacción en Arbitrum". ERC-7683 es ​​un intento de lo primero y RIP-7755 es un intento de lo segundo, aunque ambos tienen aplicaciones más amplias que estos casos de uso específicos.

4. Clientes ligeros: los usuarios deberían poder verificar realmente la cadena con la que están interactuando, en lugar de simplemente confiar en el proveedor de RPC. Helios de a16z crypto puede hacer esto (para el propio Ethereum), pero necesitamos extender esta falta de confianza a L2. ERC-3668 (lectura CCIP) es una estrategia para lograr este objetivo.

Una vista de cómo los clientes ligeros actualizan su cadena de encabezados de Ethereum. Una vez que tenga la cadena de encabezado, puede usar las 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 firmas si desea verificar la confirmación previa) para verificar cualquier objeto de estado en L2. Helios ha hecho lo primero. Escalar a este último es un desafío de estandarización.

1. Billetera del almacén de claves: hoy en día, si desea actualizar la clave que controla su billetera de contrato inteligente, debe actualizarla en todas las N cadenas donde existe la billetera. Las billeteras de almacén de claves son una tecnología que permite que las claves existan en un solo lugar (ya sea en L1 o posiblemente más tarde en L2) y luego cualquier L2 que tenga una copia de la billetera puede leer las claves. Esto significa que la actualización sólo debe realizarse una vez. Para mejorar la eficiencia, la billetera Keystore requiere que L2 tenga una forma estandarizada de leer información en L1 sin costo. Hay dos propuestas para esto, a saber, L1S LOAD y REMOTESTATICCALL;

Cómo funciona la billetera Keystore

2. Un concepto más radical de "puente de token compartido": imagine un mundo donde todo L2 es un paquete acumulativo de prueba de validez y cada ranura se envía a Ethereum. Incluso en un mundo así, transferir activos de una L2 a otra L2 en su estado natal todavía requiere retiros y depósitos, lo que requiere el pago de importantes tarifas de gas L1. Una forma de resolver este problema es crear un paquete acumulativo minimalista compartido cuya única función sea mantener qué L2 posee cada tipo de token y cuánto saldo tiene cada uno, y permitir que estos saldos pasen a través de una serie de transacciones iniciadas por cualquier operación de envío de L2. en L2 para actualizaciones por lotes. Esto permitirá realizar transferencias entre L2 sin tener que pagar tarifas de gas L1 por cada transferencia y sin utilizar tecnologías basadas en proveedores de liquidez como ERC-7683.

3. Composicionalidad síncrona: permite que se produzcan llamadas síncronas entre una L2 y una L1 específicas o entre varias L2. Esto ayuda a mejorar la eficiencia financiera de los protocolos DeFi. El primero se puede implementar sin ninguna coordinación entre L2; el segundo requiere un orden compartido. Las técnicas basadas en rollups funcionan automáticamente con todos ellos.

¿Cuáles son los vínculos con la investigación existente?

Dirección específica de la cadena:

ERC-3770 ：https://eips.ethereum.org/EIPS/eip-3770

ERC-7683: https://eips.ethereum.org/EIPS/eip-7683

RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md

Diseño de billetera de almacén de claves de desplazamiento: https://hackmd.io/@haichen/keystore

Helios: https://github.com/a16z/helios

ERC-3668 (a veces llamado lectura CCIP): https://eips.ethereum.org/EIPS/eip-3668

Propuesta de "preconfirmaciones basadas (compartidas)" propuesta por Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353

CARGA L1S (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1s load-precompile/20388

Llamada remota a Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76

AggLayer, que incluye la idea de un puente de token compartido: https://github.com/AggLayer

¿Qué más hay que hacer? ¿Cuáles son las compensaciones?

Muchos de los ejemplos anteriores enfrentan el dilema de los estándares: cuándo estandarizar y qué capas estandarizar. Si estandariza demasiado pronto, corre el riesgo de afianzar una solución deficiente. Si estandariza demasiado tarde, puede crear una fragmentación innecesaria. En algunos casos, hay una solución a corto plazo que tiene propiedades más débiles pero es más fácil de implementar, y una solución a largo plazo que es "eventualmente correcta" pero lleva años implementar.

Estas tareas no son sólo problemas técnicos, también son (quizás incluso principalmente) problemas sociales que requieren la cooperación entre la L2 y la billetera, así como la L1.

¿Cómo interactúo con otras partes de la hoja de ruta?

La mayoría de estas propuestas son estructuras de "nivel superior" y, por lo tanto, tienen poco impacto en las consideraciones de nivel L1. Una excepción son los pedidos compartidos, que tienen un impacto significativo en el valor máximo extraíble (MEV).

Extender la ejecución en L1

¿Qué problema estamos resolviendo?

Si L2 se vuelve muy escalable y exitoso, pero L1 todavía solo es capaz de manejar volúmenes de transacciones muy pequeños, podrían surgir una serie de riesgos para Ethereum:

1. El estado económico de los activos de ETH se volverá más inestable, lo que a su vez afectará la seguridad a largo plazo de la red.

2. Muchas L2 se benefician de fuertes vínculos con el ecosistema financiero altamente desarrollado de la L1, y si este ecosistema se debilita significativamente, los incentivos para convertirse en una L2 (en lugar de convertirse en una L1 independiente) se debilitarán.

3. L2 tardará mucho tiempo en lograr la misma garantía de seguridad que L1.

4. Si L2 falla (por ejemplo, debido a un comportamiento malicioso por parte del operador o desaparece), los usuarios aún necesitan recuperar sus activos a través de L1. Por lo tanto, el L1 debe ser lo suficientemente potente como para, al menos ocasionalmente, manejar los toques finales altamente complejos y desordenados del L2.

Por estas razones, es extremadamente valioso continuar expandiendo la propia L1 y garantizar que pueda seguir acomodando un número cada vez mayor de casos de uso.

¿qué es? ¿Cómo funciona?

La forma más sencilla de escalar es aumentar directamente el límite de gas. Sin embargo, esto podría centralizar L1, socavando así otra característica importante que hace que Ethereum L1 sea tan poderoso: su credibilidad como una capa base sólida. Todavía existe un debate sobre hasta qué punto es sostenible simplemente aumentar el límite de gas, y esto también dependerá de qué otras técnicas se implementen para facilitar la verificación de bloques más grandes (por ejemplo, vencimiento del historial, sin estado, prueba de validez de EVM L1). Otra cosa importante que debe seguir mejorando es la eficiencia del software cliente de Ethereum, que es mucho más eficiente hoy que hace cinco años. Una estrategia eficaz de limitación del gas L1 implicará acelerar el desarrollo de estas tecnologías de verificación.

• EOF: un nuevo formato de código de bytes EVM que es más amigable para el análisis estático y permite implementaciones más rápidas. Dadas estas ganancias de eficiencia, el código de bytes EOF puede lograr menores costos de gas.

• Precios multidimensionales del gas: establecer diferentes tarifas base y límites para la computación, los datos y el almacenamiento puede aumentar la capacidad promedio de Ethereum L1 sin aumentar la capacidad máxima (evitando así la creación de nuevos riesgos de seguridad).

• Reducir los costos de gas para precompilaciones y códigos de operación específicos: históricamente, hemos aumentado el costo del gas de ciertas operaciones con precios bajos en varias ocasiones para evitar ataques de denegación de servicio. Una cosa que se podría hacer más es reducir los costos de gas para códigos de operación demasiado caros. 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. Podemos hacer que ADD sea más barato e incluso códigos de operación más simples como PUSH. En general, EOF está más optimizado a este respecto.

• EVM-MAX y SIMD: EVM-MAX es una propuesta para permitir matemáticas analógicas nativas de números grandes más eficientes como un módulo separado de EVM. A menos que se exporten intencionalmente, solo se puede acceder a los valores calculados mediante cálculos EVM-MAX mediante otros códigos de operación EVM-MAX. Esto permite más espacio para almacenar estos valores en un formato optimizado. SIMD (instrucción única de datos múltiples) es una propuesta que permite la ejecución eficiente de una misma instrucción sobre un conjunto de valores. Juntos, los dos crean un potente coprocesador junto con el EVM que se puede utilizar para implementar operaciones criptográficas de manera más eficiente. Esto es particularmente útil para protocolos de privacidad y sistemas de protección L2, por lo que ayudará con el escalamiento L1 y L2.

Estas mejoras se analizarán con más detalle en futuros artículos de Splurge.

Finalmente, la tercera estrategia son los paquetes acumulativos nativos (o paquetes acumulativos consagrados): esencialmente, crear muchas copias del EVM que se ejecutan en paralelo, lo que da como resultado un modelo equivalente a lo que Rollup puede proporcionar, pero más integrado de forma nativa en el protocolo.

¿Cuáles son los vínculos con la investigación existente?

• Hoja de ruta de escalado Ethereum L1 de Polynya: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ

• Precio multidimensional del gas: https://vitalik.eth.limo/general/2024/05/09/multidim.html

• EIP-7706: https://eips.ethereum.org/EIPS/eip-7706

• Fin del proyecto: https://evmobjectformat.org/

• EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

• SIMD: https://eips.ethereum.org/EIPS/eip-616

• Paquetes de rollups nativos: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE

• Entrevista a Max Resnick sobre el valor de escalar L1: https://x.com/BanklessHQ/status/1831319419739361321

• Justin Drake habla sobre escalar con SNARK y Rollups nativos: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

¿Qué más hay que hacer y cuáles son las compensaciones?

Existen tres estrategias para la expansión de la L1, que se pueden realizar de forma individual o en paralelo:

• Mejorar las técnicas (por ejemplo, código de cliente, clientes sin estado, vencimiento del historial) para que L1 sea más fácil de verificar y luego aumentar los límites de gas.

• Reducir los costos de operaciones específicas y aumentar la capacidad promedio sin aumentar el riesgo del peor de los casos;

• Rollups nativos (es decir, crear N copias paralelas del EVM).

Al comprender estas diferentes tecnologías, encontraremos que existen diferentes compensaciones. Por ejemplo, los Rollups nativos sufren de muchas de las mismas debilidades en la capacidad de composición que los Rollups simples: no se puede enviar una única transacción para realizar operaciones sincrónicamente en varios Rollups, como se puede hacer dentro de un contrato en la misma L1 (o L2). forma. Aumentar el límite de gasolina socavaría otros beneficios que se pueden lograr al simplificar la verificación L1, como aumentar la proporción de usuarios que ejecutan nodos de validación y aumentar el número de participantes individuales. Dependiendo de la implementación, abaratar operaciones específicas en la EVM (Máquina Virtual Ethereum) puede aumentar la complejidad general de la EVM.

Una gran pregunta que cualquier hoja de ruta de escalamiento de L1 debe responder es: ¿Cuál es la visión definitiva para L1 y L2? Obviamente, poner todo en L1 es ridículo: los casos de uso potenciales podrían involucrar cientos de miles de transacciones por segundo, lo que haría que L1 no sea completamente verificable (a menos que sigamos la ruta Rollup nativa). Pero necesitamos algunas pautas para asegurarnos de no entrar en una situación en la que un aumento de 10 veces en el límite de la gasolina dañe gravemente la descentralización de Ethereum L1.

Una visión de la división del trabajo entre L1 y L2

¿Cómo interactúo con otras partes de la hoja de ruta?

Traer más usuarios a la L1 significa no sólo mejorar la escala, sino también mejorar otros aspectos de la L1. Esto significa que quedará más MEV en L1 (en lugar de ser simplemente un problema de L2), por lo que la necesidad de manejar MEV explícitamente será más urgente. Esto aumentará en gran medida el valor de los tiempos de ranura rápidos en L1. Al mismo tiempo, esto también depende en gran medida del buen progreso de la verificación L1 (The Verge).