Learn
Posibles futuros de Ethereum, Parte 2: La Oleada

Posibles futuros de Ethereum, Parte 2: La Oleada

Avanzado
Ethereum
10/22/2024, 4:38:46 AM
La estrategia de escalado de Ethereum ha evolucionado desde el shardin y los protocolos de capa 2 hacia un enfoque centrado en rollups. El roadmap actual propone una división de tareas entre L1 y L2: L1 sirve como una capa base robusta, mientras que L2 es responsable de la expansión del ecosistema. Los logros recientes incluyen los blobs de EIP-4844 que aumentan el ancho de banda de datos de L1 y varios rollups de EVM alcanzando la etapa 1. Los objetivos futuros incluyen lograr 100,000+ TPS, mantener la descentralización de L1, garantizar que algunos L2 hereden las propiedades fundamentales de Ethereum y maximizar la interoperabilidad entre L2. Las áreas clave de investigación incluyen muestreo de disponibilidad de datos, compresión de datos e interoperabilidad entre L2.

Al principio, Ethereum tenía dos estrategias de escalado en su hoja de ruta. Uno (por ejemplo, ver este primer documentodesde 2015) fue “fragmentación”: en lugar de verificar y almacenar todas las transacciones en la cadena, cada nodo solo necesitaría verificar y almacenar una pequeña fracción de las transacciones. Así es como funciona cualquier otra red peer-to-peer (por ejemplo, BitTorrent), por lo que seguramente podríamos hacer que las blockchains funcionen de la misma manera. Otro fue los protocolos de capa 2: redes que se ubicarían encima de Ethereum de una manera que les permita beneficiarse plenamente de su seguridad, al tiempo que mantienen la mayor parte de los datos y cálculos fuera de la cadena principal. Los “protocolos de capa 2” significaban canales de estadoen 2015, Plasmaen 2017, y luegorollupsen 2019. Rollups son más poderosos que los canales de estado o Plasma, pero requieren una gran cantidad de ancho de banda de datos en cadena. Afortunadamente, para 2019 la investigación de shardings había resuelto el problema de verificar la "disponibilidad de datos" a escala. Como resultado, los dos caminos convergieron, y obtuvimos el hoja de ruta centrada en rollupque sigue siendo la estrategia de escalado de Ethereum hoy.

La oleada, edición de la hoja de ruta de 2023.

La hoja de ruta centrada en rollups propone una simple división del trabajo: Ethereum L1 se enfoca en ser una capa base sólida y descentralizada, mientras que L2 se encarga de ayudar a escalar el ecosistema. Este es un patrón que se repite en todas partes en la sociedad: el sistema judicial (L1) no está ahí para ser ultra rápido y eficiente, está ahí para proteger contratos y derechos de propiedad, y corresponde a los emprendedores (L2) construir sobre esosólido base capay llevar a la humanidad a Marte (metafórica y literalmente).

Este año, la hoja de ruta centrada en rollup ha tenido importantes éxitos: el ancho de banda de datos de Ethereum L1 ha aumentado considerablemente con blobs EIP-4844, y ahora hay múltiples rollups de EVM en la etapa 1. Un muy implementación heterogénea y pluralista de sharding, donde cada L2 actúa como un “fragmento” con sus propias reglas y lógica interna, es ahora una realidad. Pero como hemos visto, tomar este camino tiene sus propios desafíos únicos. Y así que ahora nuestra tarea es llevar el mapa de ruta centrado en rollup a su finalización, y resolver estos problemas, mientras se preserva la solidez y descentralización que hacen especial a Ethereum L1.

La oleada: objetivos clave

  • 100,000+ TPS en L1+L2
  • Preservar la descentralización y la robustez de L1
  • Al menos algunos L2 heredan completamente las propiedades fundamentales de Ethereum (sin confianza, abierto, resistente a la censura)
  • Máxima interoperabilidad entre L2s. Ethereum debería sentirse como un ecosistema único, no como 34 blockchains diferentes.

En este capítulo

Aparte: el trilema de la escalabilidad

El trilema de escalabilidad era una idea introducido en 2017, que argumentó que hay una tensión entre tres propiedades de una cadena de bloques: descentralización (más específicamente: bajo costo para ejecutar un nodo), escalabilidad (más específicamente: alto número de transacciones procesadas) y seguridad (más específicamente: un atacante necesitando corromper una gran parte de los nodos en toda la red para hacer que falle incluso una sola transacción).

Es importante destacar que el trilema no es un teorema, y la publicación que introduce el trilema no venía acompañada de una prueba matemática. Sin embargo, sí proporcionó un argumento matemático heurístico: si un nodo amigable con la descentralización (por ejemplo, una computadora portátil de consumidor) puede verificar N transacciones por segundo, y tienes una cadena que procesa k*N transacciones por segundo, entonces o bien (i) cada transacción solo es vista por 1/k de los nodos, lo que implica que un atacante solo necesita corromper unos pocos nodos para hacer pasar una transacción incorrecta, o (ii) tus nodos van a ser potentes y tu cadena no será descentralizada. El propósito de la publicación nunca fue demostrar que romper el trilema es imposible; más bien, fue mostrar que romper el trilema es difícil, requiere de alguna manera pensar fuera de la caja que el argumento implica.

Durante muchos años, ha sido común que algunas cadenas de alto rendimiento afirmen que resuelven el trilema sin hacer nada inteligente a nivel de arquitectura fundamental, típicamente utilizando trucos de ingeniería de software para optimizar el nodo. Esto siempre es engañoso, y ejecutar un nodo en dichas cadenas siempre termina siendo mucho más difícil que en Ethereum.Esta publicaciónentra en algunas de las muchas sutilezas de por qué esto es así (y, por lo tanto, por qué la ingeniería de software del cliente L1 por sí sola no puede escalar Ethereum en sí mismo).

Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs resuelve el trilema: permite a un cliente verificar que cierta cantidad de datos está disponible y que se llevaron a cabo correctamente cierta cantidad de pasos de cálculo, mientras descarga solo una pequeña porción de esos datos y ejecuta una cantidad mucho menor de cálculos. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un enfoque sutil modelo de confianza few-of-N, pero conserva la propiedad fundamental que tienen las cadenas no escalables, que es que ni siquiera un ataque del 51% puede obligar a que los bloques malos sean aceptados por la red.

Otra forma de resolver el trilema es a través de arquitecturas de Plasma, que utilizan técnicas ingeniosas para trasladar la responsabilidad de vigilar la disponibilidad de datos al usuario de manera compatible con los incentivos. En 2017-2019, cuando todo lo que teníamos para escalar la computación eran pruebas de fraude, Plasma estaba muy limitado en lo que podía hacer de forma segura, pero la incorporación de SNARKs hace que las arquitecturas de Plasma mucho más viablepara una gama más amplia de casos de uso que antes.

Más avances en muestreo de disponibilidad de datos

¿Qué problema estamos resolviendo?

A partir del 13 de marzo de 2024, cuando el Actualización de DencunCuando se puso en marcha, la cadena de bloques de Ethereum tiene tres "blobs" de ~125 kB por ranura de 12 segundos, o ~375 kB por ranura de ancho de banda de disponibilidad de datos. Suponiendo que los datos de transacción se publican en la cadena directamente, una transferencia ERC20 es de ~180 bytes, por lo que el TPS máximo de rollups en Ethereum es:

375000 / 12 / 180 = 173.6 TPS

Si agregamos los calldatas 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, el plan es aumentar el objetivo de recuento de blobs a 8-16, lo que nos daría 463-926 TPS en calldata.

Este es un gran aumento sobre el Ethereum L1, pero no es suficiente. Queremos mucha más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por ranura, lo que, combinado con mejoras en la compresión de datos de rollup, nos daría ~58,000 TPS.

¿Qué es esto y cómo funciona?

PeerDAS es una implementación relativamente simple de "muestreo 1D". Cada blob en Ethereum es un polinomio de grado 4096 sobre un campo primo de 253 bits. Transmitimos "partes" del polinomio, donde cada parte consta de 16 evaluaciones en 16 coordenadas adyacentes tomadas de un conjunto total de 8192 coordenadas. Cualquier conjunto de 4096 de las 8192 evaluaciones (con los parámetros propuestos actuales: cualquier conjunto de 64 de las 128 muestras posibles) puede recuperar el blob.

PeerDAS funciona haciendo que cada cliente escuche en un pequeño número de subredes, donde la subred i-ésima transmite la i-ésima muestra de cualquier blob, y además solicita blobs en otras subredes que necesite preguntando a sus pares en la red p2p global (que estarían escuchando diferentes subredes). Una versión más conservadora, SubnetDAS, utiliza solo el mecanismo de subred, sin la capa adicional de preguntar a los pares. Una propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, y que otros nodos (es decir, "clientes") utilicen PeerDAS.

Teóricamente, podemos escalar el muestreo 1D bastante lejos: si aumentamos el recuento máximo de blobs a 256 (por lo tanto, el objetivo a 128), entonces llegaríamos a nuestro objetivo de 16 MB mientras que el muestreo de disponibilidad de datos solo costaría a cada nodo 16 muestras128 blobs512 bytes por muestra por fragmento = 1 MB de ancho de banda de datos por ranura. Esto está justo dentro de nuestro alcance de tolerancia: es factible, pero significaría que los clientes con restricciones de ancho de banda no podrían muestrear. Podríamos optimizar esto en cierta medida disminuyendo el recuento de fragmentos y aumentando el tamaño de los fragmentos, pero esto haría que la reconstrucción fuera más costosa.

Y así, en última instancia, queremos ir más allá y hacerMuestreo 2D, que funciona mediante muestreo aleatorio no solo dentro de los bloques, sino también entre los bloques. Las propiedades lineales de las confirmaciones KZG se utilizan para “extender” el conjunto de bloques en un bloque con una lista de nuevos “bloques virtuales” que codifican redundante la misma información.

