#dusk $DUSK
Ces deux derniers jours, je lis la documentation DuskEVM de @Dusk et il y a un détail que j’avais effectivement ignoré auparavant :
Le fait qu’une transaction soit incluse et empaquetée dans DuskEVM ne signifie pas que la transaction est déjà entièrement terminée.
Dans cette architecture actuelle, Dusk ne fait pas la même chose via DuskEVM et via DuskDS.
Les contrats Solidity s’exécutent d’abord dans DuskEVM ; la transaction arrive ensuite au sequencer, puis est intégrée dans un bloc L2. Plus tard, le batcher doit encore soumettre les données de la transaction à DuskDS, et l’état est ensuite confirmé plus en profondeur via des mécanismes comme les commitments et les fault proofs.
Au final, ce sont DuskDS qui se chargent du settlement et de la disponibilité des données.
Donc, à présent, je comprends DuskEVM d’une manière qui ne consiste pas simplement à le considérer comme « Dusk a ajouté un EVM ».
Pour être plus précis :
DuskEVM exécute, DuskDS tranche à la fin si c’est valide.
Cela explique aussi pourquoi la documentation officielle distingue spécifiquement l’inclusion des transactions et le settlement.
On peut également voir cette logique de conception dans le processus de retrait du testnet : on initie d’abord dans DuskEVM, puis on prouve sur Dusk L1, et enfin on finalise ; ce n’est pas parce que l’état apparaît comme réussi du côté L2 que tout s’arrête définitivement.
La différence peut sembler moins « sexy » pour un simple virement, mais je pense qu’elle est au contraire cruciale dans un contexte financier.
Pour des actifs tels que les valeurs mobilières ou les fonds, s’ils doivent vraiment être tokenisés et mis on-chain, ce qui intéresse tout le monde n’est pas seulement « est-ce que la transaction est rapide ? », mais surtout :
À quel niveau cet état obtient-il la finalité ?
Donc, par la suite, en regardant le mainnet DuskEVM, en plus de la performance et de la compatibilité Solidity, je veux surtout observer concrètement comment cette chaîne allant de l’exécution jusqu’au settlement via DuskDS se comporte une fois en conditions réelles.
Au moins, j’ai maintenant bien compris la répartition des rôles au niveau de l’architecture.
Ces deux derniers jours, je lis la documentation DuskEVM de @Dusk et il y a un détail que j’avais effectivement ignoré auparavant :
Le fait qu’une transaction soit incluse et empaquetée dans DuskEVM ne signifie pas que la transaction est déjà entièrement terminée.
Dans cette architecture actuelle, Dusk ne fait pas la même chose via DuskEVM et via DuskDS.
Les contrats Solidity s’exécutent d’abord dans DuskEVM ; la transaction arrive ensuite au sequencer, puis est intégrée dans un bloc L2. Plus tard, le batcher doit encore soumettre les données de la transaction à DuskDS, et l’état est ensuite confirmé plus en profondeur via des mécanismes comme les commitments et les fault proofs.
Au final, ce sont DuskDS qui se chargent du settlement et de la disponibilité des données.
Donc, à présent, je comprends DuskEVM d’une manière qui ne consiste pas simplement à le considérer comme « Dusk a ajouté un EVM ».
Pour être plus précis :
DuskEVM exécute, DuskDS tranche à la fin si c’est valide.
Cela explique aussi pourquoi la documentation officielle distingue spécifiquement l’inclusion des transactions et le settlement.
On peut également voir cette logique de conception dans le processus de retrait du testnet : on initie d’abord dans DuskEVM, puis on prouve sur Dusk L1, et enfin on finalise ; ce n’est pas parce que l’état apparaît comme réussi du côté L2 que tout s’arrête définitivement.
La différence peut sembler moins « sexy » pour un simple virement, mais je pense qu’elle est au contraire cruciale dans un contexte financier.
Pour des actifs tels que les valeurs mobilières ou les fonds, s’ils doivent vraiment être tokenisés et mis on-chain, ce qui intéresse tout le monde n’est pas seulement « est-ce que la transaction est rapide ? », mais surtout :
À quel niveau cet état obtient-il la finalité ?
Donc, par la suite, en regardant le mainnet DuskEVM, en plus de la performance et de la compatibilité Solidity, je veux surtout observer concrètement comment cette chaîne allant de l’exécution jusqu’au settlement via DuskDS se comporte une fois en conditions réelles.
Au moins, j’ai maintenant bien compris la répartition des rôles au niveau de l’architecture.