Análisis profundo de la era posterior a la actualización de Cancún: perspectiva de datos e inversión
Introducción
Desde que Ethereum se lanzó oficialmente el 30 de julio de 2015, ha tenido un historial de 12 actualizaciones, cada una de las cuales ha sido muy destacada.
La principal objetivo de la actualización de Ethereum Cancún-Deneb ( Dencun ) es mejorar la escalabilidad y modularidad de la red Layer 2, fortalecer las capacidades de seguridad de la red Ethereum y mejorar la usabilidad general.
1. ¿Qué es la actualización Dencun?
1.1 Introducción a la actualización
1.1.1 Origen del nombre
La capa base de Ethereum se compone de dos partes combinadas: la capa de ejecución y la capa de consenso, y cada parte tiene diferentes reglas de nomenclatura.
La regla de nomenclatura de las actualizaciones de la capa de ejecución ha sido nombrada desde 2021 por las ciudades que albergan Devcon (la conferencia de desarrolladores de Ethereum). Por ejemplo, actualización de Berlín, actualización de Londres, actualización de Shanghái, etc.
La regla de nomenclatura de las actualizaciones de la capa de consenso se basa en nombres de cuerpos celestes desde el lanzamiento de la cadena de referencia, siguiendo el orden alfabético. Por ejemplo, Altair (牵牛星), Bellatrix (参宿五), Capella (五车二), etc.
El nombre de cada actualización de Ethereum se forma combinando diferentes nombres de actualizaciones. Dado que este Devcon se celebra en Cancún, México, y la actualización de la capa de consenso se llama Deneb, esta actualización de Ethereum se abrevia como Dencun.
1.1.2 Antecedentes de la actualización
El contexto de la actualización de Dencun se basa en una planificación a largo plazo desarrollada sobre Ethereum, y un núcleo fundamental es mejorar la experiencia de Ethereum, logrando finalmente un ecosistema sin permisos, descentralizado, resistente a la censura y de código abierto.
Por un lado, a través del mapa de planificación publicado por el fundador de Ethereum, Vitalik Buterin, el 31 de diciembre de 2023, se puede ver que la actualización Dencun corresponde a la parte de The surge, comenzando con la experiencia del usuario como prioridad (por ejemplo, aumentando la velocidad de las transacciones y reduciendo las tarifas de Gas), con el objetivo de mejorar la eficiencia de la red, reducir los costos de transacción y sentar una base sólida para el desarrollo futuro.
Por otro lado, del artículo de Vitalik Buterin publicado el 28 de diciembre de 2023 titulado "Make Ethereum Cypherpunk Again", se puede entender que Vitalik considera que una de las razones principales que está llevando a que la blockchain se limite cada vez más a la especulación de activos es el aumento de las tarifas de transacción, lo que ha convertido a los Degen Gamblers en un grupo dominante, lo que es perjudicial para la realización del valor de aplicación de la blockchain, por lo que es necesario reducir las tarifas de transacción.
1.1.3 Tiempo de actualización
Según la planificación de Ethereum, la información sobre el tiempo de actualización y activación es:
Altura del bloque de actualización de la capa de ejecución: 18,963,249
Época de la capa de consenso: 269,568
Hora estimada: 13 de marzo de 2024 (hora UTC)
1.1.4 Contenido relacionado
Las actualizaciones de Ethereum Cancun-Deneb han realizado una serie de mejoras tanto en la capa de ejecución (EL) como en la capa de consenso (CL). Cancun ha mejorado la capa de ejecución, mientras que Deneb ha reforzado la capa de consenso, incorporando una serie de EIP (Propuestas de Mejora de Ethereum) que son fundamentales para el desarrollo de la red de Ethereum. Hay un total de 9 EIP, y presentaremos las EIP clave en las próximas secciones.
1.2 Enfoques clave de la actualización Dencun
1.2.1 EIP-4844 Transacciones de Blob de fragmentación (Proto-Danksharding)
EIP-4844 es el principal atractivo de esta actualización, que tiene como objetivo reducir las tarifas de transacción, aumentar el rendimiento de las transacciones por segundo (TPS) y la escalabilidad. Su esencia es una actualización transitoria para preparar el futuro, con el fin de lograr un Danksharding completo (la última parte de la actualización "Serena" de Ethereum), donde el Proto-Danksharding sienta las bases para el Danksharding.
La disponibilidad de datos en la cadena principal de Ethereum se proporciona a través de Calldata (que se puede entender como los datos generados en las llamadas de transacciones de contratos), y los datos que Layer 2 devuelve a Layer 1 se almacenan en Calldata. Además, para mayor seguridad, cada paso de ejecución de Calldata requiere Gas, lo que genera una situación de altos costos de Gas. Sin embargo, una vez que se verifica la transacción en Calldata, en realidad no tiene mucha utilidad, ya que los datos a largo plazo también se pueden descargar y verificar, e incluso no es necesario enviarlos a la capa de ejecución. Como ejemplo de la composición histórica de los costos de transacción promedio de la cadena Layer2-OP, se puede observar que cerca del 80% de los costos provienen de los costos de datos de L1.
Por lo tanto, EIP-4844 introduce una nueva estructura de almacenamiento de datos: Blob, diseñada específicamente para almacenar los datos de transacciones enviadas de L2 a L1. Después de su introducción, los datos de transacciones de L2 se envían directamente al Blob para su almacenamiento, disponible para su descarga completa por parte de los nodos de consenso, y se pueden eliminar después de un breve retraso, reduciendo la carga de almacenamiento innecesaria. Esto significa que la introducción de Blob reducirá drásticamente las tarifas de transacción de L2. Al mismo tiempo, Blob también expande el espacio de bloques para L2, y la capacidad de procesamiento de transacciones de L2 también aumentará significativamente.
1.2.2 EIP-1153 Código de operación de almacenamiento transitorio
El objetivo principal de EIP-1153 es ahorrar espacio de almacenamiento y costos de almacenamiento. El almacenamiento transitorio se descarta después de cada transacción, por lo que el almacenamiento temporal es más barato, ya que no requiere acceso al disco.
EIP-1153 es más amigable para los desarrolladores de Dapp, introduciendo nuevos códigos de operación TSTORE y TLOAD en el EVM, cuyo costo de Gas al invocar estos códigos es de aproximadamente 100 Gas cada uno, un 95% más barato que las llamadas de almacenamiento tradicionales (SLOAD y SSTORE). Al mismo tiempo, una vez que se completa la ejecución de la transacción, esa parte del almacenamiento se elimina, lo que reduce el costo de almacenamiento y el consumo de Gas, lo que podría hacer que los nuevos contratos DeFi sean más ahorradores en Gas en el futuro.
1.2.3 EIP-4788 Raíz del bloque de baliza en EVM
EIP-4788 permitirá la comunicación entre la EVM (máquina virtual de Ethereum) y la cadena de balizas (Beacon). Esta función admite varios casos de uso, puede mejorar los grupos de participación (staking pools), las construcciones de re-staking (restaking constructions), los puentes de contratos inteligentes (smart contract bridges), MEV, etc.
Anteriormente, el EVM no podía acceder directamente a los datos y estados del Beacon, solo podía capturar el estado a través de oráculos externos confiables. Por lo tanto, se propuso colocar una raíz de bloque padre del Beacon (parent_beacon_block_root) en cada bloque del EVM, de modo que cuando el Beacon se actualizara, el EVM pudiera obtener información precisa de inmediato.
La raíz del bloque de señal padre se almacenará en un búfer circular, conservándose durante aproximadamente un día. Una vez que una nueva raíz de bloque de señal padre ingrese y la capacidad del búfer alcance un valor crítico, la raíz de bloque de señal padre más antigua será reemplazada, logrando así un almacenamiento de consenso eficiente y limitado. De esta manera, se logra la comunicación de una manera que minimiza la confianza, además de eliminar fallos de oráculos externos y riesgos maliciosos, aumentando la seguridad.
1.2.4 EIP-5656 MCOPY - Instrucción de copia de memoria
EIP-5656 optimiza el costo del proceso de copia de áreas de memoria al introducir una nueva instrucción EVM llamada MCOPY, mejorando así la eficiencia del movimiento de datos en EVM.
La copia de memoria es una operación fundamental, pero implementarla en EVM conlleva un costo. Tomando como ejemplo la copia de datos de memoria de 256 bytes, los desarrolladores pueden reducir significativamente el costo de 96 Gas (usando MLOAD y MSTORE) a 27 Gas mediante el opcode MCOPY. Se espera que en el futuro la mayoría de los desarrolladores utilicen MCOPY en lugar de MSTORE/MLOAD, y los contratos de Gas más eficientes eventualmente beneficiarán a los usuarios finales.
Al mismo tiempo, MCOPY llena el vacío que falta en el método de copia de memoria en EVM.
1.2.5 EIP-6780 SELFDESTRUCT solo en la misma transacción
EIP-6780 restringe la función del código de operación SELFDESTRUCT; la nueva función simplemente envía todos los fondos de la cuenta al objetivo, pero no afecta al código, almacenamiento y otra información, y también se prepara para la futura actualización del árbol Verkle.
Antes de EIP-6780, si el código del contrato hacía referencia a la operación SELFDESTRUCT, los fondos podían enviarse al destino, pero el código, el almacenamiento y otra información serían eliminados; sin embargo, esta función conlleva ciertos peligros y consecuencias inesperadas. Después de EIP-6780, todo esto no se verá afectado, los desarrolladores podrán gestionar mejor los proyectos, logrando así una blockchain más estable y predecible.
2. Impacto en los datos tras la actualización
2.1 El impacto de las tarifas de gas
La parte más fundamental de esta actualización, y la que más preocupa a todos, son los cambios en las tarifas de Gas. Con la introducción de EIP-4844, el beneficiario más notable es la capa Layer2, donde la reducción de las tarifas de Gas es muy evidente, mejorando la experiencia del usuario. Básicamente se alinea con la expectativa previa a la actualización de una reducción del 90% en las tarifas de Layer2.
En cuanto a Layer 1 (Ethereum mismo), después de la actualización, las tarifas de Gas han disminuido, pero no de manera significativa, y los usuarios en la práctica no notan ningún cambio.
2.2 Impacto del volumen de negociación
La actualización no solo busca reducir el Gas, sino también aumentar el rendimiento, que es un aspecto clave en el plan de desarrollo de escalabilidad de Ethereum.
Después de completar la actualización, el volumen de transacciones de Base se disparó primero y superó el anterior umbral, pasando de 500,000 a 2 millones, lo que significa que EIP-4844 tuvo un impacto directo en él, siendo los beneficios también los más evidentes.
2.3 impacto en TPS
La optimización de TPS (transacciones por segundo) significa que los desarrolladores tienen mayor flexibilidad al construir y desplegar dApps, lo que se espera que genere aplicaciones más complejas y densas en datos, atrayendo así a un público más amplio.
Después de completar la actualización, el TPS de cada Layer2 ha aumentado, pero no supera los 30 transacciones por segundo.
La baja TPS es un fenómeno común en la industria Web3 en la actualidad, a diferencia de las características de alta TPS de la industria tradicional Web2. La TPS máxima de Layer2 no ha superado los 500, pero desde el punto de vista del desarrollo de la industria, esta actualización también está sentando las bases para el futuro, al mismo tiempo que responde a las expectativas de desarrollo de Ethereum: alcanzar más de 100,000 TPS.
2.4 Uso de Blob
La principal razón de la disminución general de las tarifas de transacción de Layer2 es la introducción del tipo Blob. Cuantos más Blobs haya en una transacción, mayor será la capacidad total, lo que también sienta las bases para futuras actualizaciones de Ethereum.
Se esperaba inicialmente que, si se lograba un objetivo promedio de 3 Blob por bloque, el rendimiento de L2 tendría un aumento cercano al 200%. Si finalmente se lograra el objetivo de 64 Blob por bloque, el rendimiento de L2 tendría un aumento cercano al 4000%. La limitación máxima de esta actualización se ha establecido en 6 Blob.
En la situación actual, Blob ha comenzado a usarse en las transacciones, pero la tasa de uso general no es alta, el pico también se observó justo después de completar la actualización, y posteriormente ha ido disminuyendo, aún no se ha alcanzado el objetivo promedio estimado de 3 Blobs.
Sin embargo, la introducción del tipo Blob ha mejorado notablemente los costos de datos de Layer2 sobre Layer1. A partir del ejemplo de la cadena OP mencionado anteriormente, se puede percibir de manera intuitiva que los costos de datos de L1 en el costo promedio de transacciones de Layer2 se han reducido significativamente, casi eliminándose, lo que también sugiere desde otro ángulo que el margen de beneficio de Layer2 podría aumentar.
El modelo de ganancias de L2 es relativamente simple y claro, y se puede resumir básicamente como: Ganancia en cadena = Tarifas de transacción de L2 - Costos de pago de L1; tomando como ejemplo la cadena OP, aunque la actualización redujo simultáneamente las tarifas de transacción de L2 y los costos de pago de L1, debido al aumento en el volumen de transacciones y la base de usuarios, la disminución de ambos no está en la misma magnitud. Las tarifas de transacción disminuyeron de cientos de miles a decenas de miles, mientras que los costos de pago bajaron de cientos de miles a menos de 1k, y las ganancias en cadena también aumentaron después de la actualización.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Nuevo patrón del ecosistema de Ethereum tras la actualización de Cancún: las tarifas de transacción de L2 caen un 90%
Análisis profundo de la era posterior a la actualización de Cancún: perspectiva de datos e inversión
Introducción
Desde que Ethereum se lanzó oficialmente el 30 de julio de 2015, ha tenido un historial de 12 actualizaciones, cada una de las cuales ha sido muy destacada.
La principal objetivo de la actualización de Ethereum Cancún-Deneb ( Dencun ) es mejorar la escalabilidad y modularidad de la red Layer 2, fortalecer las capacidades de seguridad de la red Ethereum y mejorar la usabilidad general.
1. ¿Qué es la actualización Dencun?
1.1 Introducción a la actualización
1.1.1 Origen del nombre
La capa base de Ethereum se compone de dos partes combinadas: la capa de ejecución y la capa de consenso, y cada parte tiene diferentes reglas de nomenclatura.
La regla de nomenclatura de las actualizaciones de la capa de ejecución ha sido nombrada desde 2021 por las ciudades que albergan Devcon (la conferencia de desarrolladores de Ethereum). Por ejemplo, actualización de Berlín, actualización de Londres, actualización de Shanghái, etc.
La regla de nomenclatura de las actualizaciones de la capa de consenso se basa en nombres de cuerpos celestes desde el lanzamiento de la cadena de referencia, siguiendo el orden alfabético. Por ejemplo, Altair (牵牛星), Bellatrix (参宿五), Capella (五车二), etc.
El nombre de cada actualización de Ethereum se forma combinando diferentes nombres de actualizaciones. Dado que este Devcon se celebra en Cancún, México, y la actualización de la capa de consenso se llama Deneb, esta actualización de Ethereum se abrevia como Dencun.
1.1.2 Antecedentes de la actualización
El contexto de la actualización de Dencun se basa en una planificación a largo plazo desarrollada sobre Ethereum, y un núcleo fundamental es mejorar la experiencia de Ethereum, logrando finalmente un ecosistema sin permisos, descentralizado, resistente a la censura y de código abierto.
Por un lado, a través del mapa de planificación publicado por el fundador de Ethereum, Vitalik Buterin, el 31 de diciembre de 2023, se puede ver que la actualización Dencun corresponde a la parte de The surge, comenzando con la experiencia del usuario como prioridad (por ejemplo, aumentando la velocidad de las transacciones y reduciendo las tarifas de Gas), con el objetivo de mejorar la eficiencia de la red, reducir los costos de transacción y sentar una base sólida para el desarrollo futuro.
Por otro lado, del artículo de Vitalik Buterin publicado el 28 de diciembre de 2023 titulado "Make Ethereum Cypherpunk Again", se puede entender que Vitalik considera que una de las razones principales que está llevando a que la blockchain se limite cada vez más a la especulación de activos es el aumento de las tarifas de transacción, lo que ha convertido a los Degen Gamblers en un grupo dominante, lo que es perjudicial para la realización del valor de aplicación de la blockchain, por lo que es necesario reducir las tarifas de transacción.
1.1.3 Tiempo de actualización
Según la planificación de Ethereum, la información sobre el tiempo de actualización y activación es:
1.1.4 Contenido relacionado
Las actualizaciones de Ethereum Cancun-Deneb han realizado una serie de mejoras tanto en la capa de ejecución (EL) como en la capa de consenso (CL). Cancun ha mejorado la capa de ejecución, mientras que Deneb ha reforzado la capa de consenso, incorporando una serie de EIP (Propuestas de Mejora de Ethereum) que son fundamentales para el desarrollo de la red de Ethereum. Hay un total de 9 EIP, y presentaremos las EIP clave en las próximas secciones.
1.2 Enfoques clave de la actualización Dencun
1.2.1 EIP-4844 Transacciones de Blob de fragmentación (Proto-Danksharding)
EIP-4844 es el principal atractivo de esta actualización, que tiene como objetivo reducir las tarifas de transacción, aumentar el rendimiento de las transacciones por segundo (TPS) y la escalabilidad. Su esencia es una actualización transitoria para preparar el futuro, con el fin de lograr un Danksharding completo (la última parte de la actualización "Serena" de Ethereum), donde el Proto-Danksharding sienta las bases para el Danksharding.
La disponibilidad de datos en la cadena principal de Ethereum se proporciona a través de Calldata (que se puede entender como los datos generados en las llamadas de transacciones de contratos), y los datos que Layer 2 devuelve a Layer 1 se almacenan en Calldata. Además, para mayor seguridad, cada paso de ejecución de Calldata requiere Gas, lo que genera una situación de altos costos de Gas. Sin embargo, una vez que se verifica la transacción en Calldata, en realidad no tiene mucha utilidad, ya que los datos a largo plazo también se pueden descargar y verificar, e incluso no es necesario enviarlos a la capa de ejecución. Como ejemplo de la composición histórica de los costos de transacción promedio de la cadena Layer2-OP, se puede observar que cerca del 80% de los costos provienen de los costos de datos de L1.
Por lo tanto, EIP-4844 introduce una nueva estructura de almacenamiento de datos: Blob, diseñada específicamente para almacenar los datos de transacciones enviadas de L2 a L1. Después de su introducción, los datos de transacciones de L2 se envían directamente al Blob para su almacenamiento, disponible para su descarga completa por parte de los nodos de consenso, y se pueden eliminar después de un breve retraso, reduciendo la carga de almacenamiento innecesaria. Esto significa que la introducción de Blob reducirá drásticamente las tarifas de transacción de L2. Al mismo tiempo, Blob también expande el espacio de bloques para L2, y la capacidad de procesamiento de transacciones de L2 también aumentará significativamente.
1.2.2 EIP-1153 Código de operación de almacenamiento transitorio
El objetivo principal de EIP-1153 es ahorrar espacio de almacenamiento y costos de almacenamiento. El almacenamiento transitorio se descarta después de cada transacción, por lo que el almacenamiento temporal es más barato, ya que no requiere acceso al disco.
EIP-1153 es más amigable para los desarrolladores de Dapp, introduciendo nuevos códigos de operación TSTORE y TLOAD en el EVM, cuyo costo de Gas al invocar estos códigos es de aproximadamente 100 Gas cada uno, un 95% más barato que las llamadas de almacenamiento tradicionales (SLOAD y SSTORE). Al mismo tiempo, una vez que se completa la ejecución de la transacción, esa parte del almacenamiento se elimina, lo que reduce el costo de almacenamiento y el consumo de Gas, lo que podría hacer que los nuevos contratos DeFi sean más ahorradores en Gas en el futuro.
1.2.3 EIP-4788 Raíz del bloque de baliza en EVM
EIP-4788 permitirá la comunicación entre la EVM (máquina virtual de Ethereum) y la cadena de balizas (Beacon). Esta función admite varios casos de uso, puede mejorar los grupos de participación (staking pools), las construcciones de re-staking (restaking constructions), los puentes de contratos inteligentes (smart contract bridges), MEV, etc.
Anteriormente, el EVM no podía acceder directamente a los datos y estados del Beacon, solo podía capturar el estado a través de oráculos externos confiables. Por lo tanto, se propuso colocar una raíz de bloque padre del Beacon (parent_beacon_block_root) en cada bloque del EVM, de modo que cuando el Beacon se actualizara, el EVM pudiera obtener información precisa de inmediato.
La raíz del bloque de señal padre se almacenará en un búfer circular, conservándose durante aproximadamente un día. Una vez que una nueva raíz de bloque de señal padre ingrese y la capacidad del búfer alcance un valor crítico, la raíz de bloque de señal padre más antigua será reemplazada, logrando así un almacenamiento de consenso eficiente y limitado. De esta manera, se logra la comunicación de una manera que minimiza la confianza, además de eliminar fallos de oráculos externos y riesgos maliciosos, aumentando la seguridad.
1.2.4 EIP-5656 MCOPY - Instrucción de copia de memoria
EIP-5656 optimiza el costo del proceso de copia de áreas de memoria al introducir una nueva instrucción EVM llamada MCOPY, mejorando así la eficiencia del movimiento de datos en EVM.
La copia de memoria es una operación fundamental, pero implementarla en EVM conlleva un costo. Tomando como ejemplo la copia de datos de memoria de 256 bytes, los desarrolladores pueden reducir significativamente el costo de 96 Gas (usando MLOAD y MSTORE) a 27 Gas mediante el opcode MCOPY. Se espera que en el futuro la mayoría de los desarrolladores utilicen MCOPY en lugar de MSTORE/MLOAD, y los contratos de Gas más eficientes eventualmente beneficiarán a los usuarios finales.
Al mismo tiempo, MCOPY llena el vacío que falta en el método de copia de memoria en EVM.
1.2.5 EIP-6780 SELFDESTRUCT solo en la misma transacción
EIP-6780 restringe la función del código de operación SELFDESTRUCT; la nueva función simplemente envía todos los fondos de la cuenta al objetivo, pero no afecta al código, almacenamiento y otra información, y también se prepara para la futura actualización del árbol Verkle.
Antes de EIP-6780, si el código del contrato hacía referencia a la operación SELFDESTRUCT, los fondos podían enviarse al destino, pero el código, el almacenamiento y otra información serían eliminados; sin embargo, esta función conlleva ciertos peligros y consecuencias inesperadas. Después de EIP-6780, todo esto no se verá afectado, los desarrolladores podrán gestionar mejor los proyectos, logrando así una blockchain más estable y predecible.
2. Impacto en los datos tras la actualización
2.1 El impacto de las tarifas de gas
La parte más fundamental de esta actualización, y la que más preocupa a todos, son los cambios en las tarifas de Gas. Con la introducción de EIP-4844, el beneficiario más notable es la capa Layer2, donde la reducción de las tarifas de Gas es muy evidente, mejorando la experiencia del usuario. Básicamente se alinea con la expectativa previa a la actualización de una reducción del 90% en las tarifas de Layer2.
En cuanto a Layer 1 (Ethereum mismo), después de la actualización, las tarifas de Gas han disminuido, pero no de manera significativa, y los usuarios en la práctica no notan ningún cambio.
2.2 Impacto del volumen de negociación
La actualización no solo busca reducir el Gas, sino también aumentar el rendimiento, que es un aspecto clave en el plan de desarrollo de escalabilidad de Ethereum.
Después de completar la actualización, el volumen de transacciones de Base se disparó primero y superó el anterior umbral, pasando de 500,000 a 2 millones, lo que significa que EIP-4844 tuvo un impacto directo en él, siendo los beneficios también los más evidentes.
2.3 impacto en TPS
La optimización de TPS (transacciones por segundo) significa que los desarrolladores tienen mayor flexibilidad al construir y desplegar dApps, lo que se espera que genere aplicaciones más complejas y densas en datos, atrayendo así a un público más amplio.
Después de completar la actualización, el TPS de cada Layer2 ha aumentado, pero no supera los 30 transacciones por segundo.
La baja TPS es un fenómeno común en la industria Web3 en la actualidad, a diferencia de las características de alta TPS de la industria tradicional Web2. La TPS máxima de Layer2 no ha superado los 500, pero desde el punto de vista del desarrollo de la industria, esta actualización también está sentando las bases para el futuro, al mismo tiempo que responde a las expectativas de desarrollo de Ethereum: alcanzar más de 100,000 TPS.
2.4 Uso de Blob
La principal razón de la disminución general de las tarifas de transacción de Layer2 es la introducción del tipo Blob. Cuantos más Blobs haya en una transacción, mayor será la capacidad total, lo que también sienta las bases para futuras actualizaciones de Ethereum.
Se esperaba inicialmente que, si se lograba un objetivo promedio de 3 Blob por bloque, el rendimiento de L2 tendría un aumento cercano al 200%. Si finalmente se lograra el objetivo de 64 Blob por bloque, el rendimiento de L2 tendría un aumento cercano al 4000%. La limitación máxima de esta actualización se ha establecido en 6 Blob.
En la situación actual, Blob ha comenzado a usarse en las transacciones, pero la tasa de uso general no es alta, el pico también se observó justo después de completar la actualización, y posteriormente ha ido disminuyendo, aún no se ha alcanzado el objetivo promedio estimado de 3 Blobs.
Sin embargo, la introducción del tipo Blob ha mejorado notablemente los costos de datos de Layer2 sobre Layer1. A partir del ejemplo de la cadena OP mencionado anteriormente, se puede percibir de manera intuitiva que los costos de datos de L1 en el costo promedio de transacciones de Layer2 se han reducido significativamente, casi eliminándose, lo que también sugiere desde otro ángulo que el margen de beneficio de Layer2 podría aumentar.
El modelo de ganancias de L2 es relativamente simple y claro, y se puede resumir básicamente como: Ganancia en cadena = Tarifas de transacción de L2 - Costos de pago de L1; tomando como ejemplo la cadena OP, aunque la actualización redujo simultáneamente las tarifas de transacción de L2 y los costos de pago de L1, debido al aumento en el volumen de transacciones y la base de usuarios, la disminución de ambos no está en la misma magnitud. Las tarifas de transacción disminuyeron de cientos de miles a decenas de miles, mientras que los costos de pago bajaron de cientos de miles a menos de 1k, y las ganancias en cadena también aumentaron después de la actualización.
2.5 impacto en el precio
Para esta actualización,