Muestreo 2D. Fuente: a16z crypto

Es crucial destacar que calcular la extensión de los compromisos no requiere tener los bloques, por lo que el esquema es fundamentalmente amigable para la construcción de bloques distribuidos. El nodo que realmente construye el bloque solo necesitaría tener los compromisos de bloques KZG y puede confiar en DAS para verificar la disponibilidad de los bloques. 1D DAS también es inherentemente amigable para la construcción de bloques distribuidos.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

El siguiente paso inmediato es terminar la implementación y el despliegue de PeerDAS. A partir de ahí, es una tarea progresiva seguir aumentando el recuento de blobs en PeerDAS mientras se vigila cuidadosamente la red y se mejora el software para garantizar la seguridad. Al mismo tiempo, queremos más trabajos académicos para formalizar PeerDAS y otras versiones de DAS y sus interacciones con problemas como la seguridad de la regla de elección de bifurcación.

Más adelante en el futuro, necesitamos mucho más trabajo para descubrir la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También queremos eventualmente migrar lejos de KZG a una alternativa resistente a la computación cuántica y libre de configuración confiable. Actualmente, no conocemos candidatos que sean amigables para la construcción de bloques distribuidos. Incluso la costosa técnica de "fuerza bruta" de usar STARKs recursivos para generar pruebas de validez para la reconstrucción de filas y columnas no es suficiente, porque técnicamente un STARK tiene un tamaño de O(log(n) * log(log(n)) hashes.STIR) en la práctica, un STARK es casi tan grande como un blob completo.

Los caminos realistas que veo a largo plazo son:

  • Implementar ideal 2D DAS
  • Mantente con 1D DAS, sacrificando eficiencia de ancho de banda de muestreo y aceptando un límite de datos más bajo en aras de la simplicidad y la robustez
  • (Pivote radical) abandonar DA y abrazar por completo Plasma como una arquitectura de capa 2 primaria en la que nos estamos centrando

Podemos ver esto a lo largo de un espectro de compensación:

Tenga en cuenta que esta opción existe incluso si decidimos escalar la ejecución en L1 directamente. Esto se debe a que si L1 va a procesar muchas TPS, los bloques de L1 serán muy grandes y los clientes querrán una forma eficiente de verificar que son correctos, por lo que tendríamos que utilizar la misma tecnología que impulsa los rollups (ZK-EVM y DAS) en L1.

¿Cómo interactúa con otras partes del mapa de ruta?

La necesidad de 2D DAS se reduce en cierta medida, o al menos se retrasa, si se implementa la compresión de datos (ver abajo), y se reduce aún más si Plasma se usa ampliamente. DAS también plantea un desafío a los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable para la reconstrucción distribuida, esto necesita combinarse en la práctica conlista de inclusiónpropuestas y su mecánica de selección de bifurcación circundante.

Compresión de datos

¿Qué problema estamos resolviendo?

Cada transacción en un rollup ocupa una cantidad significativa de espacio de datos en la cadena: una transferencia ERC20 ocupa alrededor de 180 bytes. Incluso con un muestreo ideal de disponibilidad de datos, esto pone un límite a la escalabilidad de los protocolos de capa 2. Con 16 MB por ranura, obtenemos:

16000000 / 12 / 180 = 7407 TPS

¿Y si además de abordar el numerador, también podemos abordar el denominador y hacer que cada transacción en un rollup ocupe menos bytes en la cadena?

¿Qué es y cómo funciona?

La mejor explicación en mi opinión es este diagramahace dos años:

Las ganancias más simples son simplemente compresión de bytes cero: reemplazando cada secuencia larga de bytes cero con dos bytes que representan cuántos bytes cero hay. Para ir más allá, aprovechamos las propiedades específicas de las transacciones:

  • La agregación de firmas: cambiamos de firmas ECDSA a firmas BLS, que tienen la propiedad de que muchas firmas pueden combinarse en una sola firma que certifica la validez de todas las firmas originales. Esto no se considera para L1 porque los costos computacionales de verificación, incluso con agregación, son más altos, pero en un entorno escaso en datos como L2s, sin duda tiene sentido. La función de agregación de ERC-4337presenta una forma de implementar esto.
  • Reemplazar direcciones con punteros: si una dirección fue utilizada anteriormente, podemos reemplazar la dirección de 20 bytes con un puntero de 4 bytes a una ubicación en la historia. Esto es necesario para lograr las mayores ganancias, aunque requiere esfuerzo para implementarse, ya que se necesita que (al menos una parte de) la historia de la cadena de bloques se convierta efectivamente en parte del estado.
  • Serialización personalizada para 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. Las tarifas máximas de gas base y las tarifas prioritarias funcionan de manera similar. Por lo tanto, podemos representar la mayoría de los valores de moneda de manera muy compacta con un formato decimal de punto flotante personalizado, o incluso con un diccionario de valores especialmente comunes.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son las compensaciones?

Lo principal que queda por hacer es implementar realmente los esquemas anteriores. Los principales compromisos son:

  • Cambiar a firmas BLS requiere un esfuerzo significativo y reduce la compatibilidad con chips de hardware de confianza que pueden aumentar la seguridad. Un envoltorio ZK-SNARK alrededor de otros esquemas de firma podría usarse para reemplazar esto.
  • La compresión dinámica (por ejemplo, reemplazar direcciones con punteros) complica el código del cliente.
  • Publicar diferencias de estado en la cadena en lugar de transacciones reduce la auditabilidad y hace que mucho software (por ejemplo, exploradores de bloques) no funcione.

¿Cómo interactúa con otras partes del plan de trabajo?

La adopción de ERC-4337, y eventualmente la consagración de partes de ella en L2 EVMs, puede acelerar en gran medida la implementación de técnicas de agregación. La consagración de partes de ERC-4337 en L1 puede acelerar su implementación en L2s.

Plasma generalizado

¿Qué problema estamos resolviendo?

Incluso con blobs de 16 MB y compresión de datos, 58.000 TPS no son necesariamente suficientes para hacerse cargo por completo de los pagos de los consumidores, las redes sociales descentralizadas u otros sectores de gran ancho de banda, y esto se vuelve especialmente cierto si comenzamos a tener en cuenta la privacidad, que podría reducir la escalabilidad entre 3 y 8 veces. Para aplicaciones de alto volumen y bajo valor, una opción hoy en día es un validium, que mantiene los datos fuera de la cadena y tiene un interesante modelo de seguridad donde el operador no puede robar los fondos de los usuarios, pero pueden desaparecer y 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 de escalado que implica que un operador publique bloques fuera de la cadena, y coloque las raíces de Merkle de esos bloques en la cadena (a diferencia de los rollups, donde el bloque completo se coloca en la cadena). Para cada bloque, el operador envía a cada usuario una rama de Merkle que prueba lo que sucedió, o no sucedió, con los activos de ese usuario. Los usuarios pueden retirar sus activos proporcionando una rama de Merkle. Es importante destacar que esta rama no tiene que estar enraizada en el estado más reciente, por esta razón, incluso si la disponibilidad de datos falla, el usuario aún puede recuperar sus activos retirando el estado más reciente que tienen disponible. Si un usuario envía una rama inválida (por ejemplo, sale de un activo que ya envió a otra persona, o el mismo operador crea un activo de la nada), un mecanismo de desafío en cadena puede decidir a quién pertenece legítimamente el activo.

Un diagrama de una cadena de Plasma Cash. Las transacciones que gastan la moneda i se colocan en la posición i-ésima en el árbol. En este ejemplo, asumiendo que todos los árboles anteriores son válidos, sabemos que Eve actualmente posee la moneda 1, David posee la moneda 4 y George posee la moneda 6.

Las primeras versiones de Plasma solo podían manejar el caso de uso de pagos y no podían generalizarse de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con un SNARK, Plasma se vuelve mucho más poderoso. Cada juego de desafío puede simplificarse significativamente, porque eliminamos la mayoría de los posibles caminos para que el operador haga trampa. También se abren nuevos caminos para permitir que las técnicas de Plasma se extiendan a una clase mucho más general de activos. Finalmente, en el caso de que el operador no haga trampa, los usuarios pueden retirar sus fondos al instante, sin necesidad de esperar un período de desafío de una semana.

Una forma (no la única forma) de crear una cadena de plasma de EVM: utilizar un ZK-SNARK para construir un árbol UTXO paralelo que refleje los cambios de saldo realizados por el EVM, y defina un mapeo único de lo que es “la misma moneda” en diferentes momentos de la historia. Una construcción de Plasma puede entonces construirse sobre eso.

Una idea clave es que el sistema Plasma no necesita ser perfecto. Incluso si solo puedes proteger un subconjunto de activos (por ejemplo, incluso solo monedas que no se han movido en la última semana), ya has mejorado en gran medida el estado actual del EVM ultramoderno, que es un validium válido.

Otra clase de construcciones son los plasmas híbridos/rollups, como Intmax. Estas construcciones colocan una cantidad muy pequeña de datos por usuario en la cadena (por ejemplo, 5 bytes), y al hacerlo, obtienen propiedades que se encuentran en algún punto intermedio entre plasma y rollups: en el caso de Intmax, se obtiene un nivel muy alto de escalabilidad y privacidad, aunque incluso en el mundo de 16 MB, la capacidad está teóricamente limitada a aproximadamente 16,000,000 / 12 / 5 = 266,667 TPS.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

La principal tarea pendiente es llevar los sistemas de plasma a la producción. Como se mencionó anteriormente, "plasma vs validium" no es binario: cualquier validium puede mejorar sus propiedades de seguridad al menos un poco al agregar características de plasma en el mecanismo de salida. La parte de investigación consiste en obtener las propiedades óptimas (en términos de requisitos de confianza, el costo del gas L1 en el peor de los casos y la vulnerabilidad a DoS) para una EVM, así como construcciones alternativas específicas de la aplicación. Además, la mayor complejidad conceptual de Plasma en relación con los rollups debe abordarse directamente, tanto a través de la investigación como a través de la construcción de mejores marcos generalizados.

