Deux fonctions d’expéditeur dans les contrats intelligents de Dusk ont retenu mon attention : caller() et public_sender().
Elles ressemblent à deux façons de répondre à la même question, qui a initié cette action, mais elles peuvent pointer vers des acteurs différents. Cette distinction compte, car Dusk pousse à faire entrer les marchés financiers onchain avec des institutions agréées par l’UE, où l’autorisation doit survivre à des interactions contractuelles plus complexes sans perdre de vue l’acteur initial. caller() identifie le contrat qui effectue l’appel immédiat, tandis que public_sender() peut encore renvoyer au compte Moonlight à l’origine de la transaction.
Ce que je ne sais pas encore, c’est si les contrats Dusk autoriseront de manière constante l’utilisateur qui a réellement initié une action, ou si l’ajout de contrats intermédiaires peut changer discrètement quelle identité la logique d’autorisation “voit”. Les mécanismes à surveiller sont simples : lorsque des contrats s’appuient sur caller(), lorsqu’ils s’appuient sur public_sender(), et ce qui se passe une fois que des batchers ou des forwarders se placent au milieu.
Une transaction qui s’exécute avec succès ne suffit pas à répondre à cela. Le test plus solide consiste à vérifier si les mêmes règles d’autorisation renvoient toujours vers l’acteur visé, même lorsque le chemin d’exécution change.
Je me soucie moins du nombre de contrats intermédiaires qu’une action traverse que du fait que l’autorisation se résolve encore vers l’acteur qui l’a effectivement initiée.
Cela compte parce qu’ajouter un intermédiaire peut faire en sorte qu’un contrat “voie” quelqu’un d’autre, sans pour autant modifier qui a réellement autorisé l’action.
La question est donc de savoir si Dusk peut ajouter davantage de chemins d’exécution composables sans que l’autorisation dépende du contrat qui se trouve par hasard au milieu.
Je regarde comment caller() et public_sender() sont utilisés à mesure que ces schémas se développent.
@Dusk $DUSK #dusk
Elles ressemblent à deux façons de répondre à la même question, qui a initié cette action, mais elles peuvent pointer vers des acteurs différents. Cette distinction compte, car Dusk pousse à faire entrer les marchés financiers onchain avec des institutions agréées par l’UE, où l’autorisation doit survivre à des interactions contractuelles plus complexes sans perdre de vue l’acteur initial. caller() identifie le contrat qui effectue l’appel immédiat, tandis que public_sender() peut encore renvoyer au compte Moonlight à l’origine de la transaction.
Ce que je ne sais pas encore, c’est si les contrats Dusk autoriseront de manière constante l’utilisateur qui a réellement initié une action, ou si l’ajout de contrats intermédiaires peut changer discrètement quelle identité la logique d’autorisation “voit”. Les mécanismes à surveiller sont simples : lorsque des contrats s’appuient sur caller(), lorsqu’ils s’appuient sur public_sender(), et ce qui se passe une fois que des batchers ou des forwarders se placent au milieu.
Une transaction qui s’exécute avec succès ne suffit pas à répondre à cela. Le test plus solide consiste à vérifier si les mêmes règles d’autorisation renvoient toujours vers l’acteur visé, même lorsque le chemin d’exécution change.
Je me soucie moins du nombre de contrats intermédiaires qu’une action traverse que du fait que l’autorisation se résolve encore vers l’acteur qui l’a effectivement initiée.
Cela compte parce qu’ajouter un intermédiaire peut faire en sorte qu’un contrat “voie” quelqu’un d’autre, sans pour autant modifier qui a réellement autorisé l’action.
La question est donc de savoir si Dusk peut ajouter davantage de chemins d’exécution composables sans que l’autorisation dépende du contrat qui se trouve par hasard au milieu.
Je regarde comment caller() et public_sender() sont utilisés à mesure que ces schémas se développent.
@Dusk $DUSK #dusk
