[¿Es la prueba de fraude ZK perfecta?] Una buena investigación de @GCdePaula_ - profundicemos en la seguridad de los actuales protocolos de prueba de fraude ZK.
Gabriel Coutinho de Paula 🐝 🐧
Gabriel Coutinho de Paula 🐝 🐧29 sept 2025
Las Pruebas de Fraude ZK No Interactivas (NI) se presentan como lo "mejor de ambos mundos" para los rollups. Sin embargo, nuestra última investigación encuentra que corren el riesgo de ser lo peor de ambos. Hemos publicado en ethresearch un análisis en profundidad de NI bajo condiciones adversariales. 🧵
Primero que nada, incluso si se utilizan pruebas de fraude ZK, el período de desafío no puede ser acortado. Esto se debe a que las pruebas de fraude ZK no resuelven ataques de censura fuertes. 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 disputa basado en pruebas 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 inválidas en OP Kailua. Antes de publicar, el atacante precomputes pruebas ZK que refutarían sus propias raíces de estado inválidas. 2. Un defensor honesto responde generando una prueba ZK para desafiar la raíz de estado inválida.
3. Mientras el defensor todavía está generando la prueba ZK, el atacante presenta la prueba ZK precomputada para refutar su propia raíz de estado y termina 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 ninguna fianza.
Aquí, el atacante asume 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 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 maliciosa y drenar todos los activos del rollup.
Esto ilustra efectivamente que los protocolos de prueba de fraude ZK requieren consideraciones de seguridad más matizadas de lo que uno podría suponer. Lograr una seguridad más fuerte 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 las L2 de próxima generación como MegaETH están planeando integrar. Al perseguir estándares de seguridad más altos, podemos ofrecer un producto mucho más robusto y listo para producción.
4,83K