Eine kleine Sache zu den Dusk-Transaktionen, die mich nicht mehr losgelassen hat.
Ich habe mir den Transaktionsablauf von Dusk angesehen und festgestellt, dass derzeit eine Transaktion genau eine Operation enthält. Für etwas Grundlegendes ist das eigentlich ziemlich sinnvoll. Es macht Validierung und Verständnis leichter. Dann aber dachte ich über einen komplexeren DeFi-Ablauf nach, wie z. B. das Vorbereiten von Mitteln, das Durchführen eines Swaps und anschließend das Staking. Für den Nutzer fühlt sich das wie eine einzige Aktion an. In Dusk wird daraus jedoch eine Reihe einzelner Transaktionen, jede mit ihrem eigenen Nonce, ihrer eigenen Signatur und der Chance, in einen Block aufgenommen zu werden.
Genau da fragte ich mich, was passiert, wenn nur ein Teil der Sequenz erfolgreich durchläuft. Auf Protokollebene gibt es kein Rollback über diese Transaktionen hinweg, sodass man am Ende mitten in einem größeren Ablauf stecken bleiben kann. Bei einem normalen Trade dürfte das wahrscheinlich kein großes Problem sein. Aber bei DeFi-Settlement- oder Treasury-Operationen kann ich mir vorstellen, dass das zu einem echten Kopfzerbrechen wird.
Was ich interessant fand: Dusk hat bereits ein offenes GitHub-Issue, #4058, das Batch-Transaktionen diskutiert. Eine Idee ist ein Batcher-Contract, der mehrere Calls in eine einzige Transaktion verpackt. Contracts, die caller() verwenden, könnten dann aber den Batcher statt des ursprünglichen Nutzers sehen. Die andere Option wäre ein Batch auf Protokollebene, bei dem mehrere Operationen unter der Identität des Nutzers bleiben. Das würde jedoch Änderungen am Transaktionsformat, Support im Konsens, die Aktivierung eines Hard Forks und Anpassungen in den SDKs bedeuten.
Daher würde ich das aktuelle Modell mit einer einzelnen Operation nicht einfach ersetzen. Ich denke, es ist als einfacher Standard sinnvoll. Ich würde lieber einen optionalen atomaren Batch für komplexe Workflows sehen: Die Operationen laufen der Reihe nach ab, das gesamte Batch kann zurückgerollt werden, wenn eine Operation fehlschlägt, und der ursprüngliche Nutzer bleibt bei jedem Call sichtbar.
Wäre das ein richtiger Ausgleich für Dusk, oder ist die zusätzliche Protokollkomplexität den Aufwand nicht wert?
$DUSK @Dusk #dusk
Ich habe mir den Transaktionsablauf von Dusk angesehen und festgestellt, dass derzeit eine Transaktion genau eine Operation enthält. Für etwas Grundlegendes ist das eigentlich ziemlich sinnvoll. Es macht Validierung und Verständnis leichter. Dann aber dachte ich über einen komplexeren DeFi-Ablauf nach, wie z. B. das Vorbereiten von Mitteln, das Durchführen eines Swaps und anschließend das Staking. Für den Nutzer fühlt sich das wie eine einzige Aktion an. In Dusk wird daraus jedoch eine Reihe einzelner Transaktionen, jede mit ihrem eigenen Nonce, ihrer eigenen Signatur und der Chance, in einen Block aufgenommen zu werden.
Genau da fragte ich mich, was passiert, wenn nur ein Teil der Sequenz erfolgreich durchläuft. Auf Protokollebene gibt es kein Rollback über diese Transaktionen hinweg, sodass man am Ende mitten in einem größeren Ablauf stecken bleiben kann. Bei einem normalen Trade dürfte das wahrscheinlich kein großes Problem sein. Aber bei DeFi-Settlement- oder Treasury-Operationen kann ich mir vorstellen, dass das zu einem echten Kopfzerbrechen wird.
Was ich interessant fand: Dusk hat bereits ein offenes GitHub-Issue, #4058, das Batch-Transaktionen diskutiert. Eine Idee ist ein Batcher-Contract, der mehrere Calls in eine einzige Transaktion verpackt. Contracts, die caller() verwenden, könnten dann aber den Batcher statt des ursprünglichen Nutzers sehen. Die andere Option wäre ein Batch auf Protokollebene, bei dem mehrere Operationen unter der Identität des Nutzers bleiben. Das würde jedoch Änderungen am Transaktionsformat, Support im Konsens, die Aktivierung eines Hard Forks und Anpassungen in den SDKs bedeuten.
Daher würde ich das aktuelle Modell mit einer einzelnen Operation nicht einfach ersetzen. Ich denke, es ist als einfacher Standard sinnvoll. Ich würde lieber einen optionalen atomaren Batch für komplexe Workflows sehen: Die Operationen laufen der Reihe nach ab, das gesamte Batch kann zurückgerollt werden, wenn eine Operation fehlschlägt, und der ursprüngliche Nutzer bleibt bei jedem Call sichtbar.
Wäre das ein richtiger Ausgleich für Dusk, oder ist die zusätzliche Protokollkomplexität den Aufwand nicht wert?
$DUSK @Dusk #dusk
