Nuevo artículo de Vitalik: El futuro posible de Ethereum, The Surge
El mapa de ruta de Ethereum inicialmente incluía dos estrategias de escalado: fragmentación y protocolo Layer2. La fragmentación permite que cada nodo verifique y almacene solo una parte de las transacciones, mientras que Layer2 construye una red sobre Ethereum, aprovechando su seguridad y manteniendo la mayor parte de los datos y cálculos fuera de la cadena principal. A medida que la investigación avanzaba, estos dos caminos se fusionaron, formando un mapa de ruta centrado en Rollup, que hasta hoy sigue siendo la estrategia de escalado de Ethereum.
La hoja de ruta centrada en Rollup propone una simple división del trabajo: Ethereum L1 se enfoca en convertirse en una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es omnipresente en la sociedad: la existencia del sistema judicial (L1) no busca la máxima velocidad y eficiencia, sino proteger contratos y derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta sólida capa base, llevando a la humanidad hacia Marte.
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 Rollups de Ethereum Virtual Machine (EVM) han entrado en la primera fase. Cada L2 existe como un "shard" con sus propias reglas internas y lógica, y la diversidad y pluralidad en la implementación de shards se ha convertido en una realidad. Pero, como hemos visto, seguir 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, manteniendo al mismo tiempo la robustez y descentralización que son características de Ethereum L1.
The Surge: Objetivo 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 fundamentales de Ethereum: ( confianza, apertura, resistencia a la censura );
Ethereum debería sentirse como un ecosistema unificado, y no como 34 blockchains diferentes.
Contenido de este capítulo
La paradoja del triángulo de escalabilidad
Progreso adicional en el muestreo de disponibilidad de datos
Compresión de datos
Plasma Generalizado
Sistema de prueba L2 maduro
Mejora de la interoperabilidad entre L2
Ampliar la ejecución en L1
Paradoja del triángulo de escalabilidad
El triángulo de la escalabilidad es una idea propuesta en 2017, que sostiene que existe 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 (, cantidad de transacciones procesadas ) y seguridad (, donde los atacantes necesitan comprometer una gran parte de los nodos en la red para hacer que una transacción falle ).
Es importante señalar que la paradoja del triángulo no es un teorema, y las publicaciones que introducen la paradoja del triángulo tampoco incluyen pruebas matemáticas. Sin embargo, ofrece un argumento matemático heurístico: si un nodo amigable con la descentralización (, 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 ejecutar 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, tiene como objetivo mostrar que romper la paradoja ternaria es difícil y que requiere, en cierta medida, salir del marco de pensamiento implícito en ese argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que han resuelto 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; 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, incluso descargando solo una pequeña cantidad de datos y realizando una cantidad mínima de cálculos. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características esenciales de una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Una forma alternativa de resolver el dilema de las tres partes 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 una manera compatible con los incentivos. Ya en 2017-2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad computacional, Plasma estaba muy limitado en la ejecución segura, pero con la popularización de los 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.
Progreso adicional 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 por slot cada 12 segundos, o un ancho de banda de datos disponible por slot de aproximadamente 375 kB. Suponiendo que los datos de las transacciones se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo que el TPS máximo 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 de 463 a 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, ofrecerá ~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 grados 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 basado en los parámetros actualmente propuestos: cualquiera de los 64 de 128 muestras posibles (.
El funcionamiento de PeerDAS es hacer 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á las 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 usen SubnetDAS, mientras que otros nodos ), es decir, los clientes (, utilicen PeerDAS.
Teóricamente, 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 muestra por blob = 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, finalmente queremos ir un paso más allá, realizar el 2D sampling )2D sampling (, este método no solo realiza muestreo aleatorio dentro del blob, sino también entre blobs. Aprovechando la propiedad lineal del compromiso KZG, expandimos el conjunto de blobs en un bloque a través de un conjunto de nuevos blobs virtuales, que codifican redundantemente la misma información.
Por lo tanto, al final queremos ir un paso más allá, realizando 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 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 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 del blob, y pueden confiar en la 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 con la construcción de bloques distribuidos.
) ¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación se completa la implementación y el lanzamiento de PeerDAS. Después, se irá aumentando 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 trabajo académico para normar PeerDAS y otras versiones de DAS, así como su interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, necesitamos hacer más trabajo para determinar la versión ideal del 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa que sea cuánticamente segura y no requiera una configuración 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)( hash ( usando STIR), en realidad el STARK es casi del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que pienso es:
Implementar un DAS 2D ideal;
Mantener 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.
Renunciar a DA y aceptar completamente Plasma como nuestra principal arquitectura Layer2 de interés.
Por favor, ten en cuenta que, incluso si decidimos escalar la ejecución directamente en la capa L1, esta opción sigue existiendo. 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 el cliente deseará tener un método eficiente para verificar su corrección, por lo que tendremos que utilizar en la capa L1 la misma tecnología 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 con la reconstrucción distribuida, en la práctica esto debe combinarse con la propuesta de listas de inclusión de paquetes y su mecanismo de selección de bifurcaciones.
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 pudiéramos resolver no solo los problemas de los numeradores, sino también los problemas de los denominadores, y hacer 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 ceros se realiza reemplazando cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos las propiedades específicas de las transacciones:
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.
15 me gusta
Recompensa
15
4
Compartir
Comentar
0/400
CryptoTarotReader
· 07-22 16:59
Esta ola de L2 va a To the moon.
Ver originalesResponder0
NightAirdropper
· 07-22 05:24
El emperador del hígado V vuelve a dibujar BTC.
Ver originalesResponder0
LayerZeroHero
· 07-19 20:54
Los datos no pueden correr, la estrategia de división del trabajo inevitablemente llevará a rollup.
Vitalik interpreta el futuro de Ethereum: la estrategia The Surge y la superación del dilema de la escalabilidad.
Nuevo artículo de Vitalik: El futuro posible de Ethereum, The Surge
El mapa de ruta de Ethereum inicialmente incluía dos estrategias de escalado: fragmentación y protocolo Layer2. La fragmentación permite que cada nodo verifique y almacene solo una parte de las transacciones, mientras que Layer2 construye una red sobre Ethereum, aprovechando su seguridad y manteniendo la mayor parte de los datos y cálculos fuera de la cadena principal. A medida que la investigación avanzaba, estos dos caminos se fusionaron, formando un mapa de ruta centrado en Rollup, que hasta hoy sigue siendo la estrategia de escalado de Ethereum.
La hoja de ruta centrada en Rollup propone una simple división del trabajo: Ethereum L1 se enfoca en convertirse en una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema. Este modelo es omnipresente en la sociedad: la existencia del sistema judicial (L1) no busca la máxima velocidad y eficiencia, sino proteger contratos y derechos de propiedad, mientras que los emprendedores (L2) construyen sobre esta sólida capa base, llevando a la humanidad hacia Marte.
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 Rollups de Ethereum Virtual Machine (EVM) han entrado en la primera fase. Cada L2 existe como un "shard" con sus propias reglas internas y lógica, y la diversidad y pluralidad en la implementación de shards se ha convertido en una realidad. Pero, como hemos visto, seguir 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, manteniendo al mismo tiempo la robustez y descentralización que son características de Ethereum L1.
The Surge: Objetivo 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 fundamentales de Ethereum: ( confianza, apertura, resistencia a la censura );
Ethereum debería sentirse como un ecosistema unificado, y no como 34 blockchains diferentes.
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
El triángulo de la escalabilidad es una idea propuesta en 2017, que sostiene que existe 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 (, cantidad de transacciones procesadas ) y seguridad (, donde los atacantes necesitan comprometer una gran parte de los nodos en la red para hacer que una transacción falle ).
Es importante señalar que la paradoja del triángulo no es un teorema, y las publicaciones que introducen la paradoja del triángulo tampoco incluyen pruebas matemáticas. Sin embargo, ofrece un argumento matemático heurístico: si un nodo amigable con la descentralización (, 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 ejecutar 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, tiene como objetivo mostrar que romper la paradoja ternaria es difícil y que requiere, en cierta medida, salir del marco de pensamiento implícito en ese argumento.
Durante años, algunas cadenas de alto rendimiento han afirmado que han resuelto 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; 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, incluso descargando solo una pequeña cantidad de datos y realizando una cantidad mínima de cálculos. Los SNARKs no requieren confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características esenciales de una cadena no escalable, es decir, incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Una forma alternativa de resolver el dilema de las tres partes 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 una manera compatible con los incentivos. Ya en 2017-2019, cuando solo teníamos la prueba de fraude como medio para expandir la capacidad computacional, Plasma estaba muy limitado en la ejecución segura, pero con la popularización de los 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.
Progreso adicional 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 por slot cada 12 segundos, o un ancho de banda de datos disponible por slot de aproximadamente 375 kB. Suponiendo que los datos de las transacciones se publiquen directamente en la cadena, una transferencia ERC20 es de aproximadamente 180 bytes, por lo que el TPS máximo 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 de 463 a 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, ofrecerá ~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 grados 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 basado en los parámetros actualmente propuestos: cualquiera de los 64 de 128 muestras posibles (.
El funcionamiento de PeerDAS es hacer 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á las 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 usen SubnetDAS, mientras que otros nodos ), es decir, los clientes (, utilicen PeerDAS.
Teóricamente, 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 muestra por blob = 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, finalmente queremos ir un paso más allá, realizar el 2D sampling )2D sampling (, este método no solo realiza muestreo aleatorio dentro del blob, sino también entre blobs. Aprovechando la propiedad lineal del compromiso KZG, expandimos el conjunto de blobs en un bloque a través de un conjunto de nuevos blobs virtuales, que codifican redundantemente la misma información.
Por lo tanto, al final queremos ir un paso más allá, realizando 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 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 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 del blob, y pueden confiar en la 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 con la construcción de bloques distribuidos.
) ¿Qué más se necesita hacer? ¿Cuáles son las compensaciones?
A continuación se completa la implementación y el lanzamiento de PeerDAS. Después, se irá aumentando 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 trabajo académico para normar PeerDAS y otras versiones de DAS, así como su interacción con cuestiones de seguridad como las reglas de selección de bifurcación.
En etapas más avanzadas en el futuro, necesitamos hacer más trabajo para determinar la versión ideal del 2D DAS y demostrar sus propiedades de seguridad. También esperamos poder eventualmente pasar de KZG a una alternativa que sea cuánticamente segura y no requiera una configuración 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)( hash ( usando STIR), en realidad el STARK es casi del mismo tamaño que todo el blob.
El camino de realidad a largo plazo que pienso es:
Por favor, ten en cuenta que, incluso si decidimos escalar la ejecución directamente en la capa L1, esta opción sigue existiendo. 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 el cliente deseará tener un método eficiente para verificar su corrección, por lo que tendremos que utilizar en la capa L1 la misma tecnología 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 con la reconstrucción distribuida, en la práctica esto debe combinarse con la propuesta de listas de inclusión de paquetes y su mecanismo de selección de bifurcaciones.
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 pudiéramos resolver no solo los problemas de los numeradores, sino también los problemas de los denominadores, y hacer 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 ceros se realiza reemplazando cada secuencia larga de ceros con dos bytes que indican cuántos ceros hay. Más allá de eso, aprovechamos las propiedades específicas de las transacciones:
Agregación de firmas: nosotros de ECD