¿Qué sucede cuando una blockchain decide escalar no reinventándose a sí misma, sino simplemente ajustando los mandos? El 7 de enero de 2026, Ethereum activó BPO-2 —el segundo fork de solo parámetros de blob (Blob Parameters Only)— completando silenciosamente la fase final de la actualización Fusaka. El resultado: una expansión de capacidad del 40 % que redujo las tarifas de Capa 2 hasta en un 90 % de la noche a la mañana. No fue una revisión ostentosa del protocolo. Fue precisión quirúrgica, demostrando que la escalabilidad de Ethereum ahora es paramétrica, no procedimental.
La Actualización BPO-2: Números que Importan
BPO-2 elevó el objetivo de blobs de Ethereum de 10 a 14 y el límite máximo de blobs de 15 a 21. Cada blob contiene 128 kilobytes de datos, lo que significa que un solo bloque ahora puede transportar aproximadamente 2.6 – 2.7 megabytes de datos de blob —frente a los aproximadamente 1.9 MB antes del fork.
Para contextualizar, los blobs son los paquetes de datos que los rollups publican en Ethereum. Permiten que las redes de Capa 2 como Arbitrum, Base y Optimism procesen transacciones fuera de la cadena mientras heredan las garantías de seguridad de Ethereum. Cuando el espacio de los blobs es escaso, los rollups compiten por la capacidad, lo que eleva los costos. BPO-2 alivió esa presión.
El Cronograma: El Despliegue en Tres Fases de Fusaka
La actualización no ocurrió de forma aislada. Fue la etapa final del despliegue metódico de Fusaka:
- 3 de diciembre de 2025: Activación de la mainnet de Fusaka, introduciendo PeerDAS (Peer Data Availability Sampling)
- 9 de diciembre de 2025: BPO-1 aumentó el objetivo de blobs a 10 y el máximo a 15
- 7 de enero de 2026: BPO-2 llevó el objetivo a 14 y el máximo a 21
Este enfoque por etapas permitió a los desarrolladores monitorear la salud de la red entre cada incremento, asegurando que los operadores de nodos domésticos pudieran manejar las crecientes demandas de ancho de banda.
Por qué el "Objetivo" y el "Límite" son Diferentes
Comprender la distinción entre el objetivo de blobs (blob target) y el límite de blobs (blob limit) es fundamental para entender la mecánica de tarifas de Ethereum.
El límite de blobs (21) representa el techo máximo —el número absoluto de blobs que se pueden incluir en un solo bloque. El objetivo de blobs (14) es el punto de equilibrio que el protocolo busca mantener a lo largo del tiempo.
Cuando el uso real de blobs supera el objetivo, las tarifas base suben para desalentar el consumo excesivo. Cuando el uso cae por debajo del objetivo, las tarifas disminuyen para incentivar más actividad. Este ajuste dinámico crea un mercado autorregulado:
- Blobs llenos: Las tarifas base aumentan aproximadamente un 8.2 %
- Sin blobs: Las tarifas base disminuyen aproximadamente un 14.5 %
Esta asimetría es intencional. Permite que las tarifas bajen rápidamente durante los períodos de baja demanda, mientras aumentan de forma más gradual durante la alta demanda, evitando picos de precios que podrían desestabilizar la economía de los rollups.
El Impacto en las Tarifas: Números Reales de Redes Reales
Los costos de transacción de la Capa 2 se han desplomado entre un 40 % y un 90 % desde el despliegue de Fusaka. Las cifras hablan por sí solas:
| Red | Tarifa Promedio Post-BPO-2 | Comparación con la Mainnet de Ethereum |
|---|
| Base | $ 0.000116 | $ 0.3139 |
| Arbitrum | ~ $ 0.001 | $ 0.3139 |
| Optimism | ~ $ 0.001 | $ 0.3139 |
Las tarifas medianas de los blobs han caído hasta tan solo $ 0.0000000005 por blob —efectivamente gratuitas para fines prácticos. Para los usuarios finales, esto se traduce en costos cercanos a cero para swaps, transferencias, acuñación de NFTs y transacciones de juegos.
Cómo se Adaptaron los Rollups
Los principales rollups reestructuraron sus operaciones para maximizar la eficiencia de los blobs:
- Optimism actualizó su batcher para depender principalmente de los blobs en lugar de calldata, reduciendo los costos de disponibilidad de datos en más de la mitad
- zkSync reelaboró su canalización de envío de pruebas para comprimir las actualizaciones de estado en menos blobs y más grandes, reduciendo la frecuencia de publicación
- Arbitrum se preparó para su actualización ArbOS Dia (T1 2026), que introduce tarifas más fluidas y un mayor rendimiento con soporte para Fusaka
Desde la introducción del EIP-4844, se han publicado más de 950,000 blobs en Ethereum. Los rollups optimistas han visto una reducción del 81 % en el uso de calldata, lo que demuestra que el modelo de blobs está funcionando según lo previsto.
El Camino hacia los 128 Blobs: Qué Sigue
BPO-2 es un punto de paso, no el destino. La hoja de ruta de Ethereum visualiza un futuro donde los bloques contengan 128 o más blobs por slot —un aumento de 8 veces respecto a los niveles actuales.
PeerDAS: La Base Técnica
PeerDAS (EIP-7594) es el protocolo de red que hace posible el escalado agresivo de los blobs. En lugar de requerir que cada nodo descargue cada blob, PeerDAS utiliza el muestreo de disponibilidad de datos (data availability sampling) para verificar la integridad de los datos descargando solo un subconjunto.
Aquí se explica cómo funciona:
- Los datos extendidos del blob se dividen en 128 partes llamadas columnas
- Cada nodo participa en al menos 8 subredes de columnas elegidas al azar
- Recibir 8 de 128 columnas (aproximadamente el 12.5 % de los datos) es matemáticamente suficiente para demostrar la disponibilidad total de los datos
- La codificación de borrado (erasure coding) garantiza que incluso si faltan algunos datos, el original se pueda reconstruir
Este enfoque permite un escalado teórico de 8 veces el rendimiento de datos, manteniendo los requisitos de los nodos manejables para los operadores domésticos.
Cronograma de Escalado de Blobs
| Fase | Objetivo de Blobs | Máximo de Blobs | Estado |
|---|
| Dencun (marzo 2024) | 3 | 6 | Completado |
| Pectra (mayo 2025) | 6 | 9 | Completado |
| BPO-1 (diciembre 2025) | 10 | 15 | Completado |
| BPO-2 (enero 2026) | 14 | 21 | Completado |
| BPO-3/4 (2026) | Por determinar | 72 + | Planificado |
| A largo plazo | 128 + | 128 + | Hoja de ruta |
Una llamada reciente de todos los desarrolladores principales (all-core-devs) discutió un "cronograma especulativo" que podría incluir forks BPO adicionales cada dos semanas después de finales de febrero para lograr un objetivo de 72 blobs. El hecho de que este cronograma agresivo se materialice depende de los datos de monitoreo de la red.
Glamsterdam: El Próximo Gran Hito
Más allá de los forks BPO, la actualización combinada Glamsterdam (Glam para la capa de consenso, Amsterdam para la capa de ejecución) está programada actualmente para el Q2 / Q3 de 2026. Promete mejoras aún más drásticas:
- Block Access Lists (BALs): Límites de gas dinámicos que permiten el procesamiento de transacciones en paralelo
- Enshrined Proposer-Builder Separation (ePBS): Protocolo on-chain para separar los roles de construcción de bloques, proporcionando más tiempo para la propagación de bloques
- Aumento del límite de gas: Potencialmente hasta 200 millones, permitiendo un "procesamiento paralelo perfecto"
Vitalik Buterin ha proyectado que finales de 2026 traerá "grandes aumentos de los límites de gas no dependientes de ZK-EVM debido a las BALs y ePBS". Estos cambios podrían impulsar el rendimiento sostenible hacia más de 100,000 TPS en todo el ecosistema de Capa 2.
Lo que Revela BPO-2 sobre la Estrategia de Ethereum
El modelo de fork BPO representa un cambio filosófico en la forma en que Ethereum aborda las actualizaciones. En lugar de agrupar múltiples cambios complejos en hard forks monolíticos, el enfoque BPO aísla ajustes de una sola variable que pueden desplegarse rápidamente y revertirse si surgen problemas.
"El fork BPO2 subraya que la escalabilidad de Ethereum es ahora paramétrica, no procedimental", observó un desarrollador. "El espacio de blobs sigue estando lejos de la saturación, y la red puede expandir el rendimiento simplemente ajustando la capacidad".
Esta observación conlleva implicaciones significativas:
- Escalado predecible: Los rollups pueden planificar las necesidades de capacidad sabiendo que Ethereum continuará expandiendo el espacio de blobs
- Riesgo reducido: Los cambios de parámetros aislados minimizan la posibilidad de errores en cascada
- Iteración más rápida: Los forks BPO pueden ocurrir en semanas, no en meses
- Decisiones impulsadas por datos: Cada incremento proporciona datos del mundo real para informar el siguiente
La Economía: ¿Quién se Beneficia?
Los beneficiarios de BPO-2 se extienden más allá de los usuarios finales que disfrutan de transacciones más baratas:
Operadores de Rollups
Los menores costes de publicación de datos mejoran la economía unitaria de cada rollup. Las redes que anteriormente operaban con márgenes estrechos ahora tienen margen para invertir en la adquisición de usuarios, herramientas para desarrolladores y el crecimiento del ecosistema.
Desarrolladores de Aplicaciones
Los costes de transacción de menos de un céntimo desbloquean casos de uso que antes no eran rentables: micropagos, juegos de alta frecuencia, aplicaciones sociales con estado on-chain e integraciones de IoT.
Validadores de Ethereum
El aumento del rendimiento de blobs significa más comisiones totales, incluso si las comisiones por blob disminuyen. La red procesa más valor, manteniendo los incentivos de los validadores al tiempo que mejora la experiencia del usuario.
El Ecosistema en General
La disponibilidad de datos de Ethereum más barata hace que las capas de DA alternativas sean menos atractivas para los rollups que priorizan la seguridad. Esto refuerza la posición de Ethereum en el centro del stack de blockchain modular.
Desafíos y Consideraciones
BPO-2 no está exento de compensaciones:
Requisitos de los Nodos
Si bien PeerDAS reduce los requisitos de ancho de banda mediante el muestreo, el aumento del número de blobs sigue exigiendo más de los operadores de nodos. El despliegue por etapas tiene como objetivo identificar cuellos de botella antes de que se vuelvan críticos, pero los operadores domésticos con ancho de banda limitado pueden tener dificultades a medida que el recuento de blobs asciende hacia 72 o 128.
Dinámicas de MEV
Más blobs significan más oportunidades para la extracción de MEV en las transacciones de los rollups. La actualización ePBS en Glamsterdam tiene como objetivo abordar esto, pero el período de transición podría ver un aumento en la actividad de MEV.
Volatilidad del Espacio de Blobs
Durante los picos de demanda, las comisiones de los blobs aún pueden aumentar rápidamente. El incremento del 8.2 % por bloque lleno significa que una demanda alta sostenida crea un crecimiento exponencial de las comisiones. Los futuros forks BPO deberán equilibrar la expansión de la capacidad frente a esta volatilidad.
Conclusión: Escalado por Grados
BPO-2 demuestra que el escalado significativo no siempre requiere avances revolucionarios. A veces, las mejoras más efectivas provienen de una calibración cuidadosa de los sistemas existentes.
La capacidad de blobs de Ethereum ha crecido de un máximo de 6 en Dencun a 21 en BPO-2 — un aumento del 250 % en menos de dos años. Las comisiones de Capa 2 han caído en órdenes de magnitud. Y la hoja de ruta hacia más de 128 blobs sugiere que esto es solo el comienzo.
Para los rollups, el mensaje es claro: la capa de disponibilidad de datos de Ethereum se está escalando para satisfacer la demanda. Para los usuarios, el resultado es cada vez más invisible: transacciones que cuestan fracciones de céntimo, finalizadas en segundos, aseguradas por la plataforma de contratos inteligentes más probada en batalla que existe.
La era paramétrica del escalado de Ethereum ha llegado. BPO-2 es la prueba de que, a veces, girar el dial correcto es todo lo que se necesita.
¿Está construyendo sobre la capacidad de blobs en expansión de Ethereum? BlockEden.xyz proporciona servicios RPC de nivel empresarial para Ethereum y su ecosistema de Capa 2, incluidos Arbitrum, Optimism y Base. Explore nuestro API marketplace para conectarse a la infraestructura que impulsa la próxima generación de aplicaciones escalables.
