Han pasado ya 8 meses desde que la red Ethereum introdujo los blobs a través de la actualización EIP-4844. Como se esperaba, los rollups se están beneficiando de tarifas de publicación de lotes significativamente más bajas, lo que les permite enviar más transacciones a Ethereum a través de la opción de blobs, que es rentable.
Sin embargo, el uso de blobs ha sido bajo como se esperaba : todavía no hay suficientes acumulaciones o aplicaciones descentralizadas (DApps) que aprovechen los blobs.
Como resultado, la tarifa base del gas blob se ha mantenido en el precio mínimo de solo 1 wei. A pesar de cuatro períodos de alta demanda de blobs, el costo general sigue siendo excepcionalmente bajo. Esto hace que Ethereum sea una capa de disponibilidad de datos (DA) atractiva para los rollups, pero también genera inquietudes dentro de la comunidad sobre si los rollups están contribuyendo lo suficiente a la red principal. Además, Ethereum ha estado experimentando una inflación de emisión desde la adopción de los blobs, lo que ha provocado debates sobre su impacto.
Algunos sostienen que los blobs permiten que Ethereum escale y que, con el tiempo, más servicios de rollup migrarán a la red. Otros sostienen que, por ahora, los rollups ofrecen poca o ninguna contribución a Ethereum.
Más allá de los efectos sobre el precio, han surgido debates sobre las implicaciones más amplias de los blobs. Un tema importante es si se debe ajustar la tarifa base mínima de los blobs, como se propone en EIP-7762. El resultado de esta propuesta sigue siendo incierto. Otro debate, plasmado en EIP-7691, se centra en si se debe aumentar la cantidad de blobs, y los defensores afirman que esto no comprometería la seguridad del consenso. Ambas propuestas se están considerando para la próxima bifurcación dura de Pectra .
Este artículo profundiza en los detalles de cada propuesta, explorando los antecedentes, los detalles de lo que se ha propuesto y las posibles ventajas y desventajas.
Para aquellos que no están familiarizados con los blobs, primero cubriremos los aspectos básicos. Si ya conoces EIP-4844 y los blobs y estás interesado específicamente en las propuestas, puedes pasar directamente a la discusión sobre EIP-7762.
Primero, profundicemos en el concepto exacto de disponibilidad de datos y expliquemos cómo EIP-4844 mejora Ethereum como capa DA.
La disponibilidad de datos es la propiedad que garantiza que se pueda acceder a datos específicos en un momento determinado, en particular con el fin de validar nuevos bloques en redes blockchain. Se centra en el acceso en tiempo real necesario para validar nuevos bloques y garantizar que se alcance un consenso. Garantiza que los datos necesarios para la validación del bloque actual estén disponibles para todos los nodos participantes, lo que les permite verificar las transacciones antes de agregar el bloque a la cadena.
La DA suele confundirse con la recuperabilidad de datos, que se refiere a la capacidad de acceder a datos históricos. La recuperabilidad implica recuperar datos pasados, como información de bloques antiguos, normalmente con fines como sincronizar nuevos nodos o revisar el historial de transacciones. Sin embargo, la recuperabilidad no afecta a la validación en tiempo real necesaria para la creación de bloques.
Por ejemplo, la cadena de bloques Ethereum garantiza la DA al poner a disposición de los nodos los datos necesarios para la validación de bloques en el momento en que se propone un bloque. Incluso si los nodos Ethereum no proporcionan todos los datos históricos a los nodos de sincronización en ciertos casos, el mecanismo de consenso garantiza que los datos necesarios estén disponibles durante la validación . Si los datos no hubieran estado disponibles en ese momento, el bloque no se habría añadido a la cadena de bloques.
También es importante señalar que la DA no es una propiedad binaria: no significa simplemente “disponible” o “no disponible”. En cambio, existe en un espectro continuo. Las cadenas de bloques seguras y descentralizadas como Ethereum proporcionan una DA sólida, pero pueden ocurrir variaciones en el grado de disponibilidad según factores como el mecanismo de consenso y el nivel de descentralización.
La disponibilidad de datos (DA) es vital para los rollups porque garantiza que se pueda acceder a los datos de transacciones para verificar las actualizaciones de estado y reconstruir el estado actual del rollup. Para los rollups optimistas, la DA es esencial para construir pruebas de fraude. Si se publica una transición de estado falsa, los usuarios pueden confiar en los datos de transacciones almacenados en la capa DA para validar la transición y demostrar el fraude. Sin la DA, los usuarios tendrían que confiar completamente en los operadores de rollups, lo que podría exponerlos a riesgos si los operadores actúan de manera maliciosa u ocultan datos.
En el caso de los rollups de ZK, DA garantiza la existencia de pruebas criptográficas para validar las transiciones de estado sin necesidad de publicar todos los datos de las transacciones. Sin embargo, en la práctica, muchos rollups de ZK aún publican datos de transacciones en la capa DA para mejorar la transparencia y facilitar la verificación por parte de los usuarios.
Las sólidas garantías de DA de Ethereum son la razón por la que los rollups lo utilizan como su capa de DA. Antes de EIP-4844, los rollups aprovechaban el campo calldata de Ethereum para DA. Ahora, pueden utilizar tanto blobs como calldata, lo que mejora la escalabilidad y la eficiencia de las implementaciones de rollups.
EIP-4844 introduce una nueva estructura de datos llamada blob, que, a diferencia de calldata , se almacena temporalmente en la capa de consenso durante aproximadamente 18 días antes de su eliminación. Los validadores de Ethereum asignan alrededor de 50 GB para el almacenamiento temporal de blobs. Los blobs se diferencian de calldata porque no son accesibles a través de la máquina virtual Ethereum (EVM); solo se puede acceder a sus compromisos de blobs, lo que reduce la huella de datos y al mismo tiempo garantiza la DA. Los blobs ofrecen una DA eficiente al proporcionar solo las funciones esenciales necesarias para los rollups, lo que contribuye a reducir significativamente las tarifas de transacción.
Cada blob tiene aproximadamente 128 KiB y un bloque puede contener hasta 6 blobs, lo que suma un total de alrededor de 0,784 MiB por bloque. Los blobs se agregan a través de un nuevo tipo de transacción llamado transacciones de blobs, que, al igual que las transacciones tradicionales, utilizan al menos 21 000 gas y pueden incluir de 1 a 6 blobs.
Los blobs se cotizan utilizando una nueva unidad llamada gas blob , donde cada blob consume 217 = 131,072 unidades de gas blob. De manera similar al mecanismo de tarifa de gas EIP-1559 de Ethereum, los precios del gas blob se ajustan dinámicamente en función de la congestión de blobs en los bloques recientes. La tarifa base del gas blob Bblobgas,k+1 para el siguiente bloque k + 1 se calcula de la siguiente manera:
Cuando un bloque se llena con el máximo de 6 blobs, la tarifa base de gas por blob puede aumentar aproximadamente un 12,5 % en el bloque siguiente. Actualmente, la tarifa base mínima por blob está fijada en 1 wei, estableciendo la tarifa mínima por blob en 131 072 wei. Cada transacción de blob también incluye la tarifa de ejecución estándar de 21 000 gas multiplicada por el precio del gas. La tarifa base mínima de 1 wei está en discusión activa, y la EIP-7762 propone un aumento para equilibrar mejor los costos y las necesidades de disponibilidad de datos.
EIP-7762 propone aumentar la tarifa base del gas blob (reservar un hotel mucho más cerca del centro) para que el descubrimiento de precios sea más rápido. Lo que intenta cambiar es solo un parámetro: MIN_BLOB_BASE_FEE
. Propone cambiarlo de 1 wei a 225 wei. Pero ¿cuál es el razonamiento detrás de esta propuesta?
El problema no es que los rollups contribuyan mínimamente a las transacciones de la red principal o paguen muy poco en comisiones. Por el contrario, el objetivo de Ethereum, especialmente con EIP-4844, es respaldar transacciones de rollup escalables y de bajo costo. Las tarifas base del gas blob se han mantenido consistentemente en 1 wei desde que se activó EIP-4844, con solo unos pocos aumentos breves cuando la demanda de blobs aumentó. Idealmente, si la tarifa base pudiera mantenerse en 1 wei indefinidamente, esto no sería una preocupación. Lo que importa es que, durante los aumentos repentinos de demanda, el bajo punto de partida de las tarifas base de blobs presenta desafíos en el descubrimiento de precios.
Durante estos aumentos repentinos, el ajuste gradual de la tarifa base del gas blob desde 1 wei puede tardar en alinearse con la demanda real. Imaginemos un escenario hipotético: imaginemos que asistimos a la ETH Bangkok 2024 y decidimos alojarnos en un hotel remoto con alimentos casi gratis cerca. Para las necesidades diarias, esto es ideal. Sin embargo, cuando necesitamos asistir a un evento en el centro de conferencias, se necesitan seis horas para llegar en condiciones normales. Si añadimos el tráfico y la falta de rutas directas, el viaje podría extenderse a 14 horas.
De manera similar, cuando la tarifa base mínima del gas blob se establece en 1 wei, los rollups se benefician de blobs económicos cuando la demanda es baja. Pero durante un aumento repentino de la demanda, el ajuste al alza de la tarifa base del gas blob es lento, lo que deja un período prolongado de descubrimiento de precios antes de que se alcance una tasa de mercado justa.
Además, el tiempo mínimo teórico para alcanzar un precio apropiado puede no ser válido en la práctica. Si los validadores o los constructores de bloques omiten las transacciones de blobs de los bloques, este período de descubrimiento podría extenderse aún más. Por ejemplo (de la publicación de dataalways ), durante el airdrop de LayerZero el 20 de junio, la tarifa base de blobs aumentó de 1 wei a 7471 Gwei. En teoría, esto debería haber llevado aproximadamente 252 bloques o 51 minutos (calculados de la siguiente manera):
log1.125 (7.471 x 1012) = 251.66
Sin embargo, el tiempo real fue de alrededor de 6 horas, casi 5 o 6 veces más largo de lo esperado. Los períodos de descubrimiento de precios prolongados significan que la tarifa base no refleja con precisión la demanda de blobs. Esta discrepancia puede impulsar a los usuarios de blobs y a los rollups a ofertar agresivamente a través de tarifas prioritarias, lo que genera un mercado de tarifas impredecible y altamente competitivo. En resumen, una tarifa base demasiado baja retrasa el descubrimiento de precios, lo que desalinea las tarifas con la demanda en tiempo real.
Lo que propone la EIP-7762 es como alojarse en un hotel más cercano al centro de convenciones. Si bien es posible que pague más por comprar alimentos cerca, estar más cerca hace que sea más rápido y más cómodo llegar al centro de conferencias cuando lo necesite.
Si la tarifa base mínima de blob aumenta, los rollups incurrirán en tarifas más altas por enviar transacciones de blob. Sin embargo, aumentar la tarifa base mínima de blob de 1 wei a 225 wei no implica que los rollups paguen 225 veces la tarifa actual por transacciones de blob. Esto se debe a que las transacciones de blob no solo pagan tarifas por el gas de blob, sino que también pagan tarifas de ejecución por transacciones de blob. Al igual que las transacciones que no son de blob, las transacciones de blob pagan al menos 21 000 gas. Si publican datos de llamadas, la tarifa de ejecución aumenta aún más.
Suponiendo una tarifa base de gas de 5 Gwei, la tarifa de ejecución para transacciones de blobs sería (al menos) aproximadamente 21,000 x 109 = 2.1 x 1013
wei. En comparación, la tarifa mínima para un solo blob es 131,072 = 1.3 x 105 wei
, lo que hace que la tarifa base de blobs sea trivial: aproximadamente 1.6 x 108 = 160,000
veces más barata que la tarifa de ejecución. Intuitivamente, un aumento modesto en la tarifa base mínima de blobs no afectaría drásticamente el costo total de las transacciones de blobs.
Por ejemplo, según la tarifa base mínima de blob propuesta en EIP-7762 de 225 wei, la tarifa de blob se convierte en 225 x 1.3 x 105 = 4.3 x 1012
wei. Por lo tanto, el costo total (tarifa de ejecución + tarifa de blob) se convierte en 2.1 x 1013 + 4.3 x 1012 = 2.5 x 1013
Esto representa aproximadamente un aumento del 20 % con respecto a la tarifa base mínima actual de 1 wei por blob. En los casos en que el bloque se llena con el máximo de 6 blobs, el aumento podría alcanzar alrededor del 120 %.
El aumento de costo real a partir de EIP-7762 también depende de la estrategia de transacción de cada rollup. Los rollups varían en las estrategias de envío de blobs: utilizan diferentes cantidades de blobs por transacción, publican distintas cantidades de datos de llamadas y, por lo tanto, incurren en diferentes tarifas de ejecución. Los rollups que publican pruebas más complejas en los datos de llamadas pagarán tarifas de ejecución más altas, lo que significa que el aumento propuesto en la tarifa base de blobs afectará sus costos de transacción generales de manera menos significativa.
Los datos de las simulaciones históricas de dataalways indican que, en el caso de los rollups basados en OP Stack como Base, Optimism y Blast, los costos podrían aumentar hasta un 16 % con una tarifa base de blob de 225 wei. Sin embargo, otros rollups mostraron un aumento de menos del 2 %, lo que sugiere un impacto mínimo en los costos totales de transacción de blobs.
Además de ajustar MIN_BLOB_BASE_FEE
, se realizó un pequeño cambio en la forma en que se calcula el exceso de gas blob . Anteriormente, el cálculo de excess_blob_gas
podría potencialmente conducir a un pico no deseado en la tarifa base del blob. Para evitar esto, el EIP introduce una modificación que restablece el exceso de gas blob a la altura de la bifurcación. Este ajuste garantiza transiciones más suaves alrededor del evento de bifurcación.
Desde la propuesta de EIP-7762, se ha generado un debate considerable. Si bien los investigadores coinciden en gran medida en la motivación detrás de esta propuesta y en la necesidad de abordar cuestiones relacionadas con el descubrimiento de precios, persisten algunas preocupaciones . Una cuestión principal es el posible impacto de los frecuentes ajustes del protocolo en la estabilidad de Ethereum. Los ajustes periódicos pueden introducir complejidades y riesgos imprevistos.
Otra preocupación se centra en determinar una tarifa base mínima adecuada para los blobs. La elección arbitraria de 225 wei carece de una base empírica sólida, lo que motiva peticiones de más investigaciones para garantizar que este valor respalde los objetivos a largo plazo del protocolo. Establecer una justificación sólida para esta tarifa base es esencial para evitar una posible inestabilidad o distorsiones no deseadas del mercado.
La EIP-7691 propone un cambio sencillo: aumentar la cantidad máxima de blobs por bloque. Actualmente, el límite es de 6 blobs por bloque, con un objetivo de 3. La EIP-7691 sugiere que al aumentar este límite (no hay un número exacto por ahora), los rollups podrían lograr una mayor escalabilidad sin comprometer la estabilidad del consenso de Ethereum.
Aumentar la cantidad de blobs por bloque podría aumentar el tamaño total de los datos transmitidos a través de la red peer-to-peer (p2p) de Ethereum, lo que podría provocar demoras en alcanzar el consenso. Cada blob contiene 128 KiB de datos, por lo que 6 blobs suman 784 KiB. Con el tamaño máximo de bloque de Ethereum de alrededor de 2 MB, los datos totales transmitidos por ranura, incluidos los blobs, podrían alcanzar aproximadamente 2,78 MB .
A medida que aumenta el número de blobs, también aumenta el tamaño de los datos, lo que extiende el tiempo necesario para que los bloques y los blobs se propaguen entre los nodos. Esta demora puede desafiar el proceso de consenso de Ethereum, especialmente porque los validadores deben enviar las certificaciones dentro de una ventana de 4 segundos antes de que finalice cada intervalo. Por lo tanto, garantizar la estabilidad del consenso exige una gestión cuidadosa de estos tiempos de propagación.
Algunos pueden argumentar que, dado que cada blob se propaga a través de un canal independiente, el aumento en la cantidad de blobs no debería afectar significativamente el consenso. Sin embargo, los nodos deben esperar a que lleguen todos los blobs y los datos de los bloques, lo que significa que una mayor cantidad de blobs podría generar tiempos de espera más prolongados.
Los análisis empíricos posteriores a la EIP-4844 (ver post1 , post2 ) revelan que la tasa de bifurcaciones ha aumentado después de la implementación y aumenta con el recuento de blobs por bloque. El gráfico a continuación ilustra las tasas de reorganización por recuento de blobs desde el 6 de abril hasta el 6 de junio de 2024. Los bloques que contienen un máximo de 6 blobs muestran una tasa de reorganización significativamente mayor que los bloques con menos de 4 blobs, lo que genera inquietudes sobre el impacto de la EIP-4844 en la seguridad del consenso de Ethereum.
Si bien las reorganizaciones pueden ocurrir por múltiples razones, las mayores cargas de datos en la red p2p son solo un factor. Las implementaciones de clientes subóptimas también pueden contribuir a las tasas de reorganización. Mi análisis inicial sugiere que el tiempo de disponibilidad de datos (DA), la duración que los nodos esperan a que llegue el blob final, es mínimo: en promedio, menos de 20 ms, con una diferencia de menos de 5 ms entre los bloques que contienen 0 blobs y aquellos con 6 blobs. Dado que los nodos esperan aproximadamente 4000 ms antes de enviar las certificaciones, esta latencia parece insignificante y es poco probable que afecte críticamente el consenso. El siguiente gráfico muestra el tiempo de DA estimado con bloques que contienen diferentes cantidades de blobs.
Además, el análisis de Toni indica que las tasas de reorganización generales han estado disminuyendo desde la implementación de EIP-4844. Si bien los datos anteriores mostraron una fuerte correlación entre las tasas de reorganización y los recuentos de blobs hasta junio, los datos más recientes de los últimos tres meses revelan diferencias mínimas en las tasas de reorganización entre bloques con diferentes recuentos de blobs. Estos hallazgos, atribuidos a las mejoras continuas en el rendimiento del cliente Ethereum, sugieren que aumentar el límite de blobs no representaría un riesgo significativo para la estabilidad del consenso.
Recientemente, Vitalik sugirió: “Creo que deberíamos volver a considerar la posibilidad de agregar EIP-7623 y un pequeño aumento en el recuento de blobs (por ejemplo, objetivo 3 -> 4, máximo 6 -> 8) para PectraA”. Para entender cómo EIP-7623 puede facilitar este aumento, examinemos primero su propuesta principal. (Vea aquí para obtener una explicación detallada de EIP-7623)
La EIP-7623 propone ajustar el costo del gas para los datos de llamadas específicamente para las transacciones que sirven principalmente para fines de disponibilidad de datos (DA). Básicamente, las transacciones con un bajo nivel de gas de ejecución en relación con el tamaño de sus datos de llamadas incurrirían en un mayor costo de gas (posiblemente hasta 3 veces más) por el uso de datos de llamadas. Por lo tanto, las transacciones que contienen una gran cantidad de datos de llamadas pero realizan una ejecución mínima de EVM tendrían costos más altos, lo que incentivaría el uso de blobs en lugar de datos de llamadas para funciones relacionadas con DA.
La razón detrás de este ajuste es minimizar el impacto en las transacciones diarias de usuarios que no son de DA mientras se optimiza el marco de DA. Al aumentar los costos de calldata para transacciones específicas de DA, EIP-7623 alienta a las operaciones con gran cantidad de datos a realizar la transición de calldata a blobs, optimizando el almacenamiento de la red y la eficiencia de DA. Además, esta propuesta tiene como objetivo reducir el tamaño de bloque en el peor de los casos de 2,78 MB a aproximadamente 1,2 MB, abordando la brecha actual donde el tamaño de bloque promedio de Ethereum de alrededor de 125 KB podría alcanzar potencialmente un límite mucho mayor.
Si EIP-7623 reduce efectivamente el tamaño máximo de bloque, crea espacio para una mayor cantidad de blobs, lo que respalda los objetivos de EIP-7691. Incluso con una mayor cantidad de blobs, el tamaño total de los datos sigue siendo manejable en las peores condiciones posibles debido a la menor dependencia de los datos de llamadas para DA. Esta alineación entre EIP-7623 y EIP-7691 permite un mayor rendimiento de blobs sin aumentar el tamaño máximo de bloque más allá de los límites sostenibles.
Este artículo ha presentado las EIP recientes enfocadas en mejorar la funcionalidad de los blobs de Ethereum. La EIP-7762 propone aumentar la tarifa base mínima de los blobs para permitir un descubrimiento de precios más rápido durante los picos de demanda, al tiempo que se minimiza el impacto en los costos generales de transacción de blobs. La EIP-7691 busca aumentar el recuento de blobs por bloque para escalar aún más la capa de disponibilidad de datos (DA) de Ethereum. Con un mayor recuento de blobs, la tarifa base de blobs experimentaría un aumento más controlado durante los picos de demanda, lo que permitiría ajustes de precios más suaves.
Se están llevando a cabo debates detallados sobre estos cambios propuestos. Por ejemplo, los debates incluyen fijar el número objetivo de blobs en 4 y el recuento máximo de blobs en 6, así como determinar si la regla de actualización de la tarifa base debe ser simétrica o asimétrica. Otras consideraciones incluyen la normalización del exceso de gas de blobs y el ajuste de la fracción de actualización de la tarifa base de blobs .
Los blobs son una incorporación reciente al ecosistema de Ethereum y cada cambio relacionado con ellos se aborda con cautela debido a su impacto tanto en la capa de aplicación como en la seguridad del consenso. No obstante, Ethereum está avanzando rápidamente y la comunidad de investigación trabaja diligentemente para impulsar el desarrollo y garantizar que la red siga creciendo y evolucionando.
Nota del autor: una versión de este artículo fue publicada originalmente aquí .