J’ai supposé que si je voulais faire trois opérations sur la chaîne — approuver, échanger, puis miser — alors la chaîne traiterait cela comme une seule chose qui arrive ou n’arrive pas du tout. Un sujet ouvert dans le propre dépôt Rusk de Dusk indique que ce n’est pas ainsi que cela fonctionne aujourd’hui.
Une transaction Dusk aujourd’hui transporte une seule opération optionnelle : un appel de contrat, un déploiement ou un mémo, avec une seule valeur, un seul destinataire, un seul nonce et une seule signature. Ainsi, approuver, échanger et miser deviennent trois transactions distinctes, chacune pouvant être incluse ou rejetée indépendamment. L’issue de Dusk le formule clairement : il n’existe aucune garantie d’atomicité entre elles. Approuvez et échangez mais pas misez, et vous vous retrouvez à mi-parcours sans mécanisme de rollback au niveau du protocole.
Le problème ne tient pas seulement au fait que les flux multi-étapes peuvent s’arrêter à mi-chemin. Les corriger change aussi qui doit absorber le coût de compatibilité.
Un contrat batcher rend toute la séquence atomique, car un sous-appel échoué annule la transaction externe. Mais un contrat cible qui vérifie qui l’appelle directement verrait le batcher, pas vous, sauf si ce contrat est déjà écrit pour passer outre l’appelant immédiat. Une transaction batch au niveau du protocole vous maintient comme appelant à chaque étape, mais elle ne s’expédie pas sans un nouveau format de transaction, des changements de consensus, un hard fork, et la mise à jour de chaque SDK de wallet.
Ajouter le batching ne supprime pas le compromis. Cela détermine si le fardeau de compatibilité se situe dans l’autorisation applicative ou dans la pile du protocole.
« La correction de l’atomicité ne supprime pas le compromis ; elle décide où le fardeau de compatibilité et la frontière de confiance se déplacent. »
Ce que j’aimerais en réalité surveiller : si Dusk choisit le batcher au niveau applicatif ou la transaction au niveau du protocole, et quelles hypothèses existantes d’autorisation ce choix force les développeurs à modifier.
#dusk $DUSK @Dusk
Une transaction Dusk aujourd’hui transporte une seule opération optionnelle : un appel de contrat, un déploiement ou un mémo, avec une seule valeur, un seul destinataire, un seul nonce et une seule signature. Ainsi, approuver, échanger et miser deviennent trois transactions distinctes, chacune pouvant être incluse ou rejetée indépendamment. L’issue de Dusk le formule clairement : il n’existe aucune garantie d’atomicité entre elles. Approuvez et échangez mais pas misez, et vous vous retrouvez à mi-parcours sans mécanisme de rollback au niveau du protocole.
Le problème ne tient pas seulement au fait que les flux multi-étapes peuvent s’arrêter à mi-chemin. Les corriger change aussi qui doit absorber le coût de compatibilité.
Un contrat batcher rend toute la séquence atomique, car un sous-appel échoué annule la transaction externe. Mais un contrat cible qui vérifie qui l’appelle directement verrait le batcher, pas vous, sauf si ce contrat est déjà écrit pour passer outre l’appelant immédiat. Une transaction batch au niveau du protocole vous maintient comme appelant à chaque étape, mais elle ne s’expédie pas sans un nouveau format de transaction, des changements de consensus, un hard fork, et la mise à jour de chaque SDK de wallet.
Ajouter le batching ne supprime pas le compromis. Cela détermine si le fardeau de compatibilité se situe dans l’autorisation applicative ou dans la pile du protocole.
« La correction de l’atomicité ne supprime pas le compromis ; elle décide où le fardeau de compatibilité et la frontière de confiance se déplacent. »
Ce que j’aimerais en réalité surveiller : si Dusk choisit le batcher au niveau applicatif ou la transaction au niveau du protocole, et quelles hypothèses existantes d’autorisation ce choix force les développeurs à modifier.
#dusk $DUSK @Dusk
