La hoja de ruta de Interop se acelera: después de la actualización de Fusaka, la interoperabilidad con Ethereum podría dar un paso clave

Autor: imToken

Enlace:

Declaración: Este artículo es una reproducción de contenido original, los lectores pueden obtener más información a través del enlace del texto original. Si el autor tiene alguna objeción respecto a la forma de reproducción, por favor contáctenos y haremos las modificaciones según sus requisitos. La reproducción se realiza únicamente para compartir información, no constituye ningún consejo de inversión, ni representa la opinión o postura de Wu.

En artículos anteriores de la serie Interop, hemos explorado por separado OIF (Marco de Intenciones) y EIL (Capa de Interoperabilidad), que abordan respectivamente la estandarización de intenciones cross-chain (hacer que toda la red entienda qué quieres hacer) y el problema de canales de ejecución (permitiendo que los fondos operen de manera estandarizada).

Pero para lograr una «experiencia de cadena única» perfecta, aún enfrentamos el equilibrio entre velocidad y confianza. Después de todo, en la experiencia actual de interoperabilidad, o bien toleramos lentitud (como Optimistic Rollup, que requiere esperar 7 días de período de desafío para confirmar la finalización), o bien sacrificamos la descentralización (dependiendo de la confianza en puentes multisig).

Romper esta «tríada imposible» requiere una hoja de ruta de interoperabilidad en Ethereum que incluya «Aceleración» y capacidades fundamentales para la finalización — la «prueba en tiempo real» que trae la tecnología ZK (lectura adicional: «Hoja de ruta de Interoperabilidad de Ethereum: cómo desbloquear la última milla para una adopción masiva»).

Y en la reciente actualización Fusaka, la modesta EIP-7825, ha despejado el mayor obstáculo técnico para este objetivo final.

1. Detrás de la actualización Fusaka, la subestimada EIP-7825

El 4 de diciembre, la actualización Fusaka de Ethereum se activó oficialmente en la red principal, aunque no con el mismo bombo que la actualización Dencun de hace unos años. La atención del mercado se centró en la expansión de Blob y PeerDAS, y en la reducción de costos de datos en L2.

Pero más allá del ruido, hay una propuesta discreta, EIP-7825, que despeja el mayor obstáculo para que Ethereum implemente zkEVM en L1 y la prueba en tiempo real, e incluso puede estar allanando silenciosamente el camino para la hoja de ruta final de Interoperabilidad.

En esta actualización Fusaka, casi todos los focos estaban en la expansión de capacidad: Blob se amplía 8 veces, junto con la verificación mediante muestreo aleatorio PeerDAS, haciendo que los costos en la pista de disponibilidad de datos (DA) sean historia.

Por supuesto, L2 más barato es positivo, pero para la hoja de ruta a largo plazo de Ethereum en ZK, EIP-7825 es el verdadero cambio de reglas, porque establece un límite de Gas para cada transacción individual (aproximadamente 16.78 millones de Gas).

Se sabe que el límite de Gas en bloques de Ethereum ya se elevó a 60 millones este año, pero incluso con límites crecientes, en teoría, si alguien está dispuesto a pagar un Gas Price muy alto, puede enviar una «mega-transacción» extremadamente compleja que ocupe todo el bloque (60 millones de Gas), bloqueando toda la red.

Antes esto también era posible, pero EIP-7825 introduce una restricción: independientemente del tamaño del bloque, una sola transacción no puede consumir más de 16.78 millones de Gas.

¿Y por qué limitar el tamaño de una transacción? En realidad, este cambio no afecta a los usuarios normales en transferencias, pero para los Provers de ZK (generadores de pruebas), sí marca la diferencia entre la vida y la muerte, ya que está estrechamente relacionado con la forma en que los sistemas ZK generan las pruebas.

Por ejemplo, antes de EIP-7825, si un bloque contenía una mega-transacción que consumía 60 millones de Gas, el ZK Prover debía procesar esa transacción extremadamente compleja en orden secuencial, sin poder dividirla ni paralelizarla. Era como una autopista de un solo carril con un camión gigante que va muy lento, y todos los demás vehículos (otras transacciones) deben esperar a que pase.

Esto prácticamente condenaba a la «prueba en tiempo real», ya que el tiempo para generar la prueba era totalmente impredecible, pudiendo tomar decenas de minutos o más.

Pero tras EIP-7825, incluso si en el futuro el tamaño del bloque aumenta a 100 millones de Gas, cada transacción estará limitada a 16.78 millones, dividiendo cada bloque en «pequeñas tareas» predecibles, acotadas y paralelizables. Esto convierte la generación de pruebas ZK en un problema de «poder de cómputo» más que de lógica difícil.

Mientras se pueda aportar suficiente poder de cómputo paralelo, se podrán procesar en paralelo estas pequeñas tareas, permitiendo generar pruebas ZK para bloques muy grandes en segundos.

Como dice Michael, cofundador y CEO de Brevis, EIP-7825 es la actualización más subestimada en el camino hacia la expansión 100x de ZK y Ethereum. Hace que la «prueba en tiempo real» pase de ser «teóricamente imposible» a «factible en ingeniería», y si podemos resolver el problema del poder de cómputo en paralelo, incluso bloques de 200 millones de Gas podrían generar pruebas en segundos. Esto no solo representa un avance en la tecnología ZK, sino que también sienta la base física para que la capa de interoperabilidad de Ethereum (EIL) pueda realizar liquidaciones cross-chain en segundos.

Por eso, esta actualización puede parecer menor, pero en realidad es un gran avance para la hoja de ruta ZK y el futuro de la expansión de Ethereum en 2026.

2. L1 zkEVM: el «pilar de confianza» para la interoperabilidad de Ethereum

