TL;DR

1. Nuestra investigación se adentra en el mercado emergente de blobs EIP-4844, que opera de manera similar a la fijación de precios de gas EIP-1559 pero carece de un mecanismo directo de propina para el constructor de bloques para la inclusión de blobs, lo que podría resultar en una experiencia de transacción de blobs poco fiable e desafíos de inclusión.
2. Notamos que si bien las transacciones de blob son grandes (~125 kB) y más baratas que el calldata equivalente, agregan un tamaño significativo a los bloques de Ethereum pero aportan un poder de oferta incremental para un bloque.
3. Demostramos que la capacidad de este nuevo mercado absorbe las necesidades actuales de datos de rollup y reduce los costos estándar de gas en el espacio de bloque en un 15-20%, desbloqueando oportunidades de mev de menor costo.
4. Observamos que las transacciones de blob pueden ralentizar la propagación de bloques en órdenes de cien milisegundos en momentos de alta actividad de red, lo que puede llevar a que los constructores de bloques censuren los blobs para mantener la oferta competitiva en mev-boost.
5. Evaluamos que una "oferta previa de confirmación" puede aliviar estos desafíos y las preconfirmaciones de blob pueden mejorar las capacidades de EIP-4844, ofreciendo experiencias de transacción mejoradas para los usuarios de L2 y una experiencia de inclusión estable para los rollups.
6. Estaremos experimentando en la red de prueba Holesky, recopilando datos de construcción de bloques y configurando relés como proveedores de preconf de blob usando mev-commit, y invitamos a los actores de PBS a participar.

Introducción

EIP-4844 expande las capacidades de disponibilidad de datos de Ethereum con la introducción de un mercado de blobs. Este mercado incipiente utiliza un mecanismo de precios de gas similar al EIP-1559 para fijar y quemar las tarifas de gas base de blobs. Sin embargo, a diferencia de las transacciones de tipo2, no hay una forma directa de ofertar por una propina de constructor para su inclusión en el mercado de blobs. La falta de una tarifa de prioridad hace que sea difícil fijar con precisión el precio de la inclusión de blobs. Además, se espera que los bloques que contienen blobs se propaguen más lentamente a través de la red debido a que los blobs son algunas de las transacciones de Ethereum más grandes en tamaño. Si los constructores aceptan muchos blobs en un bloque, actualmente se enfrentan a un mayor riesgo de reorganización de bloques, y un constructor económicamente racional optaría por censurar blobs en ocasiones para mantener baja la latencia de construcción de bloques, lo que probablemente se correlacione con picos de mev.

Presentamos un esfuerzo de construcción de bloques relacionados con blobs y recopilación de datos de impulso de mev, junto con un experimento de proveedor de preconfirmación de blobs utilizandomev-commit, e invitar a la comunidad de rollups, relays, block builders y proposers a participar. Nuestros conocimientos sobre el comportamiento relacionado con blob en EIP-4844 sugieren que las preconfirmaciones de blob L1 pueden mejorar las capacidades del mercado de blob para proporcionar una mejor experiencia de transacción para los usuarios de L2, una inclusión confiable para rollups bajo condiciones de mev emergentes y un futuro más estable centrado en rollup para Ethereum.

Comprendiendo el Mercado Blob

Transacciones de Blob

EIP-4844introduce un tipo de transacción tipo3 (tx) llamada tx de blob. Una tx que lleva un blob es como una transacción regular, pero mejorada con datos de blob, compromisos KZG y pruebas. Los blobs son extremadamente grandes (~125 kB) en comparación con las tx estándar de Ethereum, y son mucho más baratos que una cantidad equivalente de calldata. Mientras que calldata tiene un costo de 16 gas por byte distinto de cero y puede tener un tamaño variable, los datos de blob tienen un costo de 1.04 gas por byte y tienen un tamaño fijo de131,072 gas.

Mecánica de gas de Blob

Precios del gas base blobtiene un mecanismo de tarifa de congestión similar a EIP-1559. La diferencia principal es que el gas de blob es un recuento de bloques objetivo, mientras que EIP-1559 se basa en la utilización de gas objetivo. El recuento de bloques objetivo es 3 (0.375 MB), y el máximo es 6 (0.75 MB) por bloque. El gas base de blob mínimo está establecido en 1 wei.