El principal compromiso en el uso de los diseños de Plasma es que dependen más de los operadores y son más difíciles de hacer “basadoAunque los diseños híbridos de plasma/rollup a menudo pueden evitar esta debilidad.

¿Cómo interactúa con otras partes del plan de trabajo?

Cuanto más efectivas sean las soluciones de Plasma, menos presión habrá para que el L1 tenga una funcionalidad de disponibilidad de datos de alto rendimiento. Mover la actividad al L2 también reduce la presión de MEV en el L1.

Maduración de los sistemas a prueba de L2

¿Qué problema estamos resolviendo?

Hoy en día, la mayoría de los rollups aún no son realmente descentralizados; hay un consejo de seguridad que tiene la capacidad de anular el comportamiento del (optimista o de validez)sistema de pruebaEn algunos casos, el sistema de prueba ni siquiera está en funcionamiento, o si lo está, solo tiene una funcionalidad "asesora". Los más avanzados son (i) algunos rollups específicos de aplicaciones, como Fuel, que son sin confianza, y (ii) en el momento de esta escritura, Optimism y Arbitrum, dos rollups completos de EVM que han logrado un hito de "parcial sin confianza" conocido como "etapa 1". La razón por la que los rollups no han avanzado más es la preocupación por los errores en el código. Necesitamos rollups sin confianza, y por lo tanto, debemos abordar este problema de frente.

¿Qué es y cómo funciona?

Primero, vamos a repasar el sistema de 'etapas', originalmente introducido en esta publicación. Hay más requisitos detallados, pero el resumen es:

  • Etapa 0: debe ser posible para un usuario ejecutar un nodo y sincronizar la cadena. Está bien si la validación es totalmente confiable / centralizada.
  • Etapa 1: debe existir un sistema de prueba (sin confianza) que garantice que solo se acepten transacciones válidas. Se permite que haya un consejo de seguridad que pueda anular el sistema de prueba, pero solo con un voto de umbral del 75%. Además, una parte del consejo que bloquee el quórum (por ejemplo, 26% o más) debe estar fuera del edificio principal de la empresa que construye el rollup. Se permite un mecanismo de actualización con características más débiles (por ejemplo, un DAO), pero debe tener un retraso lo suficientemente largo para que, si aprueba una actualización maliciosa, los usuarios puedan retirar sus fondos antes de que entre en funcionamiento.
  • Etapa 2: debe haber un sistema de prueba (sin confianza) que garantice que solo se acepten transacciones válidas. Los consejos de seguridad solo pueden intervenir en caso de errores demostrables en el código, por ejemplo. si dos sistemas de prueba redundantes no están de acuerdo 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, por ejemplo, una semana). Se permite un mecanismo de actualización, pero debe tener un retraso muy largo.

El objetivo es llegar a la Etapa 2. El principal desafío para llegar a la etapa 2 es obtener suficiente confianza en que el sistema de prueba es realmente lo suficientemente confiable. Hay dos formas principales de hacer esto:

  • Verificación formal: podemos utilizar técnicas matemáticas y computacionales modernas para demostrar que un sistema de prueba (optimista o de validez) solo acepta bloques que cumplan con la especificación de EVM. Estas técnicas han existido durante décadas, pero avances recientes como Lean 4los han hecho mucho más prácticos, y los avances en la demostración asistida por IA podrían potencialmente acelerar esta tendencia aún más.
  • Multi-verificadores: crear múltiples sistemas de prueba y colocar fondos en una multisig de 2-de-3 (o más) entre esos sistemas de prueba y un consejo de seguridad (y/o otro dispositivo con suposiciones de confianza, por ejemplo, TEEs). Si los sistemas de prueba están de acuerdo, el consejo de seguridad no tiene poder; si no están de acuerdo, el consejo de seguridad solo puede elegir entre uno de ellos, no puede imponer unilateralmente su propia respuesta.

Diagrama estilizado de un multi-demostrador, combinando un sistema de prueba optimista, un sistema de prueba de validez y un consejo de seguridad.

¿Cuáles son algunos de los vínculos con las investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

Para la verificación formal, mucho. Necesitamos crear una versión formalmente verificada de un probador de SNARK completo de un EVM. Este es un proyecto increíblemente complejo, aunque es uno que Ya hemos empezado. Hay un truco que simplifica significativamente la tarea: podemos hacer un probador SNARK verificado formalmente de una VM mínima, por ejemplo. RISC-VoCairo, y luego escribir una implementación del EVM en esa VM minimalista (y demostrar formalmente su equivalencia con alguna otra especificación del EVM).

Para los multi-provers, quedan dos piezas principales restantes. Primero, necesitamos tener suficiente confianza en al menos dos sistemas de prueba diferentes, ambos que son razonablemente seguros individualmente y que si fallan, fallarían por razones diferentes e no relacionadas (y por lo tanto no fallarían al mismo tiempo). Segundo, necesitamos obtener un nivel muy alto de seguridad en la lógica subyacente que fusiona los sistemas de prueba. Esta es una pieza de código mucho más pequeña. Hay formas de hacerla extremadamente pequeña: simplemente almacenar fondos en un Contrato seguro de firma múltiplecuyos firmantes son contratos que representan sistemas de prueba individuales, pero esto tiene el inconveniente de altos costos de gas en la cadena. Será necesario encontrar un equilibrio entre eficiencia y seguridad.

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

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

Mejoras de interoperabilidad entre L2 cruzados

¿Qué problema estamos resolviendo?

Uno de los principales desafíos con el ecosistema L2 hoy en día es que es difícil para los usuarios navegar. Además, las formas más fáciles de hacerlo a menudo reintroducen suposiciones de confianza: puentes centralizados, clientes de RPC, y así sucesivamente. Si tomamos en serio la idea de que los L2 son parte de Ethereum, necesitamos hacer que el uso del ecosistema L2 se sienta como usar un ecosistema unificado de Ethereum.

Un ejemplo de una experiencia de usuario entre capas (L2) patológicamente mala (e incluso peligrosa: personalmente perdí $100 debido a un error en la selección de cadena aquí) - aunque esto no es culpa de Polymarket, la interoperabilidad entre capas L2 debería ser responsabilidad de las carteras y la comunidad de estándares de Ethereum (ERC). En un ecosistema Ethereum bien funcionando, enviar monedas de L1 a L2, o de una L2 a otra, debería sentirse igual que enviar monedas dentro de la misma L1.

¿Qué es y cómo funciona?

Hay muchas categorías de mejoras de interoperabilidad cruzada de L2. En general, la forma de idearlas es darse cuenta de que en teoría, un Ethereum centrado en rollups es lo mismo que el particionamiento de ejecución L1, y luego preguntar dónde la actual Ethereum L2-verse se queda corta de ese ideal en la práctica. Aquí hay algunos:

  • Direcciones específicas de la cadena: la cadena (L1, Optimism, Arbitrum...) debe formar parte de la dirección. Una vez que esto se implementa, los flujos de envío entre L2 se pueden implementar simplemente colocando la dirección en el campo "enviar", momento en el que la billetera puede averiguar cómo realizar el envío (incluido el uso de protocolos de puente) en segundo plano.
  • Solicitudes de pago específicas de la cadena: debe ser fácil y estandarizado hacer un mensaje del tipo "envíame X tokens de tipo Y en la cadena Z". Esto tiene dos casos de uso principales: (i) pagos, ya sean de persona a persona o de persona a comerciante, y (ii) dapps que solicitan fondos, por ejemplo. el ejemplo anterior de Polymarket.
  • Intercambios entre cadenas y pago de gas: debería existir un protocolo abierto estandarizado para expresar operaciones entre cadenas como “Estoy enviando 1 ETH en Optimism a quien me envíe 0.9999 ETH en Arbitrum”, y “Estoy enviando 0.0001 ETH en Optimism a quien incluya esta transacción en Arbitrum”.ERC-7683es un intento del primero, y RIP-7755es un intento en este último, aunque ambos también son más generales que solo estos casos de uso específicos.
  • Clientes ligeros: los usuarios deberían poder verificar realmente las cadenas con las que interactúan, y no simplemente confiar en los proveedores de RPC. A16z crypto’sHeliosesto lo hace para Ethereum en sí, pero necesitamos extender esta falta de confianza a L2s.ERC-3668 (CCIP-read)es una estrategia para hacer esto.

Cómo un cliente ligero puede actualizar su vista de la cadena de encabezado de Ethereum. Una vez que tenga la cadena de encabezados, puede usar pruebas de Merkle para validar cualquier objeto de estado. Y una vez que tenga los objetos de estado L1 correctos, puede usar pruebas de Merkle (y posiblemente firmas, si desea verificar preconfirmaciones) para validar cualquier objeto de estado en L2. Helios ya hace lo primero. Extenderlo al último es un desafío de estandarización.

  • Monederos de keystore: hoy en día, si quieres actualizar las claves que controlan tu monedero de contrato inteligente, debes hacerlo en todas las N cadenas en las que ese monedero existe. Los monederos de keystore son una técnica que permite que las claves existan en un solo lugar (ya sea en L1, o más tarde potencialmente en un L2), y luego se lean desde cualquier L2 que tenga una copia del monedero. Esto significa que las actualizaciones solo necesitan hacerse una vez. Para ser eficientes, los monederos de keystore requieren que los L2 tengan una forma estandarizada de leer de forma gratuita desde L1; dos propuestas para esto son L1SLOAD y REMOTESTATICCALL.

