[¿Es perfecta la prueba de fraude de ZK?] Una buena investigación de @GCdePaula_: profundicemos en la seguridad de los protocolos actuales a prueba de fraude de ZK.

En primer lugar, incluso si se utilizan pruebas de fraude de ZK, el período de impugnación no se puede acortar. Esto se debe a que las pruebas de fraude de ZK no resuelven los fuertes ataques de censura. En otras palabras, la lógica es que simplemente enviar una transacción una vez no es suficiente para reducir el período de desafío.

Además, los mecanismos actuales, como el simple juego de disputas a prueba de fraude ZK de OP Kailua, no pueden detener los ataques de agotamiento. Un escenario de ataque en OP Kailua podría verse así:

1. El atacante publica continuamente raíces de estado no válidas en OP Kailua. Antes de publicar, el atacante calcula previamente las pruebas ZK que refutarían sus propias raíces de estado no válidas. 2. Un defensor honesto responde generando una prueba ZK para desafiar la raíz del estado inválido.

3. Mientras el defensor sigue generando la prueba ZK, el atacante envía la prueba ZK precalculada para refutar su propia raíz de estado y finaliza el juego de disputa. El defensor pierde los recursos gastados en generar su prueba ZK.

4. En OP Kailua, la fianza de la parte perdedora se paga al ganador. Dado que el atacante se ha refutado a sí mismo, no pierde ningún vínculo.

Aquí, el atacante gasta los costos de generación de pruebas ZK + los costos de verificación, mientras que el defensor asume el costo de generación de pruebas ZK.

Si el atacante tiene más capital que el defensor por al menos N veces el costo de verificación de la prueba, el atacante puede repetir este ciclo hasta que el defensor se quede sin fondos. En ese momento, el atacante puede publicar una raíz de estado malintencionado y drenar todos los activos del resumen.

Esto ilustra efectivamente que los protocolos a prueba de fraude de ZK requieren consideraciones de seguridad más matizadas de lo que uno podría suponer. Lograr una seguridad más sólida requerirá medidas de diseño adicionales.

Las pruebas de fraude ZK ya están siendo adoptadas por rollups en vivo como BOB, y son un mecanismo central que los L2 de próxima generación como MegaETH planean integrar. Al perseguir estándares de seguridad más altos, podemos ofrecer un producto mucho más robusto y listo para la producción.