Nuevo artículo de Vitalik: el 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 vías finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de expansión actual de Ethereum. La hoja de ruta centrada en Rollup propone una división de trabajo simple: 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 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 Rollups de la Máquina Virtual de Ethereum (EVM) 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 en la forma de implementar los fragmentos 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, al mismo tiempo que mantenemos la robustez y descentralización que son propias 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 centrales de Ethereum, (, como la confianza, la apertura y la resistencia a la censura, );
Ethereum debería sentirse como un ecosistema unificado, no como 34 blockchains diferentes.
Contenido de este capítulo
Paradoja del triángulo de escalabilidad
Progreso adicional en el muestreo de disponibilidad de datos
Compresión de datos
Plasma Generalizado
Sistemas de prueba L2 maduros
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 sugiere 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 nodos ), escalabilidad (, gran cantidad de transacciones procesadas ) y seguridad (, donde un atacante necesita comprometer una gran parte de los nodos en la red para hacer que una sola transacción falle ).
Es importante notar que la paradoja triangular no es un teorema, y las publicaciones que introducen la paradoja triangular no incluyen pruebas matemáticas. Sin embargo, presenta un argumento matemático heurístico: si un nodo amigable con la descentralización (, por ejemplo, una computadora portátil de consumo ) 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 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 nunca ha sido demostrar que romper la paradoja triangular es imposible; por el contrario, pretende 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 resuelven el trilema de la escalabilidad sin cambiar fundamentalmente la arquitectura, generalmente optimizando los nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que operar nodos en estas cadenas es mucho más difícil que operar 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 y 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 han ejecutado correctamente, todo esto descargando solo una pequeña cantidad de datos y realizando muy pocos cálculos. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características fundamentales que tiene una cadena no escalable, es decir, que incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de tres difíciles es la arquitectura Plasma, que utiliza técnicas ingeniosas para transferir la responsabilidad de monitorear la disponibilidad de datos a los usuarios de una manera compatible con los incentivos. Desde 2017-2019, cuando solo teníamos pruebas de fraude como medio para escalar la capacidad de cómputo, Plasma tenía limitaciones significativas 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 conjunto 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 cada slot de 12 segundos, o un ancho de banda de datos disponible por slot de aproximadamente 375 kB. 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 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 (: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot ), esto se convierte en 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionaría entre 463 y 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, resultará en ~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 acciones del polinomio, donde cada acción contiene 16 valores evaluados de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores evaluados, cualquier 4096 ) puede restaurar el blob según los parámetros propuestos actualmente: cualquiera de los 64 de los 128 posibles muestreos (.
El principio de 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á diferentes subredes ( para pedir 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 (, usen PeerDAS.
Teóricamente, podemos escalar un "muestreo 1D" a un tamaño bastante grande: si aumentamos el número máximo de blob a 256) con un objetivo de 128(, entonces podemos alcanzar el objetivo de 16MB, y con 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 hará que el costo de reconstrucción sea más alto.
![Vitalik nuevo artículo: El futuro posible de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Por lo tanto, al final queremos ir un paso más allá, realizar muestreo 2D )2D sampling(, este método no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Utilizando la propiedad lineal del compromiso KZG, se expande un conjunto de blobs en un bloque a través de un conjunto de nuevos blobs virtuales, que codifican de manera redundante la misma información.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, que no solo se realiza dentro del blob, sino también entre blobs. La propiedad lineal del compromiso KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que incluye una nueva lista de blobs virtuales que codifican redundantemente 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 con la construcción de bloques distribuidos. Los nodos que realmente construyen los bloques solo necesitan poseer el compromiso KZG del blob, 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? ¿Cuáles son las compensaciones?
A continuación se completará la implementación y lanzamiento de PeerDAS. Después, aumentaremos constantemente la cantidad de blobs en PeerDAS, mientras observamos cuidadosamente la red y mejoramos 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, así como su interacción con problemas de seguridad relacionados con 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 cuánticamente y que no requiera una configuración de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso usando la costosa técnica de "fuerza bruta", es decir, usando STARK recursivos para generar pruebas de validez para la reconstrucción de 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)( valor 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 creo 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 existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques de 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 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 2D DAS se reducirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda se reducirá 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 la lista de inclusión de paquetes y su mecanismo de elecció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 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 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 nuevo artículo: el futuro posible de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
La compresión de bytes cero está en curso, utilizando dos bytes para reemplazar cada larga secuencia de bytes cero, indicando cuántos bytes cero hay. Más allá de eso, aprovechamos las propiedades específicas de la transacción:
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, que puede demostrar 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 es alto, no se considera el uso de firmas BLS. Pero en L2, un entorno con escasez de datos, el uso de firmas BLS tiene sentido. La característica de agregación de ERC-4337 proporciona un camino para implementar esta funcionalidad.
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.
12 me gusta
Recompensa
12
6
Compartir
Comentar
0/400
DeFiGrayling
· 07-27 07:00
Apostar en un gran bull run en L2
Ver originalesResponder0
QuorumVoter
· 07-27 06:59
Mira, son los mismos métodos de siempre.
Ver originalesResponder0
TestnetNomad
· 07-27 06:56
vGod ha salido a hacer de las suyas de nuevo.
Ver originalesResponder0
WenAirdrop
· 07-27 06:50
Otra vez dibujando planes, Vitalik Buterin.
Ver originalesResponder0
WhaleMistaker
· 07-27 06:37
La pista L2 está completamente saturada.
Ver originalesResponder0
PumpDoctrine
· 07-27 06:35
gas no importa si se cambia, eso lo decide el viejo V.
Vitalik sobre el futuro de Ethereum: ¿Cómo logrará The Surge una expansión de 100,000 TPS?
Nuevo artículo de Vitalik: el 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 vías finalmente se fusionaron, formando una hoja de ruta centrada en Rollup, que sigue siendo la estrategia de expansión actual de Ethereum. La hoja de ruta centrada en Rollup propone una división de trabajo simple: 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 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 Rollups de la Máquina Virtual de Ethereum (EVM) 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 en la forma de implementar los fragmentos 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, al mismo tiempo que mantenemos la robustez y descentralización que son propias 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 centrales de Ethereum, (, como la confianza, la apertura y la resistencia a la censura, );
Ethereum debería sentirse como un ecosistema unificado, 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 sugiere 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 nodos ), escalabilidad (, gran cantidad de transacciones procesadas ) y seguridad (, donde un atacante necesita comprometer una gran parte de los nodos en la red para hacer que una sola transacción falle ).
Es importante notar que la paradoja triangular no es un teorema, y las publicaciones que introducen la paradoja triangular no incluyen pruebas matemáticas. Sin embargo, presenta un argumento matemático heurístico: si un nodo amigable con la descentralización (, por ejemplo, una computadora portátil de consumo ) 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 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 nunca ha sido demostrar que romper la paradoja triangular es imposible; por el contrario, pretende 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 resuelven el trilema de la escalabilidad sin cambiar fundamentalmente la arquitectura, generalmente optimizando los nodos mediante técnicas de ingeniería de software. Esto siempre es engañoso, ya que operar nodos en estas cadenas es mucho más difícil que operar 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 y 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 han ejecutado correctamente, todo esto descargando solo una pequeña cantidad de datos y realizando muy pocos cálculos. Los SNARKs son sin confianza. El muestreo de disponibilidad de datos tiene un sutil modelo de confianza de few-of-N, pero conserva las características fundamentales que tiene una cadena no escalable, es decir, que incluso un ataque del 51% no puede forzar que bloques malos sean aceptados por la red.
Otra forma de resolver el dilema de tres difíciles es la arquitectura Plasma, que utiliza técnicas ingeniosas para transferir la responsabilidad de monitorear la disponibilidad de datos a los usuarios de una manera compatible con los incentivos. Desde 2017-2019, cuando solo teníamos pruebas de fraude como medio para escalar la capacidad de cómputo, Plasma tenía limitaciones significativas 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 conjunto 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 cada slot de 12 segundos, o un ancho de banda de datos disponible por slot de aproximadamente 375 kB. 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 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 (: 30 millones de Gas por slot / 16 gas por byte = 1,875,000 bytes por slot ), esto se convierte en 607 TPS. Usando PeerDAS, la cantidad de blobs podría aumentar a 8-16, lo que proporcionaría entre 463 y 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, resultará en ~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 acciones del polinomio, donde cada acción contiene 16 valores evaluados de 16 coordenadas adyacentes de un total de 8192 coordenadas. De estos 8192 valores evaluados, cualquier 4096 ) puede restaurar el blob según los parámetros propuestos actualmente: cualquiera de los 64 de los 128 posibles muestreos (.
El principio de 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á diferentes subredes ( para pedir 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 (, usen PeerDAS.
Teóricamente, podemos escalar un "muestreo 1D" a un tamaño bastante grande: si aumentamos el número máximo de blob a 256) con un objetivo de 128(, entonces podemos alcanzar el objetivo de 16MB, y con 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 hará que el costo de reconstrucción sea más alto.
![Vitalik nuevo artículo: El futuro posible de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Por lo tanto, al final queremos ir un paso más allá, realizar muestreo 2D )2D sampling(, este método no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Utilizando la propiedad lineal del compromiso KZG, se expande un conjunto de blobs en un bloque a través de un conjunto de nuevos blobs virtuales, que codifican de manera redundante la misma información.
Por lo tanto, al final queremos ir un paso más allá y realizar muestreo 2D, que no solo se realiza dentro del blob, sino también entre blobs. La propiedad lineal del compromiso KZG se utiliza para expandir un conjunto de blobs dentro de un bloque, que incluye una nueva lista de blobs virtuales que codifican redundantemente 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 con la construcción de bloques distribuidos. Los nodos que realmente construyen los bloques solo necesitan poseer el compromiso KZG del blob, 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? ¿Cuáles son las compensaciones?
A continuación se completará la implementación y lanzamiento de PeerDAS. Después, aumentaremos constantemente la cantidad de blobs en PeerDAS, mientras observamos cuidadosamente la red y mejoramos 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, así como su interacción con problemas de seguridad relacionados con 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 cuánticamente y que no requiera una configuración de confianza. Actualmente, no está claro qué candidatos son amigables para la construcción de bloques distribuidos. Incluso usando la costosa técnica de "fuerza bruta", es decir, usando STARK recursivos para generar pruebas de validez para la reconstrucción de 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)( valor 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 creo es:
Por favor, tenga 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 de 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 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 2D DAS se reducirá, o al menos se retrasará; si Plasma se utiliza ampliamente, la demanda se reducirá 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 la lista de inclusión de paquetes y su mecanismo de elecció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 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 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 nuevo artículo: el futuro posible de Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
La compresión de bytes cero está en curso, utilizando dos bytes para reemplazar cada larga secuencia de bytes cero, indicando cuántos bytes cero hay. Más allá de eso, aprovechamos las propiedades específicas de la transacción:
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, que puede demostrar 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 es alto, no se considera el uso de firmas BLS. Pero en L2, un entorno con escasez de datos, el uso de firmas BLS tiene sentido. La característica de agregación de ERC-4337 proporciona un camino para implementar esta funcionalidad.
Usar