#dusk $DUSK
Ich habe gestern Nacht noch einmal durch die @Dusk dokumentation gearbeitet und dabei gemerkt, wie ich „finalized“ als einen einzelnen Zeitpunkt behandelt habe. Ich ging davon aus, dass, sobald eine Dusk-Transaktion final ist, die Gelder sofort auf DuskEVM existieren müssten. Die Doku machte diese Annahme sogar noch zu einfach.
Im DuskEVM-Testnet wird auf Dusk L1 eine Einzahlung eingereicht und finalisiert, dann verarbeitet, bevor der Kontostand auf DuskEVM verfügbar wird. Ein Abzug hat mehr Stufen: Initiieren auf DuskEVM, auf einen Output warten, auf Dusk L1 beweisen, die erforderlichen Maturitäts- und Dispute-Game-Checks bestehen, und dann auf L1 finalisieren. Die Dokumentation warnt, dass Aufnahme, Ausführung und Finalität nicht denselben Status bedeuten, und dass die Bereitschaft aus dem Protokollzustand stammen sollte und nicht aus verstrichener Zeit.
Das hat mich dazu gebracht, es anders zu betrachten.
Meine Interpretation: Die Bridge ist keine versteckte Verzögerung; sie versucht vielmehr, eine Cross-Layer-State-Machine so zu machen, dass eine Wallet sie erklären kann. Die Spannung liegt zwischen Sicherheit und operativer Abhängigkeit. Sichere Retries, Rollback-Recovery und Challenge-Checks reduzieren eine Art von Ausfall, aber Recovery-Pfade konzentrieren die Verantwortung auch an einer Stelle.
Meine Unsicherheit: Was kann ein Nutzer während eines Rollbacks plus Relayer-Ausfall unabhängig verifizieren, bevor die Gelder freigegeben oder erneut versucht werden? Wer kann Bridge-Operationen anhalten oder fortsetzen, und welche Grenzen gilt dieser Befugnis, wenn der Notfall länger dauert als erwartet?
Ich möchte das in der Praxis beobachten.
Ich habe gestern Nacht noch einmal durch die @Dusk dokumentation gearbeitet und dabei gemerkt, wie ich „finalized“ als einen einzelnen Zeitpunkt behandelt habe. Ich ging davon aus, dass, sobald eine Dusk-Transaktion final ist, die Gelder sofort auf DuskEVM existieren müssten. Die Doku machte diese Annahme sogar noch zu einfach.
Im DuskEVM-Testnet wird auf Dusk L1 eine Einzahlung eingereicht und finalisiert, dann verarbeitet, bevor der Kontostand auf DuskEVM verfügbar wird. Ein Abzug hat mehr Stufen: Initiieren auf DuskEVM, auf einen Output warten, auf Dusk L1 beweisen, die erforderlichen Maturitäts- und Dispute-Game-Checks bestehen, und dann auf L1 finalisieren. Die Dokumentation warnt, dass Aufnahme, Ausführung und Finalität nicht denselben Status bedeuten, und dass die Bereitschaft aus dem Protokollzustand stammen sollte und nicht aus verstrichener Zeit.
Das hat mich dazu gebracht, es anders zu betrachten.
Meine Interpretation: Die Bridge ist keine versteckte Verzögerung; sie versucht vielmehr, eine Cross-Layer-State-Machine so zu machen, dass eine Wallet sie erklären kann. Die Spannung liegt zwischen Sicherheit und operativer Abhängigkeit. Sichere Retries, Rollback-Recovery und Challenge-Checks reduzieren eine Art von Ausfall, aber Recovery-Pfade konzentrieren die Verantwortung auch an einer Stelle.
Meine Unsicherheit: Was kann ein Nutzer während eines Rollbacks plus Relayer-Ausfall unabhängig verifizieren, bevor die Gelder freigegeben oder erneut versucht werden? Wer kann Bridge-Operationen anhalten oder fortsetzen, und welche Grenzen gilt dieser Befugnis, wenn der Notfall länger dauert als erwartet?
Ich möchte das in der Praxis beobachten.