Cuando se envía una transacción de blob, el remitente enviará un max_fee_per_blob_gas como el precio más alto que está dispuesto a pagar por la tarifa base de blob gas, que se quema por completo. El max_fee_per_blob_gas es similar al max_fee_per_gas en transacciones de tipo0 y tipo2. Si el usuario quisiera enviar una tarifa adicional para incentivar la inclusión, entonces también enviaría un max_priority_fee. Sin embargo, el max_priority_fee solo cubre la parte de la transacción que no es de blob gas. Esto no deja forma directa de enviar una propina de inclusión al constructor.

Capacidad del mercado de Blob

En esta sección, nosotros realizar una prueba retrospectivaen la actividad de consolidación histórica desde enero de 2023 hasta enero de 2024 para demostrar la capacidad del mercado blob. Nos enfocamos en las txs de los rollups más activos en Ethereum y utilizamos los datos históricos para simular un mercado blob en vivo. Si bien este mercado está creciendo activamente y aún no está en mainnet,utilizamos datos históricosdesde todo el año 2023 para simular su potencial.

Basándonos en la actividad histórica de datos de rollup utilizados en el espacio de bloque de transacciones de tipo3, vemos que el precio del mercado blob puede absorber cómodamente toda la capacidad de rollup sin mover el precio del mercado blob más allá del gas base mínimo del blob.

bloque base de gas por bloque

Aunque los rollups están enviando más datos a Ethereum, la mayoría de los bloques siguen estando por debajo del objetivo, lo que garantiza que el precio del gas blob se mantenga bajo.

El color más claro indica un mayor número de veces que se construiría un bloque con cierta cantidad de bloques incluidos.

💡 Las implicaciones son que además de que el costo de los datos de llamada será menor en el mercado de blob (factor de 16), el precio del gas también será mucho más barato (wei vs gwei), lo que se traduce en dos capas de ahorro de costos adicionales para los rollups.

No solo el mercado blob puede absorber cómodamente las necesidades actuales de disponibilidad de datos de rollup, sino que también libera espacio en bloque en el mercado no blob, reduciendo los costos de gas hasta un 15-20%. Reducir los costos de gas aumenta proporcionalmente las capacidades de oferta para usuarios/buscadores, constructores y validadores, y desbloquea nuevas oportunidades de mev que estaban excluidas antes del EIP 4844.

EIP 4844 efecto en el espacio de bloque estándar usando datos de 2023.

Rollups Demand More Data Availability

Los rollups tienen una influencia importante en la cantidad de gas que se utiliza en los bloques, y son la clase más grande de usuarios de gas del espacio de bloque de Ethereum hoy en día. En 2023, los rollups han almacenado cantidades récord de datos de transacciones en Ethereum, como se representa a continuación:

Los datos de llamadas guardados en Ethereum están en máximos históricos.

Los gráficos promedio diarios a continuación muestran que los rollups están empezando a tomar más del 15% de cada bloque en el que se encuentran, lo que afecta directamente el precio para otros usuarios.

Esto puede empeorar aún más en situaciones de demanda de cisne negro.Recientemente en diciembre de 2023, el spam de inscripciones sacó fuera de línea al secuenciador de Arbitrumpor cerca de una hora debido a la abrumadora cantidad de transacciones. A medida que el secuenciador de Arbitrum reanudaba sus operaciones y comenzaba a publicar el backlog de estados guardados, el secuenciador monopolizó el espacio de bloque, causando los precios del gas subirán por encima de 140 gwei y consumirán más del 90% del gasen bloques completos, lo que hace que la red sea inutilizable para la mayoría de los usuarios durante un período de varias horas.

En la próxima sección, desplegamos cómo los juegos de tiempo y la censura probablemente afectarán este mercado incluso en ausencia de tales picos de demanda.

Desafíos del mercado de Blob: Censura

Propagación de Blob

EIP-4844 aumenta los requisitos de ancho de banda por bloque faro en un máximo de ~0.75 MB, 42m gas para acomodar un máximo adicional de 6 blobs en cada bloque faro. A diferencia de los calldata, que se almacenan para siempre, los blobs se mantienen en los nodos faro durante un corto período de tiempo (18 días a partir de febrero de 2024) para mantener manejable el crecimiento del estado de archivo de la red.

Además, las transacciones blob tienen dos representaciones en la red: para el constructor de bloques como una tx blob y para el validador como un blob sidecar. El blob sidecar existe para compatibilidad hacia adelantefines.

