Escrito por: imToken
En artículos anteriores de la serie Interop, exploramos OIF (Marco de Intenciones) y EIL (Capa de Interoperabilidad), que abordan respectivamente la estandarización de intenciones entre cadenas (para que toda la red entienda lo que quieres hacer) y el problema del canal de ejecución (para que los fondos puedan moverse de manera estandarizada).
Pero para alcanzar la experiencia perfecta de «cadena única», aún enfrentamos la disyuntiva entre velocidad y confianza. Después de todo, en la experiencia de interoperabilidad actual, o se tolera la lentitud (como Optimistic Rollup, que requiere un período de desafío de 7 días para confirmar la finalidad) o se sacrifica la descentralización (confiando en la suposición de confianza de los puentes de múltiples firmas).
Para romper este «trilema», es fundamental una capacidad básica que abarque la «aceleración» (Acceleration) y la finalización (Finalisation) en la hoja de ruta de interoperabilidad de Ethereum: la «prueba en tiempo real» que ofrece la tecnología ZK (lectura extendida: «Hoja de ruta de Interoperabilidad de Ethereum: Cómo desbloquear la 'última milla' para la adopción masiva»).
Y en la reciente activación de la actualización Fusaka, la discreta EIP-7825, es la que allana el mayor obstáculo de ingeniería para este final.
1. EIP-7825, subestimada tras la actualización Fusaka
El 4 de diciembre, la actualización Fusaka de Ethereum se activó oficialmente en la red principal, pero a diferencia de la gran expectación de la actualización Dencun en su momento, el foco del mercado se centró principalmente en la expansión de Blob y PeerDAS, comentando con entusiasmo la further reducción de costos de datos en L2.
Pero fuera de este bullicio, hubo una propuesta discreta, la EIP-7825, que eliminó el mayor obstáculo para que Ethereum implemente L1 zkEVM y las pruebas en tiempo real, e incluso podría decirse que está allanando silenciosamente el camino hacia el final de Interop.
En esta actualización Fusaka, el foco de atención estuvo casi por completo en la escalabilidad: la capacidad de Blob se expandió 8 veces, combinada con la verificación de muestreo aleatorio PeerDAS, lo que convirtió la narrativa de costos del sector DA (Disponibilidad de Datos) en historia.
Ciertamente, L2 más baratos son buenos, pero para la hoja de ruta ZK a largo plazo de Ethereum, la EIP-7825 es la verdadera cambiadora de reglas del juego, porque establece un límite máximo de Gas por transacción individual en Ethereum (aproximadamente 16.78 millones de Gas).
Como es sabido, el Límite de Gas de los bloques de Ethereum se incrementó este año a 60 millones, pero incluso aunque el límite superior sigue aumentando, en teoría, si alguien está dispuesto a pagar un precio de Gas extremadamente alto, aún podría enviar una «megatransacción (Mega-Transaction)» súper compleja, ocupando directamente toda la capacidad de 60 millones de Gas del bloque, obstruyendo así todo el bloque.
Esto estaba permitido antes, pero la EIP-7825 introduce una nueva restricción: sin importar cuán grande sea el bloque, el consumo de una sola transacción no puede superar los 16.78 millones de Gas.
¿Por qué restringir el tamaño de una transacción individual? En realidad, este cambio no afecta en absoluto las transferencias de usuarios comunes, pero para el ZK Prover (generador de pruebas) es la diferencia entre la vida y la muerte, y también está relacionado con la forma en que los sistemas ZK generan pruebas.
Por ejemplo, antes de la EIP-7825, si un bloque contenía una «megatransacción» que consumía 60 millones de Gas, el ZK Prover tenía que ejecutar secuencialmente esta transacción extremadamente compleja, sin poder dividirla ni paralelizarla. Esto es como una autopista de un solo carril con un camión gigante muy lento al frente; todos los coches detrás (otras transacciones) tendrían que esperar obstruidos a que pasara.
Eso, sin duda, habría sido una sentencia de muerte para las «pruebas en tiempo real», porque el tiempo de generación de pruebas sería completamente impredecible, pudiendo tardar decenas de minutos o más.
Después de la EIP-7825, incluso si la capacidad de los bloques se amplía a 100 millones de Gas en el futuro, dado que cada transacción está limitada forzosamente a 16.78 millones de Gas, cada bloque se descompone en «unidades de tarea» pequeñas, predecibles, acotadas y procesables en paralelo. Esto significa que la generación de pruebas en Ethereum pasó de ser un «problema lógico» espinoso a un puro «problema de potencia de cálculo (Money Problem)»:
Mientras se pueda invertir suficiente potencia de cálculo paralelo, podremos procesar simultáneamente estas pequeñas tareas divididas en muy poco tiempo, generando así pruebas ZK para bloques enormes.
Como dijo Michael, cofundador y CEO de Brevis, la EIP-7825 es la actualización más subestimada en el camino futuro de ZK y la escalabilidad 100x de Ethereum. Hizo que las «pruebas en tiempo real» pasaran de ser «teóricamente imposibles» a ser «programables en ingeniería». Siempre que podamos resolver el problema de la potencia de cálculo mediante computación paralela, incluso bloques de 200 millones de Gas podrían lograr pruebas en segundos. Esto no es solo un avance para la tecnología ZK, sino también la base física para que la capa de interoperabilidad de Ethereum (EIL) pueda lograr liquidación entre cadenas en segundos.
Así que esta actualización puede no parecer la protagonista, pero en realidad es un gran avance para la hoja de ruta ZK y el futuro de la escalabilidad de Ethereum en 2026.
2. L1 zkEVM: El «punto de anclaje de confianza» para la interoperabilidad de Ethereum
Sin embargo, aunque la EIP-7825 allanó el camino físico (paralelizable) para las pruebas en tiempo real al limitar el tamaño de las transacciones individuales, esta es solo una cara de la moneda. La otra cara es: ¿cómo utiliza la red principal de Ethereum esta capacidad?
Esto nos lleva a la narrativa más hardcore de la hoja de ruta de Ethereum: L1 zkEVM.
Durante mucho tiempo, zkEVM ha sido visto como el «santo grial» para escalar Ethereum, no solo porque resuelve los cuellos de botella de rendimiento, sino porque redefine el mecanismo de confianza de la blockchain. La idea central es dotar a la red principal de Ethereum de la capacidad de generar y verificar pruebas ZK.
En otras palabras, en el futuro, cada bloque de Ethereum, después de ejecutarse, podría generar una prueba matemática verificable, permitiendo que otros nodos (especialmente nodos ligeros y L2) confirmen la exactitud del resultado sin necesidad de recalcular. Si la capacidad de generar pruebas ZK se integra directamente en la capa de protocolo de Ethereum (L1), el proponente (Proposer) que empaqueta un bloque y genera una prueba ZK, los nodos validadores ya no necesitarían reprocesar las transacciones, solo verificar esta pequeña prueba matemática.
¿Qué significa esto para la interoperabilidad?
En el contexto de Interop, el significado de L1 zkEVM va mucho más allá de la escalabilidad misma. Podría decirse que es el «punto de anclaje de confianza» para todas las L2. Después de todo, si Ethereum L1 puede generar pruebas en tiempo real, significa que todas las L2 pueden leer el estado final de L1 de forma instantánea y sin confianza. Esto traería dos cambios cualitativos:
-
Eliminar el período de desafío: El tiempo de confirmación entre cadenas se comprimiría de «7 días (mecanismo OP)» a «segundos (mecanismo ZK)»;
-
Interconexión descentralizada: La interoperabilidad entre cadenas ya no dependería de confiar en puentes de múltiples firmas de terceros, sino en la verdad matemática de la red principal de Ethereum;
Esta es la base física de la que hablamos en el artículo anterior para que la EIL (Capa de Interoperabilidad) funcione realmente: sin la finalidad (Finality) en tiempo real de L1, la interoperabilidad entre L2 nunca se liberará de la sombra del «retraso».
Tenemos el objetivo (L1 zkEVM), se eliminaron las limitaciones físicas (EIP-7825), entonces, ¿cuáles son las herramientas de implementación específicas?
Esto nos lleva a la sutil evolución que está ocurriendo en la pila tecnológica ZK: el cambio de zkEVM a zkVM.
3. Fusaka & EIP-7825: La hoja de ruta de interoperabilidad alcanza la liberación
Si la EIP-7825 proporciona el «entorno hardware paralelizable» para ZK al limitar el tamaño de las transacciones individuales, la evolución de la pila tecnológica ZK busca encontrar una «arquitectura de software más eficiente». Esto puede sonar a trabalenguas, pero la diferencia es grande y representa dos fases en el desarrollo de ZK (lectura extendida: «'Momento del Amanecer' de la ruta ZK: ¿La hoja de ruta del final de Ethereum se acelera por completo?»).
La primera fase fue naturalmente zkEVM, que puede considerarse la facción compatible o reformista.
La lógica es esforzarse por imitar cada instrucción de la EVM de Ethereum, permitiendo a los desarrolladores desplegar código Solidity directamente, reduciendo los costos y barreras de migración.
En otras palabras, la mayor ventaja de zkEVM es su compatibilidad con las aplicaciones existentes de Ethereum, reduciendo enormemente la carga de trabajo para los desarrolladores del ecosistema Ethereum, que pueden reutilizar la mayoría de las infraestructuras y herramientas existentes (incluidos clientes de ejecución, exploradores de bloques, herramientas de depuración, etc.).
Sin embargo, precisamente por eso, dado que la EVM no se diseñó originalmente teniendo en cuenta la compatibilidad con ZK, para mantenerla, la eficiencia de prueba de zkEVM a menudo tiene un techo, y el tiempo de prueba es mucho más lento, con una pesada carga histórica.
Mientras que zkVM pertenece a la facción revolucionaria radical, construyendo directamente una máquina virtual extremadamente amigable con las pruebas ZK (como basada en RISC-V o WASM) para acelerar el tiempo de prueba y lograr una mejor velocidad y rendimiento de ejecución.
Pero también se pierde compatibilidad con muchas funciones de EVM y la capacidad de usar herramientas existentes (como depuradores de bajo nivel). Sin embargo, actualmente una tendencia clara es que cada vez más proyectos L2 comienzan a deshacerse del lastre, optimizando al máximo la velocidad y el costo de las pruebas, explorando arquitecturas basadas en zkVM.
Entonces, ¿por qué se dice que la actualización Fusaka es la llave?
Porque antes de la EIP-7825, tanto zkEVM como zkVM, al encontrarse con megatransacciones en Ethereum, sufrían un aumento explosivo en el tiempo de generación de pruebas debido a la incapacidad de dividir las tareas.
Ahora, la EIP-7825 obliga a descomponer las transacciones en unidades pequeñas y predecibles. Con un entorno paralelizable, arquitecturas eficientes como zkVM pueden desplegar su máximo poder. Incluso bloques complejos de Ethereum, al ser procesados en zkVM con potencia de cálculo paralela, pueden lograr pruebas en tiempo real.
¿Qué significa esto para la interoperabilidad? La popularización de zkVM combinada con la EIP-7825 significa que el costo de generar pruebas disminuirá drásticamente. Cuando el costo de generar una prueba entre cadenas sea tan bajo que sea insignificante, y la velocidad sea como enviar un correo electrónico, los «puentes» tradicionales entre cadenas desaparecerán por completo, reemplazados por protocolos de mensajería universales en la capa subyacente.
Para concluir
Como se ha mencionado repetidamente en los artículos anteriores de la serie Interop, el objetivo final de Interop no es solo la «interoperabilidad entre cadenas» de activos, ni se limita al concepto de «puente de activos», sino que es un conjunto completo de capacidades a nivel de sistema, que incluye comunicación de datos entre cadenas, ejecución lógica entre cadenas, experiencia de usuario entre cadenas, seguridad y consenso entre cadenas.
Desde esta perspectiva, Interop puede entenderse como el lenguaje universal futuro entre los protocolos del ecosistema Ethereum. Su significado no solo radica en transmitir valor, sino también en compartir lógica. El papel de ZK en esto es garantizar la corrección de la ejecución, respaldar la verificación de estado en tiempo real y hacer que las llamadas entre dominios sean «atrevidas y factibles». Incluso podría decirse que sin ZK en tiempo real, es difícil tener una UX de Interop realmente utilizable.
Por lo tanto, cuando la EIP-7825 se activó silenciosamente en la actualización Fusaka, cuando L1 zkEVM se convierte gradualmente en realidad, nos estamos acercando infinitamente a ese final: la ejecución, la liquidación y las pruebas se abstraen por completo en segundo plano, y el usuario no percibe en absoluto la existencia de la cadena.
Este es el final de Interop que todos esperamos en el futuro.
