#dusk $DUSK übersetzt @Dusk , während ich die Architektur-Dokumentation lese, ist mir eine Designentscheidung aufgefallen, die leicht in einem einzigen Satz untergehen kann: DuskDS macht den Abgleich und die Datenverfügbarkeit, DuskEVM macht die Ausführung. Der Abgleich und die Ausführung sind getrennt – nicht einfach so, sondern dahinter steckt eine ganze Reihe von Abwägungen zwischen „Schnelligkeit“ und „Sicherheit“.
Wenn man dieses Design in den Kontext von OP Stack setzt, wird es klar. DuskEVM ist die Ausführungsumgebung; Solidity-Verträge laufen auf der EVM-Seite, die Gas-Kosten für Nutzerinteraktionen und Zustandsänderungen passieren in dieser Schicht. Aber DuskDS ist die eigentliche Abrechnungsschicht – die Ausgaben der EVM-Seite müssen nach L1 übermittelt, verifiziert und dann über das Warten auf proof maturity sowie das dispute-game-Fenster final „protokollbedeutend“ werden. Schnelle Ausführung gehört zur EVM-Schicht, endgültige Sicherheit zur L1-Schicht.
Die Kosten dieser Architektur sind ebenfalls direkt: Übergreifende Operationen müssen warten. Abhebungen müssen über drei Schritte laufen: Output-Proposal, Proof-Submission und finalize. Jede Stufe hat ein Zeitfenster – das ist keine Ein-Klick-Aktion. Aktuell läuft diese Architektur noch im Testnetz und verwendet Test-Token ohne realen Wert. Dass der Testprozess funktioniert, beweist nur, dass der Protokollpfad grundsätzlich gangbar ist; es lässt sich daraus weder ein Starttermin für das Mainnet ableiten noch die Stabilität von Output-Proposals und finalize unter hoher Last.
Daher bin ich bei dem Label „EVM-kompatibel“ weiterhin vorsichtig. Das, was wirklich zu validieren ist, ist nicht, ob Solidity laufen kann, sondern wie lange der gesamte Abwicklungs-Ablauf über Ebenen tatsächlich dauert, wie die Wiederherstellung nach einem Scheitern funktioniert und wie sich diese getrennte Architektur unter hoher Last verhält, nachdem die Mainnet-Parameter veröffentlicht sind. Ausführungs- und Abrechnungsschicht sind getrennt; man sagt zwar, das sei modular, aber in der Nutzererfahrung ist das Konto am Ende Sache des Produkts. #dusk @Dusk
Wenn man dieses Design in den Kontext von OP Stack setzt, wird es klar. DuskEVM ist die Ausführungsumgebung; Solidity-Verträge laufen auf der EVM-Seite, die Gas-Kosten für Nutzerinteraktionen und Zustandsänderungen passieren in dieser Schicht. Aber DuskDS ist die eigentliche Abrechnungsschicht – die Ausgaben der EVM-Seite müssen nach L1 übermittelt, verifiziert und dann über das Warten auf proof maturity sowie das dispute-game-Fenster final „protokollbedeutend“ werden. Schnelle Ausführung gehört zur EVM-Schicht, endgültige Sicherheit zur L1-Schicht.
Die Kosten dieser Architektur sind ebenfalls direkt: Übergreifende Operationen müssen warten. Abhebungen müssen über drei Schritte laufen: Output-Proposal, Proof-Submission und finalize. Jede Stufe hat ein Zeitfenster – das ist keine Ein-Klick-Aktion. Aktuell läuft diese Architektur noch im Testnetz und verwendet Test-Token ohne realen Wert. Dass der Testprozess funktioniert, beweist nur, dass der Protokollpfad grundsätzlich gangbar ist; es lässt sich daraus weder ein Starttermin für das Mainnet ableiten noch die Stabilität von Output-Proposals und finalize unter hoher Last.
Daher bin ich bei dem Label „EVM-kompatibel“ weiterhin vorsichtig. Das, was wirklich zu validieren ist, ist nicht, ob Solidity laufen kann, sondern wie lange der gesamte Abwicklungs-Ablauf über Ebenen tatsächlich dauert, wie die Wiederherstellung nach einem Scheitern funktioniert und wie sich diese getrennte Architektur unter hoher Last verhält, nachdem die Mainnet-Parameter veröffentlicht sind. Ausführungs- und Abrechnungsschicht sind getrennt; man sagt zwar, das sei modular, aber in der Nutzererfahrung ist das Konto am Ende Sache des Produkts. #dusk @Dusk
分层架构是优势还是负担
0%
DuskDS和EVM分家合理吗?
0%
跨层退出体验如何
100%
1 Stimmen • Abstimmung beendet