¿OP a corto plazo, ZK a largo plazo?
Debido a que V Dios dijo esta frase, muchas personas la consideran una "regla de oro". Sin embargo, la situación real es mucho más complicada.
Las comparaciones comunes ya son malas en Internet, es decir, OP se basa en juegos < ZK se basa en matemáticas; OP1 tiene un período de retiro de dos semanas < ZK tiene un período de retiro de solo unos minutos a unas pocas horas; La compatibilidad con EVM es mejor> La compatibilidad de ZK también lo es. Hay un largo camino por recorrer... No más tonterías, los comentarios a corto y largo plazo de V God generalmente se basan en los tres fundamentos anteriores.
Sin embargo, los juegos versus las matemáticas (los usuarios no pueden experimentar ninguna diferencia y no les importa en absoluto); el período de retiro de dos semanas versus los minutos u horas: todas estas diferencias se suavizan. La compatibilidad con EVM es de hecho mejor; Ahora, pero a medida que ZK se desarrolle lentamente, esto eventualmente se solucionará.
Entonces di algo diferente
1. Lo primero es el rendimiento
Un dicho común es que el TPS de la serie ZK es mayor que el de la serie OP. La razón principal de esto es que la relación de compresión de ZK es mayor que la de OP. A L1, ZK tiene una relación de compresión más alta. La relación de compresión puede enviar más transacciones que OP y, naturalmente, la conversión a TPS es mucho mayor.
Sin embargo, esta afirmación ignora los enormes gastos generales y el tiempo que ZK necesita para generar pruebas.
Por lo tanto, es más probable que el rendimiento de OP VS ZK sea un estilo que mejora alternativamente y termina con el mismo objetivo; lo siguiente es puramente una suposición y puede no ser exacta.
1. ZK acaba de ser lanzado: OP TPS es alto porque el costo y el tiempo demostrado por ZK superan con creces las ventajas aportadas por la relación de compresión.
2. La arquitectura Prover de la serie ZK es relativamente madura: ZK TPS es alto, han aparecido máquinas ZK como FPGA o ASIC, ZK ha demostrado que el costo y el consumo de tiempo se han reducido significativamente y las ventajas de la relación de compresión han aumentado. comenzado a aparecer.
3. Pro-Danksharding está en línea: OP y ZK TPS son casi iguales, porque L1 no usa datos de llamada y usa un Blob con mucho más espacio y menor costo como DA, por lo que la ventaja de la relación de compresión será mucho menor de lo que es. Ahora era tan obvio en la era de Call Data que las ventajas de las relaciones de compresión pequeñas se compensaban básicamente con las pequeñas desventajas demostradas por ZK. Los límites teóricos de TPS de OP y ZK se limitaban básicamente a las capacidades de procesamiento del hardware de Sequencer.
2. En segundo lugar, las ventajas reales del mercado ZK.
Criptozoología > Juego, el período de retiro que es mucho menor que el OP es la ventaja técnica de ZK, pero no es necesariamente la del mercado. El mundo de blockchain nunca ha sido "solo técnico". Al igual que ETH ahora está cambiando de POW a POS, todavía hay muchas personas mayores y expertos técnicos que publican incansablemente artículos argumentando que POW es mejor que POS, y hay que admitir que muchos de sus argumentos son realmente razonables.
Pero no importa, el mercado simplemente piensa que POS es el futuro de la nueva cadena pública (excluyendo BTC).
¿Cuáles son entonces las ventajas reales de ZK en el mercado? pienso en dos
1. ZK, como el "conocimiento explícito" actual de la tecnología blockchain, puede encender una cadena industrial, al igual que POW encendió máquinas mineras (desde CPU hasta GPU, FPGA y ASIC), grupos de minería, minas e informática. Cadenas industriales ascendentes y descendentes, como los derivados, ZK también pueden conducir a una cadena industrial similar a POW y basada en la combinación de hardware desde la certificación hasta la verificación.
2. ZK puede hacer más trucos, como implementar funciones de privacidad (Aztec), como el reciente artículo de Buterin "¿Qué tipo de capa 3 tiene significado?" 》 - Menciona un escenario en el que el token nativo de Arb está "encadenado" con Optimism (método Wrap). Debido a que también depende de ETH L1, el contrato Wrap en Optimism lee el depósito cargado en L1 en el método de contrato. La prueba de recibo Merkle puede evitar por completo los puentes "inseguros" actuales. Sin embargo, en teoría, los depósitos OP tipo L2 deben esperar a que pase un período de ventana de fraude (7 días) antes de que se consideren seguros, por lo que es difícil hacerlo. Si fuera reemplazado por ZK, esta escena no sería un problema.
3. Finalmente, hablemos del final de ZK y OP.
¿Crees que ZK-sync, Scroll, etc. ya han iniciado la red de prueba Alpha y crees que ZK estará disponible pronto?
Es demasiado ingenuo. ZK todavía tiene un largo camino por recorrer. Por ejemplo, el código de circuito oficial ZKEVM de la Fundación Ethereum tiene más de 30.000 líneas. Según las palabras originales de V God, requiere "un desarrollo muy largo y pruebas continuas". implementado en unos pocos años." No se puede confiar plenamente en la seguridad proporcionada por el sistema ZK."
Por supuesto, aunque OP está por delante, aún no ha terminado su viaje. Por ejemplo, debido a que Optimisim cambió su arquitectura OVM, la función principal a prueba de fraude de OP aún no se ha lanzado y mucha gente no lo sabe.
Entonces, ¿cómo sería el final? Buterin también dio una discusión. Personalmente creo que es bastante confiable. De hecho, podría ser así en unos años.
Cómo se ve? Está todo en este hilo de discusión.
Específicamente
Antes de que zkEVM madure, OP será el principal y ZK será el complemento.
1. Publicar bloque
2. Espere 24 horas
3. Si no hay ningún desafío por fraude durante el período, libere ZKP, finalice el bloqueo,
De lo contrario (desafío), introduzca la Gobernanza y determine el resultado final a través del modelo 2 de 3.
Una vez que zkEVM madure, ZK será el principal y OP será el complemento.
1. Publicar bloque
2. Libere ZKP con regularidad
3. SI ZKP se lanza normalmente durante el período especificado, entonces Finalizar
De lo contrario (ZKP no se lanzó normalmente durante el período, ya sea que Prover fallara o se produjera un error), el sistema cambia al mecanismo Optimista hasta que se restablezca el mecanismo ZK.