#dusk $DUSK L’autorisation a déjà été libérée ; l’échange de tokens n’a pas abouti, et le mécanisme de mise en jeu (staking) a aussi été stoppé. À ce moment-là, les fonds ne se sont pas déplacés comme prévu, mais le marché continue d’évoluer. Ensuite, il faut retirer l’autorisation, la réémettre et faire un hedge : à chaque étape, il faut encore payer. — Face à ce type de conception de processus de transaction, qu’en pensez-vous ?
Je prends le chemin courant « Approve → Swap → Stake », et je le compare à la structure actuelle des transactions sur Dusk. Dans le dépôt Rusk officiel de Dusk, les discussions ouvertes indiquent qu’à l’heure actuelle, une transaction Moonlight ou Phoenix ne contient qu’une seule action au niveau supérieur : dans le format de transaction, il n’y a pas de Batch natif. Il n’y a pas de contrat de routage dédié : les trois étapes doivent donc être envoyées séparément. Une fois la première étape confirmée, si la deuxième échoue, la précédente ne sera pas annulée automatiquement.
Quand j’ai vu que, dans la conception du flux, les trois étapes exigent chacune un Gas, j’ai été honnêtement un peu content pour $DUSK . Mais en traçant les positions après l’échec et le coût de remédiation, mon enthousiasme a disparu d’un coup. Le fait d’exécuter tout le flux jusqu’au bout génère des frais de service ; retirer l’autorisation, réessayer et effectuer des opérations inverses génèrent des frais d’incident. Les deux types de frais consomment du DUSK, mais à long terme, le « contenu en valeur » n’est pas du tout comparable.
Dusk pourrait d’abord laisser un contrat de routage s’occuper des trois étapes. Mais certains contrats cibles ne reconnaissent que « la personne qui vient exécuter la tâche tout de suite ». Ils voient donc le contrat de routage plutôt que la véritable autorité de l’utilisateur. Un Batch natif au niveau du protocole peut préserver l’identité de l’utilisateur ; en contrepartie, il faut mettre à niveau en même temps le format de transaction, les nœuds et le portefeuille. J’ai l’impression que ce problème est assez difficile à résoudre.
Cela dit, Phoenix offre ici une carte maîtresse dédiée à Dusk : les preuves de confidentialité ne consignent que l’empreinte (« fingerprint ») du contenu des appels, sans qu’il soit nécessaire de comprendre chaque étape à l’intérieur. Je pense qu’à l’avenir, lorsque Batch sera ajouté, il serait théoriquement inutile de refaire entièrement les circuits de confidentialité et tous les paramètres des preuves. Dusk aurait donc la possibilité de transformer des processus complexes en mode « tout réussi ou tout annulé », et le coût de l’adaptation pourrait aussi être plus faible.
Pour $DUSK , je pense que le Gas d’une seule étape doit être mis dans le même tableau que le taux de succès complet, la proportion de transactions de remédiation et le taux de réutilisation des utilisateurs. Chaque bouton est facturé : ce n’est pas suffisant. Une série de transactions doit pouvoir aboutir de façon à la fois efficace et rentable, pour que les utilisateurs aient envie de laisser la prochaine tranche de fonds sur la blockchain.
Une expérience à la fois plus économique et plus fluide : quelle transaction pourrait y résister ? C’est aussi l’un des indicateurs que j’utilise pour évaluer à long terme la valorisation de $DUSK .
@Dusk
$BTC
Je prends le chemin courant « Approve → Swap → Stake », et je le compare à la structure actuelle des transactions sur Dusk. Dans le dépôt Rusk officiel de Dusk, les discussions ouvertes indiquent qu’à l’heure actuelle, une transaction Moonlight ou Phoenix ne contient qu’une seule action au niveau supérieur : dans le format de transaction, il n’y a pas de Batch natif. Il n’y a pas de contrat de routage dédié : les trois étapes doivent donc être envoyées séparément. Une fois la première étape confirmée, si la deuxième échoue, la précédente ne sera pas annulée automatiquement.
Quand j’ai vu que, dans la conception du flux, les trois étapes exigent chacune un Gas, j’ai été honnêtement un peu content pour $DUSK . Mais en traçant les positions après l’échec et le coût de remédiation, mon enthousiasme a disparu d’un coup. Le fait d’exécuter tout le flux jusqu’au bout génère des frais de service ; retirer l’autorisation, réessayer et effectuer des opérations inverses génèrent des frais d’incident. Les deux types de frais consomment du DUSK, mais à long terme, le « contenu en valeur » n’est pas du tout comparable.
Dusk pourrait d’abord laisser un contrat de routage s’occuper des trois étapes. Mais certains contrats cibles ne reconnaissent que « la personne qui vient exécuter la tâche tout de suite ». Ils voient donc le contrat de routage plutôt que la véritable autorité de l’utilisateur. Un Batch natif au niveau du protocole peut préserver l’identité de l’utilisateur ; en contrepartie, il faut mettre à niveau en même temps le format de transaction, les nœuds et le portefeuille. J’ai l’impression que ce problème est assez difficile à résoudre.
Cela dit, Phoenix offre ici une carte maîtresse dédiée à Dusk : les preuves de confidentialité ne consignent que l’empreinte (« fingerprint ») du contenu des appels, sans qu’il soit nécessaire de comprendre chaque étape à l’intérieur. Je pense qu’à l’avenir, lorsque Batch sera ajouté, il serait théoriquement inutile de refaire entièrement les circuits de confidentialité et tous les paramètres des preuves. Dusk aurait donc la possibilité de transformer des processus complexes en mode « tout réussi ou tout annulé », et le coût de l’adaptation pourrait aussi être plus faible.
Pour $DUSK , je pense que le Gas d’une seule étape doit être mis dans le même tableau que le taux de succès complet, la proportion de transactions de remédiation et le taux de réutilisation des utilisateurs. Chaque bouton est facturé : ce n’est pas suffisant. Une série de transactions doit pouvoir aboutir de façon à la fois efficace et rentable, pour que les utilisateurs aient envie de laisser la prochaine tranche de fonds sur la blockchain.
Une expérience à la fois plus économique et plus fluide : quelle transaction pourrait y résister ? C’est aussi l’un des indicateurs que j’utilise pour évaluer à long terme la valorisation de $DUSK .
@Dusk
$BTC