#dusk $DUSK
Die technischen Details dieser Dusk-virtuellen Maschine – je mehr man nachgräbt, desto kopflastiger wird’s.
Ganz am Anfang hatte ich mich gefragt, wo diese Zustände aus dem Vertrag überhaupt liegen – also Positionen, Berechtigungen usw. Ich hab ewig gesucht, bis es mir klar wurde: Sie packen den kompletten Vertragsspeicherzustand in einen zusammenhängenden Speicherblock. Nach jeder Änderung schreiben sie einfach diesen ganzen Block wieder zurück. Das ist überhaupt nicht der typische EVM-Ansatz: Bei der EVM ändert man dort, wo man ändert; es ist wie bei einem Dokument, man bearbeitet nur die eine Zeile. Bei Dusk dagegen: Selbst wenn man nur eine Zahl ändert, muss die komplette Seite Speicher neu aufgebaut und neu geschrieben werden.
Das ist schon teuer genug – und dann kommt noch das doppelte Kassenbuch-Design obendrauf. Ein öffentliches Buch zur Einsicht für Regulierungsbehörden, und ein privates Buch läuft in der XSC. Pro Transaktion: Der öffentliche Zustand wird einmal geändert, der private Zustand wird einmal neu generiert – und beide Speicher-Kopien müssen zurückgeschrieben werden. Auf Hedger-Seite muss außerdem nochmal ein Zero-Knowledge-Beweis durchlaufen werden, und die Knoten rechnen erneut nach. Ergebnis: Die Kosten sind nicht einfach 1+1, sie multiplizieren sich.
Bei tokenisierten Wertpapieren erhöhen sich diese Zustände – wie Bestände, Whitelist, Locking-Regeln – ohnehin nur, sie werden nie kleiner. Wenn du so einen komplexeren XSC-Vertrag deployst, dann gilt: Schon bei einer einzigen Kontoänderung muss die gesamte Speicherseite vollumfänglich neu geschrieben werden.
Da wird jemand bestimmt sagen: „Na und? Die Zustände laufen doch in der oberen Schicht, und die untere DuskDS speichert nur die Beweise.“ Das klingt erst mal plausibel, aber wenn man genauer nachdenkt, stimmt es nicht! Speichert der Archivknoten etwa keine historischen Speicher-Snapshots? Wenn nicht, worauf soll man dann bei einer späteren Prüfung in der Historie schauen? Auf die Luft? Wenn doch – was ist dann der Unterschied zum Vollknoten? Damit schiebst du im Grunde nur das Problem, dass der Zustand immer weiter aufgestapelt wird, von der Ausführungsschicht in die Archivschicht.
Offiziell wird darüber hin und hergeredet, aber es gibt nicht eine einzige klare, positive Antwort.
Momentan interessiert mich besonders, wie NPEX in der Praxis seine echten Wertpapierverträge on-chain abwickelt. Wenn innerhalb von sechs Monaten die Zustandsgröße eines einzelnen Vertrags das Zehnfache eines normalen ERC20 erreicht – oder wenn Archivknoten anfangen, heimlich Speicher-Snapshots zu speichern – dann ist dieses Design schlicht eine Zeitbombe für RWA. Dann fasse ich es direkt nicht an.
Ach ja! Noch ein Stolperstein: Der kompakte Beweis von DuskDS kann zwar belegen, dass das private Kassenbuch an sich korrekt ist – aber kann er auch beweisen, dass jede einzelne historische Speicher-Snapshot-Aufzeichnung durchgehend konsistent und nie verändert wurde? Wenn das nicht geht, dann bricht die Prüfspur für tokenisierte Wertpapiere direkt zwischen der Privacy-Schicht und der Archivschicht ab.
@Dusk
Die technischen Details dieser Dusk-virtuellen Maschine – je mehr man nachgräbt, desto kopflastiger wird’s.
Ganz am Anfang hatte ich mich gefragt, wo diese Zustände aus dem Vertrag überhaupt liegen – also Positionen, Berechtigungen usw. Ich hab ewig gesucht, bis es mir klar wurde: Sie packen den kompletten Vertragsspeicherzustand in einen zusammenhängenden Speicherblock. Nach jeder Änderung schreiben sie einfach diesen ganzen Block wieder zurück. Das ist überhaupt nicht der typische EVM-Ansatz: Bei der EVM ändert man dort, wo man ändert; es ist wie bei einem Dokument, man bearbeitet nur die eine Zeile. Bei Dusk dagegen: Selbst wenn man nur eine Zahl ändert, muss die komplette Seite Speicher neu aufgebaut und neu geschrieben werden.
Das ist schon teuer genug – und dann kommt noch das doppelte Kassenbuch-Design obendrauf. Ein öffentliches Buch zur Einsicht für Regulierungsbehörden, und ein privates Buch läuft in der XSC. Pro Transaktion: Der öffentliche Zustand wird einmal geändert, der private Zustand wird einmal neu generiert – und beide Speicher-Kopien müssen zurückgeschrieben werden. Auf Hedger-Seite muss außerdem nochmal ein Zero-Knowledge-Beweis durchlaufen werden, und die Knoten rechnen erneut nach. Ergebnis: Die Kosten sind nicht einfach 1+1, sie multiplizieren sich.
Bei tokenisierten Wertpapieren erhöhen sich diese Zustände – wie Bestände, Whitelist, Locking-Regeln – ohnehin nur, sie werden nie kleiner. Wenn du so einen komplexeren XSC-Vertrag deployst, dann gilt: Schon bei einer einzigen Kontoänderung muss die gesamte Speicherseite vollumfänglich neu geschrieben werden.
Da wird jemand bestimmt sagen: „Na und? Die Zustände laufen doch in der oberen Schicht, und die untere DuskDS speichert nur die Beweise.“ Das klingt erst mal plausibel, aber wenn man genauer nachdenkt, stimmt es nicht! Speichert der Archivknoten etwa keine historischen Speicher-Snapshots? Wenn nicht, worauf soll man dann bei einer späteren Prüfung in der Historie schauen? Auf die Luft? Wenn doch – was ist dann der Unterschied zum Vollknoten? Damit schiebst du im Grunde nur das Problem, dass der Zustand immer weiter aufgestapelt wird, von der Ausführungsschicht in die Archivschicht.
Offiziell wird darüber hin und hergeredet, aber es gibt nicht eine einzige klare, positive Antwort.
Momentan interessiert mich besonders, wie NPEX in der Praxis seine echten Wertpapierverträge on-chain abwickelt. Wenn innerhalb von sechs Monaten die Zustandsgröße eines einzelnen Vertrags das Zehnfache eines normalen ERC20 erreicht – oder wenn Archivknoten anfangen, heimlich Speicher-Snapshots zu speichern – dann ist dieses Design schlicht eine Zeitbombe für RWA. Dann fasse ich es direkt nicht an.
Ach ja! Noch ein Stolperstein: Der kompakte Beweis von DuskDS kann zwar belegen, dass das private Kassenbuch an sich korrekt ist – aber kann er auch beweisen, dass jede einzelne historische Speicher-Snapshot-Aufzeichnung durchgehend konsistent und nie verändert wurde? Wenn das nicht geht, dann bricht die Prüfspur für tokenisierte Wertpapiere direkt zwischen der Privacy-Schicht und der Archivschicht ab.
@Dusk