La hoja de ruta de Ethereum originalmente incluía dos estrategias de escalado: fragmentación y protocolos Layer2. Estos dos caminos 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 ser una capa base potente y descentralizada, mientras que L2 asume la tarea de ayudar a la expansión del ecosistema. Este modelo es omnipresente en la sociedad: la existencia del sistema judicial (L1) no es para perseguir la super velocidad y eficiencia, sino para proteger los contratos y los derechos de propiedad, mientras que los emprendedores (L2) deben construir sobre esta sólida capa base, llevando a la humanidad hacia Marte.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: 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 "fragmento" con sus propias reglas y lógica internas, y la diversidad y pluralidad de las formas de implementación de los fragmentos se ha convertido en una realidad. Pero, como hemos visto, 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 descentralización que son 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: ( confianza, apertura, resistencia a la censura );
Ethereum debería sentirse como un ecosistema unificado, no como 34 cadenas de bloques diferentes.
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
Avances adicionales en el muestreo de disponibilidad de datos
Compresión de datos
Plasma Generalizado
Sistema de prueba L2 maduro
Mejora de la interoperabilidad entre L2
Escalado de ejecución en L1
La paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad es una idea propuesta en 2017, que sostiene que hay una contradicción entre las tres características de la blockchain: descentralización (, más específicamente: bajo costo de operación de los nodos ), escalabilidad (, que maneja un gran número de transacciones ) y seguridad (, donde un atacante necesita comprometer una gran parte de los nodos en la red para hacer que una única transacción falle ).
Es importante notar que la paradoja triangular no es un teorema, y las publicaciones que introducen la paradoja triangular tampoco incluyen una prueba matemática. Sin embargo, presenta un argumento matemático heurístico: si un nodo amigable con la descentralización (, por ejemplo, una laptop 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 llevar a cabo una transacción maliciosa, o (ii) tu nodo se volverá poderoso, mientras que tu cadena no estará descentralizada. El propósito de este artículo no es demostrar que romper la paradoja triangular es imposible; por el contrario, tiene como objetivo mostrar que romper la paradoja ternaria es difícil y que requiere, de alguna manera, salir del marco de pensamiento implícito en ese argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, a menudo 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 muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja triangular: 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, con solo descargar una pequeña cantidad de datos y realizar un número muy limitado de cálculos. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza few-of-N, pero conserva las características básicas de una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar a que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de las tres dificultades es la arquitectura Plasma, que utiliza técnicas ingeniosas para trasladar la responsabilidad de supervisar la disponibilidad de los datos a los usuarios de manera compatible con los incentivos. Desde 2017 hasta 2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad computacional, Plasma tenía limitaciones significativas en la ejecución segura, pero con la popularización de SNARKs( pruebas de conocimiento cero concisas e interactivas), la arquitectura Plasma se vuelve más viable para un rango de casos 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 blockchain de Ethereum tendrá 3 blobs de aproximadamente 125 kB por slot cada 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de transacción se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS
Si añadimos el valor máximo teórico de calldata de Ethereum (: cada slot 30 millones de Gas / cada byte 16 gas = cada slot 1,875,000 bytes ), esto se convierte en 607 TPS. Usando PeerDAS, la cantidad 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.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "muestreo 1D". 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 en 16 coordenadas adyacentes de un total de 8192 coordenadas. En estos 8192 valores de evaluación, cualquier 4096 de ) se puede recuperar el blob según los parámetros propuestos actualmente: cualquier 64 de 128 posibles muestras (.
![Vitalik nuevo artículo: El futuro posible de Ethereum, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(
El funcionamiento de PeerDAS es 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 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 un mecanismo de subred sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos ), es decir, los clientes (, utilicen PeerDAS.
Desde un punto de vista teórico, podemos escalar una "muestra 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 el objetivo de 16MB, donde en la muestra de disponibilidad de datos cada nodo tiene 16 muestras * 128 blobs * 512 bytes por blob por muestra = 1 MB de ancho de banda de datos por slot. Esto apenas está dentro de nuestro rango 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 esto aumentará el costo de reconstrucción.
Por lo tanto, en última instancia, queremos ir más allá y realizar una 2D sampling), este método no solo realiza muestreo aleatorio dentro del blob, sino también entre blobs. Utilizando la propiedad lineal de la promesa KZG, se expande un conjunto de blobs en un bloque mediante un conjunto de nuevos blobs virtuales, que codifican redundante la misma información.
Por lo tanto, en última instancia, queremos ir un paso más allá y realizar muestreo 2D, que no solo se realiza dentro del blob, sino también entre blobs de forma aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir el conjunto de blobs en un bloque, que contiene una nueva lista de blobs virtuales con codificación redundante de la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera un blob, por lo tanto, esta propuesta 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 depender de 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 inherentemente amigable para la construcción de bloques distribuidos.
( ¿Qué más se necesita hacer? ¿Cuáles son las consideraciones?
A continuación se completará la implementación y el lanzamiento de PeerDAS. Después, se aumentará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, este es un proceso progresivo. Al mismo tiempo, esperamos más trabajos académicos para regular PeerDAS y otras versiones de DAS y su interacción con cuestiones 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ántica y que no requiera un entorno de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso con tecnologías 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() hash ( usando STIR(, en realidad, el STARK es casi del tamaño de todo el blob.
El camino de realidad a largo plazo que pienso es:
Implementar un DAS 2D ideal;
Persistir en el uso de 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 enfoque.
Por favor, ten en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opció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 logra la compresión de datos, la demanda de DAS 2D se reducirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos a los protocolos y mecanismos de construcción de bloques distribuidos: aunque el DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica esto necesita combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación asociado.
Compresión de datos
) ¿Qué problema estamos resolviendo?
Cada transacción en un Rollup ocupará 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 de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos no solo resolver el problema de los numeradores, sino también el de los denominadores, haciendo que cada transacción en el 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:
 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.
13 me gusta
Recompensa
13
6
Compartir
Comentar
0/400
DeFiVeteran
· 08-03 08:54
La pista L2 entra en el período de emprender un esfuerzo decidido.
Ver originalesResponder0
SquidTeacher
· 08-02 08:18
Hay mucho trabajo en L2...
Ver originalesResponder0
DevChive
· 08-02 08:12
No se puede aprovechar la oportunidad, hay que pagar para seguir vivo.
Ver originalesResponder0
GraphGuru
· 08-02 08:06
El ecosistema L2 está despegando, BTC sigue en caída
Ver originalesResponder0
ZKProofEnthusiast
· 08-02 08:00
el gas va a subir
Ver originalesResponder0
MidsommarWallet
· 08-02 07:57
L2 por más grande que sea, todavía tiene que trabajar para L1.
Ethereum The Surge: 100,000 TPS, L2 hereda propiedades centrales, visión de un ecosistema unificado
El futuro de Ethereum: The Surge
La hoja de ruta de Ethereum originalmente incluía dos estrategias de escalado: fragmentación y protocolos Layer2. Estos dos caminos 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 ser una capa base potente y descentralizada, mientras que L2 asume la tarea de ayudar a la expansión del ecosistema. Este modelo es omnipresente en la sociedad: la existencia del sistema judicial (L1) no es para perseguir la super velocidad y eficiencia, sino para proteger los contratos y los derechos de propiedad, mientras que los emprendedores (L2) deben construir sobre esta sólida capa base, llevando a la humanidad hacia Marte.
Este año, la hoja de ruta centrada en Rollup ha logrado importantes resultados: 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 "fragmento" con sus propias reglas y lógica internas, y la diversidad y pluralidad de las formas de implementación de los fragmentos se ha convertido en una realidad. Pero, como hemos visto, 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 descentralización que son 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: ( confianza, apertura, resistencia a la censura );
Ethereum debería sentirse como un ecosistema unificado, no como 34 cadenas de bloques diferentes.
Contenido de este capítulo
La paradoja del triángulo de escalabilidad
La paradoja del triángulo de escalabilidad es una idea propuesta en 2017, que sostiene que hay una contradicción entre las tres características de la blockchain: descentralización (, más específicamente: bajo costo de operación de los nodos ), escalabilidad (, que maneja un gran número de transacciones ) y seguridad (, donde un atacante necesita comprometer una gran parte de los nodos en la red para hacer que una única transacción falle ).
Es importante notar que la paradoja triangular no es un teorema, y las publicaciones que introducen la paradoja triangular tampoco incluyen una prueba matemática. Sin embargo, presenta un argumento matemático heurístico: si un nodo amigable con la descentralización (, por ejemplo, una laptop 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 llevar a cabo una transacción maliciosa, o (ii) tu nodo se volverá poderoso, mientras que tu cadena no estará descentralizada. El propósito de este artículo no es demostrar que romper la paradoja triangular es imposible; por el contrario, tiene como objetivo mostrar que romper la paradoja ternaria es difícil y que requiere, de alguna manera, salir del marco de pensamiento implícito en ese argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que resuelven el trilema sin cambiar fundamentalmente la arquitectura, a menudo 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 muestreo de disponibilidad de datos con SNARKs realmente resuelve la paradoja triangular: 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, con solo descargar una pequeña cantidad de datos y realizar un número muy limitado de cálculos. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza few-of-N, pero conserva las características básicas de una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar a que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de las tres dificultades es la arquitectura Plasma, que utiliza técnicas ingeniosas para trasladar la responsabilidad de supervisar la disponibilidad de los datos a los usuarios de manera compatible con los incentivos. Desde 2017 hasta 2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad computacional, Plasma tenía limitaciones significativas en la ejecución segura, pero con la popularización de SNARKs( pruebas de conocimiento cero concisas e interactivas), la arquitectura Plasma se vuelve más viable para un rango de casos 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 blockchain de Ethereum tendrá 3 blobs de aproximadamente 125 kB por slot cada 12 segundos, o un ancho de banda de datos disponible de aproximadamente 375 kB por slot. Suponiendo que los datos de transacción se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo tanto, el máximo TPS de Rollup en Ethereum es: 375000 / 12 / 180 = 173.6 TPS
Si añadimos el valor máximo teórico de calldata de Ethereum (: cada slot 30 millones de Gas / cada byte 16 gas = cada slot 1,875,000 bytes ), esto se convierte en 607 TPS. Usando PeerDAS, la cantidad 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.
¿Qué es? ¿Cómo funciona?
PeerDAS es una implementación relativamente simple de "muestreo 1D". 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 en 16 coordenadas adyacentes de un total de 8192 coordenadas. En estos 8192 valores de evaluación, cualquier 4096 de ) se puede recuperar el blob según los parámetros propuestos actualmente: cualquier 64 de 128 posibles muestras (.
![Vitalik nuevo artículo: El futuro posible de Ethereum, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(
El funcionamiento de PeerDAS es 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 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 un mecanismo de subred sin consultas adicionales a la capa de pares. La propuesta actual es que los nodos que participan en la prueba de participación utilicen SubnetDAS, mientras que otros nodos ), es decir, los clientes (, utilicen PeerDAS.
Desde un punto de vista teórico, podemos escalar una "muestra 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 el objetivo de 16MB, donde en la muestra de disponibilidad de datos cada nodo tiene 16 muestras * 128 blobs * 512 bytes por blob por muestra = 1 MB de ancho de banda de datos por slot. Esto apenas está dentro de nuestro rango 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 esto aumentará el costo de reconstrucción.
Por lo tanto, en última instancia, queremos ir más allá y realizar una 2D sampling), este método no solo realiza muestreo aleatorio dentro del blob, sino también entre blobs. Utilizando la propiedad lineal de la promesa KZG, se expande un conjunto de blobs en un bloque mediante un conjunto de nuevos blobs virtuales, que codifican redundante la misma información.
Por lo tanto, en última instancia, queremos ir un paso más allá y realizar muestreo 2D, que no solo se realiza dentro del blob, sino también entre blobs de forma aleatoria. La propiedad lineal del compromiso KZG se utiliza para expandir el conjunto de blobs en un bloque, que contiene una nueva lista de blobs virtuales con codificación redundante de la misma información.
Es crucial que la expansión del compromiso de cálculo no requiera un blob, por lo tanto, esta propuesta 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 depender de 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 inherentemente amigable para la construcción de bloques distribuidos.
( ¿Qué más se necesita hacer? ¿Cuáles son las consideraciones?
A continuación se completará la implementación y el lanzamiento de PeerDAS. Después, se aumentará continuamente la cantidad de blobs en PeerDAS, mientras se observa cuidadosamente la red y se mejora el software para garantizar la seguridad, este es un proceso progresivo. Al mismo tiempo, esperamos más trabajos académicos para regular PeerDAS y otras versiones de DAS y su interacción con cuestiones 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ántica y que no requiera un entorno de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso con tecnologías 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() hash ( usando STIR(, en realidad, el STARK es casi del tamaño de todo el blob.
El camino de realidad a largo plazo que pienso es:
Por favor, ten en cuenta que, incluso si decidimos expandir la ejecución directamente en la capa L1, esta opció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 logra la compresión de datos, la demanda de DAS 2D se reducirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda disminuirá aún más. DAS también plantea desafíos a los protocolos y mecanismos de construcción de bloques distribuidos: aunque el DAS es teóricamente amigable con la reconstrucción distribuida, en la práctica esto necesita combinarse con la propuesta de lista de inclusión de paquetes y su mecanismo de selección de bifurcación asociado.
Compresión de datos
) ¿Qué problema estamos resolviendo?
Cada transacción en un Rollup ocupará 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 de 16 MB, obtenemos:
16000000 / 12 / 180 = 7407 TPS
¿Qué pasaría si pudiéramos no solo resolver el problema de los numeradores, sino también el de los denominadores, haciendo que cada transacción en el 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:
![Vitalik nueva publicación: Ethereum posible futuro, The Surge](