Ce qui a attiré mon attention dans la documentation de Dusk n’est pas la couche de confidentialité : c’est la façon dont la petite unité atomique d’une transaction L1 reste, elle, encore très simple.
Le modèle de transaction actuel de Dusk ne prévoit qu’une seule action optionnelle : un transfert, un mémo, un appel de contrat, un déploiement ou un blob. Un problème soumis en juin 2026 sur Rusk propose des transactions par lots (batch) car les intentions utilisateur multi-étapes doivent actuellement être séparées en transactions distinctes, chacune étant signée indépendamment et soumise ensuite à l’inclusion.
Cela compte davantage pour l’infrastructure financière que ce que cela peut sembler.
Pensez émission → paiement → livraison, ou à une règle de règlement multi-étapes. Si ces étapes sont séparées, le protocole ne garantit pas aujourd’hui qu’elles arrivent ensemble. L’une peut réussir tandis qu’une autre échoue, laissant potentiellement un état intermédiaire.
Il y a une nuance importante : DuskVM prend en charge les appels inter-contrats, donc la composition au niveau applicatif est déjà possible. Le manque que je surveille concerne l’atomicité des transactions au niveau inférieur, pas la capacité de Dusk à exécuter des contrats complexes.
Pour moi, c’est un compromis intéressant : Dusk pousse vers une finance programmable et réglementée, tandis qu’une primitive fondamentale de transaction reste, volontairement, encore très simple.
Je me demande si l’ajout natif de transactions par lots fera partie du protocole — ou si Dusk conserve cette complexité à l’intérieur des contrats et des couches d’exécution.
@Dusk $DUSK #dusk
Le modèle de transaction actuel de Dusk ne prévoit qu’une seule action optionnelle : un transfert, un mémo, un appel de contrat, un déploiement ou un blob. Un problème soumis en juin 2026 sur Rusk propose des transactions par lots (batch) car les intentions utilisateur multi-étapes doivent actuellement être séparées en transactions distinctes, chacune étant signée indépendamment et soumise ensuite à l’inclusion.
Cela compte davantage pour l’infrastructure financière que ce que cela peut sembler.
Pensez émission → paiement → livraison, ou à une règle de règlement multi-étapes. Si ces étapes sont séparées, le protocole ne garantit pas aujourd’hui qu’elles arrivent ensemble. L’une peut réussir tandis qu’une autre échoue, laissant potentiellement un état intermédiaire.
Il y a une nuance importante : DuskVM prend en charge les appels inter-contrats, donc la composition au niveau applicatif est déjà possible. Le manque que je surveille concerne l’atomicité des transactions au niveau inférieur, pas la capacité de Dusk à exécuter des contrats complexes.
Pour moi, c’est un compromis intéressant : Dusk pousse vers une finance programmable et réglementée, tandis qu’une primitive fondamentale de transaction reste, volontairement, encore très simple.
Je me demande si l’ajout natif de transactions par lots fera partie du protocole — ou si Dusk conserve cette complexité à l’intérieur des contrats et des couches d’exécution.
@Dusk $DUSK #dusk