Ich bin heute damit beschäftigt gewesen, mir Schritt für Schritt anzusehen, wie DuskEVM eine Transaktion tatsächlich von Anfang bis Ende verarbeitet. Der Grund: Ich habe immer wieder „Rollup“ gelesen, aber ohne dass die konkreten Mechanismen wirklich erklärt wurden. Also dachte ich mir, ich verfolge es selbst.
Es beginnt damit, dass du eine Transaktion an den DuskEVM-Sequencer übermittelst – dieser Teil ist vertraut, wenn du irgendetwas anderes mit einem Rollup berührt hast, also eine Standard-Solidity/EVM-Transaktion, noch nichts Exotisches. Von dort aus nimmt die Execution Layer die Transaktion in einen L2-Block auf. Bis hierhin ist es einfach normales Rollup-Verhalten, das auf der Execution-Seite schnell abläuft.
Spannender wird es bei den nächsten zwei Schritten. Der Batcher nimmt die Transaktionsdaten und veröffentlicht sie in DuskDS – das ist Dusk’ eigentliche Konsens-, Settlement- und Data-Availability-Layer, also genau die Ebene, die die ganze schwere Arbeit im Hintergrund erledigt. Danach sind State-Commitments und Fault Proofs das, was den resultierenden DuskEVM-Status tatsächlich wieder mit dem DuskDS-Settlement verbindet.
Der praktische Punkt, der meiner Meinung nach am wichtigsten ist: Inklusion und Settlement sind hier ausdrücklich unterschiedliche Phasen – nicht dasselbe Ding mit zwei Namen. Dass deine Tx schnell in einen L2-Block aufgenommen wird, passiert zügig, aber das ist nicht dasselbe wie „settled“. Und die Doku ist hier ziemlich klar: Wenn du etwas baust, das Werte zwischen DuskEVM und dem Dusk L1 bewegt, solltest du den tatsächlichen Protokoll- oder Wallet-Status prüfen – nicht einfach davon ausgehen, dass etwas endgültig ist, nur weil seit einer gewissen Zeit etwas vergangen ist.
Das ist eine Unterscheidung, die viele Leute meiner Ansicht nach überspringen, wenn sie „fast rollup“ hören und annehmen, dass allein die Geschwindigkeit automatisch Finalität bedeutet. Dem ist nicht so – zumindest nicht nur dadurch.
Trotzdem möchte ich noch herausfinden, wie die tatsächliche typische Lücke zwischen Inklusion und vollständigem Settlement in der Praxis aussieht. Die Doku beschreibt zwar die Phasen, aber keine konkreten Zeitangaben.
#dusk @Dusk $DUSK
Es beginnt damit, dass du eine Transaktion an den DuskEVM-Sequencer übermittelst – dieser Teil ist vertraut, wenn du irgendetwas anderes mit einem Rollup berührt hast, also eine Standard-Solidity/EVM-Transaktion, noch nichts Exotisches. Von dort aus nimmt die Execution Layer die Transaktion in einen L2-Block auf. Bis hierhin ist es einfach normales Rollup-Verhalten, das auf der Execution-Seite schnell abläuft.
Spannender wird es bei den nächsten zwei Schritten. Der Batcher nimmt die Transaktionsdaten und veröffentlicht sie in DuskDS – das ist Dusk’ eigentliche Konsens-, Settlement- und Data-Availability-Layer, also genau die Ebene, die die ganze schwere Arbeit im Hintergrund erledigt. Danach sind State-Commitments und Fault Proofs das, was den resultierenden DuskEVM-Status tatsächlich wieder mit dem DuskDS-Settlement verbindet.
Der praktische Punkt, der meiner Meinung nach am wichtigsten ist: Inklusion und Settlement sind hier ausdrücklich unterschiedliche Phasen – nicht dasselbe Ding mit zwei Namen. Dass deine Tx schnell in einen L2-Block aufgenommen wird, passiert zügig, aber das ist nicht dasselbe wie „settled“. Und die Doku ist hier ziemlich klar: Wenn du etwas baust, das Werte zwischen DuskEVM und dem Dusk L1 bewegt, solltest du den tatsächlichen Protokoll- oder Wallet-Status prüfen – nicht einfach davon ausgehen, dass etwas endgültig ist, nur weil seit einer gewissen Zeit etwas vergangen ist.
Das ist eine Unterscheidung, die viele Leute meiner Ansicht nach überspringen, wenn sie „fast rollup“ hören und annehmen, dass allein die Geschwindigkeit automatisch Finalität bedeutet. Dem ist nicht so – zumindest nicht nur dadurch.
Trotzdem möchte ich noch herausfinden, wie die tatsächliche typische Lücke zwischen Inklusion und vollständigem Settlement in der Praxis aussieht. Die Doku beschreibt zwar die Phasen, aber keine konkreten Zeitangaben.
#dusk @Dusk $DUSK
YES
0%
NO
0%
0 Stimmen • Abstimmung beendet