Autor: 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 (hacer que toda la red entienda lo que quieres hacer) y el problema de los canales de ejecución (permitir que los fondos se muevan de forma 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 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 suposiciones de confianza de puentes multisig).
Para romper este "trilema imposible", es esencial una capacidad fundamental que abarque la "aceleración" 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 Interop 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 precisamente lo que allana el mayor obstáculo de ingeniería para este final.
一、Tras 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 la misma fanfarria que la actualización Dencun en su momento. Los focos del mercado también se centraron principalmente en la expansión de Blob y PeerDAS, deleitándose con la further reducción de costos de datos de L2.
Pero fuera de este bullicio, hubo una propuesta discreta, la EIP-7825, que eliminó el mayor obstáculo para que Ethereum implemente zkEVM en L1 y las pruebas en tiempo real, e incluso podría decirse que está allanando silenciosamente el camino para 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, haciendo que la narrativa de costos en el campo de DA (Disponibilidad de Datos) se convirtiera 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 (aproximadamente 16.78 millones de Gas).
Como es bien sabido, el Límite de Gas de los bloques de Ethereum este año ya aumentó a 60 millones, pero incluso si el límite superior sigue aumentando, en teoría, si alguien está dispuesto a pagar un precio extremadamente alto por el Gas, aún podría enviar una "megatransacción (Mega-Transaction)" supercompleja, 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 transacción individual no puede exceder los 16.78 millones de Gas.
¿Y por qué restringir el tamaño de la 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á íntimamente 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 donde un camión gigante avanza muy lentamente al frente, y todos los autos pequeños detrás (otras transacciones) tienen que esperar obstruidos a que pase.
Eso, sin duda, sentenciaba a muerte la "prueba en tiempo real", porque el tiempo de generación de pruebas era completamente impredecible, pudiendo tardar decenas de minutos o más.
Después de la EIP-7825, incluso si la capacidad del bloque se amplía a 100 millones de Gas en el futuro, dado que cada transacción está limitada por fuerza a menos de 16.78 millones de Gas, cada bloque se descompone en "pequeñas unidades de tarea" predecibles, acotadas y procesables en paralelo. Esto significa que la generación de pruebas para Ethereum pasó de ser un "problema lógico" espinoso a un puro "problema de potencia de cálculo (Money Problem)":
Siempre que 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 de 100x de Ethereum. Hizo que la "prueba en tiempo real" pasara de ser "teóricamente imposible" a "programable 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.
二、zkEVM de L1: 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, esto 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: zkEVM en L1.
Durante mucho tiempo, zkEVM ha sido visto como el "santo grial" para escalar Ethereum, no solo porque resuelve cuellos de botella de rendimiento, sino porque redefine el mecanismo de confianza de blockchain. Su 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, después de ejecutar cada bloque, Ethereum podría emitir 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) genera una prueba ZK por cada bloque que empaqueta, y los nodos validadores ya no necesitan 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 zkEVM en L1 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 requeriría confiar en puentes multisig de terceros, sino confiar en la verdad matemática de la red principal de Ethereum;
Esta también 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 (zkEVM en L1), se eliminaron las restricciones físicas (EIP-7825), ¿y 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.
三、Fusaka y 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". Aunque suene a trabalenguas, la diferencia es grande y representa dos fases en el desarrollo de ZK.
La primera fase es 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 que los desarrolladores desplieguen 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, quienes 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, por razones de compatibilidad, la eficiencia probatoria 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 perdería 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 de 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 el desbloqueo?
Después de todo, 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 pequeñas unidades 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á significativamente. Cuando el costo de generar una prueba entre cadenas sea tan bajo que sea insignificante, y la velocidad sea tan rápida como enviar un correo electrónico, los "puentes entre cadenas" tradicionales desaparecerán por completo, reemplazados por protocolos de mensajería universales subyacentes.
Para Finalizar
Como se mencionó 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 de capacidades a nivel del 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在其中 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 zkEVM en L1 se convierte gradualmente en realidad, nos estamos acercando infinitamente a ese final: la ejecución, la liquidación y la prueba están completamente abstraídas en segundo plano, y el usuario no percibe en absoluto la existencia de la cadena durante todo el proceso.
Este es también el final de Interop que todos esperamos en el futuro.