Un diagrama estilizado de cómo funcionan las billeteras de almacén de claves.

  • Más ideas radicales de "puente de token compartido": imagina un mundo donde todos los L2 son rollups de prueba de validez, que se comprometen con Ethereum en cada ranura. Incluso en este mundo, mover activos de un L2 a otro L2 "nativamente" requeriría retirar y depositar, lo que requiere pagar una cantidad sustancial de gas L1. Una forma de resolver esto es crear un rollup mínimo compartido, cuya única función sería mantener los saldos de cuántos tokens de qué tipo son propiedad de qué L2, y permitir que esos saldos se actualicen en masa mediante una serie de operaciones de envío entre L2 iniciadas por cualquiera de los L2. Esto permitiría que las transferencias entre L2 ocurrieran sin necesidad de pagar gas L1 por transferencia, y sin necesidad de técnicas basadas en proveedores de liquidez como ERC-7683.
  • Composabilidad sincrónica: permitir que las llamadas sincrónicas ocurran entre un L2 específico y L1, o entre varios L2. Esto podría ser útil para mejorar la eficiencia financiera de los protocolos defi. Lo primero se podría hacer sin ninguna coordinación entre L2; lo segundo requeriríasecuenciación compartida. Resúmenes basadosson automáticamente amigables con todas estas técnicas.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

Muchos de los ejemplos anteriores enfrentan dilemas estándar sobre cuándo estandarizar y en qué capas estandarizar. Si estandarizas demasiado pronto, corres el riesgo de consolidar una solución inferior. Si estandarizas demasiado tarde, corres el riesgo de 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 "en última instancia correcta" pero llevará bastantes años llegar a ella.

Una forma en la que esta sección es única es que estas tareas no son solo problemas técnicos: también son (¡quizás incluso principalmente!) problemas sociales. Requieren que L2 y las billeteras y L1 cooperen. Nuestra capacidad para manejar este problema con éxito es una prueba de nuestra capacidad para permanecer unidos como comunidad.

¿Cómo interactúa con otras partes del plan de trabajo?

La mayoría de estas propuestas son construcciones de "capa superior" y, por lo tanto, no afectan en gran medida las consideraciones de L1. Una excepción es la secuenciación compartida, que tiene un fuerte impacto en MEV.

Escalando la ejecución en L1

¿Qué problema estamos resolviendo?

Si las capas 2 se vuelven muy escalables y exitosas pero la capa 1 sigue siendo capaz de procesar solo un volumen muy bajo de transacciones, existen muchos riesgos para Ethereum que podrían surgir:

  1. La situación económica de ETH como activo se vuelve más arriesgada, lo que a su vez afecta la seguridad a largo plazo de la red.
  2. Muchos L2 se benefician al estar estrechamente ligados a un ecosistema financiero altamente desarrollado en L1, y si este ecosistema se debilita en gran medida, el incentivo para convertirse en un L2 (en lugar de ser un L1 independiente) se debilita
  3. Pasará mucho tiempo antes de que las capas 2 tengan exactamente las mismas garantías de seguridad que la capa 1.
  4. Si un L2 falla (por ejemplo, debido a un operador malicioso o que desaparece), los usuarios aún necesitarían pasar por L1 para recuperar sus activos. Por lo tanto, L1 debe ser lo suficientemente potente como para poder manejar al menos ocasionalmente un cierre altamente complejo y caótico de un L2.

Por estas razones, es valioso seguir escalando L1 en sí mismo y asegurarse de que pueda seguir acomodando un número creciente de usos.

¿Qué es y cómo funciona?

La forma más fácil de escalar es simplemente aumentar el límite de gas. Sin embargo, esto corre el riesgo de centralizar la L1 y, por lo tanto, debilitar la otra propiedad importante que hace que la L1 de Ethereum sea tan poderosa: su credibilidad como una capa base robusta. Existe un debate en curso sobre qué grado de aumento simple del límite de gas es sostenible, y esto también cambia en función de qué otras tecnologías se implementan para hacer que los bloques más grandes sean más fáciles de verificar (por ejemplo, caducidad del historial, apatridia, pruebas de validez L1 EVM). Otra cosa importante que hay que seguir mejorando es simplemente la eficiencia del software cliente de Ethereum, que está mucho más optimizado hoy que hace cinco años. Una estrategia eficaz de aumento del límite de gas L1 implicaría acelerar estas tecnologías de verificación.

Otra estrategia de escalado implica identificar características específicas y tipos de cálculos que se pueden hacer más baratos sin dañar la descentralización de la red o sus propiedades de seguridad. Ejemplos de esto incluyen:

  • EOF- un nuevo formato de bytecode EVM que es más amigable para el análisis estático, lo que permite implementaciones más rápidas. El bytecode EOF podría recibir costos de gas más bajos para tener en cuenta estas eficiencias.
  • Precios de gas multidimensionalesestablecer tarifas y límites separados para la computación, los datos y el almacenamiento puede aumentar la capacidad promedio de Ethereum L1 sin aumentar su capacidad máxima (y por lo tanto crear nuevos riesgos de seguridad).
  • Reducir los costos de gas de códigos de operación específicos y precompilaciones - históricamente, hemos tenido varios rondasdeaumentandogascostospara ciertas operaciones que estaban subvaloradas para evitar ataques de denegación de servicio. Lo que hemos tenido menos, y podríamos hacer mucho más, es reducir los costos de gas para operaciones que están sobrevaloradas. Por ejemplo, la suma es mucho más barata que la multiplicación, pero los costos de los opcodes ADD y MUL son actualmente los mismos. Podríamos hacer que ADD sea más barato e incluso opcodes más simples como PUSH aún más baratos.
  • EVM-MAXySIMD: EVM-MAX ("extensiones de aritmética modular") es una propuesta para permitir matemáticas modulares de números grandes nativos más eficientes como un módulo separado del EVM. Los valores calculados por las operaciones de EVM-MAX solo serían accesibles por otras operaciones de EVM-MAX, a menos que se exporten deliberadamente; esto permite un mayor espacio para almacenar estos valores en formatos optimizados. SIMD (“instrucción única, múltiples datos”) es una propuesta para permitir ejecutar eficientemente la misma instrucción en un conjunto de valores. Los dos juntos pueden crear un poderoso coprocesadorjunto al EVM que podría ser utilizado para implementar de manera mucho más eficiente operaciones criptográficas. Esto sería especialmente útil para protocolos de privacidad, y para sistemas de prueba L2, por lo que ayudaría tanto a la escalabilidad L1 como a la L2.

Estas mejoras se discutirán con más detalle en una publicación futura sobre el Despilfarro.

Finalmente, una tercera estrategia son los rollups nativos (o rollups "consagrados"): esencialmente, crear muchas copias del EVM que se ejecutan en paralelo, lo que conduce a un modelo que es equivalente a lo que los rollups pueden proporcionar, pero mucho más integrado de forma nativa en el protocolo.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

Hay tres estrategias para la escalabilidad de L1, que se pueden seguir individualmente o en paralelo:

  • Mejorar la tecnología (por ejemplo, código del cliente, clientes sin estado, caducidad del historial) para que sea más fácil verificar L1 y luego aumentar el límite de gas
  • Hacer operaciones específicas más baratas, aumentando la capacidad promedio sin aumentar los riesgos en el peor de los casos
  • Rollups nativos (es decir, “crear N copias paralelas de la EVM”, aunque potencialmente brindando a los desarrolladores mucha flexibilidad en los parámetros de las copias que implementan)

Vale la pena entender que estas son técnicas diferentes que tienen compensaciones diferentes. Por ejemplo, los rollups nativos tienen muchas de las mismas debilidades en la composabilidad que los rollups regulares: no puedes enviar una sola transacción que realice sincrónicamente operaciones a través de muchos de ellos, como puedes hacer con contratos en el mismo L1 (o L2). Aumentar el límite de gas resta otros beneficios que se pueden lograr al hacer que el L1 sea más fácil de verificar, como aumentar la porción de usuarios que ejecutan nodos de verificación y aumentar los apostadores en solitario. Hacer que operaciones específicas en el EVM sean más baratas, dependiendo de cómo se haga, puede aumentar la complejidad total del EVM.

Una gran pregunta que cualquier hoja de ruta de escalado L1 necesita responder es: ¿cuál es la visión final de lo que pertenece a L1 y lo que pertenece a L2? Claramente, es absurdo que todo vaya en L1: los casos de uso potenciales llegan a cientos de miles de transacciones por segundo, y eso haría que L1 fuera completamente inviable de verificar (a menos que optemos por la ruta de rollup nativa). Pero necesitamos algún principio rector, para asegurarnos de que no estamos creando una situación en la que aumentamos el límite de gas en 10 veces, dañamos gravemente la descentralización de Ethereum L1, y descubrimos que solo hemos llegado a un mundo en el que en lugar de que el 99% de la actividad esté en L2, el 90% de la actividad esté en L2, y por lo tanto, el resultado de lo contrario parece casi lo mismo, excepto por una pérdida irreversible de gran parte de lo que hace especial a Ethereum L1.

Una vista propuesta de una “división del trabajo” entre L1 y L2s,fuente.

¿Cómo interactúa con otras partes del plan de trabajo?

Traer a más usuarios a L1 implica mejorar no solo la escala, sino también otros aspectos de L1. Significa que más MEV permanecerá en L1 (en lugar de convertirse en un problema solo para L2), por lo que será aún más necesario abordarlo explícitamente. Aumenta en gran medida el valor de tener tiempos de ranura rápidos en L1. Y también depende en gran medida de que la verificación de L1 ("la Verge") salga bien.

Descargo de responsabilidad:

  1. Este artículo es reimpreso de [Vitalik Buterin], Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
  2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
  3. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.

Поділіться

Контент

La Oleada: objetivos clave

En este capítulo

Aparte: el trilema de escalabilidad

Avances adicionales en muestreo de disponibilidad de datos

Compresión de datos

Plasma Generalizado

Sistemas de prueba L2 maduros

Mejoras de interoperabilidad entre L2 cruzados

Escalando la ejecución en L1

Posibles futuros de Ethereum, Parte 2: La Oleada

