Utilizamos dos métodos de cálculo para evaluar la posible reducción en las tarifas del gas, TPS (transacciones por segundo) y la capacidad de acomodar Rollups después de implementar EIP-4844.
Se estima que cuando el tamaño de Calldata es de 10 KB y 2 KB respectivamente, EIP-4844 puede acomodar más Calldata, desde 38 hasta 192 veces. Dado que se pueden acomodar más Calldata en el mismo bloque, el costo por unidad de Calldata también se reducirá en consecuencia.
Suponiendo que el tamaño de los datos de llamada de cada paquete acumulativo es uniformemente de 2 KB, EIP-4844 solo puede acomodar hasta 384 paquetes acumulativos.
En circunstancias normales (es decir, cuando el bloque alcanza el tamaño objetivo), Ethereum alcanzará 175 TPS a través de EIP-4844, con un máximo de 350.
**Contrariamente a la creencia popular, EIP-4844 por sí solo no es suficiente para que Ethereum mejore significativamente la escalabilidad. **
Utilizar capas DA alternativas (como Celestia) o DAC (como zkPorter), mejorar la tasa de compresión de los datos de transacciones L2 y aumentar la proporción de zk Rollups tendrá un impacto importante en la mejora adicional de la escalabilidad de Ethereum.
Proto-danksharding (también conocido como EIP-4844) propone implementar la mayor parte de la lógica y las reglas que Danksharding puede utilizar en el futuro. Actualmente, debido al alto costo de almacenamiento en L1, la tarifa de transición para L2 también es relativamente alta. Para resolver este problema, EIP-4844 introduce un nuevo tipo de datos Blob, que es más barato y más grande que calldata, lo que proporciona otra forma de almacenamiento de datos acumulativos.
Con el próximo lanzamiento de EIP-4844, los secuenciadores L2 pueden volverse más rentables. Esto se debe a que el secuenciador es responsable de importar lotes de transacciones a L1 y pagar tarifas de datos, y las tarifas de datos L1 pagadas por el secuenciador se reducirán significativamente. Las bajas tarifas de transacción tienen el potencial de generar más MEV al aumentar la cantidad de pedidos en L2.
La actualización de Cancún incluirá EIP-4844, pero aún no hay una hora exacta para la actualización. El equipo de investigación de la Fundación Ethereum declaró que la actualización de Cancún podría lanzarse a finales de octubre. Sin embargo, es más probable que se lance alrededor del primer trimestre de 2024.
**Entonces, ¿hasta qué punto puede EIP-4844 reducir las tarifas de transacción? **Actualmente, las tarifas de transacción L2 constan principalmente de dos partes:
Costo acumulado: El costo de empaquetar, enviar y almacenar una transacción en Ethereum.
Costo de ejecución (ución): El costo de ejecutar una transacción en L2
Tarifa de transacción L2 = Costos acumulados + Costos de operación
= [Precio del gas L1 * (datos de llamada + gastos generales fijos)] + [Precio del gas L2 * Gas L2 utilizado]
Tomando Optimism como ejemplo, actualmente, casi el 80% de las tarifas de transacción totales provienen de los costos de almacenamiento L1 (es decir, los costos de Calldata). Ignoramos el impacto de otras tarifas por ahora y proponemos dos métodos para estimar cuánto se pueden reducir las tarifas de transacción L2 después de EIP-4844.
En EIP-4844, una vez implementada la propuesta, el tamaño de cada Blob es de 128 KB y cada Blob consume 131,072 Gas. Por lo tanto, en promedio cada byte de datos de Blob consumirá 128 * 1024 / 131,072 = 1 Gas. En comparación, almacenar actualmente un solo byte de Calldata consume 16 gases. Esto muestra que el costo de almacenamiento de las transacciones L2 se reducirá 16 veces.
Sin embargo, este método sólo compara el costo de almacenamiento por byte y no considera la capacidad total de Gas del bloque. Dado que la cantidad total de Gas que puede transportar un solo bloque puede cambiar después de EIP-4844, los costos de almacenamiento de transacciones L2 pueden reducirse en más de 16 veces.
El segundo método considera el tamaño del bloque y verifica la cantidad de veces que los datos de llamada actuales se pueden acomodar en diferentes tamaños de bloque. Según los parámetros actuales, en el escenario del tamaño de bloque objetivo, un bloque puede acomodar 3 Blobs (0,375 MB) y un máximo de 6 Blobs (0,75 MB). Teniendo en cuenta que los datos de llamada actuales de cada bloque ocupan entre 2 y 10 KB, después de EIP-4844, puede acomodar hasta 0,75 * 1024/2 = 384 veces de datos de llamada.
Sin embargo, a medida que el tamaño del bloque aumenta desde el valor objetivo hasta el valor máximo, el precio del gas aumenta exponencialmente. Por lo tanto, en el caso más común (es decir, cuando el bloque alcanza el tamaño objetivo), EIP-4844 puede acomodar entre 38 y 192 veces los datos de llamada de 10 KB y 2 KB respectivamente. **A medida que aumenta la capacidad de Calldata dentro del bloque, el costo de almacenamiento de Calldata también disminuirá en consecuencia. Por lo tanto, el coste de las transacciones L2 también se reducirá en consecuencia.
Además, suponiendo que el tamaño de los datos de llamada de cada paquete acumulativo sea uniformemente de 2 KB, EIP-4844 solo puede acomodar hasta 384 paquetes acumulativos. Esto no llega a los miles de resúmenes que mucha gente imaginaba.
En base a esto, también podemos derivar el orden de TPS que Ethereum puede lograr después de EIP-4844. Actualmente, una transacción promedio de L2 requiere aproximadamente 3000 datos de llamadas de gas en L1. Teniendo en cuenta que Calldata tiene un costo de gas de 16 por byte, esto indica que cada transacción L2 en L1 es de aproximadamente 187 bytes.
Después de EIP-4844, el tamaño del bloque objetivo es 0,375 MB y Ethereum genera un bloque cada 12 segundos. Por lo tanto, el espacio disponible por segundo es 0,375 / 12 * 1024 = 32 KB, que puede acomodar 32 * 1024 / 187 = 175 transacciones. Por lo tanto, en circunstancias normales (es decir, cuando el bloque alcanza el tamaño objetivo), el TPS de Ethereum después de la actualización EIP-4844 debería ser 175, con un máximo de 350.
Aunque un TPS más alto puede mejorar la eficiencia, vale la pena señalar que incluso con la implementación de EIP-4844, Ethereum todavía no es tan bueno como Visa, que actualmente tiene un TPS de hasta 1700. Esta brecha aún puede causar congestión en las redes L1 y L2, especialmente en escenarios de alta demanda.
**Por lo tanto, EIP-4844 por sí solo no es suficiente para permitir que Ethereum alcance una mayor escalabilidad. **Aún necesitamos una solución de disponibilidad de datos más rentable y eficiente para almacenar más Calldata (como una capa DA como Celestia o un DAC como zkPorter), que siguen siendo fundamentales para lograr escalabilidad.
Finalmente, la relación de compresión de las transacciones L2 afecta directamente el tamaño de los datos de llamada almacenados en L1. Cuanto mayor sea la relación de compresión, menor será el costo L1 requerido. A medida que zkRollup continúa desarrollándose, la cantidad de datos que deben almacenarse en L1 será cada vez menor, lo que también será más propicio para mejorar la escalabilidad de Ethereum. Debido a que zkRollup es diferente de Optimistic Rollup, zkRollup solo necesita almacenar cambios de estado en lugar de toda la transacción.
en conclusión
En este artículo, utilizamos dos métodos de cálculo diferentes para evaluar las posibles reducciones en las tarifas del gas, TPS (transacciones por segundo) y la capacidad de acomodar acumulaciones después de implementar EIP-4844. Los resultados muestran que, suponiendo que el tamaño de los datos de llamada de cada paquete acumulativo sea uniformemente de 2 KB, EIP-4844 solo puede admitir menos de 400 paquetes acumulativos como máximo. Esto está muy lejos de la demanda de miles de Rollups que muchos esperaban. El uso de capas DA o DAC alternativas, el aumento de la tasa de compresión de los datos de transacciones L2 y el aumento de la proporción de acumulaciones de zk tendrán un impacto significativo en la mejora adicional de la escalabilidad de Ethereum.
Ver originales
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.
Economía acumulativa: se sobreestima el impacto de EIP-4844 en la escalabilidad
Autor: 0xfan, Smarti Lab; Compilador: Peng SUN, Foresight News
TL; DR:
Proto-danksharding (también conocido como EIP-4844) propone implementar la mayor parte de la lógica y las reglas que Danksharding puede utilizar en el futuro. Actualmente, debido al alto costo de almacenamiento en L1, la tarifa de transición para L2 también es relativamente alta. Para resolver este problema, EIP-4844 introduce un nuevo tipo de datos Blob, que es más barato y más grande que calldata, lo que proporciona otra forma de almacenamiento de datos acumulativos.
Con el próximo lanzamiento de EIP-4844, los secuenciadores L2 pueden volverse más rentables. Esto se debe a que el secuenciador es responsable de importar lotes de transacciones a L1 y pagar tarifas de datos, y las tarifas de datos L1 pagadas por el secuenciador se reducirán significativamente. Las bajas tarifas de transacción tienen el potencial de generar más MEV al aumentar la cantidad de pedidos en L2.
La actualización de Cancún incluirá EIP-4844, pero aún no hay una hora exacta para la actualización. El equipo de investigación de la Fundación Ethereum declaró que la actualización de Cancún podría lanzarse a finales de octubre. Sin embargo, es más probable que se lance alrededor del primer trimestre de 2024.
**Entonces, ¿hasta qué punto puede EIP-4844 reducir las tarifas de transacción? **Actualmente, las tarifas de transacción L2 constan principalmente de dos partes:
Tomando Optimism como ejemplo, actualmente, casi el 80% de las tarifas de transacción totales provienen de los costos de almacenamiento L1 (es decir, los costos de Calldata). Ignoramos el impacto de otras tarifas por ahora y proponemos dos métodos para estimar cuánto se pueden reducir las tarifas de transacción L2 después de EIP-4844.
En EIP-4844, una vez implementada la propuesta, el tamaño de cada Blob es de 128 KB y cada Blob consume 131,072 Gas. Por lo tanto, en promedio cada byte de datos de Blob consumirá 128 * 1024 / 131,072 = 1 Gas. En comparación, almacenar actualmente un solo byte de Calldata consume 16 gases. Esto muestra que el costo de almacenamiento de las transacciones L2 se reducirá 16 veces.
Sin embargo, este método sólo compara el costo de almacenamiento por byte y no considera la capacidad total de Gas del bloque. Dado que la cantidad total de Gas que puede transportar un solo bloque puede cambiar después de EIP-4844, los costos de almacenamiento de transacciones L2 pueden reducirse en más de 16 veces.
El segundo método considera el tamaño del bloque y verifica la cantidad de veces que los datos de llamada actuales se pueden acomodar en diferentes tamaños de bloque. Según los parámetros actuales, en el escenario del tamaño de bloque objetivo, un bloque puede acomodar 3 Blobs (0,375 MB) y un máximo de 6 Blobs (0,75 MB). Teniendo en cuenta que los datos de llamada actuales de cada bloque ocupan entre 2 y 10 KB, después de EIP-4844, puede acomodar hasta 0,75 * 1024/2 = 384 veces de datos de llamada.
Sin embargo, a medida que el tamaño del bloque aumenta desde el valor objetivo hasta el valor máximo, el precio del gas aumenta exponencialmente. Por lo tanto, en el caso más común (es decir, cuando el bloque alcanza el tamaño objetivo), EIP-4844 puede acomodar entre 38 y 192 veces los datos de llamada de 10 KB y 2 KB respectivamente. **A medida que aumenta la capacidad de Calldata dentro del bloque, el costo de almacenamiento de Calldata también disminuirá en consecuencia. Por lo tanto, el coste de las transacciones L2 también se reducirá en consecuencia.
Además, suponiendo que el tamaño de los datos de llamada de cada paquete acumulativo sea uniformemente de 2 KB, EIP-4844 solo puede acomodar hasta 384 paquetes acumulativos. Esto no llega a los miles de resúmenes que mucha gente imaginaba.
En base a esto, también podemos derivar el orden de TPS que Ethereum puede lograr después de EIP-4844. Actualmente, una transacción promedio de L2 requiere aproximadamente 3000 datos de llamadas de gas en L1. Teniendo en cuenta que Calldata tiene un costo de gas de 16 por byte, esto indica que cada transacción L2 en L1 es de aproximadamente 187 bytes.
Después de EIP-4844, el tamaño del bloque objetivo es 0,375 MB y Ethereum genera un bloque cada 12 segundos. Por lo tanto, el espacio disponible por segundo es 0,375 / 12 * 1024 = 32 KB, que puede acomodar 32 * 1024 / 187 = 175 transacciones. Por lo tanto, en circunstancias normales (es decir, cuando el bloque alcanza el tamaño objetivo), el TPS de Ethereum después de la actualización EIP-4844 debería ser 175, con un máximo de 350.
Aunque un TPS más alto puede mejorar la eficiencia, vale la pena señalar que incluso con la implementación de EIP-4844, Ethereum todavía no es tan bueno como Visa, que actualmente tiene un TPS de hasta 1700. Esta brecha aún puede causar congestión en las redes L1 y L2, especialmente en escenarios de alta demanda.
**Por lo tanto, EIP-4844 por sí solo no es suficiente para permitir que Ethereum alcance una mayor escalabilidad. **Aún necesitamos una solución de disponibilidad de datos más rentable y eficiente para almacenar más Calldata (como una capa DA como Celestia o un DAC como zkPorter), que siguen siendo fundamentales para lograr escalabilidad.
Finalmente, la relación de compresión de las transacciones L2 afecta directamente el tamaño de los datos de llamada almacenados en L1. Cuanto mayor sea la relación de compresión, menor será el costo L1 requerido. A medida que zkRollup continúa desarrollándose, la cantidad de datos que deben almacenarse en L1 será cada vez menor, lo que también será más propicio para mejorar la escalabilidad de Ethereum. Debido a que zkRollup es diferente de Optimistic Rollup, zkRollup solo necesita almacenar cambios de estado en lugar de toda la transacción.
en conclusión
En este artículo, utilizamos dos métodos de cálculo diferentes para evaluar las posibles reducciones en las tarifas del gas, TPS (transacciones por segundo) y la capacidad de acomodar acumulaciones después de implementar EIP-4844. Los resultados muestran que, suponiendo que el tamaño de los datos de llamada de cada paquete acumulativo sea uniformemente de 2 KB, EIP-4844 solo puede admitir menos de 400 paquetes acumulativos como máximo. Esto está muy lejos de la demanda de miles de Rollups que muchos esperaban. El uso de capas DA o DAC alternativas, el aumento de la tasa de compresión de los datos de transacciones L2 y el aumento de la proporción de acumulaciones de zk tendrán un impacto significativo en la mejora adicional de la escalabilidad de Ethereum.