$DUSK #Alba — DuskEVM se salta la clásica ventana de desafío de 7 días de Optimism. Ese retraso no fue simplemente un fallo de UX; es parte del modelo de seguridad.
Profundizando en el análisis de @DuskFoundation sobre el port al OP Stack, DuskEVM se asienta en DuskDS, mientras que un pre-verificador basado en MIPS comprueba las transiciones de estado antes de que se acepten para su liquidación. La documentación de Dusk describe las retiradas como finalizando en aproximadamente 15 minutos.
Al principio, eso parece una mejora de UX sencilla. Pero la cuestión de seguridad es más interesante.
En el OP Stack estándar, la ventana de 7 días ofrece tiempo para que las pruebas de fraude sin permisos impugnen una raíz de estado inválida. El diseño de Dusk mueve la verificación antes en el flujo.
Así que no lo describiría simplemente como “eliminar el requisito de confianza”. La pregunta importante es dónde se sostiene ahora la suposición de seguridad: ¿la pre-verificación se hace cumplir de forma independiente por el conjunto de validadores de DuskDS, o depende de un conjunto de verificadores distinto?
Esa distinción importa. Una mayor rapidez de liquidación es valiosa, pero solo si entendemos qué cambió por debajo.
A continuación, voy a revisar el GitHub de Rusk y la documentación técnica de Dusk para ver cómo se relaciona el conjunto de pre-verificadores con los validadores de DuskDS.
#dusk $DUSK @Dusk
Profundizando en el análisis de @DuskFoundation sobre el port al OP Stack, DuskEVM se asienta en DuskDS, mientras que un pre-verificador basado en MIPS comprueba las transiciones de estado antes de que se acepten para su liquidación. La documentación de Dusk describe las retiradas como finalizando en aproximadamente 15 minutos.
Al principio, eso parece una mejora de UX sencilla. Pero la cuestión de seguridad es más interesante.
En el OP Stack estándar, la ventana de 7 días ofrece tiempo para que las pruebas de fraude sin permisos impugnen una raíz de estado inválida. El diseño de Dusk mueve la verificación antes en el flujo.
Así que no lo describiría simplemente como “eliminar el requisito de confianza”. La pregunta importante es dónde se sostiene ahora la suposición de seguridad: ¿la pre-verificación se hace cumplir de forma independiente por el conjunto de validadores de DuskDS, o depende de un conjunto de verificadores distinto?
Esa distinción importa. Una mayor rapidez de liquidación es valiosa, pero solo si entendemos qué cambió por debajo.
A continuación, voy a revisar el GitHub de Rusk y la documentación técnica de Dusk para ver cómo se relaciona el conjunto de pre-verificadores con los validadores de DuskDS.
#dusk $DUSK @Dusk