Avanzado10/22/2024, 4:38:46 AM
La estrategia de escalado de Ethereum ha evolucionado desde el shardin y los protocolos de capa 2 hacia un enfoque centrado en rollups. El roadmap actual propone una división de tareas entre L1 y L2: L1 sirve como una capa base robusta, mientras que L2 es responsable de la expansión del ecosistema. Los logros recientes incluyen los blobs de EIP-4844 que aumentan el ancho de banda de datos de L1 y varios rollups de EVM alcanzando la etapa 1. Los objetivos futuros incluyen lograr 100,000+ TPS, mantener la descentralización de L1, garantizar que algunos L2 hereden las propiedades fundamentales de Ethereum y maximizar la interoperabilidad entre L2. Las áreas clave de investigación incluyen muestreo de disponibilidad de datos, compresión de datos e interoperabilidad entre L2.
Ethereum

La Oleada: objetivos clave

En este capítulo

Aparte: el trilema de escalabilidad

Avances adicionales en muestreo de disponibilidad de datos

Compresión de datos

Plasma Generalizado

Sistemas de prueba L2 maduros

Mejoras de interoperabilidad entre L2 cruzados

Escalando la ejecución en L1

Al principio, Ethereum tenía dos estrategias de escalado en su hoja de ruta. Uno (por ejemplo, ver este primer documentodesde 2015) fue “fragmentación”: en lugar de verificar y almacenar todas las transacciones en la cadena, cada nodo solo necesitaría verificar y almacenar una pequeña fracción de las transacciones. Así es como funciona cualquier otra red peer-to-peer (por ejemplo, BitTorrent), por lo que seguramente podríamos hacer que las blockchains funcionen de la misma manera. Otro fue los protocolos de capa 2: redes que se ubicarían encima de Ethereum de una manera que les permita beneficiarse plenamente de su seguridad, al tiempo que mantienen la mayor parte de los datos y cálculos fuera de la cadena principal. Los “protocolos de capa 2” significaban canales de estadoen 2015, Plasmaen 2017, y luegorollupsen 2019. Rollups son más poderosos que los canales de estado o Plasma, pero requieren una gran cantidad de ancho de banda de datos en cadena. Afortunadamente, para 2019 la investigación de shardings había resuelto el problema de verificar la "disponibilidad de datos" a escala. Como resultado, los dos caminos convergieron, y obtuvimos el hoja de ruta centrada en rollupque sigue siendo la estrategia de escalado de Ethereum hoy.

La oleada, edición de la hoja de ruta de 2023.

La hoja de ruta centrada en rollups propone una simple división del trabajo: Ethereum L1 se enfoca en ser una capa base sólida y descentralizada, mientras que L2 se encarga de ayudar a escalar el ecosistema. Este es un patrón que se repite en todas partes en la sociedad: el sistema judicial (L1) no está ahí para ser ultra rápido y eficiente, está ahí para proteger contratos y derechos de propiedad, y corresponde a los emprendedores (L2) construir sobre esosólido base capay llevar a la humanidad a Marte (metafórica y literalmente).

Este año, la hoja de ruta centrada en rollup ha tenido importantes éxitos: el ancho de banda de datos de Ethereum L1 ha aumentado considerablemente con blobs EIP-4844, y ahora hay múltiples rollups de EVM en la etapa 1. Un muy implementación heterogénea y pluralista de sharding, donde cada L2 actúa como un “fragmento” con sus propias reglas y lógica interna, es ahora una realidad. Pero como hemos visto, tomar este camino tiene sus propios desafíos únicos. Y así que ahora nuestra tarea es llevar el mapa de ruta centrado en rollup a su finalización, y resolver estos problemas, mientras se preserva la solidez y descentralización que hacen especial a Ethereum L1.

La oleada: objetivos clave

  • 100,000+ TPS en L1+L2
  • Preservar la descentralización y la robustez de L1
  • Al menos algunos L2 heredan completamente las propiedades fundamentales de Ethereum (sin confianza, abierto, resistente a la censura)
  • Máxima interoperabilidad entre L2s. Ethereum debería sentirse como un ecosistema único, no como 34 blockchains diferentes.

En este capítulo

Aparte: el trilema de la escalabilidad

El trilema de escalabilidad era una idea introducido en 2017, que argumentó que hay una tensión entre tres propiedades de una cadena de bloques: descentralización (más específicamente: bajo costo para ejecutar un nodo), escalabilidad (más específicamente: alto número de transacciones procesadas) y seguridad (más específicamente: un atacante necesitando corromper una gran parte de los nodos en toda la red para hacer que falle incluso una sola transacción).

Es importante destacar que el trilema no es un teorema, y la publicación que introduce el trilema no venía acompañada de una prueba matemática. Sin embargo, sí proporcionó un argumento matemático heurístico: si un nodo amigable con la descentralización (por ejemplo, una computadora portátil de consumidor) puede verificar N transacciones por segundo, y tienes una cadena que procesa k*N transacciones por segundo, entonces o bien (i) cada transacción solo es vista por 1/k de los nodos, lo que implica que un atacante solo necesita corromper unos pocos nodos para hacer pasar una transacción incorrecta, o (ii) tus nodos van a ser potentes y tu cadena no será descentralizada. El propósito de la publicación nunca fue demostrar que romper el trilema es imposible; más bien, fue mostrar que romper el trilema es difícil, requiere de alguna manera pensar fuera de la caja que el argumento implica.

Durante muchos años, ha sido común que algunas cadenas de alto rendimiento afirmen que resuelven el trilema sin hacer nada inteligente a nivel de arquitectura fundamental, típicamente utilizando trucos de ingeniería de software para optimizar el nodo. Esto siempre es engañoso, y ejecutar un nodo en dichas cadenas siempre termina siendo mucho más difícil que en Ethereum.Esta publicaciónentra en algunas de las muchas sutilezas de por qué esto es así (y, por lo tanto, por qué la ingeniería de software del cliente L1 por sí sola no puede escalar Ethereum en sí mismo).

Sin embargo, la combinación de muestreo de disponibilidad de datos y SNARKs resuelve el trilema: permite a un cliente verificar que cierta cantidad de datos está disponible y que se llevaron a cabo correctamente cierta cantidad de pasos de cálculo, mientras descarga solo una pequeña porción de esos datos y ejecuta una cantidad mucho menor de cálculos. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un enfoque sutil modelo de confianza few-of-N, pero conserva la propiedad fundamental que tienen las cadenas no escalables, que es que ni siquiera un ataque del 51% puede obligar a que los bloques malos sean aceptados por la red.

Otra forma de resolver el trilema es a través de arquitecturas de Plasma, que utilizan técnicas ingeniosas para trasladar la responsabilidad de vigilar la disponibilidad de datos al usuario de manera compatible con los incentivos. En 2017-2019, cuando todo lo que teníamos para escalar la computación eran pruebas de fraude, Plasma estaba muy limitado en lo que podía hacer de forma segura, pero la incorporación de SNARKs hace que las arquitecturas de Plasma mucho más viablepara una gama más amplia de casos de uso que antes.

Más avances en muestreo de disponibilidad de datos

¿Qué problema estamos resolviendo?

A partir del 13 de marzo de 2024, cuando el Actualización de DencunCuando se puso en marcha, la cadena de bloques de Ethereum tiene tres "blobs" de ~125 kB por ranura de 12 segundos, o ~375 kB por ranura de ancho de banda de disponibilidad de datos. Suponiendo que los datos de transacción se publican en la cadena directamente, una transferencia ERC20 es de ~180 bytes, por lo que el TPS máximo de rollups en Ethereum es:

375000 / 12 / 180 = 173.6 TPS

Si agregamos los calldatas 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, el plan es aumentar el objetivo de recuento de blobs a 8-16, lo que nos daría 463-926 TPS en calldata.

Este es un gran aumento sobre el Ethereum L1, pero no es suficiente. Queremos mucha más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por ranura, lo que, combinado con mejoras en la compresión de datos de rollup, nos daría ~58,000 TPS.

¿Qué es esto y cómo funciona?

PeerDAS es una implementación relativamente simple de "muestreo 1D". Cada blob en Ethereum es un polinomio de grado 4096 sobre un campo primo de 253 bits. Transmitimos "partes" del polinomio, donde cada parte consta de 16 evaluaciones en 16 coordenadas adyacentes tomadas de un conjunto total de 8192 coordenadas. Cualquier conjunto de 4096 de las 8192 evaluaciones (con los parámetros propuestos actuales: cualquier conjunto de 64 de las 128 muestras posibles) puede recuperar el blob.

PeerDAS funciona haciendo que cada cliente escuche en un pequeño número de subredes, donde la subred i-ésima transmite la i-ésima muestra de cualquier blob, y además solicita blobs en otras subredes que necesite preguntando a sus pares en la red p2p global (que estarían escuchando diferentes subredes). Una versión más conservadora, SubnetDAS, utiliza solo el mecanismo de subred, sin la capa adicional de preguntar a los pares. Una propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, y que otros nodos (es decir, "clientes") utilicen PeerDAS.

Teóricamente, podemos escalar el muestreo 1D bastante lejos: si aumentamos el recuento máximo de blobs a 256 (por lo tanto, el objetivo a 128), entonces llegaríamos a nuestro objetivo de 16 MB mientras que el muestreo de disponibilidad de datos solo costaría a cada nodo 16 muestras128 blobs512 bytes por muestra por fragmento = 1 MB de ancho de banda de datos por ranura. Esto está justo dentro de nuestro alcance de tolerancia: es factible, pero significaría que los clientes con restricciones de ancho de banda no podrían muestrear. Podríamos optimizar esto en cierta medida disminuyendo el recuento de fragmentos y aumentando el tamaño de los fragmentos, pero esto haría que la reconstrucción fuera más costosa.

