Ampliación y seguridad en paralelo: análisis completo de la actualización Fusaka de Ethereum y las 12 EIP

作者：@ChromiteMerge

Ethereum experimentará una actualización de hard fork llamada “Fusaka” el 3 de diciembre de 2025. Esta actualización incluye un total de 12 propuestas de mejora de Ethereum (EIP). Son como 12 piezas de precisión que, en conjunto, mejorarán la escalabilidad, la seguridad y la eficiencia de funcionamiento de Ethereum. A continuación, el autor explicará de forma ordenada y en lenguaje sencillo qué problemas resuelve cada una de estas 12 EIP y por qué son tan importantes para el futuro de Ethereum.

¡Escalado! Para que Ethereum vaya más rápido y pueda alojar más

Este es el tema central de la actualización Fusaka. Para que Ethereum soporte la economía digital global, debe resolver la congestión de transacciones y los costos elevados. Las siguientes EIP están precisamente orientadas a lograr ese objetivo, en particular mediante la reducción de costos y la mejora de la eficiencia para el escalado de Layer 2.

EIP-7594: PeerDAS - Muestreo de disponibilidad de datos

Dolor: Después de que la actualización Dencun introdujo “Blob” como un almacenamiento de datos barato para Layer 2, surgió un problema central: ¿cómo garantizar que estos ingentes datos sean realmente utilizables? Actualmente, el método consiste en exigir que cada nodo validador descargue y verifique todos los datos blob que lleva un bloque. Cuando un bloque puede contener como máximo 9 Blob, este enfoque todavía es viable. Pero si en el futuro aumenta aún más la cantidad de Blob (por ejemplo, 128), descargar y verificar todos los Blob generará un costo enorme, elevando el umbral de participación para los nodos validadores y amenazando la descentralización de la red.

Solución: PeerDAS (Peer Data Availability Sampling) cambia el tradicional “chequeo completo” por “muestreo”. En términos simples:

2. La red corta los datos blob completos en fragmentos.

3. Cada validador no necesita descargar todos los blob; solo debe descargar y verificar aleatoriamente algunos fragmentos de datos.

4. Luego, todos pueden confirmar la integridad y la disponibilidad de todo el conjunto de datos blob mediante la revisión mutua y el intercambio de resultados de verificación.

Es como un juego grande de rompecabezas: cada quien tiene solo unas cuantas piezas, pero mientras todos verifiquen juntas las conexiones clave, pueden determinar que el rompecabezas completo está intacto. Cabe destacar que PeerDAS no es una invención totalmente nueva: la idea central de DAS ya se ha aplicado con éxito en proyectos de DA de terceros como Celestia. La implementación de PeerDAS se parece más a cubrir una “deuda técnica” clave en el plan de escalado a largo plazo de Ethereum.

Significado: PeerDAS reduce drásticamente la carga de almacenamiento para los validadores, eliminando los obstáculos que podrían debilitar la descentralización al permitir la expansión masiva de datos en Ethereum. En el futuro, cada bloque podría albergar cientos de Blob, apoyando la visión de Teragas de hasta 10 millones de TPS, mientras que el usuario común también podrá ejecutar un validador de forma sencilla, manteniendo la descentralización de la red.

EIP-7892: Hard fork BPO - Actualización ligera de parámetros

Dolor: La demanda del mercado por la capacidad de datos de Layer 2 cambia a una velocidad vertiginosa. Si cada vez que se ajusta el límite máximo de Blob hay que esperar una actualización grande como Fusaka, entonces es demasiado lento y no se ajusta al ritmo del desarrollo del ecosistema.

Solución: Esta EIP define un mecanismo especial de “hard fork dedicado a parámetros de Blob” (Blob Parameter Only Hardfork, BPO). Esta actualización es muy ligera: solo modifica algunos parámetros relacionados con Blob (por ejemplo, la cantidad objetivo de Blob por bloque) y no implica cambios complejos de código. Los operadores de nodos incluso no necesitan actualizar el software del cliente: solo tienen que aceptar los nuevos parámetros en el momento indicado, como si fuera tan simple como actualizar un archivo de configuración “en línea” del software.

Significado: El mecanismo BPO le da a Ethereum la capacidad de ajustar la capacidad de la red de manera rápida y segura. Por ejemplo, después de la actualización Fusaka, la comunidad planea ejecutar consecutivamente dos actualizaciones BPO en un periodo corto, duplicando gradualmente la capacidad de Blob. Esto permite a Ethereum escalar el espacio para Blob bajo demanda, con elasticidad y de forma progresiva, haciendo que los costos y el rendimiento de L2 aumenten de manera suave y con riesgos más controlables.

