Ich ging davon aus, dass die Chain, wenn ich drei Dinge On-Chain ausführen möchte—genehmigen, tauschen und dann staken—dies als genau eine Sache behandelt: entweder geschieht sie oder sie geschieht gar nicht. Ein offenes Issue im eigenen Rusk-Repository von Dusk sagt, dass das heute nicht so funktioniert.
Eine Dusk-Transaktion trägt heute eine einzelne optionale Operation: einen einzelnen Contract-Call, einen einzelnen Deploy oder ein Memo—jeweils mit einem Wert, einem Empfänger, einem Nonce und einer Signatur. Genehmigen, Tauschen und Staken werden damit zu drei separaten Transaktionen, die jeweils unabhängig voneinander aufgenommen oder verworfen werden. Das Issue von Dusk stellt das ganz klar: Es gibt keine Atomizitätsgarantie über sie hinweg. Genehmige und tausche das Land, aber nicht staken—und du bleibst mitten im Ablauf stecken, ohne Rollback auf Protokollebene.
Das Problem besteht nicht nur darin, dass mehrstufige Abläufe halbwegs stoppen können. Das Beheben daran ändert, wer die Kompatibilitätskosten tragen muss.
Ein Batcher-Contract macht die gesamte Abfolge atomar, weil ein fehlgeschlagener Sub-Call die äußere Transaktion zurückrollt. Aber ein Ziel-Contract, der prüft, wer ihn direkt aufruft, würde den Batcher sehen und nicht dich—außer dieser Contract ist bereits so geschrieben, dass er über den unmittelbaren Aufrufer hinwegschaut. Eine Batch-Transaktion auf Protokollebene hält dich in jedem Schritt als Aufrufer fest, aber sie kommt nicht ohne ein neues Transaktionsformat, Konsensänderungen, einen Hard Fork und das Nachziehen sämtlicher Wallet-SDKs.
Das Hinzufügen von Batching beseitigt den Tradeoff nicht. Es entscheidet, ob die Kompatibilitätsbelastung in der Anwendungsautorisierung oder im Protokoll-Stack liegt.
„Das Beheben der Atomizität beseitigt nicht den Tradeoff; es entscheidet, wohin sich die Kompatibilitätsbelastung und die Vertrauensgrenze verlagern.“
Was ich mir tatsächlich ansehen möchte: ob Dusk den Application-Level-Batcher oder die Protokoll-Level-Transaktion wählt, und welche bestehenden Annahmen zur Autorisierung diese Entscheidung Entwickler dazu zwingt zu ändern.
#dusk $DUSK @Dusk
Eine Dusk-Transaktion trägt heute eine einzelne optionale Operation: einen einzelnen Contract-Call, einen einzelnen Deploy oder ein Memo—jeweils mit einem Wert, einem Empfänger, einem Nonce und einer Signatur. Genehmigen, Tauschen und Staken werden damit zu drei separaten Transaktionen, die jeweils unabhängig voneinander aufgenommen oder verworfen werden. Das Issue von Dusk stellt das ganz klar: Es gibt keine Atomizitätsgarantie über sie hinweg. Genehmige und tausche das Land, aber nicht staken—und du bleibst mitten im Ablauf stecken, ohne Rollback auf Protokollebene.
Das Problem besteht nicht nur darin, dass mehrstufige Abläufe halbwegs stoppen können. Das Beheben daran ändert, wer die Kompatibilitätskosten tragen muss.
Ein Batcher-Contract macht die gesamte Abfolge atomar, weil ein fehlgeschlagener Sub-Call die äußere Transaktion zurückrollt. Aber ein Ziel-Contract, der prüft, wer ihn direkt aufruft, würde den Batcher sehen und nicht dich—außer dieser Contract ist bereits so geschrieben, dass er über den unmittelbaren Aufrufer hinwegschaut. Eine Batch-Transaktion auf Protokollebene hält dich in jedem Schritt als Aufrufer fest, aber sie kommt nicht ohne ein neues Transaktionsformat, Konsensänderungen, einen Hard Fork und das Nachziehen sämtlicher Wallet-SDKs.
Das Hinzufügen von Batching beseitigt den Tradeoff nicht. Es entscheidet, ob die Kompatibilitätsbelastung in der Anwendungsautorisierung oder im Protokoll-Stack liegt.
„Das Beheben der Atomizität beseitigt nicht den Tradeoff; es entscheidet, wohin sich die Kompatibilitätsbelastung und die Vertrauensgrenze verlagern.“
Was ich mir tatsächlich ansehen möchte: ob Dusk den Application-Level-Batcher oder die Protokoll-Level-Transaktion wählt, und welche bestehenden Annahmen zur Autorisierung diese Entscheidung Entwickler dazu zwingt zu ändern.
#dusk $DUSK @Dusk
