Fusaka en la actualización en curso presenta la propuesta EIP-7825, que mediante la limitación del límite de Gas en una sola transacción, elimina los obstáculos para la implementación de L1 zkEVM y pruebas en tiempo real en Ethereum, convirtiendo la “prueba en tiempo real” de una imposibilidad teórica a una tarea factible de gestionar, allanando el camino para la interoperabilidad definitiva.
（Resumen previo: ¡BitMine invierte 1.1 mil millones de dólares adicionales en 33,000 ETH! Tom Lee declara: ETH ya tocó fondo）
（Información adicional: Vitalik responde al incidente de vulnerabilidad en el “cliente Prysm”: ¡Que Ethereum ocasionalmente no tenga finalidad no importa! Lo importante es no cometer errores de finalización）

Índice del artículo

• Uno, La propuesta EIP-7825, subestimada tras la actualización Fusaka
• Dos, L1 zkEVM: el “Ancla de confianza” para la interoperabilidad de Ethereum
• Tres, Fusaka y EIP-7825: la hoja de ruta de interoperabilidad que llega a su liberación
• Para terminar

En artículos anteriores de la serie Interop, exploramos por separado OIF (Marco de Intenciones) y EIL (Capa de Interoperabilidad), que resuelven respectivamente la estandarización de intenciones entre cadenas (hacer que toda la red entienda qué quieres hacer) y el problema de canales de ejecución (permitir que los fondos operen de manera estandarizada).

Pero para lograr una experiencia “de una sola cadena” perfecta, aún enfrentamos la compensación entre velocidad y confianza. Al fin y al cabo, en la experiencia actual de interoperabilidad, o se soporta lentitud (como Optimistic Rollup que requiere esperar un período de desafío de 7 días para confirmar la finalización), o se sacrifica la descentralización (dependiendo de la confianza en puentes multi-firma).

Es imprescindible romper esta “tríada imposible”, apoyándose en una hoja de ruta de interoperabilidad que cruce Ethereum con capacidades fundamentales de “aceleración” (Acceleration) y finalización (Finalisation) mediante tecnologías ZK — las “pruebas en tiempo real”.

Justo en la actualización Fusaka, la insignificante propuesta EIP-7825, elimina el mayor obstáculo técnico para esta meta final.

Uno, La propuesta EIP-7825, subestimada tras la actualización Fusaka

El 4 de diciembre, la actualización Fusaka en Ethereum se activó oficialmente en la red principal, aunque no con el mismo gran despliegue de Dencun en su lanzamiento, sino con un foco mayor en la expansión del tamaño de Blob y PeerDAS, y en reducir aún más los costos de datos en L2.

Pero detrás de este ruido, una propuesta discreta, EIP-7825, ha sido clave para despejar el mayor obstáculo para que Ethereum implemente L1 zkEVM y pruebas en tiempo real, y quizás esté allanando silenciosamente el camino para la definitiva interoperabilidad.

En esta actualización Fusaka, todos estaban concentrados en la expansión del tamaño del bloque: el capacidad de Blob se multiplicó por 8, y con la verificación mediante muestreo aleatorio PeerDAS, los costos en la carrera de la disponibilidad de datos (DA) se redujeron a historia pasada.

Por supuesto, una capa L2 más barata es buena noticia, pero para la hoja de ruta a largo plazo de Ethereum en ZK, EIP-7825 es en realidad el verdadero cambio de reglas, ya que establece un límite de Gas en una sola transacción (aprox. 17,78 millones de Gas).

Es bien sabido que el límite de Gas en bloques de Ethereum ya se ha elevado a 60 millones, pero incluso con esa tendencia, en teoría, si alguien está dispuesto a pagar un Gas Price muy alto, puede enviar una “mega-transacción” extremadamente compleja que ocupe los 60 millones de Gas de un bloque, bloqueando toda la cadena.

Antes también era posible, pero EIP-7825 introduce una restricción: independientemente del tamaño total del bloque, el consumo de Gas en una sola transacción no puede superar los 1678 millones de Gas.

¿Pero por qué limitar el tamaño de una sola transacción? En realidad, este cambio no afecta a los usuarios normales que simplemente transfieren fondos, pero para los Provers de ZK (generadores de pruebas), sí que marca la diferencia entre la vida y la muerte, y está estrechamente relacionado con cómo el sistema ZK genera la prueba.