EIP-7918: Mercado estable de tarifas de Blob

Dolor: El mecanismo anterior para ajustar las tarifas de Blob era demasiado “según el mercado”, lo que causa algunos problemas inesperados. Primero, cuando la demanda de Blob es muy baja, el precio baja hasta casi cero, pero esto no incentiva eficazmente la creación de nueva demanda; en cambio, crea un “precio históricamente más bajo” anómalo. Al contrario, cuando la demanda es fuerte, la tarifa de blob se dispara, creando otro extremo de precio alto. Esta “canibalización por precios” hace que la planificación de costos de Layer 2 quede en una situación difícil.

Solución: La idea central de EIP-7918 es que la tarifa de Blob ya no fluctúe sin límites; en su lugar, se establece un rango de precios razonable, es decir, un consumo elástico con “piso”. El método consiste en vincular los límites superior e inferior (limits) de la tarifa blob con el costo de ejecución (execution fee) de Layer 2 en Layer 1. Ya sea actualizar la raíz de estado (state root) o verificar una prueba ZK, estos costos de ejecución son relativamente estables y no dependen mucho del volumen de transacciones dentro del bloque de L2. Por lo tanto, al vincular los límites superior e inferior de la tarifa de blob con este “ancla” estable, se evita que su precio suba y baje bruscamente.

Significado: El beneficio directo de esta mejora es que evita la “canibalización por precios” del mercado de tarifas de Blob, haciendo que el modelo de costos operativos de los proyectos de Layer 2 sea más predecible. Así, Layer 2 puede establecer comisiones de transacción más estables y razonables para los usuarios finales, evitando la experiencia tipo “gratis hoy, precio exorbitante mañana” como en una montaña rusa.

EIP-7935: Aumentar la capacidad de transacciones de la red principal

Dolor: La cantidad total de transacciones que puede contener cada bloque de Ethereum la determina el “límite máximo de Gas del bloque” (actualmente cerca de 30 millones), y durante años no se ha ajustado. Para aumentar el rendimiento de toda la red, la forma más directa es elevar ese límite. Sin embargo, debe asegurarse que** no se eleve el umbral de hardware de los validadores ni se debilite la descentralización**.

Solución: Esta propuesta sugiere elevar el límite máximo de Gas predeterminado del bloque a un nuevo nivel (el valor exacto se definirá; podría ser 45 millones o más). No es un bloqueo obligatorio, sino una recomendación de nuevos valores predeterminados que guían a los validadores del consenso para que vayan aceptando gradualmente límites de Gas más altos.

Significado: Esto significa que cada bloque de Layer 1 puede empaquetar más transacciones. El TPS de la red principal de Ethereum mejorará directamente, mitigando tanto la congestión como el aumento descontrolado de las tarifas de Gas. Por supuesto, esto también implica mayores requisitos para el hardware de los validadores, por lo que la comunidad realizará pruebas con cautela y lo avanzará paso a paso.

¡Seguridad y estabilidad! Construyendo una defensa sólida para la red

Al mismo tiempo que se escala, es imprescindible garantizar la seguridad y la estabilidad de la red. La Fundación Ethereum inició en mayo de 2025 el “Trillion Dollar Security” (1TS) con el objetivo de crear una red Ethereum capaz de soportar de forma segura activos a escala de billones de dólares. Varios EIP dentro de Fusaka son parte del avance del plan 1TS, como instalar frenos y barandas más confiables a un Ethereum que viaja a alta velocidad.

EIP-7934: Definir un límite máximo de tamaño físico del bloque

Dolor: El “límite máximo de Gas del bloque” de Ethereum solo se preocupa por la cantidad total de cómputo de todas las transacciones dentro del bloque, pero no especifica el tamaño físico del bloque. Esto crea un vacío: un atacante puede construir con cuidado muchas transacciones “de bajo costo y de gran tamaño” (por ejemplo, transferir 0 ETH a una gran cantidad de direcciones; el cómputo es muy bajo, pero los datos son enormes). Así puede empaquetar un bloque con una carga de cómputo que no supera el límite, pero con un volumen físico excepcionalmente grande. Estos bloques tipo “bomba de datos” se propagan muy lentamente por la red y podrían provocar que algunos nodos no reciban los datos a tiempo y se queden atrás, lo que constituye un riesgo serio de ataque DoS (denegación de servicio).

