Vier Phasen, und nur eine davon ist der Teil, den du siehst
letzte Woche habe ich jemandem geholfen, ein Problem an einer Brücke zu debuggen, die komplett mit einer anderen Kette zu tun hatte, und dabei ist mir aufgefallen, dass die meisten Leute, einschließlich mir, eine eher vage Vorstellung davon haben, was passiert, nachdem man auf Senden bei einem Rollup geklickt hat.
die DuskEVM-Dokumentation erklärt das in vier Schritten.
erstens: Die Transaktion geht an den Sequencer. zwei: Die Execution Layer packt sie in einen L2-Block. drei: Der Batcher veröffentlicht die Transaktionsdaten dann bei DuskDS. vier: State-Commitments und Fault-Proofs verbinden den resultierenden State mit dem DuskDS-Settlement.
die Anzeige in deiner Wallet wird bei Schritt zwei grün.
Schritte drei und vier passieren danach – und genau sie sorgen dafür, dass es als GESETTLET gilt, statt nur „eingeschlossen“ zu sein. Die Doku sagt das ganz klar: Inklusion und Settlement sind unterschiedliche Phasen, und Anwendungen, die Werte übertragen, sollten Protokoll- oder Wallet-Status verwenden, statt Finalität aus der verstrichenen Zeit abzuleiten.
Dieser Satz leistet eine Menge Schutzarbeit, und ich vermute, dass er existiert, weil irgendwo mal jemand verbrannt wurde.
das allgemeine Fazit ist größer als Dusk. jedes optimistic Rollup hat diese Form: Die Bestätigung, die du siehst, ist nicht die Garantie, die du annimmst, und die Lücke dazwischen ist der Bereich, in dem Brücken-Exploits und Reorg-Verluste historisch ihren Platz hatten.
was ich hinzufügen würde: Das ist NOCH wichtiger für Wertpapiere als für Swaps. Ein Swap, der sich wieder auflöst, ist zwar nervig. Eine Übertragung von Wertpapieren, die sich wieder auflöst, nachdem die Gegenpartei darauf reagiert hat, ist ein rechtliches Problem, kein technisches – und der ganze Grund, warum deterministische Finalität auf der L1 so eine tragende Behauptung ist, lautet: Die darüberliegende Schicht erbt diese Eigenschaft nicht automatisch.
#dusk @Dusk $DUSK
letzte Woche habe ich jemandem geholfen, ein Problem an einer Brücke zu debuggen, die komplett mit einer anderen Kette zu tun hatte, und dabei ist mir aufgefallen, dass die meisten Leute, einschließlich mir, eine eher vage Vorstellung davon haben, was passiert, nachdem man auf Senden bei einem Rollup geklickt hat.
die DuskEVM-Dokumentation erklärt das in vier Schritten.
erstens: Die Transaktion geht an den Sequencer. zwei: Die Execution Layer packt sie in einen L2-Block. drei: Der Batcher veröffentlicht die Transaktionsdaten dann bei DuskDS. vier: State-Commitments und Fault-Proofs verbinden den resultierenden State mit dem DuskDS-Settlement.
die Anzeige in deiner Wallet wird bei Schritt zwei grün.
Schritte drei und vier passieren danach – und genau sie sorgen dafür, dass es als GESETTLET gilt, statt nur „eingeschlossen“ zu sein. Die Doku sagt das ganz klar: Inklusion und Settlement sind unterschiedliche Phasen, und Anwendungen, die Werte übertragen, sollten Protokoll- oder Wallet-Status verwenden, statt Finalität aus der verstrichenen Zeit abzuleiten.
Dieser Satz leistet eine Menge Schutzarbeit, und ich vermute, dass er existiert, weil irgendwo mal jemand verbrannt wurde.
das allgemeine Fazit ist größer als Dusk. jedes optimistic Rollup hat diese Form: Die Bestätigung, die du siehst, ist nicht die Garantie, die du annimmst, und die Lücke dazwischen ist der Bereich, in dem Brücken-Exploits und Reorg-Verluste historisch ihren Platz hatten.
was ich hinzufügen würde: Das ist NOCH wichtiger für Wertpapiere als für Swaps. Ein Swap, der sich wieder auflöst, ist zwar nervig. Eine Übertragung von Wertpapieren, die sich wieder auflöst, nachdem die Gegenpartei darauf reagiert hat, ist ein rechtliches Problem, kein technisches – und der ganze Grund, warum deterministische Finalität auf der L1 so eine tragende Behauptung ist, lautet: Die darüberliegende Schicht erbt diese Eigenschaft nicht automatisch.
#dusk @Dusk $DUSK