#dusk $DUSK 授权 wurde bereits freigegeben, der Tausch hat nicht成交, und das Staking wurde ebenfalls gestoppt. In dieser Phase sind die Gelder nicht wie geplant geflossen, aber der Markt bewegt sich trotzdem. Als Nächstes muss man die Autorisierung zurückziehen, neu senden und absichern/gegensteuern – jeder Schritt erfordert erneut eine Zahlung.----Wenn du so einen Transaktionsablauf-Design siehst, was denkst du darüber?
Ich betrachte den gängigen Pfad „Approve→Swap→Stake“ und ordne ihn der aktuellen Transaktionsstruktur von Dusk zu. In den offenen Diskussionen im offiziellen Rusk-Repository heißt es, dass derzeit bei einer Moonlight- oder Phoenix-Transaktion nur eine Top-Level-Aktion mitkommt, und im Transaktionsformat noch kein natives Batch vorgesehen ist. Es gibt keinen speziellen Router-Contract; die drei Schritte müssen daher einzeln gesendet werden. Sobald der erste Schritt bestätigt ist, scheitert der zweite Schritt – und der erste wird nicht automatisch zurückgerollt.
Gerade gesehen: Im Prozess zahlen alle drei Schritte jeweils eigenes Gas. Da hätte ich DUSK fast schon ein bisschen gejubelt. Aber als ich mir die Positionen nach einem Scheitern und die Kosten für die Behebung als Diagramm vor Augen führe, ist die Begeisterung in dem Moment verschwunden. Wenn alles durchläuft, entstehen Business-Gebühren; wenn es fehlschlägt, entstehen Gebühren durch das Zurückziehen der Autorisierung, Retries und Rückwärtsaktionen – also eine Art „Unfallkosten“. Beide Kosten verbrauchen DUSK, aber langfristig ist der Wertunterschied enorm.
Dusk könnte zunächst Router-Contracts vorschalten, die die drei Schritte in einem erledigen. Aber manche Ziel-Contracts akzeptieren nur „die Person, die gerade die Aufgabe erledigt“, also den aktuellen Caller. Sie sehen dann den Router-Contract und erkennen womöglich nicht die echten Berechtigungen des eigentlichen Nutzers an. Native Batch-Funktionalität auf Protokollebene könnte die Nutzeridentität bewahren; der Preis wäre jedoch, dass Transaktionsformat, Knoten und Wallets gemeinsam aktualisiert werden müssen. Plötzlich wirkt diese Aufgabe ein wenig schwer zu lösen.
Phoenix hat hier aber eine Dusk-spezifische Trumpfkarte: Der Privacy-Proof speichert nur den „Fingerprint“ des Aufrufinhalts, ohne jeden einzelnen Schritt verstehen zu müssen. Ich denke, wenn man später Batch hinzufügt, müsste man theoretisch weder die Privacy-Schaltkreise noch die kompletten Proof-Parameter neu aufsetzen. Dusk hätte dadurch die Chance, komplexe Abläufe als „Alles oder nichts“ umzusetzen, und die Umbaukosten könnten entsprechend niedriger ausfallen.
Für $DUSK glaube ich: Das Gas pro Single-Flow sollte gemeinsam mit Erfolgsquote, Anteil der benötigten Rückabwicklungs-/Behebungs-Transaktionen und der Nutzer-Wiederverwendungsrate in derselben Tabelle betrachtet werden. Jede einzelne Taste kostet – das allein ist bei weitem nicht genug. Erst wenn eine Reihe von Transaktionen in hoher Effizienz vollständig und reibungslos umgesetzt werden kann, sind Nutzer bereit, die nächste Geldmenge auch weiterhin auf der Kette zu lassen.
Sparen bei den Kosten und trotzdem ein geschmeidiges Erlebnis – welche Transaktion könnte dem widerstehen? Das ist einer der Indikatoren, anhand dessen ich $DUSK langfristige Bewertung/Value einschätze.
@Dusk
$BTC
Ich betrachte den gängigen Pfad „Approve→Swap→Stake“ und ordne ihn der aktuellen Transaktionsstruktur von Dusk zu. In den offenen Diskussionen im offiziellen Rusk-Repository heißt es, dass derzeit bei einer Moonlight- oder Phoenix-Transaktion nur eine Top-Level-Aktion mitkommt, und im Transaktionsformat noch kein natives Batch vorgesehen ist. Es gibt keinen speziellen Router-Contract; die drei Schritte müssen daher einzeln gesendet werden. Sobald der erste Schritt bestätigt ist, scheitert der zweite Schritt – und der erste wird nicht automatisch zurückgerollt.
Gerade gesehen: Im Prozess zahlen alle drei Schritte jeweils eigenes Gas. Da hätte ich DUSK fast schon ein bisschen gejubelt. Aber als ich mir die Positionen nach einem Scheitern und die Kosten für die Behebung als Diagramm vor Augen führe, ist die Begeisterung in dem Moment verschwunden. Wenn alles durchläuft, entstehen Business-Gebühren; wenn es fehlschlägt, entstehen Gebühren durch das Zurückziehen der Autorisierung, Retries und Rückwärtsaktionen – also eine Art „Unfallkosten“. Beide Kosten verbrauchen DUSK, aber langfristig ist der Wertunterschied enorm.
Dusk könnte zunächst Router-Contracts vorschalten, die die drei Schritte in einem erledigen. Aber manche Ziel-Contracts akzeptieren nur „die Person, die gerade die Aufgabe erledigt“, also den aktuellen Caller. Sie sehen dann den Router-Contract und erkennen womöglich nicht die echten Berechtigungen des eigentlichen Nutzers an. Native Batch-Funktionalität auf Protokollebene könnte die Nutzeridentität bewahren; der Preis wäre jedoch, dass Transaktionsformat, Knoten und Wallets gemeinsam aktualisiert werden müssen. Plötzlich wirkt diese Aufgabe ein wenig schwer zu lösen.
Phoenix hat hier aber eine Dusk-spezifische Trumpfkarte: Der Privacy-Proof speichert nur den „Fingerprint“ des Aufrufinhalts, ohne jeden einzelnen Schritt verstehen zu müssen. Ich denke, wenn man später Batch hinzufügt, müsste man theoretisch weder die Privacy-Schaltkreise noch die kompletten Proof-Parameter neu aufsetzen. Dusk hätte dadurch die Chance, komplexe Abläufe als „Alles oder nichts“ umzusetzen, und die Umbaukosten könnten entsprechend niedriger ausfallen.
Für $DUSK glaube ich: Das Gas pro Single-Flow sollte gemeinsam mit Erfolgsquote, Anteil der benötigten Rückabwicklungs-/Behebungs-Transaktionen und der Nutzer-Wiederverwendungsrate in derselben Tabelle betrachtet werden. Jede einzelne Taste kostet – das allein ist bei weitem nicht genug. Erst wenn eine Reihe von Transaktionen in hoher Effizienz vollständig und reibungslos umgesetzt werden kann, sind Nutzer bereit, die nächste Geldmenge auch weiterhin auf der Kette zu lassen.
Sparen bei den Kosten und trotzdem ein geschmeidiges Erlebnis – welche Transaktion könnte dem widerstehen? Das ist einer der Indikatoren, anhand dessen ich $DUSK langfristige Bewertung/Value einschätze.
@Dusk
$BTC