En la hoja de ruta de Ethereum, inicialmente había dos estrategias de escalabilidad: sharding y protocolos Layer 2. Estas dos vías finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalabilidad de Ethereum hasta hoy. La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se centra en ser una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema.
Este año, la hoja de ruta centrada en Rollup ha logrado resultados importantes: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, 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ógica internas. La diversidad y pluralidad en la implementación de shards se ha convertido en una realidad. Pero este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar la hoja de ruta centrada en Rollup y abordar estos problemas, mientras mantenemos la robustez y 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 de la confianza, la apertura y la resistencia a la censura (;
Ethereum debería sentirse como un ecosistema unificado, y no como 34 blockchains diferentes.
![Vitalik nuevo artículo: el posible futuro de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad sostiene que existe una contradicción entre las tres características de la blockchain: descentralización ), más concretamente: bajo costo de operación de nodos (, escalabilidad ), que implica un gran número de transacciones procesadas (, y seguridad ), donde un atacante necesita comprometer una gran parte de los nodos en la red para que una sola transacción falle (.
Es importante señalar que la paradoja del triángulo no es un teorema, y las publicaciones que presentan la paradoja del triángulo no incluyen pruebas matemáticas. Sin embargo, ofrece un argumento matemático heurístico: si un nodo descentralizado amigable ), por ejemplo, una computadora portátil de consumo ( puede validar N transacciones por segundo, y tienes una cadena que puede procesar 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 realizar una transacción maliciosa, o )ii( tu nodo se volverá poderoso, mientras que tu cadena no se descentralizará. El propósito de este artículo no es demostrar que romper la paradoja del triángulo es imposible; más bien, busca mostrar que romper la paradoja ternaria es difícil y requiere, de alguna manera, salir del marco de pensamiento implicado por el argumento.
A lo largo de los años, algunas cadenas de alto rendimiento han afirmado que resuelven 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 de la muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja triangular: permite a los clientes verificar que una cantidad determinada de datos está disponible y que una cantidad determinada de pasos de cálculo se están ejecutando correctamente, con solo descargar una pequeña cantidad de datos y realizar muy poco cálculo. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un modelo de confianza sutil de few-of-N, pero conserva las características fundamentales que tiene 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 la trilema es la arquitectura Plasma, que utiliza técnicas ingeniosas para trasladar la responsabilidad de la disponibilidad de los datos de monitoreo a los usuarios de una manera compatible con los incentivos. Desde 2017 hasta 2019, cuando solo teníamos pruebas de fraude como medio para expandir la capacidad de cómputo, Plasma estaba muy limitado en la ejecución segura, pero con la popularización de los SNARKs), las pruebas de conocimiento cero concisas y no interactivas(, la arquitectura Plasma se ha vuelto más viable para un rango más amplio de casos de uso que nunca.
![Vitalik nuevo artículo: el posible futuro de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Avances adicionales en el muestreo de disponibilidad de datos
) ¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se implemente la actualización Dencun, la blockchain 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 las transacciones se publiquen directamente en la cadena, una transferencia ERC20 tiene un tamaño de aproximadamente 180 bytes, por lo que el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si añadimos el valor máximo teórico del calldata de Ethereum ###: cada slot 30 millones de Gas / por byte 16 gas = cada slot 1,875,000 bytes (, 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 el 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, y si se combinan con mejoras en la compresión de datos de Rollup, esto llevará a ~58000 TPS.
) ¿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 partes del polinomio, donde cada parte contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier 4096 ( puede recuperar el blob según los parámetros propuestos actualmente: cualquier 64 de los 128 posibles muestreos ).
El funcionamiento de PeerDAS consiste en permitir 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 otros 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 subredes, sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos (, es decir, los clientes ), utilicen PeerDAS.
Teóricamente, podemos escalar un "muestreo 1D" a un tamaño 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 muestra por blob = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro margen de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo el número de blobs y aumentando el tamaño de los blobs, pero eso aumentará el costo de reconstrucción.
Por lo tanto, al final queremos llevarlo un paso más allá, realizando muestreo 2D (2D sampling). Este método no solo realiza muestreo aleatorio dentro de los blobs, sino también entre ellos. Utilizando la propiedad lineal de los compromisos KZG, se expande un conjunto de blobs dentro de un bloque mediante un nuevo conjunto de blobs virtuales, que codifican redundantemente la misma información.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, que no solo se lleva a cabo dentro del blob, sino también entre los blobs mediante muestreo aleatorio. La propiedad lineal de la promesa KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que contiene una nueva lista de blobs virtuales codificados de manera redundante con la misma información.
Es crucial que la expansión de los compromisos de cálculo no requiera blobs, por lo que este esquema es fundamentalmente amigable con la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de blobs, y pueden confiar en la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos. La muestreo de disponibilidad de datos unidimensional (1D DAS) también es esencialmente amigable con la construcción de bloques distribuidos.
( ¿Qué más se necesita hacer? ¿Qué consideraciones hay?
A continuación se encuentra la implementación y lanzamiento de PeerDAS. Después, se aumentará continuamente el número de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, este es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajos académicos para regular PeerDAS y otras versiones de DAS y su interacción con problemas de seguridad como las reglas de selección de bifurcaciones.
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 que no requiera un entorno de confianza. Actualmente, no está claro qué candidatos son amigables con la construcción de bloques distribuidos. Incluso utilizando técnicas de "fuerza bruta" costosas, es decir, utilizando STARK recursivos 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() el hash ( usando STIR(, pero en realidad, el STARK es casi del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que considero es:
Implementar un DAS 2D ideal;
Seguir utilizando 1D DAS, sacrificando la eficiencia del ancho de banda de muestreo, aceptando un límite de datos más bajo por simplicidad y robustez.
Abandonar DA y aceptar completamente Plasma como nuestra principal arquitectura Layer2 de interés.
Por favor, tenga 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 usar en la capa L1 las mismas tecnologías que Rollup) como ZK-EVM y DAS).
( ¿Cómo interactuar con otras partes del mapa de ruta?
Si se implementa la compresión de datos, la demanda de DAS 2D disminuirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también presenta desafíos para los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable para la reconstrucción distribuida, en la práctica esto debe combinarse con las propuestas de listas de inclusión de paquetes y los mecanismos de selección de bifurcación que las rodean.
![Vitalik nuevo artículo: Ethereum posible futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
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 ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo Layer. Cada slot es de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si no solo pudiéramos resolver el problema del numerador, sino también el problema del denominador, haciendo que cada transacción en un Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En mi opinión, la mejor explicación es esta imagen de hace dos años:
La compresión de bytes cero está en curso, utilizando dos bytes para reemplazar cada secuencia larga de bytes cero, indicando cuántos bytes cero hay. Más allá de eso, hemos aprovechado 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, la cual 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 verificación sigue siendo alto, por lo que no se considera el uso de firmas BLS. Pero en un entorno L2 donde los datos son escasos, tiene sentido usar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para lograr esta funcionalidad.
Reemplazar direcciones con punteros: Si se ha utilizado una dirección anteriormente, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunte a una ubicación en el historial.
Secuencia personalizada del valor de la transacción
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
19 me gusta
Recompensa
19
9
Compartir
Comentar
0/400
HashBard
· 07-19 15:02
ser... rollups son como poesía en movimiento fr fr. alcista en esta Subida repentina narrativa ngl
Ethereum The Surge: Estrategia de escalado centrada en Rollup
El futuro posible de Ethereum: The Surge
En la hoja de ruta de Ethereum, inicialmente había dos estrategias de escalabilidad: sharding y protocolos Layer 2. Estas dos vías finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de escalabilidad de Ethereum hasta hoy. La hoja de ruta centrada en Rollup propone una división de trabajo simple: Ethereum L1 se centra en ser una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a escalar el ecosistema.
Este año, la hoja de ruta centrada en Rollup ha logrado resultados importantes: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, 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ógica internas. La diversidad y pluralidad en la implementación de shards se ha convertido en una realidad. Pero este camino también enfrenta algunos desafíos únicos. Nuestra tarea ahora es completar la hoja de ruta centrada en Rollup y abordar estos problemas, mientras mantenemos la robustez y 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 de la confianza, la apertura y la resistencia a la censura (;
Ethereum debería sentirse como un ecosistema unificado, y no como 34 blockchains diferentes.
![Vitalik nuevo artículo: el posible futuro de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(
Paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad sostiene que existe una contradicción entre las tres características de la blockchain: descentralización ), más concretamente: bajo costo de operación de nodos (, escalabilidad ), que implica un gran número de transacciones procesadas (, y seguridad ), donde un atacante necesita comprometer una gran parte de los nodos en la red para que una sola transacción falle (.
Es importante señalar que la paradoja del triángulo no es un teorema, y las publicaciones que presentan la paradoja del triángulo no incluyen pruebas matemáticas. Sin embargo, ofrece un argumento matemático heurístico: si un nodo descentralizado amigable ), por ejemplo, una computadora portátil de consumo ( puede validar N transacciones por segundo, y tienes una cadena que puede procesar 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 realizar una transacción maliciosa, o )ii( tu nodo se volverá poderoso, mientras que tu cadena no se descentralizará. El propósito de este artículo no es demostrar que romper la paradoja del triángulo es imposible; más bien, busca mostrar que romper la paradoja ternaria es difícil y requiere, de alguna manera, salir del marco de pensamiento implicado por el argumento.
A lo largo de los años, algunas cadenas de alto rendimiento han afirmado que resuelven 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 de la muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja triangular: permite a los clientes verificar que una cantidad determinada de datos está disponible y que una cantidad determinada de pasos de cálculo se están ejecutando correctamente, con solo descargar una pequeña cantidad de datos y realizar muy poco cálculo. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un modelo de confianza sutil de few-of-N, pero conserva las características fundamentales que tiene 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 la trilema es la arquitectura Plasma, que utiliza técnicas ingeniosas para trasladar la responsabilidad de la disponibilidad de los datos de monitoreo a los usuarios de una manera compatible con los incentivos. Desde 2017 hasta 2019, cuando solo teníamos pruebas de fraude como medio para expandir la capacidad de cómputo, Plasma estaba muy limitado en la ejecución segura, pero con la popularización de los SNARKs), las pruebas de conocimiento cero concisas y no interactivas(, la arquitectura Plasma se ha vuelto más viable para un rango más amplio de casos de uso que nunca.
![Vitalik nuevo artículo: el posible futuro de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Avances adicionales en el muestreo de disponibilidad de datos
) ¿Qué problema estamos resolviendo?
El 13 de marzo de 2024, cuando se implemente la actualización Dencun, la blockchain 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 las transacciones se publiquen directamente en la cadena, una transferencia ERC20 tiene un tamaño de aproximadamente 180 bytes, por lo que el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS.
Si añadimos el valor máximo teórico del calldata de Ethereum ###: cada slot 30 millones de Gas / por byte 16 gas = cada slot 1,875,000 bytes (, 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 el 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, y si se combinan con mejoras en la compresión de datos de Rollup, esto llevará a ~58000 TPS.
) ¿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 partes del polinomio, donde cada parte contiene 16 valores de evaluación de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores de evaluación, cualquier 4096 ( puede recuperar el blob según los parámetros propuestos actualmente: cualquier 64 de los 128 posibles muestreos ).
El funcionamiento de PeerDAS consiste en permitir 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 otros 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 subredes, sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos (, es decir, los clientes ), utilicen PeerDAS.
Teóricamente, podemos escalar un "muestreo 1D" a un tamaño 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 muestra por blob = 1 MB de ancho de banda de datos por slot. Esto está apenas dentro de nuestro margen de tolerancia: es factible, pero significa que los clientes con ancho de banda limitado no pueden muestrear. Podemos optimizar esto hasta cierto punto reduciendo el número de blobs y aumentando el tamaño de los blobs, pero eso aumentará el costo de reconstrucción.
Por lo tanto, al final queremos llevarlo un paso más allá, realizando muestreo 2D (2D sampling). Este método no solo realiza muestreo aleatorio dentro de los blobs, sino también entre ellos. Utilizando la propiedad lineal de los compromisos KZG, se expande un conjunto de blobs dentro de un bloque mediante un nuevo conjunto de blobs virtuales, que codifican redundantemente la misma información.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, que no solo se lleva a cabo dentro del blob, sino también entre los blobs mediante muestreo aleatorio. La propiedad lineal de la promesa KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que contiene una nueva lista de blobs virtuales codificados de manera redundante con la misma información.
Es crucial que la expansión de los compromisos de cálculo no requiera blobs, por lo que este esquema es fundamentalmente amigable con la construcción de bloques distribuidos. Los nodos que realmente construyen bloques solo necesitan tener el compromiso KZG de blobs, y pueden confiar en la muestreo de disponibilidad de datos (DAS) para verificar la disponibilidad de los bloques de datos. La muestreo de disponibilidad de datos unidimensional (1D DAS) también es esencialmente amigable con la construcción de bloques distribuidos.
( ¿Qué más se necesita hacer? ¿Qué consideraciones hay?
A continuación se encuentra la implementación y lanzamiento de PeerDAS. Después, se aumentará continuamente el número de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, este es un proceso gradual. Al mismo tiempo, esperamos que haya más trabajos académicos para regular PeerDAS y otras versiones de DAS y su interacción con problemas de seguridad como las reglas de selección de bifurcaciones.
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 que no requiera un entorno de confianza. Actualmente, no está claro qué candidatos son amigables con la construcción de bloques distribuidos. Incluso utilizando técnicas de "fuerza bruta" costosas, es decir, utilizando STARK recursivos 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() el hash ( usando STIR(, pero en realidad, el STARK es casi del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que considero es:
Por favor, tenga 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 usar en la capa L1 las mismas tecnologías que Rollup) como ZK-EVM y DAS).
( ¿Cómo interactuar con otras partes del mapa de ruta?
Si se implementa la compresión de datos, la demanda de DAS 2D disminuirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también presenta desafíos para los protocolos y mecanismos de construcción de bloques distribuidos: aunque DAS es teóricamente amigable para la reconstrucción distribuida, en la práctica esto debe combinarse con las propuestas de listas de inclusión de paquetes y los mecanismos de selección de bifurcación que las rodean.
![Vitalik nuevo artículo: Ethereum posible futuro, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
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 ERC20 requiere aproximadamente 180 bytes. Incluso con un muestreo de disponibilidad de datos ideal, esto limita la escalabilidad del protocolo Layer. Cada slot es de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si no solo pudiéramos resolver el problema del numerador, sino también el problema del denominador, haciendo que cada transacción en un Rollup ocupe menos bytes en la cadena?
¿Qué es y cómo funciona?
En mi opinión, la mejor explicación es esta imagen de hace dos años:
La compresión de bytes cero está en curso, utilizando dos bytes para reemplazar cada secuencia larga de bytes cero, indicando cuántos bytes cero hay. Más allá de eso, hemos aprovechado 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, la cual 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 verificación sigue siendo alto, por lo que no se considera el uso de firmas BLS. Pero en un entorno L2 donde los datos son escasos, tiene sentido usar firmas BLS. La característica de agregación de ERC-4337 proporciona un camino para lograr esta funcionalidad.
Reemplazar direcciones con punteros: Si se ha utilizado una dirección anteriormente, podemos reemplazar la dirección de 20 bytes por un puntero de 4 bytes que apunte a una ubicación en el historial.
Secuencia personalizada del valor de la transacción