Los bloques primero deben propagarse a través de la capa de ejecución antes de pasar a través de la capa de consenso. Esto significa que los constructores, no los validadores, tienen la última palabra sobre inclusión de blob. Los proponentes solo pueden excluir transacciones de blob basadas en el compromiso o la invalidez de la prueba bajo la dinámica de impulso mev.

La verificación de ejecución la realizan los constructores. La verificación de consenso la realizan los validadores.

La Perspectiva del Constructor de Bloques

Investigaciones recientes en el momento de los juegos de validacióndestaca que la optimización de la latencia puede beneficiar estratégicamente a los operadores de nodos para maximizar las ganancias al retrasar las propuestas de bloques. Los autores explican que esto es perjudicial para la salud de la cadena. Las transacciones de blob complican aún más los juegos de tiempo al agregar una cantidad variable de latencia cuando el blob sidecar propaga.

Las transacciones de Blob son equivalentes a los tamaños de transacción más grandes posibles. Como resultado, los bloques que contienen estas transacciones pueden propagarse más lentamente, lo que hace que los constructores de bloques menos competitivo en ganar ofertas de impulso MEV. Como resultado, esto incentiva a los constructores de bloques a censurar temporalmente o incluso indefinidamente los bloques para que puedan presentar ofertas de mev con frecuencia más alta.

La ethpandael equipo ha estado realizando pruebas de latencia del mundo real en las testnets usando@ethpandaops/xatu-overview">Xatu. Se colocan centinelas en las regiones de NYC, FRA, BLR y SYD para representar medidas reales de latencia utilizando los clientes de consenso Prysm, Nimbus, Lodestar y Lighthouse. Una instantánea de datos con datos de blob de Holesky el 20 de febrero de 2024 indica que se incurre una cantidad no trivial de latencia en todo el pipeline de mev.

Después de que el constructor de bloques gane la subasta de impulso MEV, el proponente debe esperar a que los sidecars de blob se propaguen antes de poder verificar los blobs incluidos en el bloque. La tabla a continuación muestra que el tiempo mínimo para que un solo sidecar de blob se propague es de aproximadamente 400 ms en un tamaño de muestra de aproximadamente 800 sidecars de blob.

Tabla 1. Propagación de blobs vs número de blobs para slot

El pequeño tamaño de los datos contribuye a algunas de las observaciones contraintuitivas representadas en este conjunto de datos

La siguiente tabla muestra las variaciones de latencia al esperar a que lleguen más sidecars de blob. El percentil 50 (p50) indica que la variación de la latencia entre un bloque de 2 blobs y un bloque de 6 blobs es de aproximadamente 225 ms.

Tabla 2. Diferencia de tiempo entre el primer y último sidecar de blob agrupado por el número total de sidecars de blob en el bloque

Esta latencia de propagación de blobs pone un riesgo adicional de reorganización de bloques en los constructores de bloques mientras llenan sus bloques con blobs, por poco beneficio económico. El constructor podría optar por excluir/censurar la transacción de blob para evitar una posible reorganización. Si un bloque contiene mucha mev, los constructores económicamente racionales necesitarían ser compensados adecuadamente por los rollups por este riesgo.

En la subasta de inclusión de mercado Blob UX

La investigación de juegos de sincronización del validadorseñala que las ofertas más grandes están correlacionadas con bloques de mayor tamaño más adelante en el proceso de oferta mev-boost. A medida que las ofertas y el precio del gas aumentan, una mayor parte de ETH se quema en las ranuras subsiguientes. Si la tarifa base aumenta mientras la extracción de mev permanece constante, los constructores tienen menos para ofertar hacia los ingresos futuros de un proponente.

En el mercado de blob esperado donde la capacidad supera la demanda actual, la tarifa base de blob que se quema seguirá siendo muy pequeña, en las decenas o cientos de wei. Se vuelve esencial para los rollups reconocer que sus transacciones de blob podrían no ser incluidas a pesar de pagar la tarifa base suficiente. El mercado de blob de tarifas base bajas implica que los blobs deberán ofertar múltiplos más altos para incentivar a los constructores a incluir las transacciones. En tales casos, la transacción de blob tendrá que ser reenviada con una tarifa aumentada, lo que resulta en una mala UX.

Además, dado que el mercado inicial de bloques bajo EIP-4844 no tendrá un mecanismo de propina de inclusión (por ejemplo, una tarifa de gas de prioridad de bloque), esto agrava aún más el problema UX porque el rollup no puede ofertar directamente en la transacción de bloque.