Solución: Establecer un límite duro (hard cap) de 10MB al tamaño de cada bloque. Cualquier bloque que supere ese volumen será rechazado por la red.

Significado: Es como definir el tamaño máximo de los camiones en una autopista, evitando que “vehículos demasiado anchos o demasiado largos” afecten el tráfico. Esto garantiza que los bloques puedan propagarse rápidamente por la red, reduce la latencia y mejora la estabilidad de la red y su resistencia a ataques.

EIP-7825: Definir un límite máximo de Gas por transacción

Dolor: Actualmente, aunque hay un límite máximo total de Gas por bloque, no existe un límite máximo por transacción individual. En teoría, alguien podría construir una transacción que consuma casi todo el recurso de un bloque, empujando fuera del bloque las transacciones de todos los demás. Esto es injusto y también representa un riesgo de seguridad.

Solución: Establecer un límite duro de 16.77 millones de Gas para cada transacción. Las operaciones complejas que excedan ese tamaño deben dividirse previamente en varias transacciones para poder presentarse.

Significado: Esto mejora la equidad y la previsibilidad de la red, asegurando que ninguna transacción pueda “reservar el salón”. Las transacciones normales de los usuarios no se verán excesivamente retrasadas debido a algún “pedido súper grande”.

EIP-7823 & EIP-7883: Fortalecimiento de seguridad para ModExp (precompilado)

Dolor: ModExp es una función en Ethereum usada para manejar operaciones modulares de exponenciación de números grandes, común en algunas aplicaciones criptográficas. Sin embargo, existen dos riesgos: primero, la longitud de los números de entrada no tiene un límite, por lo que puede ser maliciosamente configurada con entradas excesivamente grandes “para desbordar”; segundo, su estructura de tarifas de Gas es baja, lo que podría permitir que un atacante la invoque muchas veces con bajo costo, consumiendo recursos de los nodos.

Solución:

• EIP-7823: Establecer un límite superior de 8192 bits para la longitud de entrada de ModExp; esta longitud es más que suficiente para las necesidades de aplicaciones reales.

• EIP-7883: Aumentar el cobro de Gas de ModExp; en particular, para entradas más grandes, la tarifa aumentará drásticamente, asegurando que el costo de cómputo se corresponda con el consumo de recursos.

Significado: Estas dos mejoras atacan el problema desde dos frentes, eliminando un posible vector de ataque. Son como ponerle a un servicio de cómputo tanto un “máximo de carga de trabajo” como un “precio escalonado” del servicio, para evitar el abuso y, así, aumentar la solidez general de la red.

¡Actualización de funciones! Herramientas más potentes para desarrolladores

Además del escalado y la seguridad, Fusaka también trae nuevas herramientas y funcionalidades prácticas para desarrolladores, haciendo que construir aplicaciones en Ethereum sea más eficiente y potente.

EIP-7951: Compatibilidad con firmas de hardware comunes

Dolor: Los dispositivos que usamos a diario, como teléfonos (por ejemplo iPhone), llaves de U de banco (banco U盾) y módulos de seguridad de hardware, suelen tener chips de seguridad integrados que usan un estándar criptográfico llamado secp256r1 (también conocido como P-256). Ethereum, por defecto, usa otro estándar secp256k1, lo que impide que esos dispositivos comunes interactúen directamente de forma segura con Ethereum, limitando la adopción masiva de Web3.

Solución: Agregar un contrato precompilado para que Ethereum pueda soportar y verificar nativamente firmas provenientes de la curva secp256r1.

Significado: Esta es una mejora de tipo hito. Abre a Ethereum la puerta a decenas de miles de millones de dispositivos de hardware en todo el mundo. En el futuro, podrás firmar transacciones de Ethereum directamente con el chip de seguridad de tu teléfono, sin necesidad de aplicaciones de billetera adicionales ni conversiones complejas, con una experiencia más fluida y también con mayor seguridad. Esto reduce enormemente el umbral de conectar el mundo tradicional con Ethereum y es una gran ventaja para la integración de Web2 y Web3.

EIP-7939: Nueva instrucción de cómputo CLZ eficiente

