La primera advertencia llegó desde una línea bajo un diagrama de ciclo de vida, fácil de pasar por alto.
Un explicador de la comunidad sobre DuskEVM lo dijo sin rodeos: no hay una ventana de fallo de 7 días, ~15 min para la finalización del retiro, y el pre-verificador MIPS elimina el retraso de la prueba de fraude. Número limpio; pensé que planearía un retiro en torno a eso.
Suposición: la documentación oficial confirmaría ese dato.
No fue lo que encontré. La propia documentación de Dusk describe el ciclo de vida de DuskEVM en cuatro pasos: tx al secuenciador, incluido en un bloque de L2, el publicador (bacher) lo publica en DuskDS, y luego compromisos de estado y pruebas de fallo conectan ese estado con la liquidación. Las pruebas de fallo siguen nombradas explícitamente. No hay 15 minutos en ninguna parte. En su lugar, una línea que te dice que no infieras la finalización por el tiempo transcurrido; en cambio, revisa el estado del protocolo o de la billetera.
Ahí está la brecha real. La inclusión es rápida; los documentos dicen eso mismos. La liquidación es algo aparte, condicionada por algo que nadie puso en forma de reloj.
Así que el paso de la prueba de fallo no desapareció: solo no está documentado de la manera en que el sistema de desafíos sin permisos de Optimism lo está, donde cualquiera puede ejecutar el probador y ver cómo ocurre la contestación.
No puedo saber si eso está comprimido y resuelto de forma privada, o si simplemente todavía no es público.
Me alegra haberlo revisado antes de programar un retiro usando el número de otra persona.
¿Qué pasa con ese número de 15 minutos la primera vez que una prueba de fallo necesita ser contestada en medio de una prisa de liquidación? 👍
#dusk $DUSK @Dusk
Un explicador de la comunidad sobre DuskEVM lo dijo sin rodeos: no hay una ventana de fallo de 7 días, ~15 min para la finalización del retiro, y el pre-verificador MIPS elimina el retraso de la prueba de fraude. Número limpio; pensé que planearía un retiro en torno a eso.
Suposición: la documentación oficial confirmaría ese dato.
No fue lo que encontré. La propia documentación de Dusk describe el ciclo de vida de DuskEVM en cuatro pasos: tx al secuenciador, incluido en un bloque de L2, el publicador (bacher) lo publica en DuskDS, y luego compromisos de estado y pruebas de fallo conectan ese estado con la liquidación. Las pruebas de fallo siguen nombradas explícitamente. No hay 15 minutos en ninguna parte. En su lugar, una línea que te dice que no infieras la finalización por el tiempo transcurrido; en cambio, revisa el estado del protocolo o de la billetera.
Ahí está la brecha real. La inclusión es rápida; los documentos dicen eso mismos. La liquidación es algo aparte, condicionada por algo que nadie puso en forma de reloj.
Así que el paso de la prueba de fallo no desapareció: solo no está documentado de la manera en que el sistema de desafíos sin permisos de Optimism lo está, donde cualquiera puede ejecutar el probador y ver cómo ocurre la contestación.
No puedo saber si eso está comprimido y resuelto de forma privada, o si simplemente todavía no es público.
Me alegra haberlo revisado antes de programar un retiro usando el número de otra persona.
¿Qué pasa con ese número de 15 minutos la primera vez que una prueba de fallo necesita ser contestada en medio de una prisa de liquidación? 👍
#dusk $DUSK @Dusk