Observamos un ejemplo de transacción y calculamos el costo equivalente de blob asumiendo un gas base de blob de 10 wei. Tenga en cuenta que este ejemplo asume que hay un mecanismo efectivo de subasta de inclusión para poder ofertar en el espacio de blob en primer lugar.

💡Aquí hay una muestra de transacción:

Datos de llamada: 129,998 bytes (129429 bytes distintos de cero) ~ 2,094,140 de gas utilizado a 10.56 gwei (precio base de 10.55 gwei + tarifa de prioridad de .01 gwei) = .022 ETH

Blob - 128,000 bytes ~ 131,072 gas used at 1 gwei (10 wei base price + .99999999 gwei priority fee) = 0.000131072 ETH

El cálculo concluye que si los rollups utilizan el mercado de blob, pueden enviar una oferta potencialmente 100 veces más grande debido a la tarifa base de blob más baja, y aún así ahorrar más de 150 veces el costo. La tarifa baseFee de blob más baja permitirá a los rollups ofrecer ofertas de inclusión más competitivas, y aún así ahorrar en costos. La tarifa de inclusión deberá ser tan competitiva como las oportunidades existentes de mev en el bloque para compensar el riesgo potencial de reorganización del constructor, y así incluso ofertar 100 veces más alto puede no ser suficiente. Es decir, en ausencia de preconfirmaciones de blob.

Preconfirmaciones de Blob con mev-commit

Bajo tales juegos de sincronización, el papel principal de una preconfirmación de blob se convierte en hacer una lista de blobs que un proveedor preconfirmó disponible a través del canal de mev. En mev-commit, cada proveedor preconf emite sus propios compromisos a txs. El proveedor luego puede dar acceso a estos datos a otros (por ejemplo, constructores de bloques, relés, secuenciadores). La disponibilidad de datos de la lista de preconf para otros actores a lo largo del canal de mev permite que la carga de ejecución coincidente se envíe en paralelo por un constructor de bloques. Esta noción se puede aprovechar para crear listas de inclusión de blobs preconf'd, o hacer que el espacio de bloque de tipo3 sea construido en colaboración por un relé.

Con el conocimiento avanzado de bloques preconfirmados, los constructores de bloques pueden comenzar a construir bloques futuros con bloques antes de que comience su ranura. Esto crea una base de precios y sienta las bases para un mercado de futuros robusto que brinda a los rollups una inclusión más confiable y estabilidad en el precio del espacio del bloque. Además, las ofertas preconf de mev-commit brindan a los rollups un mecanismo de descubrimiento de precios más confiable porque los rollups pueden actualizar sus ofertas preconf en tiempo real sin volver a enviar toda la tx de bloques.

Finalmente, agrupar blobs y usar una oferta preconf permite a los rollups construir alianzas. Las ofertas preconf pueden aplicarse a paquetes de transacciones de blob o blobs agregados, lo que permite a los rollups compartir su poder de oferta e inclusión con otros rollups, ayudando a estabilizar y hacer crecer el mercado de blobs de Ethereum.

Conclusión

En resumen, mostramos que la economía para rollups está mejorando, mientras emerge un nuevo mercado con consideraciones adicionales que van desde juegos de tiempo hasta la falta de un mecanismo de propina. Si bien es demasiado pronto para pasar a la fase de solución de los problemas que destacamos, podemos experimentar fácilmente con esto con actores de PBS ya que mev-commit está activo en la red de prueba de Holesky. Primev recopilará datos sobre los efectos de los bloques en la construcción de bloques y la latencia del proponente, y esperamos descubrir ideas sobre posibles patrones de comportamiento.

Si bien la economía y la experiencia de usuario son los principales impulsores de las transacciones de tipo2 preconf; parece que la inclusión, la fiabilidad y la estabilidad del rollup y el ecosistema centrado en rollup se convertirán en razones importantes para los bloques preconf bajo el EIP-4844. También estaremos experimentando con un relevo de preconf de bloques que puede aprovechar los bloques preconf y la coordinación de constructores de bloques para mejorar la propagación de la latencia del sidecar de bloques en la red de prueba de Holesky. Invitamos a la comunidad a comunicarse y participar en este experimento, ya que informará una solución potencial para toda la comunidad.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [espejo], Transmitir el título original 'Censura, Latencia y Preconfirmaciones en el Mercado de Blobs', Todos los derechos de autor pertenecen al autor original [Primev]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo, y lo resolverán rápidamente.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.

3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.