Aunque EIP-7825, limitando el tamaño de las transacciones, allana el camino para la prueba en tiempo real (paralelizable), la otra cara de la moneda es: ¿cómo puede la propia red principal de Ethereum aprovechar esta capacidad?

Aquí entra la narrativa más fundamental en la hoja de ruta de Ethereum: L1 zkEVM.

Desde hace tiempo, zkEVM se considera el «Santo Grial» para ampliar Ethereum, no solo por resolver cuellos de botella de rendimiento, sino también por redefinir el mecanismo de confianza en blockchain. La idea central es que la red principal de Ethereum pueda generar y verificar pruebas ZK.

En otras palabras, en el futuro, cada bloque de Ethereum podría producir una prueba matemática verificable, que otros nodos (especialmente los ligeros y L2) puedan verificar sin volver a calcular todo. Si la capacidad de generar pruebas ZK se incorpora directamente en la capa de protocolo (L1), el proponente (Proposer) que empaqueta un bloque y genera la prueba ZK, no necesitará que los nodos verificadores vuelvan a ejecutar las transacciones, solo verificar esa pequeña prueba matemática.

¿Y qué significa esto para la interoperabilidad?

En el contexto de Interop, L1 zkEVM tiene un significado mucho más allá de la expansión: es el «pilar de confianza» de todos los L2. Si la capa principal puede generar pruebas en tiempo real, todos los L2 podrán leer el estado final de L1 en tiempo real y sin confianza, lo que provocará dos cambios radicales:

· Eliminación del período de desafío: la confirmación entre cadenas pasará de «7 días (mecanismo OP)» a «segundos (mecanismo ZK)»;

· Interconexión descentralizada: los puentes entre cadenas ya no necesitarán confiar en terceros, sino en la verdad matemática de Ethereum.

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

Con el objetivo (L1 zkEVM) y la restricción física (EIP-7825) en su lugar, ¿qué herramientas concretas tenemos?

Aquí entra la evolución sutil en la pila tecnológica ZK: de zkEVM a zkVM.

3. Fusaka & EIP-7825: la hoja de ruta de interoperabilidad se libera

Si EIP-7825 proporciona un «entorno de hardware paralelo» para ZK limitando el tamaño de las transacciones, la evolución en la pila ZK busca «arquitecturas de software más eficientes». Aunque parezca un trabalenguas, en realidad representan dos fases en el desarrollo de ZK (lectura adicional: «El amanecer de la hoja de ruta ZK: ¿se acelera la hoja de ruta de la finalización de Ethereum?»).

La primera fase es zkEVM, que puede considerarse como una versión compatible o mejorada.

Su lógica es imitar cada instrucción de la EVM de Ethereum, permitiendo a los desarrolladores desplegar código Solidity directamente, reduciendo costos y barreras de migración.

En otras palabras, la mayor ventaja de zkEVM es la compatibilidad con las aplicaciones existentes en Ethereum, lo que reduce significativamente la carga de trabajo para los desarrolladores del ecosistema, quienes pueden reutilizar gran parte de su infraestructura y herramientas (clientes de ejecución, exploradores, herramientas de depuración, etc.).

Pero esto también tiene un inconveniente: dado que la EVM no fue diseñada pensando en ZK, la eficiencia de las pruebas suele tener un límite, y el tiempo de generación de pruebas es mucho mayor, con cargas históricas que arrastrar.

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

Pero también pierde compatibilidad con muchas funciones de EVM y la capacidad de usar herramientas existentes (como depuradores de bajo nivel). Sin embargo, la tendencia actual es que cada vez más proyectos L2 dejan atrás esas limitaciones, optimizando al máximo la velocidad y el costo de las pruebas, explorando arquitecturas basadas en zkVM.

¿Y por qué decir que la actualización Fusaka es un desbloqueador?

Porque, antes de EIP-7825, tanto zkEVM como zkVM, al enfrentarse a mega-transacciones en Ethereum, no podían dividir tareas, lo que provocaba un aumento exponencial en el tiempo de generación de pruebas.

Ahora, con EIP-7825, las transacciones se dividen en unidades pequeñas y predecibles, y con un entorno paralelo, arquitecturas como zkVM pueden aprovechar al máximo esa capacidad, incluso en bloques complejos, logrando pruebas en tiempo real mediante cómputo paralelo.

¿Y qué implica esto para la interoperabilidad? La adopción de zkVM, junto con EIP-7825, reducirá drásticamente los costos de generación de pruebas. Cuando el costo de generar pruebas cross-chain sea insignificante 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.

En conclusión

Como se ha mencionado en varias ocasiones en esta serie sobre Interop, el objetivo final no es solo la transferencia de activos entre cadenas, sino un sistema completo de capacidades: comunicación de datos cross-chain, ejecución lógica, experiencia de usuario, seguridad y consenso.

Desde esta perspectiva, Interop puede entenderse como un lenguaje universal entre los protocolos del ecosistema Ethereum del futuro. Su importancia no solo radica en transferir valor, sino en compartir lógica, y el papel de ZK es garantizar la corrección de la ejecución, soportar la validación en tiempo real del estado, y hacer que las llamadas cross-domain sean «valientes y posibles». Sin ZK en tiempo real, será muy difícil tener una verdadera experiencia de Interop usable.

Por eso, con la activación silenciosa de EIP-7825 en Fusaka y la progresiva realización de L1 zkEVM, estamos cada vez más cerca de ese final: la ejecución, liquidación y generación de pruebas se abstraen completamente en segundo plano, y los usuarios no perciben la existencia de la cadena.

Ese será, sin duda, el final que todos esperamos para la interoperabilidad.