La hoja de ruta de Interop se "acelera": tras la actualización de Fusaka, la interoperabilidad de Ethereum podría dar un salto clave

Guía de Chainfeeds:

Sin ZK en tiempo real, es muy difícil lograr una verdadera experiencia de usuario Interop utilizable.

Fuente del artículo:

Autor del artículo:

imToken Labs

Opinión:

imToken Labs: El 4 de diciembre, la actualización Fusaka de Ethereum se activó oficialmente en la red principal, aunque no fue tan llamativa como la actualización Dencun en su momento, y la atención del mercado se centró principalmente en la expansión de Blob y PeerDAS, celebrando la reducción adicional de los costos de datos en L2. Sin embargo, fuera de este bullicio, existe una propuesta poco llamativa, la EIP-7825, que elimina el mayor obstáculo para lograr L1 zkEVM y pruebas en tiempo real en Ethereum, e incluso se podría decir que está allanando silenciosamente el camino hacia el final de Interop. En esta actualización Fusaka, casi toda la atención se centró en la escalabilidad: la capacidad de Blob se expandió 8 veces y, junto con la verificación de muestreo aleatorio de PeerDAS, la narrativa de costos en la pista de DA (disponibilidad de datos) pasó a la historia. De hecho, L2 más baratos son algo positivo, pero para la hoja de ruta a largo plazo de ZK en Ethereum, la EIP-7825 es el verdadero cambio de juego, ya que establece un límite de Gas por transacción individual (aproximadamente 16.78 millones de Gas). Como es sabido, este año el Gas Limit de los bloques de Ethereum ya se incrementó a 60 millones, pero incluso si el límite sigue aumentando, en teoría, si alguien está dispuesto a pagar un Gas Price extremadamente alto, aún podría enviar una "Mega-Transacción" súper compleja que ocupe toda la capacidad de 60 millones de Gas del bloque, bloqueando así todo el bloque. ¿Entonces por qué limitar el tamaño de cada transacción? En realidad, este cambio no afecta en absoluto a las transferencias de usuarios comunes, pero para los ZK Prover (generadores de pruebas), es una cuestión de vida o muerte, y está estrechamente relacionado con la forma en que los sistemas ZK generan pruebas. Por ejemplo, antes de la EIP-7825, si un bloque contenía una "Mega-Transacción" que consumía 60 millones de Gas, el ZK Prover debía procesar secuencialmente esa transacción extremadamente compleja, sin poder dividirla ni paralelizarla, como si una autopista de un solo carril tuviera un camión gigante avanzando muy lento y todos los autos pequeños (otras transacciones) tuvieran que esperar detrás. Esto, sin duda, sentenciaba a muerte a la "prueba en tiempo real", ya que el tiempo para generar la prueba era completamente impredecible, pudiendo tomar decenas de minutos o incluso más. Pero después de la EIP-7825, incluso si en el futuro la capacidad del bloque se expande a 100 millones de Gas, dado que cada transacción está limitada forzosamente a 16.78 millones de Gas, cada bloque se divide en "pequeñas unidades de tarea" predecibles, acotadas y paralelizables, lo que significa que la generación de pruebas en Ethereum pasa de ser un "problema lógico" complicado a un "problema de potencia de cómputo" puro (Money Problem): siempre que se pueda invertir suficiente potencia de cómputo en paralelo, se pueden procesar simultáneamente estas pequeñas tareas divididas en muy poco tiempo, generando así pruebas ZK para bloques enormes. Sin embargo, aunque la EIP-7825, al limitar el tamaño de cada transacción, allana el camino físico para las pruebas en tiempo real (paralelización), esto es solo una cara de la moneda; la otra es cómo la red principal de Ethereum puede aprovechar esta capacidad. Esto nos lleva a la narrativa más dura de la hoja de ruta de Ethereum: L1 zkEVM. Durante mucho tiempo, zkEVM ha sido considerado el "Santo Grial" para escalar Ethereum, no solo porque puede resolver cuellos de botella de rendimiento, sino también porque redefine el mecanismo de confianza de la 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 de Ethereum, se podrá emitir una prueba matemática verificable, permitiendo que otros nodos (especialmente nodos ligeros y L2) confirmen la corrección del resultado sin necesidad de recalcular — si la capacidad de generar pruebas ZK se integra directamente en la capa de protocolo de Ethereum (L1), cada vez que un proponente (Proposer) empaquete un bloque y genere una prueba ZK, los nodos validadores ya no necesitarán volver a ejecutar las transacciones, solo tendrán que verificar esta pequeña prueba matemática.