Y así, en última instancia, queremos ir más allá y hacerMuestreo 2D, que funciona mediante muestreo aleatorio no solo dentro de los bloques, sino también entre los bloques. Las propiedades lineales de las confirmaciones KZG se utilizan para “extender” el conjunto de bloques en un bloque con una lista de nuevos “bloques virtuales” que codifican redundante la misma información.

Muestreo 2D. Fuente: a16z crypto

Es crucial destacar que calcular la extensión de los compromisos no requiere tener los bloques, por lo que el esquema es fundamentalmente amigable para la construcción de bloques distribuidos. El nodo que realmente construye el bloque solo necesitaría tener los compromisos de bloques KZG y puede confiar en DAS para verificar la disponibilidad de los bloques. 1D DAS también es inherentemente amigable para la construcción de bloques distribuidos.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

El siguiente paso inmediato es terminar la implementación y el despliegue de PeerDAS. A partir de ahí, es una tarea progresiva seguir aumentando el recuento de blobs en PeerDAS mientras se vigila cuidadosamente la red y se mejora el software para garantizar la seguridad. Al mismo tiempo, queremos más trabajos académicos para formalizar PeerDAS y otras versiones de DAS y sus interacciones con problemas como la seguridad de la regla de elección de bifurcación.

Más adelante en el futuro, necesitamos mucho más trabajo para descubrir la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También queremos eventualmente migrar lejos de KZG a una alternativa resistente a la computación cuántica y libre de configuración confiable. Actualmente, no conocemos candidatos que sean amigables para la construcción de bloques distribuidos. Incluso la costosa técnica de "fuerza bruta" de usar STARKs recursivos para generar pruebas de validez para la reconstrucción de filas y columnas no es suficiente, porque técnicamente un STARK tiene un tamaño de O(log(n) * log(log(n)) hashes.STIR) en la práctica, un STARK es casi tan grande como un blob completo.

Los caminos realistas que veo a largo plazo son:

  • Implementar ideal 2D DAS
  • Mantente con 1D DAS, sacrificando eficiencia de ancho de banda de muestreo y aceptando un límite de datos más bajo en aras de la simplicidad y la robustez
  • (Pivote radical) abandonar DA y abrazar por completo Plasma como una arquitectura de capa 2 primaria en la que nos estamos centrando

Podemos ver esto a lo largo de un espectro de compensación:

Tenga en cuenta que esta opción existe incluso si decidimos escalar la ejecución en L1 directamente. Esto se debe a que si L1 va a procesar muchas TPS, los bloques de L1 serán muy grandes y los clientes querrán una forma eficiente de verificar que son correctos, por lo que tendríamos que utilizar la misma tecnología que impulsa los rollups (ZK-EVM y DAS) en L1.

¿Cómo interactúa con otras partes del mapa de ruta?

La necesidad de 2D DAS se reduce en cierta medida, o al menos se retrasa, si se implementa la compresión de datos (ver abajo), y se reduce aún más si Plasma se usa ampliamente. DAS también plantea un desafío a los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable para la reconstrucción distribuida, esto necesita combinarse en la práctica conlista de inclusiónpropuestas y su mecánica de selección de bifurcación circundante.

Compresión de datos

¿Qué problema estamos resolviendo?

Cada transacción en un rollup ocupa una cantidad significativa de espacio de datos en la cadena: una transferencia ERC20 ocupa alrededor de 180 bytes. Incluso con un muestreo ideal de disponibilidad de datos, esto pone un límite a la escalabilidad de los protocolos de capa 2. Con 16 MB por ranura, obtenemos:

16000000 / 12 / 180 = 7407 TPS

¿Y si además de abordar el numerador, también podemos abordar el denominador y hacer que cada transacción en un rollup ocupe menos bytes en la cadena?

¿Qué es y cómo funciona?

La mejor explicación en mi opinión es este diagramahace dos años:

Las ganancias más simples son simplemente compresión de bytes cero: reemplazando cada secuencia larga de bytes cero con dos bytes que representan cuántos bytes cero hay. Para ir más allá, aprovechamos las propiedades específicas de las transacciones:

  • La agregación de firmas: cambiamos de firmas ECDSA a firmas BLS, que tienen la propiedad de que muchas firmas pueden combinarse en una sola firma que certifica la validez de todas las firmas originales. Esto no se considera para L1 porque los costos computacionales de verificación, incluso con agregación, son más altos, pero en un entorno escaso en datos como L2s, sin duda tiene sentido. La función de agregación de ERC-4337presenta una forma de implementar esto.
  • Reemplazar direcciones con punteros: si una dirección fue utilizada anteriormente, podemos reemplazar la dirección de 20 bytes con un puntero de 4 bytes a una ubicación en la historia. Esto es necesario para lograr las mayores ganancias, aunque requiere esfuerzo para implementarse, ya que se necesita que (al menos una parte de) la historia de la cadena de bloques se convierta efectivamente en parte del estado.
  • Serialización personalizada para 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. Las tarifas máximas de gas base y las tarifas prioritarias funcionan de manera similar. Por lo tanto, podemos representar la mayoría de los valores de moneda de manera muy compacta con un formato decimal de punto flotante personalizado, o incluso con un diccionario de valores especialmente comunes.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son las compensaciones?

Lo principal que queda por hacer es implementar realmente los esquemas anteriores. Los principales compromisos son:

  • Cambiar a firmas BLS requiere un esfuerzo significativo y reduce la compatibilidad con chips de hardware de confianza que pueden aumentar la seguridad. Un envoltorio ZK-SNARK alrededor de otros esquemas de firma podría usarse para reemplazar esto.
  • La compresión dinámica (por ejemplo, reemplazar direcciones con punteros) complica el código del cliente.
  • Publicar diferencias de estado en la cadena en lugar de transacciones reduce la auditabilidad y hace que mucho software (por ejemplo, exploradores de bloques) no funcione.

¿Cómo interactúa con otras partes del plan de trabajo?

La adopción de ERC-4337, y eventualmente la consagración de partes de ella en L2 EVMs, puede acelerar en gran medida la implementación de técnicas de agregación. La consagración de partes de ERC-4337 en L1 puede acelerar su implementación en L2s.

Plasma generalizado

¿Qué problema estamos resolviendo?

Incluso con blobs de 16 MB y compresión de datos, 58.000 TPS no son necesariamente suficientes para hacerse cargo por completo de los pagos de los consumidores, las redes sociales descentralizadas u otros sectores de gran ancho de banda, y esto se vuelve especialmente cierto si comenzamos a tener en cuenta la privacidad, que podría reducir la escalabilidad entre 3 y 8 veces. Para aplicaciones de alto volumen y bajo valor, una opción hoy en día es un validium, que mantiene los datos fuera de la cadena y tiene un interesante modelo de seguridad donde el operador no puede robar los fondos de los usuarios, pero pueden desaparecer y 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 de escalado que implica que un operador publique bloques fuera de la cadena, y coloque las raíces de Merkle de esos bloques en la cadena (a diferencia de los rollups, donde el bloque completo se coloca en la cadena). Para cada bloque, el operador envía a cada usuario una rama de Merkle que prueba lo que sucedió, o no sucedió, con los activos de ese usuario. Los usuarios pueden retirar sus activos proporcionando una rama de Merkle. Es importante destacar que esta rama no tiene que estar enraizada en el estado más reciente, por esta razón, incluso si la disponibilidad de datos falla, el usuario aún puede recuperar sus activos retirando el estado más reciente que tienen disponible. Si un usuario envía una rama inválida (por ejemplo, sale de un activo que ya envió a otra persona, o el mismo operador crea un activo de la nada), un mecanismo de desafío en cadena puede decidir a quién pertenece legítimamente el activo.

Un diagrama de una cadena de Plasma Cash. Las transacciones que gastan la moneda i se colocan en la posición i-ésima en el árbol. En este ejemplo, asumiendo que todos los árboles anteriores son válidos, sabemos que Eve actualmente posee la moneda 1, David posee la moneda 4 y George posee la moneda 6.

Las primeras versiones de Plasma solo podían manejar el caso de uso de pagos y no podían generalizarse de manera efectiva. Sin embargo, si requerimos que cada raíz sea verificada con un SNARK, Plasma se vuelve mucho más poderoso. Cada juego de desafío puede simplificarse significativamente, porque eliminamos la mayoría de los posibles caminos para que el operador haga trampa. También se abren nuevos caminos para permitir que las técnicas de Plasma se extiendan a una clase mucho más general de activos. Finalmente, en el caso de que el operador no haga trampa, los usuarios pueden retirar sus fondos al instante, sin necesidad de esperar un período de desafío de una semana.

Una forma (no la única forma) de crear una cadena de plasma de EVM: utilizar un ZK-SNARK para construir un árbol UTXO paralelo que refleje los cambios de saldo realizados por el EVM, y defina un mapeo único de lo que es “la misma moneda” en diferentes momentos de la historia. Una construcción de Plasma puede entonces construirse sobre eso.

Una idea clave es que el sistema Plasma no necesita ser perfecto. Incluso si solo puedes proteger un subconjunto de activos (por ejemplo, incluso solo monedas que no se han movido en la última semana), ya has mejorado en gran medida el estado actual del EVM ultramoderno, que es un validium válido.

Otra clase de construcciones son los plasmas híbridos/rollups, como Intmax. Estas construcciones colocan una cantidad muy pequeña de datos por usuario en la cadena (por ejemplo, 5 bytes), y al hacerlo, obtienen propiedades que se encuentran en algún punto intermedio entre plasma y rollups: en el caso de Intmax, se obtiene un nivel muy alto de escalabilidad y privacidad, aunque incluso en el mundo de 16 MB, la capacidad está teóricamente limitada a aproximadamente 16,000,000 / 12 / 5 = 266,667 TPS.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

