- Tema
77k Popularidad
33k Popularidad
10k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
- Anclado
77k Popularidad
33k Popularidad
10k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
Ethereum expansión nuevo capítulo: Análisis profundo de la hoja de ruta The Surge
Futuro posible de Ethereum: The Surge
La hoja de ruta de Ethereum inicialmente incluía dos estrategias de escalado: sharding y protocolos Layer 2. Estas dos metodologías finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalado actual de Ethereum.
La hoja de ruta centrada en Rollup propone una división simple del trabajo: Ethereum L1 se enfoca en convertirse en una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema. Este modelo es común en la sociedad: la existencia del sistema judicial (L1) es para proteger los contratos y la propiedad, mientras que los emprendedores (L2) construyen sobre esta base, impulsando el desarrollo humano.
Este año, la hoja de ruta centrada en Rollup ha logrado avances significativos: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado considerablemente, y múltiples máquinas virtuales de Ethereum (EVM) Rollup han entrado en la primera fase. Cada L2 existe como un "shard" con sus propias reglas y lógicas internas. La diversidad y pluralidad en las formas de implementar los shards se ha convertido en una realidad. Sin embargo, este camino también enfrenta algunos desafíos únicos. Por lo tanto, nuestra tarea ahora es completar la hoja de ruta centrada en Rollup y abordar estos problemas, mientras mantenemos la robustez y la descentralización propias de Ethereum L1.
The Surge: Objetivos clave
En el futuro, Ethereum podrá alcanzar más de 100,000 TPS a través de L2;
Mantener la descentralización y robustez de L1;
Al menos algunos L2 heredan completamente las propiedades centrales de Ethereum, (, para la confianza, la apertura y la resistencia a la censura, );
Ethereum debería sentirse como un ecosistema unificado, en lugar de 34 cadenas de bloques diferentes.
Contenido de este capítulo
La paradoja del triángulo de escalabilidad
El triángulo de la escalabilidad sostiene que existe una contradicción entre tres características de la blockchain: la descentralización, el bajo costo de operar nodos (, la escalabilidad para procesar una gran cantidad de transacciones ) y la seguridad, donde un atacante necesita comprometer una gran parte de los nodos en la red para hacer que una transacción falle (.
![Vitalik nuevo artículo: El futuro posible de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Es importante señalar que la paradoja triangular no es un teorema ni tiene una demostración matemática. Proporciona un argumento matemático heurístico: si un nodo amigable con la descentralización puede verificar N transacciones por segundo, y tienes una cadena que procesa k*N transacciones por segundo, entonces )i( cada transacción solo puede ser vista por 1/k nodos, lo que significa que un atacante solo necesita comprometer unos pocos nodos para llevar a cabo una transacción maliciosa, o )ii( tu nodo se volverá poderoso, mientras que tu cadena no será descentralizada. El propósito de este artículo no es demostrar que romper la paradoja triangular es imposible; por el contrario, su objetivo es mostrar que romper la paradoja ternaria es difícil y requiere, en cierta medida, salir del marco de pensamiento implícito en este argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que han resuelto el trilema sin cambiar fundamentalmente la arquitectura, generalmente optimizando los nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que ejecutar nodos en estas cadenas es mucho más difícil que ejecutar nodos 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 del muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja del triángulo: permite a los clientes verificar que una cierta cantidad de datos está disponible y que una cierta cantidad de pasos de cálculo se ejecutan correctamente, al descargar solo una pequeña cantidad de datos y realizar muy pocos cálculos. Los SNARKs son sin necesidad de confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características fundamentales de una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de los tres es la arquitectura Plasma, que utiliza técnicas ingeniosas para transferir la responsabilidad de la disponibilidad de los datos de supervisión a los usuarios de manera compatible con los incentivos. Ya en 2017-2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad de cálculo, Plasma estaba muy limitado en la ejecución segura, pero con la proliferación de SNARKs) pruebas de conocimiento cero concisas y no interactivas(, la arquitectura Plasma se ha vuelto más viable para un rango de escenarios de uso más amplio que nunca.
Avances adicionales en el muestreo de disponibilidad de datos
) ¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se active la actualización Dencun, la cadena de bloques de Ethereum tendrá 3 blobs de aproximadamente 125 kB en cada slot de 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de la transacción se publiquen directamente en la cadena, una transferencia ERC20 ocupa aproximadamente 180 bytes, por lo que el máximo TPS de Rollup en Ethereum será: 375000 / 12 / 180 = 173.6 TPS.
Si agregamos el valor teórico máximo de calldata de Ethereum (: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot ), entonces se convierte en 607 TPS. Usando PeerDAS, el número de blobs podría aumentar a 8-16, lo que proporcionaría 463-926 TPS para calldata.
Esta es una mejora significativa para Ethereum L1, pero no es suficiente. Queremos más escalabilidad. Nuestro objetivo a medio plazo es de 16 MB por slot, lo que, combinado con las mejoras en la compresión de datos de Rollup, traerá ~58000 TPS.
![Vitalik nuevo artículo: Ethereum posible futuro, The Surge]###https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) ¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "1D sampling". En Ethereum, cada blob es un polinomio de 4096 en el campo primo de 253 bits (. Transmitimos las shares del polinomio, donde cada share contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier 4096 ) puede recuperar el blob según los parámetros propuestos: cualquiera de los 64 de 128 posibles muestreos ###.
El funcionamiento de PeerDAS permite que cada cliente escuche una pequeña cantidad de subredes, donde la i-ésima subred transmite la i-ésima muestra de cualquier blob y solicita a los pares en la red p2p global ( quién escuchará diferentes subredes ) para obtener los blobs que necesita en otras subredes. Una versión más conservadora, SubnetDAS, utiliza únicamente el mecanismo de subred sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en el mecanismo de prueba de participación utilicen SubnetDAS, mientras que otros nodos (, es decir, los clientes ), utilicen PeerDAS.
Desde un punto de vista teórico, podemos escalar un "muestreo 1D" bastante grande: si aumentamos el número máximo de blobs a 256( con un objetivo de 128), entonces podemos alcanzar un objetivo de 16 MB, y en el muestreo de disponibilidad de datos, cada nodo tiene 16 muestras * 128 blobs * 512 bytes por cada muestra por cada blob = 1 MB de ancho de banda de datos por slot. Esto apenas está dentro de nuestro margen de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto en cierta medida reduciendo el número de blobs y aumentando el tamaño de los blobs, pero esto aumentará el costo de reconstrucción.
Por lo tanto, finalmente queremos ir un paso más allá, realizando muestreo 2D (2D sampling). Este método no solo realiza muestreo aleatorio dentro del blob, sino también entre blobs. Utilizando la propiedad lineal del compromiso KZG, se expande un conjunto de blobs dentro de un bloque mediante un conjunto de nuevos blobs virtuales, que codifican redundante la misma información.
Por lo tanto, al final queremos ir un paso más allá y realizar un muestreo 2D, que no solo se realiza dentro del blob, sino también entre los blobs de manera aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir el conjunto de blobs dentro de un bloque, que contiene una nueva lista de blobs virtuales que codifican de manera redundante la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera un blob, por lo que este enfoque es fundamentalmente amigable para la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG del blob, 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 esencialmente amigable para la construcción de bloques distribuidos.
( ¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación se completará la implementación y lanzamiento de PeerDAS. Después, se incrementará continuamente la cantidad de blobs en PeerDAS, al mismo tiempo que se observará cuidadosamente la red y se mejorará el software para garantizar la seguridad, lo cual es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajo académico para regular PeerDAS y otras versiones de DAS y su interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, necesitaremos hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa que sea segura contra cuánticos y no requiera un entorno de confianza. Actualmente, no está claro qué candidatos son amigables con la construcción de bloques distribuidos. Incluso el uso de técnicas de "fuerza bruta" costosas, es decir, usar STARK recursivo para generar pruebas de validez para reconstruir filas y columnas, no es suficiente para satisfacer la demanda, ya que, aunque técnicamente el tamaño de un STARK es O)log(n) * log(log)n###( hashes ( usando STIR), en la práctica, el STARK es casi del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que creo que es:
Por favor, ten en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opción también existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo tanto, tendremos que utilizar en la capa L1 las mismas tecnologías que Rollup(, como ZK-EVM y DAS(.
) ¿Cómo interactuar con otras partes de la hoja de ruta?
Si se logra la compresión de datos, la demanda de DAS 2D se reducirá o al menos se retrasará, y si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos para los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica esto requiere combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación circundante.
Compresión de datos
) ¿Qué problema estamos resolviendo?
Cada transacción en un rollup ocupa una gran cantidad de espacio de datos en la cadena: una transferencia de ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo de Layer. Cada slot es de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos resolver no solo los problemas de los numeradores, sino también los de los denominadores, y hacer que cada transacción en los Rollups ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En mi opinión, la mejor explicación es esta imagen de hace dos años:
En la compresión de bytes cero, se reemplaza cada secuencia larga de bytes cero con dos bytes que indican cuántos bytes cero hay. Además, aprovechamos las propiedades específicas de las transacciones:
Agregación de firmas: Hemos cambiado de firmas ECDSA a firmas BLS. La característica de las firmas BLS es que múltiples firmas pueden combinarse en una única firma, y esta firma puede probar la validez de todas las firmas originales. En la capa L1, debido a que incluso con la agregación, el costo computacional de la verificación es alto, por lo que no se considera el uso de firmas BLS.