Dolor: En contratos inteligentes y aplicaciones criptográficas, a menudo es necesario calcular cuántos bits cero consecutivos hay al inicio de un número de 256 bits (por ejemplo, en escenarios como algoritmos hash, algoritmos de compresión, pruebas de conocimiento cero, etc.). Actualmente, el EVM de Ethereum no tiene soporte directo en Opcode para esta operación, por lo que los desarrolladores deben implementar la lógica mediante código complejo en Solidity. Esto es costoso y poco eficiente.

Solución: Agregar en el EVM un Opcode llamado “CLZ” (Count Leading Zeros), que realice el cálculo en un solo paso.

Significado: Es como brindar a los desarrolladores una herramienta profesional que ahorra tiempo y esfuerzo. Puede reducir significativamente el costo de Gas de las operaciones relacionadas, haciendo que aquellas aplicaciones que dependen de cálculos matemáticos complejos (especialmente ZK Rollups) se ejecuten de forma más barata y más eficiente.

¡Optimización de red! Mejoras invisibles para un ecosistema más sano

Las dos últimas EIP, aunque los usuarios no las perciban directamente, son cruciales para el funcionamiento saludable a largo plazo de la red y la eficiencia de coordinación.

EIP-7642: Reducir la carga de sincronización de nodos nuevos

Dolor: Con el tiempo, Ethereum ha acumulado enormes cantidades de datos históricos. Cuando un nodo nuevo se une a la red, necesita descargar y sincronizar todos esos datos, lo cual consume tiempo y esfuerzo, elevando cada vez más el umbral. Además, desde que Ethereum pasó a consenso PoS tras The Merge, en la información de recibos de transacciones antiguas hay algunos campos que ya no son necesarios, pero se mantienen, causando redundancia.

Solución: Introducir una estrategia de “expiración de datos históricos”, para que durante la sincronización los nodos nuevos puedan saltarse algunos datos demasiado antiguos; al mismo tiempo, simplificar el formato de los recibos de transacciones, eliminando los campos redundantes que ya no se requieren. De este modo, al sincronizar desde el bloque génesis, el nodo nuevo puede evitar descargar grandes cantidades de datos inútiles.

Significado: Esta mejora permite “reducción de peso” (adelgazamiento) para la operación de nodos. En una sincronización completa del nodo se puede reducir en aproximadamente 530GB la transferencia de datos. Un umbral más bajo significa que más personas pueden ejecutar nodos, fortaleciendo la descentralización y la robustez de la red.

EIP-7917: Orden determinista de producción de bloques y preconfirmación

Dolor: Para entender la importancia de esta EIP, primero debemos hablar de un problema central de los Rollups de Layer 2 actuales: los secuenciadores centralizados (Sequencer). En la actualidad, la mayoría de Rollups dependen de una sola entidad para recibir y ordenar las transacciones L2 de los usuarios. Esto le otorga la facultad de censurar transacciones y extraer MEV, lo cual contradice el espíritu de descentralización. Para abordar este problema, la comunidad propuso la idea de Based Rollup: simplemente renunciar al secuenciador propio de L2 y usar el proposer del bloque de Ethereum L1 para ordenar las transacciones de L2, heredando así la descentralización y la neutralidad de L1.

Sin embargo, este enfoque tiene una desventaja mortal: es lento. Layer 2 tiene que esperar a que el bloque se publique en la cadena de L1 para empezar a ejecutar transacciones; la latencia es grande y la experiencia es muy mala. La única solución es introducir un mecanismo de “preconfirmación”, es decir, que el Gateway de L2 pueda obtener un compromiso anticipado del proponente futuro de L1: “Garantizo que incluiré en cadena las transacciones que envíes; si no, habrá compensación”. Así, Layer 2 puede actualizar el estado con anticipación (por ejemplo, saldos de cuentas), reduciendo la espera del usuario. Pero con el mecanismo actual de selección aleatoria del proposer, el gateway no sabe a quién tiene que “negociar”, por lo que la preconfirmación confiable no puede existir.

Solución: EIP-7917 modifica el protocolo de consenso para que, durante un periodo futuro, el orden de los Proposer pueda calcularse con anticipación de forma determinista y darse a conocer. Convierte el “sorteo en el momento” en una “tabla de turnos” de producción de bloques que todo el mundo puede verificar y que ya viene preordenada.