La principal tarea pendiente es llevar los sistemas de plasma a la producción. Como se mencionó anteriormente, "plasma vs validium" no es binario: cualquier validium puede mejorar sus propiedades de seguridad al menos un poco al agregar características de plasma en el mecanismo de salida. La parte de investigación consiste en obtener las propiedades óptimas (en términos de requisitos de confianza, el costo del gas L1 en el peor de los casos y la vulnerabilidad a DoS) para una EVM, así como construcciones alternativas específicas de la aplicación. Además, la mayor complejidad conceptual de Plasma en relación con los rollups debe abordarse directamente, tanto a través de la investigación como a través de la construcción de mejores marcos generalizados.

El principal compromiso en el uso de los diseños de Plasma es que dependen más de los operadores y son más difíciles de hacer “basadoAunque los diseños híbridos de plasma/rollup a menudo pueden evitar esta debilidad.

¿Cómo interactúa con otras partes del plan de trabajo?

Cuanto más efectivas sean las soluciones de Plasma, menos presión habrá para que el L1 tenga una funcionalidad de disponibilidad de datos de alto rendimiento. Mover la actividad al L2 también reduce la presión de MEV en el L1.

Maduración de los sistemas a prueba de L2

¿Qué problema estamos resolviendo?

Hoy en día, la mayoría de los rollups aún no son realmente descentralizados; hay un consejo de seguridad que tiene la capacidad de anular el comportamiento del (optimista o de validez)sistema de pruebaEn algunos casos, el sistema de prueba ni siquiera está en funcionamiento, o si lo está, solo tiene una funcionalidad "asesora". Los más avanzados son (i) algunos rollups específicos de aplicaciones, como Fuel, que son sin confianza, y (ii) en el momento de esta escritura, Optimism y Arbitrum, dos rollups completos de EVM que han logrado un hito de "parcial sin confianza" conocido como "etapa 1". La razón por la que los rollups no han avanzado más es la preocupación por los errores en el código. Necesitamos rollups sin confianza, y por lo tanto, debemos abordar este problema de frente.

¿Qué es y cómo funciona?

Primero, vamos a repasar el sistema de 'etapas', originalmente introducido en esta publicación. Hay más requisitos detallados, pero el resumen es:

  • Etapa 0: debe ser posible para un usuario ejecutar un nodo y sincronizar la cadena. Está bien si la validación es totalmente confiable / centralizada.
  • Etapa 1: debe existir un sistema de prueba (sin confianza) que garantice que solo se acepten transacciones válidas. Se permite que haya un consejo de seguridad que pueda anular el sistema de prueba, pero solo con un voto de umbral del 75%. Además, una parte del consejo que bloquee el quórum (por ejemplo, 26% o más) debe estar fuera del edificio principal de la empresa que construye el rollup. Se permite un mecanismo de actualización con características más débiles (por ejemplo, un DAO), pero debe tener un retraso lo suficientemente largo para que, si aprueba una actualización maliciosa, los usuarios puedan retirar sus fondos antes de que entre en funcionamiento.
  • Etapa 2: debe haber un sistema de prueba (sin confianza) que garantice que solo se acepten transacciones válidas. Los consejos de seguridad solo pueden intervenir en caso de errores demostrables en el código, por ejemplo. si dos sistemas de prueba redundantes no están de acuerdo 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, por ejemplo, una semana). Se permite un mecanismo de actualización, pero debe tener un retraso muy largo.

El objetivo es llegar a la Etapa 2. El principal desafío para llegar a la etapa 2 es obtener suficiente confianza en que el sistema de prueba es realmente lo suficientemente confiable. Hay dos formas principales de hacer esto:

  • Verificación formal: podemos utilizar técnicas matemáticas y computacionales modernas para demostrar que un sistema de prueba (optimista o de validez) solo acepta bloques que cumplan con la especificación de EVM. Estas técnicas han existido durante décadas, pero avances recientes como Lean 4los han hecho mucho más prácticos, y los avances en la demostración asistida por IA podrían potencialmente acelerar esta tendencia aún más.
  • Multi-verificadores: crear múltiples sistemas de prueba y colocar fondos en una multisig de 2-de-3 (o más) entre esos sistemas de prueba y un consejo de seguridad (y/o otro dispositivo con suposiciones de confianza, por ejemplo, TEEs). Si los sistemas de prueba están de acuerdo, el consejo de seguridad no tiene poder; si no están de acuerdo, el consejo de seguridad solo puede elegir entre uno de ellos, no puede imponer unilateralmente su propia respuesta.

Diagrama estilizado de un multi-demostrador, combinando un sistema de prueba optimista, un sistema de prueba de validez y un consejo de seguridad.

¿Cuáles son algunos de los vínculos con las investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

Para la verificación formal, mucho. Necesitamos crear una versión formalmente verificada de un probador de SNARK completo de un EVM. Este es un proyecto increíblemente complejo, aunque es uno que Ya hemos empezado. Hay un truco que simplifica significativamente la tarea: podemos hacer un probador SNARK verificado formalmente de una VM mínima, por ejemplo. RISC-VoCairo, y luego escribir una implementación del EVM en esa VM minimalista (y demostrar formalmente su equivalencia con alguna otra especificación del EVM).

Para los multi-provers, quedan dos piezas principales restantes. Primero, necesitamos tener suficiente confianza en al menos dos sistemas de prueba diferentes, ambos que son razonablemente seguros individualmente y que si fallan, fallarían por razones diferentes e no relacionadas (y por lo tanto no fallarían al mismo tiempo). Segundo, necesitamos obtener un nivel muy alto de seguridad en la lógica subyacente que fusiona los sistemas de prueba. Esta es una pieza de código mucho más pequeña. Hay formas de hacerla extremadamente pequeña: simplemente almacenar fondos en un Contrato seguro de firma múltiplecuyos firmantes son contratos que representan sistemas de prueba individuales, pero esto tiene el inconveniente de altos costos de gas en la cadena. Será necesario encontrar un equilibrio entre eficiencia y seguridad.

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

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

Mejoras de interoperabilidad entre L2 cruzados

¿Qué problema estamos resolviendo?

Uno de los principales desafíos con el ecosistema L2 hoy en día es que es difícil para los usuarios navegar. Además, las formas más fáciles de hacerlo a menudo reintroducen suposiciones de confianza: puentes centralizados, clientes de RPC, y así sucesivamente. Si tomamos en serio la idea de que los L2 son parte de Ethereum, necesitamos hacer que el uso del ecosistema L2 se sienta como usar un ecosistema unificado de Ethereum.

Un ejemplo de una experiencia de usuario entre capas (L2) patológicamente mala (e incluso peligrosa: personalmente perdí $100 debido a un error en la selección de cadena aquí) - aunque esto no es culpa de Polymarket, la interoperabilidad entre capas L2 debería ser responsabilidad de las carteras y la comunidad de estándares de Ethereum (ERC). En un ecosistema Ethereum bien funcionando, enviar monedas de L1 a L2, o de una L2 a otra, debería sentirse igual que enviar monedas dentro de la misma L1.

¿Qué es y cómo funciona?

Hay muchas categorías de mejoras de interoperabilidad cruzada de L2. En general, la forma de idearlas es darse cuenta de que en teoría, un Ethereum centrado en rollups es lo mismo que el particionamiento de ejecución L1, y luego preguntar dónde la actual Ethereum L2-verse se queda corta de ese ideal en la práctica. Aquí hay algunos:

  • Direcciones específicas de la cadena: la cadena (L1, Optimism, Arbitrum...) debe formar parte de la dirección. Una vez que esto se implementa, los flujos de envío entre L2 se pueden implementar simplemente colocando la dirección en el campo "enviar", momento en el que la billetera puede averiguar cómo realizar el envío (incluido el uso de protocolos de puente) en segundo plano.
  • Solicitudes de pago específicas de la cadena: debe ser fácil y estandarizado hacer un mensaje del tipo "envíame X tokens de tipo Y en la cadena Z". Esto tiene dos casos de uso principales: (i) pagos, ya sean de persona a persona o de persona a comerciante, y (ii) dapps que solicitan fondos, por ejemplo. el ejemplo anterior de Polymarket.
  • Intercambios entre cadenas y pago de gas: debería existir un protocolo abierto estandarizado para expresar operaciones entre cadenas como “Estoy enviando 1 ETH en Optimism a quien me envíe 0.9999 ETH en Arbitrum”, y “Estoy enviando 0.0001 ETH en Optimism a quien incluya esta transacción en Arbitrum”.ERC-7683es un intento del primero, y RIP-7755es un intento en este último, aunque ambos también son más generales que solo estos casos de uso específicos.
  • Clientes ligeros: los usuarios deberían poder verificar realmente las cadenas con las que interactúan, y no simplemente confiar en los proveedores de RPC. A16z crypto’sHeliosesto lo hace para Ethereum en sí, pero necesitamos extender esta falta de confianza a L2s.ERC-3668 (CCIP-read)es una estrategia para hacer esto.

Cómo un cliente ligero puede actualizar su vista de la cadena de encabezado de Ethereum. Una vez que tenga la cadena de encabezados, puede usar pruebas de Merkle para validar cualquier objeto de estado. Y una vez que tenga los objetos de estado L1 correctos, puede usar pruebas de Merkle (y posiblemente firmas, si desea verificar preconfirmaciones) para validar cualquier objeto de estado en L2. Helios ya hace lo primero. Extenderlo al último es un desafío de estandarización.

  • Monederos de keystore: hoy en día, si quieres actualizar las claves que controlan tu monedero de contrato inteligente, debes hacerlo en todas las N cadenas en las que ese monedero existe. Los monederos de keystore son una técnica que permite que las claves existan en un solo lugar (ya sea en L1, o más tarde potencialmente en un L2), y luego se lean desde cualquier L2 que tenga una copia del monedero. Esto significa que las actualizaciones solo necesitan hacerse una vez. Para ser eficientes, los monederos de keystore requieren que los L2 tengan una forma estandarizada de leer de forma gratuita desde L1; dos propuestas para esto son L1SLOAD y REMOTESTATICCALL.

