Los bloques en forma de “blobs” de Ethereum: una prueba de escalabilidad para la L1

La propuesta Block-in-Blobs (BiB) representa una solución técnica dirigida a resolver un problema específico en la arquitectura de Ethereum. Su objetivo es codificar los datos de las transacciones directamente en objetos de tipo BLOB, los cuales ya forman parte de la capa de disponibilidad de datos de la red. Esto permite que los validadores no tengan que descargar y ejecutar nuevamente los datos completos de las transacciones, sino que simplemente verifiquen las pruebas criptográficas de la existencia de dichos datos. El mecanismo principal consiste en utilizar el método de muestreo de la disponibilidad de datos (DAS); en este caso, los validadores verifican pequeños fragmentos de los datos para confirmar que todo el conjunto de datos está publicado, lo que reduce significativamente la cantidad de ancho de banda requerido por cada nodo.

Esta reducción es crucial, ya que la red se prepara para una importante expansión. La Fundación Ethereum ha decidido aumentar explícitamente el límite de gastos en la transmisión de datos.Hacia y más allá de los 100 millones.Algunos miembros de la comunidad esperan que este número pueda llegar a los 180 millones. Sin BiB, esta expansión aumentaría exponencialmente la cantidad de datos que deben procesar los validadores de datos, lo que representaría un límite impuesto al rendimiento de la red. Al transferir los datos de transacciones a formato blob, la propuesta aborda directamente este problema arquitectónico, lo que hace que sea posible utilizar tamaños de bloques más grandes, sin sobrecargar la banda ancha de la red.

El diseño es una respuesta directa a los cambios que se avecinan, en particular, al paso hacia el uso de zkEVM. En ese futuro, los validadores verificarán pruebas de conocimiento cero, en lugar de ejecutar nuevamente las transacciones. Esto crea una nueva vulnerabilidad: un creador podría publicar una prueba válida, pero ocultando los datos relacionados con la transacción en cuestión. BiB soluciona este problema haciendo que la disponibilidad de los datos sea un requisito a nivel de consenso. De esta manera, se asegura que los datos estén fijados de forma criptográfica y puedan ser verificados sin necesidad de replicación completa.

Los factores que influyen en la escala actual y su impacto en el flujo de datos

Los esfuerzos inmediatos consisten en una serie de medidas para aumentar la capacidad de almacenamiento de datos y de procesamiento de información. La bifurcación del protocolo BPO en enero de 2026 permitió aumentar la capacidad de almacenamiento de datos.Otros ~66%Esto constituye una actualización importante y de corta duración, que debería reducir la congestión en el ecosistema de rollups, al proporcionar más espacio para almacenar los datos de transacciones.

Al mismo tiempo, los desarrolladores están discutiendo la posibilidad de aumentar significativamente el rendimiento del nivel básico. Se está considerando aumentar el límite de gas a 75-80 millones, con el fin de implementarlo después de la bifurcación del BPO. Esto permitiría que más transacciones y operaciones de contratos inteligentes pudieran ser incluidas en cada bloque, lo cual tendría como objetivo reducir la presión sobre los costos de transacción, al aumentar la capacidad de procesamiento de transacciones en el nivel L1.

Estos pasos forman parte de una iniciativa más amplia y a largo plazo. La Fundación Ethereum tiene como objetivo específico aumentar el límite de gastos relacionados con las transacciones en la red Ethereum.Hacia adelante y más allá… 100 millones.En el año 2026, aunque la propuesta de utilizar una capacidad de 75-80 millones de datos por segundo representa un paso importante hacia ese objetivo, el objetivo final es lograr una mayor escalabilidad en la red. El éxito de estos mejoramientos graduales determinará si la red puede transicionar sin problemas a los niveles de rendimiento más altos que se requieren para lograr un sistema L1 con un alto rendimiento.

Catalizadores, riesgos y lo que hay que observar

El principal catalizador para cualquier impacto en el flujo de transacciones es la implementación y adopción de la propuesta “Block-in-Blobs”. Actualmente, sigue siendo una versión preliminar del EIP-8142. Por lo tanto, su proceso de transformación desde un concepto de investigación hasta una actualización en la red principal está lejos de ser seguro. El éxito de esta propuesta depende del consenso entre los desarrolladores y de la priorización de sus beneficios en términos de escalabilidad, frente a las posibles complicaciones relacionadas con su integración en la red. Hasta que sea adoptada oficialmente y esté programada para una actualización en la red, su efecto en el rendimiento de las transacciones y en las tarifas será puramente teórico.

Un riesgo importante es que la propuesta no logre el aumento del espacio disponible para almacenar datos, como se prometió. La técnica de muestreo de disponibilidad de datos, aunque eficiente, introduce nuevos aspectos criptográficos y de coordinación. Si la implementación resulta más compleja o menos eficiente de lo esperado, podrían surgir nuevos problemas o se requerirá que los validadores adopten reglas de muestreo más estrictas, lo cual podría contrarrestar los beneficios obtenidos en términos de ancho de banda. La principal promesa de escalar hasta un límite de 100 millones de gas depende completamente de que BiB simplifique, y no complicara, el proceso de verificación de datos.

Se debe monitorear la llamada de los siguientes desarrolladores principales y el cronograma de actualización de Glamsterdam, para obtener señales claras sobre cómo se va a llevar a cabo dicha actualización. La actualización de Glamsterdam está programada para la primera mitad de 2026, y es el próximo gran evento en el que podría discutirse o incluso decidirse la implementación de tal propuesta. Cualquier mención de BiB en los planes de actualización de los desarrolladores será un indicador directo de su progreso. La falta de discusión sobre este tema indicará que no se da prioridad a su implementación; por otro lado, una clara ruta hacia su implementación sería una señal positiva para la trayectoria de escalabilidad de Ethereum.