#dusk $DUSK @Dusk
Ehsan m’a demandé quelque chose pendant le dîner, et cela m’a fait repenser un détail de Dusk
Pourquoi un développeur devrait-il jamais supposer que le fait qu’assez de temps se soit écoulé signifie que l’état économique est prêt à être utilisé ?
Cela semble simple, mais cela devient important lorsque l’exécution et le règlement sont séparés. DuskDS fournit la base du règlement, de la finalité et de la disponibilité des données, tandis que DuskVM exécute directement des contrats Rust/WASM sur la couche L1 et que DuskEVM fournit l’exécution EVM réglée via DuskDS.
La partie intéressante, c’est que le pont de Dusk ne traite pas le temps comme un principe de sécurité.
Un retrait DuskEVM passe par des étapes distinctes : initiation, preuve et finalisation. La question de savoir si la prochaine action est prête dépend de l’état du réseau publié, de la maturité de la preuve et des vérifications liées au « dispute-game ». La documentation indique explicitement aux développeurs de ne pas calculer la préparation à partir du temps écoulé uniquement.
Ce détail a une implication plus grande que celle du pont lui-même.
Dans l’infrastructure financière, les développeurs transforment souvent des processus asynchrones en une logique applicative simple : attendre X minutes, puis supposer que l’état est sûr à consommer. Mais si la préparation du protocole dépend de l’état et des preuves plutôt que d’une horloge fixe, ce raccourci peut créer un risque d’intégration caché.
L’application peut être parfaitement correcte concernant la transaction qu’elle a soumise, tout en se trompant sur le moment où la conséquence économique de cette transaction est devenue utilisable.
C’est cette distinction que je trouve précieuse dans Dusk. La finalité n’est pas simplement un horodatage associé à une transaction. Pour les systèmes inter-environnements, elle devient un état défini par le Protocole que les applications doivent lire et respecter.
À mesure que Dusk étend ses couches d’exécution, je pense que cela devient un principe important pour les développeurs
Les états de préparation définis par le Protocole devraient-ils devenir une interface de premier niveau pour les applications financières, plutôt que de laisser les intégrateurs déduire la finalité à partir du temps et du statut de la transaction ? ⚙️
@Binance Square Official $SOL
Ehsan m’a demandé quelque chose pendant le dîner, et cela m’a fait repenser un détail de Dusk
Pourquoi un développeur devrait-il jamais supposer que le fait qu’assez de temps se soit écoulé signifie que l’état économique est prêt à être utilisé ?
Cela semble simple, mais cela devient important lorsque l’exécution et le règlement sont séparés. DuskDS fournit la base du règlement, de la finalité et de la disponibilité des données, tandis que DuskVM exécute directement des contrats Rust/WASM sur la couche L1 et que DuskEVM fournit l’exécution EVM réglée via DuskDS.
La partie intéressante, c’est que le pont de Dusk ne traite pas le temps comme un principe de sécurité.
Un retrait DuskEVM passe par des étapes distinctes : initiation, preuve et finalisation. La question de savoir si la prochaine action est prête dépend de l’état du réseau publié, de la maturité de la preuve et des vérifications liées au « dispute-game ». La documentation indique explicitement aux développeurs de ne pas calculer la préparation à partir du temps écoulé uniquement.
Ce détail a une implication plus grande que celle du pont lui-même.
Dans l’infrastructure financière, les développeurs transforment souvent des processus asynchrones en une logique applicative simple : attendre X minutes, puis supposer que l’état est sûr à consommer. Mais si la préparation du protocole dépend de l’état et des preuves plutôt que d’une horloge fixe, ce raccourci peut créer un risque d’intégration caché.
L’application peut être parfaitement correcte concernant la transaction qu’elle a soumise, tout en se trompant sur le moment où la conséquence économique de cette transaction est devenue utilisable.
C’est cette distinction que je trouve précieuse dans Dusk. La finalité n’est pas simplement un horodatage associé à une transaction. Pour les systèmes inter-environnements, elle devient un état défini par le Protocole que les applications doivent lire et respecter.
À mesure que Dusk étend ses couches d’exécution, je pense que cela devient un principe important pour les développeurs
Les états de préparation définis par le Protocole devraient-ils devenir une interface de premier niveau pour les applications financières, plutôt que de laisser les intégrateurs déduire la finalité à partir du temps et du statut de la transaction ? ⚙️
@Binance Square Official $SOL