Un ejemplo sencillo: antes de EIP-7825, si en un bloque había una mega-transacción que consumía 60 millones de Gas, el Prover de ZK tenía que procesar esa transacción complejísima en orden secuencial, sin posibilidad de dividirla o paralelizarla, como una autopista de un solo carril donde un camión gigante lento bloquea a todos los demás vehículos (otras transacciones), que deben esperar a que pase.

Esto, sin duda, condenaba a la “prueba en tiempo real” — ya que el tiempo para generar la prueba sería completamente impredecible, pudiendo tomar minutos o incluso más.

Pero tras EIP-7825, aunque el tamaño del bloque pueda aumentar a 100 millones de Gas en el futuro, cada transacción estará limitada a 16,78 millones de Gas, dividiendo efectivamente el bloque en “pequeñas tareas” previsibles, acotadas y paralelizables, transformando la generación de pruebas ZK en un problema de “poder de cómputo (Money Problem)” en lugar de un problema lógico difícil.

Mientras más poder de cómputo paralelo se invierta, más rápido podrán procesarse esas tareas divididas, permitiendo la generación de pruebas ZK para bloques enormes en muy poco tiempo.

Como dice Michael, CEO de Brevis, EIP-7825 es la actualización más subestimada en el camino hacia la expansión ZK y 100 veces más grande de Ethereum — porque permite que la “prueba en tiempo real” pase de “teóricamente imposible” a “factible desde el punto de vista técnico”, siempre que podamos resolver el problema de la capacidad de cómputo en paralelo. Incluso para bloques de 200 millones de Gas, la generación de pruebas en segundos podría ser posible.** Esto no solo supone un avance en la tecnología ZK, sino que también provee la base física para que la capa de interoperabilidad de Ethereum (EIL) pueda realizar liquidaciones entre cadenas en segundos.

Por ello, esta actualización puede parecer menor en apariencia, pero representa un avance enorme para la hoja de ruta ZK y el futuro de la expansión de Ethereum en 2026.

Dos, L1 zkEVM: el “Ancla de confianza” para la interoperabilidad de Ethereum

Pero EIP-7825, aunque allana el camino físico para la generación paralela de pruebas (limitando el tamaño de las transacciones individuales), solo es una cara de la moneda. La otra cara es: ¿cómo puede el propio Ethereum aprovechar esta capacidad?

Aquí entra en juego la narrativa más fundamental del roadmap de Ethereum: L1 zkEVM.

Desde hace tiempo, zkEVM se considera la “Santo Grial” para escalar Ethereum, no solo por su capacidad para resolver cuellos de botella en rendimiento, sino porque redefine el mecanismo de confianza en blockchain, permitiendo que la capa principal genere y verifique pruebas ZK.

En otras palabras, en el futuro, cada bloque de Ethereum, tras su ejecución, podría generar una prueba matemática verificable, que otros nodos (especialmente nodos ligeros y L2) puedan verificar sin volver a ejecutar toda la transacción — si podemos integrar esa capacidad de generación de pruebas ZK directamente en la capa de protocolo de Ethereum (L1), los validadores (Proposers) que empaqueten un bloque y generen la prueba ZK, no necesitarán volver a ejecutar las transacciones, solo verificar esa prueba matemática muy pequeña.

¿Qué significa esto para la interoperabilidad?

En el contexto de Interop, el L1 zkEVM tiene un significado mucho mayor que solo escalar: es el “Ancla de confianza” para todos los L2, porque si la capa principal puede generar pruebas en tiempo real, todos los L2 podrán verificar en tiempo real y sin confianza en el estado final del L1, y esto trae dos cambios radicales:

• Eliminación del período de desafío: la confirmación entre cadenas se reducirá de “7 días (mecanismo OP)” a “segundos (mecanismo ZK)”.
• Interconexión descentralizada: las transferencias entre cadenas ya no dependerán de confianza en terceros, sino en la veracidad matemática del L1.

Este es también el fundamento físico que permite que la capa de interoperabilidad (EIL) funcione en realidad — sin la finalización en tiempo real del L1, la interoperabilidad entre L2 siempre tendrá la sombra del retraso.

