j’ai passé la matinée à décortiquer comment une transaction duskevm traverse réellement le système et, franchement ? 😂 je pensais qu’une fois qu’elle apparaissait dans un bloc, c’était terminé. en fait, ce n’est pas tout à fait juste.
donc duskevm, c’est la couche compatible evm sur dusk : tu écris en solidity, tu utilises des wallets evm classiques et des outils standard comme foundry ou hardhat, et tu paies le gas en dusk. mais la transaction ne reste pas et ne “meurt” pas toute seule sur duskevm. elle suit un cycle de type rollup. d’abord elle est soumise au séquenceur duskevm, puis incluse dans un bloc l2 relativement vite. ensuite, un batcher publie les données de la transaction vers duskds, la couche de règlement réel et de disponibilité des données de dusk. les engagements d’état et les preuves de fraude, c’est ce qui relie le nouvel état obtenu à duskds, pour que ce soit vraiment réglé, pas juste “assuré” quelque part dans un bloc l2 en attente.
a ce à quoi je reviens sans cesse, c’est une phrase dans la documentation qui signale que l’inclusion et le règlement sont de véritables étapes différentes, et que les apps qui transfèrent de la valeur entre duskevm et le dusk l1 doivent vérifier l’état du protocole ou du wallet plutôt que de supposer qu’un truc est final juste parce que le temps a passé. c’est une distinction réelle, pas une simple nuance technique. je n’ai trouvé nulle part qui explique clairement la durée typique de cet intervalle en pratique : une inclusion rapide ne veut clairement pas dire règlement instantané, mais je ne sais pas la fenêtre exacte qu’une personne devrait attendre.
cela dit, le choix de conception me paraît cohérent. au lieu de construire une chaîne evm totalement séparée, flottant de son côté, duskevm reste ancré à duskds pour le règlement et la disponibilité des données : tu obtiens tous les outils de solidity sans perdre les garanties de base autour de la finalité.
franchement, je ne sais pas si cet écart entre inclusion et règlement est assez faible pour être ignoré au quotidien, ou si les builders doivent activement en tenir compte.
🤔
#dusk @Dusk $DUSK
donc duskevm, c’est la couche compatible evm sur dusk : tu écris en solidity, tu utilises des wallets evm classiques et des outils standard comme foundry ou hardhat, et tu paies le gas en dusk. mais la transaction ne reste pas et ne “meurt” pas toute seule sur duskevm. elle suit un cycle de type rollup. d’abord elle est soumise au séquenceur duskevm, puis incluse dans un bloc l2 relativement vite. ensuite, un batcher publie les données de la transaction vers duskds, la couche de règlement réel et de disponibilité des données de dusk. les engagements d’état et les preuves de fraude, c’est ce qui relie le nouvel état obtenu à duskds, pour que ce soit vraiment réglé, pas juste “assuré” quelque part dans un bloc l2 en attente.
a ce à quoi je reviens sans cesse, c’est une phrase dans la documentation qui signale que l’inclusion et le règlement sont de véritables étapes différentes, et que les apps qui transfèrent de la valeur entre duskevm et le dusk l1 doivent vérifier l’état du protocole ou du wallet plutôt que de supposer qu’un truc est final juste parce que le temps a passé. c’est une distinction réelle, pas une simple nuance technique. je n’ai trouvé nulle part qui explique clairement la durée typique de cet intervalle en pratique : une inclusion rapide ne veut clairement pas dire règlement instantané, mais je ne sais pas la fenêtre exacte qu’une personne devrait attendre.
cela dit, le choix de conception me paraît cohérent. au lieu de construire une chaîne evm totalement séparée, flottant de son côté, duskevm reste ancré à duskds pour le règlement et la disponibilité des données : tu obtiens tous les outils de solidity sans perdre les garanties de base autour de la finalité.
franchement, je ne sais pas si cet écart entre inclusion et règlement est assez faible pour être ignoré au quotidien, ou si les builders doivent activement en tenir compte.
🤔
#dusk @Dusk $DUSK