Significado: Esta mejora es un cimiento clave para implementar soluciones de próxima generación de descentralización como Based Rollup. Con esta “tabla de turnos”, el gateway de L2 puede identificar con antelación quién será el proponente de un bloque futuro, y negociar directamente con él, con el fin de obtener una preconfirmación confiable respaldada por penalizaciones por Slash. Esto permite que Based Rollup disfrute la descentralización y seguridad de nivel L1, al mismo tiempo que brinda a los usuarios una experiencia de transacciones casi instantánea como la de un Sequencer centralizado. En resumen, EIP-7917 sienta las bases para que el ecosistema de Ethereum avance hacia una expansión de descentralización más profunda, abriendo una puerta crucial.

¿Por qué se dice que la actualización Fusaka llega justo a tiempo?

La actualización Fusaka de esta vez no es solo una iteración técnica, sino también una actualización estratégica importante para Ethereum en el contexto de la era en la que las finanzas tradicionales están llevando a gran escala RWA y stablecoins a la cadena. Actualmente, Ethereum como campo principal de batalla ya alberga más del 56% de la oferta de stablecoins de toda la red, convirtiéndose en la capa de liquidación central para la economía digital del “dólar global”. El objetivo de Fusaka es prepararse para activos y volúmenes de transacciones de nivel “Wall Street”.

• “Combustible” de escalado infinito para cadenas Layer 2 a medida de instituciones

Con la entrada de instituciones financieras tradicionales, veremos la aparición de más cadenas Layer 2 “cadenas dedicadas” personalizadas para necesidades específicas (como el cumplimiento KYC). Estas cadenas dedicadas necesitan que la red principal de Ethereum les proporcione un espacio de almacenamiento de datos masivo, barato y seguro (es decir, Data Availability).

Las propuestas en Fusaka, como EIP-7594, EIP-7892 y EIP-7918, están precisamente pensadas para satisfacer esta demanda. Su objetivo central se resume en uno solo: reducir de forma drástica el costo de publicación de datos de Layer 2 y proporcionar una elasticidad para escalar bajo demanda.

En realidad, después de la actualización Pectra, el costo de Blob ya es muy bajo; ¿por qué seguir bajándolo? Porque Fusaka adopta una estrategia de “sacrificar ingresos por comisiones a corto plazo a cambio de una actividad económica de mayor escala”. Su intención es hacer crecer el GDP de toda la red, de modo que más transacciones se conviertan en más staking y en la quema de ETH, sustentando así el valor total de la red.

• Avanzar hacia “seguridad de un billón de dólares” y construir infraestructura financiera inconmovible

Para instituciones financieras que gestionan activos de billones, la seguridad es una línea roja infranqueable. La comunidad de Ethereum también ha propuesto un ambicioso objetivo de “seguridad de un billón de dólares”. Las EIP-7934, EIP-7825, EIP-7823 y EIP-7883 en Fusaka están destinadas a reforzar los muros, eliminar posibles riesgos de seguridad y avanzar hacia esa meta.

En resumen, la línea principal de la actualización Fusaka es clara y firme: escalado y seguridad. Impulsada tanto por beneficios regulatorios como por el entusiasmo del mercado, Fusaka llega en un momento especialmente oportuno. Ayudará a Ethereum a aprovechar el viento favorable de la política, a consolidarse como el dominador en el campo de stablecoins y activos en cadena, y a que Ethereum evolucione aún más desde “activo especulativo” hacia una infraestructura financiera convencional.

Conclusión: transformaciones de aguas quietas y corrientes profundas

Como una actualización importante a finales de 2025, Fusaka incorpora silenciosamente un fuerte motor interno a Ethereum, sin una ola de especulación y bombo mediático. Las 12 mejoras que incluye abordan de lleno los tres grandes dolores de escalado, seguridad y eficiencia. Lo que hace es ampliar la “autopista de valor” de Ethereum, mejorar su capacidad y confiabilidad, y prepararla para un futuro con millones y millones de usuarios, activos y aplicaciones.

Para el usuario común, estos cambios quizás parezcan “tranquilos”, pero su impacto será profundo. Un Ethereum más fuerte, más eficiente y más seguro podrá materializar esas grandes visiones que antes solo se podían imaginar: ya sea una red global de liquidación inmediata o “Wall Street en la cadena”. Fusaka es precisamente un paso sólido hacia ese futuro.

• Este artículo se basa en análisis de información pública y no constituye asesoramiento de inversión. Las inversiones en criptomonedas conllevan un riesgo considerable; por favor tome decisiones con cautela y haga su propia investigación (DYOR).

• Si te gusta este artículo, ¡síguelo, dale like y comparte para apoyarlo!