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

Chainfeeds Guía de lectura:

Sin ZK en tiempo real, es 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. Sin embargo, a diferencia de la actualización Dencun en su momento, no fue tan llamativa y la atención del mercado se centró principalmente en la expansión de Blob y PeerDAS, discutiendo entusiastamente la reducción adicional de los costes de datos en L2. Pero más allá de este bullicio, existe una propuesta poco llamativa, EIP-7825, que elimina el mayor obstáculo para que Ethereum implemente L1 zkEVM y pruebas en tiempo real, 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 expansión: la capacidad de Blob se multiplicó por 8, y junto con la verificación de muestreo aleatorio de PeerDAS, la narrativa de costes en la pista de DA (disponibilidad de datos) se ha convertido completamente en historia. De hecho, L2 más baratos son algo positivo, pero para la hoja de ruta a largo plazo de ZK en Ethereum, EIP-7825 es el verdadero cambio de juego, ya que establece un límite de Gas para cada transacción individual en Ethereum (aproximadamente 16.78 millones de Gas). Como es bien sabido, este año el Gas Limit de los bloques de Ethereum ya se ha incrementado 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 consuma todo el bloque de 60 millones de Gas, 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 los 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 EIP-7825, si un bloque contenía una "mega-transacción" que consumía 60 millones de Gas, el ZK Prover tenía que procesar secuencialmente esta transacción extremadamente compleja, sin poder dividirla ni paralelizarla. Es como una autopista de un solo carril donde un enorme camión lento bloquea a todos los coches pequeños (otras transacciones) detrás, obligándolos a esperar a que termine. Esto, sin duda, condenaba a muerte a la "prueba en tiempo real", ya que el tiempo de generación de la prueba era totalmente incontrolable, pudiendo tardar decenas de minutos o incluso más. Sin embargo, después de EIP-7825, incluso si en el futuro la capacidad de los bloques se expande a 100 millones de Gas, dado que cada transacción está limitada obligatoriamente a menos de 16.78 millones de Gas, cada bloque se divide en "pequeñas unidades de tarea" previsibles, limitadas y procesables en paralelo. Esto significa que la generación de pruebas en Ethereum pasa de ser un "problema lógico" complicado a un "problema puramente de potencia de cálculo (Money Problem)": siempre que se pueda invertir suficiente potencia de cálculo en paralelo, podremos procesar simultáneamente estas pequeñas tareas divididas en muy poco tiempo, generando así pruebas ZK para bloques enormes. Sin embargo, aunque EIP-7825 allana el camino físico (paralelización) para las pruebas en tiempo real al limitar el tamaño de cada transacció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á generar una prueba matemática verificable, permitiendo que otros nodos (especialmente los nodos ligeros y L2) confirmen la corrección del resultado sin necesidad de recalcular, simplemente verificando esta pequeña prueba matemática, si la capacidad de generar pruebas ZK se integra directamente en la capa de protocolo de Ethereum (L1), el proponente (Proposer) empaquetará cada bloque y generará una prueba ZK, y los nodos de validación ya no necesitarán volver a ejecutar las transacciones, solo tendrán que verificar esta pequeña prueba matemática.