#dusk $DUSK @Dusk
Ehsan me preguntó algo en la cena que me hizo replantear un detalle de Dusk
¿Por qué un desarrollador debería asumir que, si ha pasado suficiente tiempo, significa que un estado económico ya está listo para usarse?
Suena simple, pero se vuelve importante cuando la ejecución y la liquidación se separan. DuskDS proporciona la base de liquidación, finalidad y disponibilidad de datos, mientras que DuskVM ejecuta contratos Rust/WASM directamente en la L1 y DuskEVM proporciona la ejecución EVM liquidada a través de DuskDS.
La parte interesante es que el puente de Dusk no trata el tiempo como la primitiva de seguridad.
Una retirada de DuskEVM avanza por etapas distintas: iniciación, prueba y finalización. Si la siguiente acción está lista depende del estado de red publicado, la madurez de la prueba y las comprobaciones del juego de disputas. La documentación indica explícitamente a los desarrolladores que no calculen la preparación basándose solo en el tiempo transcurrido.
Ese detalle tiene una implicación mayor que el propio puente.
En infraestructura financiera, los desarrolladores a menudo convierten procesos asíncronos en una lógica de aplicación simple: esperar X minutos y luego asumir que el estado es seguro para consumir. Pero si la preparación del protocolo depende del estado y de las pruebas en lugar de un reloj fijo, ese atajo puede crear un riesgo de integración oculto.
La aplicación puede ser perfectamente correcta con respecto a la transacción que envió, mientras está equivocada sobre cuándo sus consecuencias económicas se volvieron utilizables.
Esa es la distinción que encuentro valiosa en Dusk. La finalidad no es simplemente una marca de tiempo adjunta a una transacción. Para sistemas entre entornos, se convierte en un estado definido por Protocolo que las aplicaciones deben leer y respetar.
A medida que Dusk amplía sus capas de ejecución, creo que esto se vuelve un principio importante para desarrolladores
¿Deberían los estados de preparación definidos por Protocolo convertirse en una interfaz de primera clase para aplicaciones financieras, en lugar de dejar que los integradores infieran la finalidad a partir del tiempo y el estado de la transacción? ⚙️
@Binance Square Official $SOL
Ehsan me preguntó algo en la cena que me hizo replantear un detalle de Dusk
¿Por qué un desarrollador debería asumir que, si ha pasado suficiente tiempo, significa que un estado económico ya está listo para usarse?
Suena simple, pero se vuelve importante cuando la ejecución y la liquidación se separan. DuskDS proporciona la base de liquidación, finalidad y disponibilidad de datos, mientras que DuskVM ejecuta contratos Rust/WASM directamente en la L1 y DuskEVM proporciona la ejecución EVM liquidada a través de DuskDS.
La parte interesante es que el puente de Dusk no trata el tiempo como la primitiva de seguridad.
Una retirada de DuskEVM avanza por etapas distintas: iniciación, prueba y finalización. Si la siguiente acción está lista depende del estado de red publicado, la madurez de la prueba y las comprobaciones del juego de disputas. La documentación indica explícitamente a los desarrolladores que no calculen la preparación basándose solo en el tiempo transcurrido.
Ese detalle tiene una implicación mayor que el propio puente.
En infraestructura financiera, los desarrolladores a menudo convierten procesos asíncronos en una lógica de aplicación simple: esperar X minutos y luego asumir que el estado es seguro para consumir. Pero si la preparación del protocolo depende del estado y de las pruebas en lugar de un reloj fijo, ese atajo puede crear un riesgo de integración oculto.
La aplicación puede ser perfectamente correcta con respecto a la transacción que envió, mientras está equivocada sobre cuándo sus consecuencias económicas se volvieron utilizables.
Esa es la distinción que encuentro valiosa en Dusk. La finalidad no es simplemente una marca de tiempo adjunta a una transacción. Para sistemas entre entornos, se convierte en un estado definido por Protocolo que las aplicaciones deben leer y respetar.
A medida que Dusk amplía sus capas de ejecución, creo que esto se vuelve un principio importante para desarrolladores
¿Deberían los estados de preparación definidos por Protocolo convertirse en una interfaz de primera clase para aplicaciones financieras, en lugar de dejar que los integradores infieran la finalidad a partir del tiempo y el estado de la transacción? ⚙️
@Binance Square Official $SOL