Zwei Senderfunktionen in Dusk-Smart-Contracts haben meine Aufmerksamkeit geweckt: caller() und public_sender().
Sie klingen nach zwei Wegen, dieselbe Frage zu beantworten, nämlich wer diese Aktion ausgelöst hat, aber sie können auf unterschiedliche Akteure verweisen. Dieser Unterschied ist wichtig, weil Dusk darauf hinarbeitet, Finanzmärkte onchain mit EU-lizenzierten Institutionen zu bringen, wo Autorisierung auch komplexere Vertragsinteraktionen überstehen muss, ohne den ursprünglichen Akteur aus den Augen zu verlieren. caller() identifiziert den Vertrag, der den unmittelbaren Aufruf macht, während public_sender() noch auf das Moonlight-Konto verweisen kann, das die Transaktion gestartet hat.
Was ich noch nicht weiß, ist, ob Dusk-Verträge konsequent den Nutzer autorisieren, der eine Aktion tatsächlich initiiert hat, oder ob das Hinzufügen von Zwischenverträgen stillschweigend ändern kann, welche Identität die Autorisierungslogik sieht. Die Mechanik, auf die man achten sollte, ist klar: wenn Verträge auf caller() vertrauen, wenn sie auf public_sender() vertrauen und was passiert, sobald Batcher oder Forwarder dazwischengeschaltet sind.
Eine Transaktion, die erfolgreich ausgeführt wird, reicht nicht aus, um das zu beantworten. Der stärkere Test ist, ob dieselben Autorisierungsregeln auch dann noch auf den beabsichtigten Akteur verweisen, wenn sich der Ausführungspfad ändert.
Mir wäre es weniger wichtig, wie viele Zwischenverträge eine Aktion durchläuft, als ob die Autorisierung immer noch den Akteur auflöst, der sie tatsächlich initiiert hat.
Das ist wichtig, weil das Hinzufügen eines Vermittlers ändern kann, wen ein Vertrag sieht, ohne zu ändern, wer die Aktion tatsächlich autorisiert hat.
Die Frage ist, ob Dusk mehr zusammensetzbare Ausführungspfade hinzufügen kann, ohne die Autorisierung davon abhängig zu machen, welcher Vertrag zufällig in der Mitte sitzt.
Ich beobachte, wie caller() und public_sender() verwendet werden, während sich diese Muster entwickeln.
@Dusk $DUSK #dusk
Sie klingen nach zwei Wegen, dieselbe Frage zu beantworten, nämlich wer diese Aktion ausgelöst hat, aber sie können auf unterschiedliche Akteure verweisen. Dieser Unterschied ist wichtig, weil Dusk darauf hinarbeitet, Finanzmärkte onchain mit EU-lizenzierten Institutionen zu bringen, wo Autorisierung auch komplexere Vertragsinteraktionen überstehen muss, ohne den ursprünglichen Akteur aus den Augen zu verlieren. caller() identifiziert den Vertrag, der den unmittelbaren Aufruf macht, während public_sender() noch auf das Moonlight-Konto verweisen kann, das die Transaktion gestartet hat.
Was ich noch nicht weiß, ist, ob Dusk-Verträge konsequent den Nutzer autorisieren, der eine Aktion tatsächlich initiiert hat, oder ob das Hinzufügen von Zwischenverträgen stillschweigend ändern kann, welche Identität die Autorisierungslogik sieht. Die Mechanik, auf die man achten sollte, ist klar: wenn Verträge auf caller() vertrauen, wenn sie auf public_sender() vertrauen und was passiert, sobald Batcher oder Forwarder dazwischengeschaltet sind.
Eine Transaktion, die erfolgreich ausgeführt wird, reicht nicht aus, um das zu beantworten. Der stärkere Test ist, ob dieselben Autorisierungsregeln auch dann noch auf den beabsichtigten Akteur verweisen, wenn sich der Ausführungspfad ändert.
Mir wäre es weniger wichtig, wie viele Zwischenverträge eine Aktion durchläuft, als ob die Autorisierung immer noch den Akteur auflöst, der sie tatsächlich initiiert hat.
Das ist wichtig, weil das Hinzufügen eines Vermittlers ändern kann, wen ein Vertrag sieht, ohne zu ändern, wer die Aktion tatsächlich autorisiert hat.
Die Frage ist, ob Dusk mehr zusammensetzbare Ausführungspfade hinzufügen kann, ohne die Autorisierung davon abhängig zu machen, welcher Vertrag zufällig in der Mitte sitzt.
Ich beobachte, wie caller() und public_sender() verwendet werden, während sich diese Muster entwickeln.
@Dusk $DUSK #dusk
