Un póster del lanzamiento de Polygon zkEVM provocó una gran discusión entre los fundadores de la cadena pública sobre la escalabilidad

El 26 de febrero, un cartel promocional que anunciaba el lanzamiento de la red principal de Polygon zkEVM provocó un debate sobre el uso del término equivalencia “Ethereum”, y Ye Zhang, el fundador de Scroll, señaló solemnemente que Polygon zkEVM no tiene esta característica. En retrospectiva, Ryan Wyatt, jefe de Polygon Labs, respondió que esto era más el resultado de una mala comunicación entre los especialistas en marketing y los técnicos dentro del equipo.

Este no es un asunto trivial, y el alcance de la efectividad incluso estará directamente relacionado con el rendimiento y la escalabilidad de L1/L2, hace solo dos días, el cocreador de Solana, Toly, publicó un artículo en el que afirmaba que ZK L2s no será la mejor solución para resolver la escalabilidad.

El 27 de febrero, el equipo técnico de Polygon, protagonista de este evento, también respondió activamente al principio de funcionamiento de zkRollup, explicando hacia dónde apunta la escalabilidad de zkRollup.

El 1 de marzo, Solana también anunció un “plan para mejorar la actualización de la red” para volver a llevar el estandarte del asesino de Ethereum, pero su mecanismo operativo no se ha innovado fundamentalmente después de múltiples interrupciones, y se parece más a una optimización posterior a la crisis, que también arroja una sombra sobre el reemplazo de Ethereum por L1 de alto rendimiento.

Este artículo combinará los tweets de varios fundadores de L1/L2 para revelar los entresijos de la gran discusión sobre el desempeño de las cadenas públicas.

Orígenes: El debate sobre la equivalencia de EVM

El zkEVM de Polygon, estrictamente hablando, es un mecanismo zk VM, que es consistente con la red principal de Ethereum en el nivel L2 a través del mapeo, y la introducción de la tecnología zk es la razón por la que se llama zk VM, y en un sentido no estricto, siempre que pueda mantener la sincronización, entonces es inofensivo llamarlo zk EVM.

Sin embargo, según Ye Zhang, fundador de Scroll, la equivalencia de EVM no es exactamente lo mismo que la equivalencia de Ethereum, porque esta última debe ser al menos coherente con la red principal de Ethereum en términos de almacenamiento de datos.

Desde una perspectiva más amplia, ninguno de los actuales puentes de cadena cruzada de Ethereum o L2 puede pretender ser equivalente a Ethereum, y las pilas más modulares y complejas de Ethereum traerán una compatibilidad más difícil.

Se puede dar un ejemplo sencillo para entender intuitivamente la diferencia entre ambos, Optimism se ocupa de la diferencia entre ambos en la planificación de productos, en su opinión:

Equivalencia de EVM: Principalmente desde la perspectiva de los desarrolladores de dApps, su experiencia en OVM no es diferente de la de desarrollar dApps en la red principal de Ethereum, por lo que OVM tiene equivalencia de EVM;

Equivalencia de Ethereum: Principalmente desde la perspectiva de los desarrolladores de protocolos, es necesario mantener un alto grado de coherencia con Ethereum en términos de cliente, capa de comunicación, capa de consenso y capa de ejecución.

Además del debate sobre la equivalencia de EVM, también hay que tener en cuenta que la controversia sobre la escalabilidad es actualmente el foco de la batalla entre la L2 basada en Ethereum y la L1 de alto rendimiento.

Antecedente: Dudas de Solana sobre la escalabilidad de ZK

El 24 de febrero, dos días antes del lanzamiento del tráiler de Polygon zkEVM, el cocreador de Solana, Toly, publicó una publicación en Twitter en la que cuestionaba la capacidad de los ZK L2 para resolver el problema del escalado de la cadena pública, con el fin de compensar las dudas del público sobre el mecanismo de funcionamiento de Solana.

Sus puntos principales son los siguientes:

• La carga de datos en tiempo real a la cadena requiere capacidades de ejecución secuencial estables;
• El esquema de prueba de ZK es válido, siempre que la suma del tiempo de generación de la prueba de ZK + el tiempo de verificación sea menor que el tiempo de ejecución en tiempo real;
• La solución ZK no puede procesar grandes cantidades de datos en tiempo real y solo puede realizar agregación intermitente, pero no puede mantener el estado en tiempo real del estado en cadena;

