#dusk $DUSK @Dusk letzter Thread, den ich diese Woche in der Warteschlange habe, und er verbindet sehr viele der früheren Posts miteinander – die tatsächliche Aufteilung der Zuständigkeiten zwischen DuskDS, DuskEVM und der Bridge. Ich habe alle drei in den vergangenen zwei Wochen jeweils einzeln erwähnt, ohne sie jemals nebeneinander als drei getrennt benannte Verantwortlichkeiten darzustellen.
DuskDS ist Konsens, Abrechnung (Settlement) und Datenverfügbarkeit. Das ist die Basisschicht, die die schwere Arbeit übernimmt, die ich bereits an Tag eins abgedeckt habe – die Grundlage, gegen die DuskEVM-Transaktionen letztlich abgerechnet werden, die Quelle der Wahrheit für Finalität.
DuskEVM ist die Ausführung von smarten Verträgen, die mit Ethereum kompatibel ist. Das ist die Anwendungsschicht, in der Solidity-Contracts tatsächlich laufen, wo der Sequencer Transaktionen verarbeitet und sie zu Batches zusammenfasst, um sie anschließend wieder in DuskDS zu veröffentlichen.
Die Bridge ist das dritte, leicht zu übersehende Element – sie bewegt DUSK und Nachrichten zwischen den beiden Umgebungen. Ohne diese explizit als eigenes Bauteil zu benennen, wären DUSK, das für Gas auf DuskEVM verwendet wird, und DUSK auf dem Dusk-L1 einfach zwei getrennte Dinge, nicht eine einzige, als Asset über beide Umgebungen hinweg nutzbare Einheit.
Warum ist es wichtig, das in drei benannte Teile aufzuteilen, statt einfach „die Dusk-Blockchain“ als ein einziges Ding zu sagen – weil jedes Teil eine wirklich andere Aufgabe hat und separat betrachtet werden kann. Abrechnungsgarantien leben in DuskDS. Ausführung und Contract-Logik leben in DuskEVM. Asset- und Nachrichtenbewegung zwischen ihnen leben ganz speziell in der Bridge. Wenn etwas schiefgeht oder du verstehen willst, woher eine bestimmte Garantie tatsächlich kommt (ist meine Transaktion final, wird mein Contract korrekt ausgeführt, ist mein DUSK tatsächlich gewandert), kannst du ganz genau auf eines der drei Komponenten zeigen, das für diese konkrete Garantie verantwortlich ist, statt den gesamten Stack als eine einzige, undifferenzierte Blackbox zu behandeln.
#dusk @Dusk $DUSK
DuskDS ist Konsens, Abrechnung (Settlement) und Datenverfügbarkeit. Das ist die Basisschicht, die die schwere Arbeit übernimmt, die ich bereits an Tag eins abgedeckt habe – die Grundlage, gegen die DuskEVM-Transaktionen letztlich abgerechnet werden, die Quelle der Wahrheit für Finalität.
DuskEVM ist die Ausführung von smarten Verträgen, die mit Ethereum kompatibel ist. Das ist die Anwendungsschicht, in der Solidity-Contracts tatsächlich laufen, wo der Sequencer Transaktionen verarbeitet und sie zu Batches zusammenfasst, um sie anschließend wieder in DuskDS zu veröffentlichen.
Die Bridge ist das dritte, leicht zu übersehende Element – sie bewegt DUSK und Nachrichten zwischen den beiden Umgebungen. Ohne diese explizit als eigenes Bauteil zu benennen, wären DUSK, das für Gas auf DuskEVM verwendet wird, und DUSK auf dem Dusk-L1 einfach zwei getrennte Dinge, nicht eine einzige, als Asset über beide Umgebungen hinweg nutzbare Einheit.
Warum ist es wichtig, das in drei benannte Teile aufzuteilen, statt einfach „die Dusk-Blockchain“ als ein einziges Ding zu sagen – weil jedes Teil eine wirklich andere Aufgabe hat und separat betrachtet werden kann. Abrechnungsgarantien leben in DuskDS. Ausführung und Contract-Logik leben in DuskEVM. Asset- und Nachrichtenbewegung zwischen ihnen leben ganz speziell in der Bridge. Wenn etwas schiefgeht oder du verstehen willst, woher eine bestimmte Garantie tatsächlich kommt (ist meine Transaktion final, wird mein Contract korrekt ausgeführt, ist mein DUSK tatsächlich gewandert), kannst du ganz genau auf eines der drei Komponenten zeigen, das für diese konkrete Garantie verantwortlich ist, statt den gesamten Stack als eine einzige, undifferenzierte Blackbox zu behandeln.
#dusk @Dusk $DUSK
YES
0%
NO
0%
0 Stimmen • Abstimmung beendet