Un diagrama estilizado de cómo funcionan las billeteras de almacén de claves.

  • Más ideas radicales de "puente de token compartido": imagina un mundo donde todos los L2 son rollups de prueba de validez, que se comprometen con Ethereum en cada ranura. Incluso en este mundo, mover activos de un L2 a otro L2 "nativamente" requeriría retirar y depositar, lo que requiere pagar una cantidad sustancial de gas L1. Una forma de resolver esto es crear un rollup mínimo compartido, cuya única función sería mantener los saldos de cuántos tokens de qué tipo son propiedad de qué L2, y permitir que esos saldos se actualicen en masa mediante una serie de operaciones de envío entre L2 iniciadas por cualquiera de los L2. Esto permitiría que las transferencias entre L2 ocurrieran sin necesidad de pagar gas L1 por transferencia, y sin necesidad de técnicas basadas en proveedores de liquidez como ERC-7683.
  • Composabilidad sincrónica: permitir que las llamadas sincrónicas ocurran entre un L2 específico y L1, o entre varios L2. Esto podría ser útil para mejorar la eficiencia financiera de los protocolos defi. Lo primero se podría hacer sin ninguna coordinación entre L2; lo segundo requeriríasecuenciación compartida. Resúmenes basadosson automáticamente amigables con todas estas técnicas.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

Muchos de los ejemplos anteriores enfrentan dilemas estándar sobre cuándo estandarizar y en qué capas estandarizar. Si estandarizas demasiado pronto, corres el riesgo de consolidar una solución inferior. Si estandarizas demasiado tarde, corres el riesgo de 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 "en última instancia correcta" pero llevará bastantes años llegar a ella.

Una forma en la que esta sección es única es que estas tareas no son solo problemas técnicos: también son (¡quizás incluso principalmente!) problemas sociales. Requieren que L2 y las billeteras y L1 cooperen. Nuestra capacidad para manejar este problema con éxito es una prueba de nuestra capacidad para permanecer unidos como comunidad.

¿Cómo interactúa con otras partes del plan de trabajo?

La mayoría de estas propuestas son construcciones de "capa superior" y, por lo tanto, no afectan en gran medida las consideraciones de L1. Una excepción es la secuenciación compartida, que tiene un fuerte impacto en MEV.

Escalando la ejecución en L1

¿Qué problema estamos resolviendo?

Si las capas 2 se vuelven muy escalables y exitosas pero la capa 1 sigue siendo capaz de procesar solo un volumen muy bajo de transacciones, existen muchos riesgos para Ethereum que podrían surgir:

  1. La situación económica de ETH como activo se vuelve más arriesgada, lo que a su vez afecta la seguridad a largo plazo de la red.
  2. Muchos L2 se benefician al estar estrechamente ligados a un ecosistema financiero altamente desarrollado en L1, y si este ecosistema se debilita en gran medida, el incentivo para convertirse en un L2 (en lugar de ser un L1 independiente) se debilita
  3. Pasará mucho tiempo antes de que las capas 2 tengan exactamente las mismas garantías de seguridad que la capa 1.
  4. Si un L2 falla (por ejemplo, debido a un operador malicioso o que desaparece), los usuarios aún necesitarían pasar por L1 para recuperar sus activos. Por lo tanto, L1 debe ser lo suficientemente potente como para poder manejar al menos ocasionalmente un cierre altamente complejo y caótico de un L2.

Por estas razones, es valioso seguir escalando L1 en sí mismo y asegurarse de que pueda seguir acomodando un número creciente de usos.

¿Qué es y cómo funciona?

La forma más fácil de escalar es simplemente aumentar el límite de gas. Sin embargo, esto corre el riesgo de centralizar la L1 y, por lo tanto, debilitar la otra propiedad importante que hace que la L1 de Ethereum sea tan poderosa: su credibilidad como una capa base robusta. Existe un debate en curso sobre qué grado de aumento simple del límite de gas es sostenible, y esto también cambia en función de qué otras tecnologías se implementan para hacer que los bloques más grandes sean más fáciles de verificar (por ejemplo, caducidad del historial, apatridia, pruebas de validez L1 EVM). Otra cosa importante que hay que seguir mejorando es simplemente la eficiencia del software cliente de Ethereum, que está mucho más optimizado hoy que hace cinco años. Una estrategia eficaz de aumento del límite de gas L1 implicaría acelerar estas tecnologías de verificación.

Otra estrategia de escalado implica identificar características específicas y tipos de cálculos que se pueden hacer más baratos sin dañar la descentralización de la red o sus propiedades de seguridad. Ejemplos de esto incluyen:

  • EOF- un nuevo formato de bytecode EVM que es más amigable para el análisis estático, lo que permite implementaciones más rápidas. El bytecode EOF podría recibir costos de gas más bajos para tener en cuenta estas eficiencias.
  • Precios de gas multidimensionalesestablecer tarifas y límites separados para la computación, los datos y el almacenamiento puede aumentar la capacidad promedio de Ethereum L1 sin aumentar su capacidad máxima (y por lo tanto crear nuevos riesgos de seguridad).
  • Reducir los costos de gas de códigos de operación específicos y precompilaciones - históricamente, hemos tenido varios rondasdeaumentandogascostospara ciertas operaciones que estaban subvaloradas para evitar ataques de denegación de servicio. Lo que hemos tenido menos, y podríamos hacer mucho más, es reducir los costos de gas para operaciones que están sobrevaloradas. Por ejemplo, la suma es mucho más barata que la multiplicación, pero los costos de los opcodes ADD y MUL son actualmente los mismos. Podríamos hacer que ADD sea más barato e incluso opcodes más simples como PUSH aún más baratos.
  • EVM-MAXySIMD: EVM-MAX ("extensiones de aritmética modular") es una propuesta para permitir matemáticas modulares de números grandes nativos más eficientes como un módulo separado del EVM. Los valores calculados por las operaciones de EVM-MAX solo serían accesibles por otras operaciones de EVM-MAX, a menos que se exporten deliberadamente; esto permite un mayor espacio para almacenar estos valores en formatos optimizados. SIMD (“instrucción única, múltiples datos”) es una propuesta para permitir ejecutar eficientemente la misma instrucción en un conjunto de valores. Los dos juntos pueden crear un poderoso coprocesadorjunto al EVM que podría ser utilizado para implementar de manera mucho más eficiente operaciones criptográficas. Esto sería especialmente útil para protocolos de privacidad, y para sistemas de prueba L2, por lo que ayudaría tanto a la escalabilidad L1 como a la L2.

Estas mejoras se discutirán con más detalle en una publicación futura sobre el Despilfarro.

Finalmente, una tercera estrategia son los rollups nativos (o rollups "consagrados"): esencialmente, crear muchas copias del EVM que se ejecutan en paralelo, lo que conduce a un modelo que es equivalente a lo que los rollups pueden proporcionar, pero mucho más integrado de forma nativa en el protocolo.

¿Cuáles son algunos enlaces a investigaciones existentes?

¿Qué queda por hacer y cuáles son los compromisos?

Hay tres estrategias para la escalabilidad de L1, que se pueden seguir individualmente o en paralelo:

  • Mejorar la tecnología (por ejemplo, código del cliente, clientes sin estado, caducidad del historial) para que sea más fácil verificar L1 y luego aumentar el límite de gas
  • Hacer operaciones específicas más baratas, aumentando la capacidad promedio sin aumentar los riesgos en el peor de los casos
  • Rollups nativos (es decir, “crear N copias paralelas de la EVM”, aunque potencialmente brindando a los desarrolladores mucha flexibilidad en los parámetros de las copias que implementan)

Vale la pena entender que estas son técnicas diferentes que tienen compensaciones diferentes. Por ejemplo, los rollups nativos tienen muchas de las mismas debilidades en la composabilidad que los rollups regulares: no puedes enviar una sola transacción que realice sincrónicamente operaciones a través de muchos de ellos, como puedes hacer con contratos en el mismo L1 (o L2). Aumentar el límite de gas resta otros beneficios que se pueden lograr al hacer que el L1 sea más fácil de verificar, como aumentar la porción de usuarios que ejecutan nodos de verificación y aumentar los apostadores en solitario. Hacer que operaciones específicas en el EVM sean más baratas, dependiendo de cómo se haga, puede aumentar la complejidad total del EVM.

Una gran pregunta que cualquier hoja de ruta de escalado L1 necesita responder es: ¿cuál es la visión final de lo que pertenece a L1 y lo que pertenece a L2? Claramente, es absurdo que todo vaya en L1: los casos de uso potenciales llegan a cientos de miles de transacciones por segundo, y eso haría que L1 fuera completamente inviable de verificar (a menos que optemos por la ruta de rollup nativa). Pero necesitamos algún principio rector, para asegurarnos de que no estamos creando una situación en la que aumentamos el límite de gas en 10 veces, dañamos gravemente la descentralización de Ethereum L1, y descubrimos que solo hemos llegado a un mundo en el que en lugar de que el 99% de la actividad esté en L2, el 90% de la actividad esté en L2, y por lo tanto, el resultado de lo contrario parece casi lo mismo, excepto por una pérdida irreversible de gran parte de lo que hace especial a Ethereum L1.

Una vista propuesta de una “división del trabajo” entre L1 y L2s,fuente.

¿Cómo interactúa con otras partes del plan de trabajo?

Traer a más usuarios a L1 implica mejorar no solo la escala, sino también otros aspectos de L1. Significa que más MEV permanecerá en L1 (en lugar de convertirse en un problema solo para L2), por lo que será aún más necesario abordarlo explícitamente. Aumenta en gran medida el valor de tener tiempos de ranura rápidos en L1. Y también depende en gran medida de que la verificación de L1 ("la Verge") salga bien.

Descargo de responsabilidad:

  1. Este artículo es reimpreso de [Vitalik Buterin], Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
  2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
  3. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.
Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!