Por lo tanto, la solución ZK es más adecuada para escenarios únicos y de baja frecuencia, como la liquidación por lotes, mientras que Solana sigue siendo necesaria para la escalabilidad de la cadena pública.

Desafortunadamente, Solana sufrió una grave interrupción el 25 de febrero, y la comunidad, los ingenieros y los validadores recuperaron la red principal después de dos reinicios, y la fuga de la casa coincidió con la lluvia de la noche a la mañana, y los “bienhechores” aprovecharon la oportunidad para cuestionar el mecanismo de Solana, con el usuario de Twitter DBCryptoX argumentando que “el 90-95% de las transacciones en Solana contienen mensajes de validador y votación en cadena”.

Solana utiliza un mecanismo de consenso PoS, que se autodenomina mecanismo de “prueba de historia”. PoH permite que la red funcione más rápido porque los nodos no necesitan comunicarse para validar un bloque, y PoH permite a los validadores identificar eventos en un momento determinado.

Por un lado, este mecanismo aporta un alto grado de uniformidad, llevando el TPS mucho más allá de la red principal de Ethereum, pero por otro lado, ocupa mucho espacio en bloque en la cadena, y una vez que algo sale mal, es difícil llegar a un consenso para restaurar la red. Se produjo al menos un evento de interrupción de la red principal por año durante al menos 2021-2023.

El evento de interrupción ha contribuido con una lección negativa a la escalabilidad de Solana. El cocreador de Solana, Toly, cree que el probador en ZK L2 no se puede ejecutar en tiempo real, por lo que la ejecución final en cadena de ZK L2 no estará en el orden establecido, por lo que los usuarios pueden ejecutar nodos completos para aumentar la carga en la red, o confiar en unos pocos nodos honestos para mejorar la eficiencia y centralizarse.

Sin embargo, resulta que la Solana L1 de alto rendimiento no parece resolver el problema de la ejecución en tiempo real, después de todo, una red colapsada eventualmente perderá el orden establecido y los datos recuperados a la fuerza se convertirán en un “consenso” artificial en lugar del estado espontáneo de la red en sí.

Consecuencias: La escalabilidad de Polygon es crítica

Polygon zkEVM fue interrogado primero por Solana y luego anunció que hubo un incidente oolong, que se sospechaba que era poco profesional y engañoso. Así que el desarrollador, Jordi Baylina, se lanzó y asumió el reto de la profesionalidad, centrándose en explicar que el probador no es el factor limitante para los ZK L2, y que el verdadero obstáculo es la DA (disponibilidad de datos).

El primero es el proceso de operación de zkRollup, que se puede dividir aproximadamente en tres pasos, como se muestra en la siguiente figura:

Mantener la red sincronizada, independientemente de la arquitectura del rollup, siempre que los datos de L2 estén involucrados, debe demostrar la validez del lote de mensajes para que puedan confirmarse cuando finalmente se devuelvan a L1.

La generación de pruebas agregadas requiere el uso del esquema de prueba zk (ZKP), que puede acelerarse mediante el procesamiento paralelo, pero la generación de pruebas por lotes en sí misma lleva algún tiempo. Incluso es posible diseñar mecanismos dinámicos donde se puede aumentar o disminuir el número de probadores de red en función de las necesidades de la red.

Una vez que ZKP se está ejecutando, se genera una red completa a prueba de árboles para los datos, lo que permite que diferentes servidores verifiquen los datos y envíen los resultados a la cadena L1.

El segundo es el problema del costo, el más crítico de los cuales es el costo de prueba, el software, el hardware y el tiempo de la llamada de operación de ZK se incluirán en el factor de cálculo por la tarifa TX (transacción), y finalmente se reflejarán en la tarifa de gas de la red, y diferentes algoritmos, como STARK / SNARK / FLONK, etc., optimizarán en gran medida el costo de uso de la red. El punto clave es que no es necesario realizar la carga de datos de forma secuencial para facilitar la paralelización.

Por lo tanto, el probador que Solana cree que no puede obstaculizar el funcionamiento de las pruebas ZK, y el verdadero obstáculo es la disponibilidad de datos, que debe resolverse con ETH 2.0, DankSharding, EIP4844 y otras soluciones.

Conclusión: ¿Hacia dónde se dirige la escalabilidad?

El debate en torno a Polygon zkEVM continuará, y la clave estará en qué tan bien zk EVM puede resolver el problema actual de escalabilidad, que será la próxima prueba para que las L1/L2 se enfrenten con dApps y usuarios a gran escala.