Con el objetivo (L1 zkEVM) y la capacidad física (EIP-7825) desbloqueados, ¿qué herramientas concretas existen para realizarlas?

Aquí entra en juego la evolución sutil en la pila ZK: el paso de zkEVM a zkVM.

Tres, Fusaka & EIP-7825: la hoja de ruta de interoperabilidad que llega a su liberación

Si EIP-7825 proporciona un entorno hardware “paralelizable” para ZK limitando el tamaño de las transacciones, la evolución en la pila ZK consiste en buscar “una arquitectura de software más eficiente”. Aunque puede sonar a trabalenguas, la diferencia es sustancial y marca las fases en el desarrollo de ZK.

La primera fase sería zkEVM, que puede considerarse la versión compatible o “mejorada”.

Su lógica consiste en emular cada instrucción del EVM de Ethereum para que los desarrolladores puedan desplegar directamente código Solidity, minimizando los costos y barreras de migración.

En otras palabras, zkEVM tiene la mayor ventaja de ser compatible con las aplicaciones existentes en Ethereum, reduciendo enormemente la carga para los desarrolladores en el ecosistema, quienes podrán reutilizar gran parte de la infraestructura y herramientas existentes (clientes, exploradores, depuradores, etc.).

Pero esa compatibilidad también trae un peso histórico: dado que el diseño original del EVM no contemplaba la compatibilidad con ZK, para mantenerla, la eficiencia de generación de pruebas zkEVM suele tener un techo, siendo mucho más lenta en la generación de pruebas.

Por otro lado, zkVM representa una postura más radical y revolucionaria, creando una máquina virtual (como RISC-V o WASM) que sea muy amigable con las pruebas ZK, acelerando los tiempos de generación y logrando mejor velocidad y rendimiento en la ejecución.

Pero esto puede implicar perder compatibilidad con muchas funciones del EVM y con las herramientas existentes (depuradores, etc.), aunque la tendencia actual apunta a que cada vez más proyectos L2 están despojándose de esas limitaciones, optimizando al máximo la velocidad y costo de las pruebas zkVM.

¿Y por qué decir que la actualización Fusaka desbloquea esto?

Porque antes de EIP-7825, tanto zkEVM como zkVM enfrentaban el problema de mega-transacciones en Ethereum, que no se podían dividir, y por tanto el tiempo de generación de pruebas se disparaba.

Ahora, EIP-7825 fuerza a dividir las transacciones en unidades previsibles y pequeñas, y con un entorno paralelo, arquitecturas de alta eficiencia como zkVM pueden desplegar todo su potencial, incluso en bloques complejos de Ethereum, que en combinación con el cómputo paralelo, pueden generar pruebas en tiempo real.

¿Qué significa esto para la interoperabilidad? La adopción generalizada de zkVM, junto con EIP-7825, significa que los costos de generación de pruebas se reducirán significativamente. Cuando el coste de generar una prueba de interoperabilidad sea casi cero y la velocidad sea comparable a enviar un email, los puentes tradicionales desaparecerán, reemplazados por protocolos de mensajería universales en la capa base.

Para terminar

Como reiteramos en varias de las últimas publicaciones de la serie Interop, el objetivo final de la interoperabilidad no es solo el “intercambio de activos entre cadenas”, sino la creación de un sistema completo de capacidades: comunicación de datos entre cadenas, ejecución lógica intercadena, experiencia del usuario, seguridad y consenso.

Desde esa perspectiva, interoperabilidad puede entenderse como un lenguaje universal entre los protocolos del ecosistema Ethereum, que no solo transfiere valor, sino que comparte lógica. Y en este proceso, el papel de ZK es garantizar la corrección de la ejecución, soportar la verificación de estados en tiempo real, y hacer que las llamadas entre dominios sean “posibles y confiables”. Sin ZK en tiempo real, la verdadera experiencia de interoperabilidad sería difícil de lograr.

Por eso, cuando EIP-7825 inicia silenciosamente en Fusaka, y L1 zkEVM se acerca a la realidad, estamos muy cerca de esa meta final: ejecución, liquidación y generación de pruebas completamente abstraídas en el backend, sin que los usuarios perciban la existencia de la cadena.

Ese será también el final que todos esperamos para la interoperabilidad.