Jetzt sind Notebooks, die von KI beeinflusst sind, völlig überteuert. Früher waren die Notebooks richtig zäh – ich wollte damals ein neues holen, aber es war einfach zu teuer. Also habe ich jemanden gebeten, nach dem Grund für die „Hänger“ zu schauen. Bei der Prüfung stellte sich heraus, dass eine ganze Reihe von Software jeweils eigene Funktionen auf den System-Under-the-Hood-Möglichkeiten nutzt und sich dabei gegenseitig Ressourcen wegnimmt. Der Meister hatte einen neuen Ansatz: Die paar Vorgänge, die die meisten Ressourcen fressen, werden direkt als Hardwarebeschleunigung umgesetzt – statt sie weiterhin komplett über Software zu simulieren. Die Geschwindigkeit war danach sofort eine ganz andere.
Das, was Dusk mit der VM Piecrust macht, ist im Grunde etwas Ähnliches. Smart Contracts laufen selbst in einer WASM-Sandbox – das ist für Sicherheit und Portabilität gedacht, hat aber den Preis, dass es langsam ist. Vor allem kryptografische Operationen wie Hashes, Signaturprüfungen und Zero-Knowledge-Beweise kosten in der Sandbox richtig viel. Der Weg von Dusk: Diese paar besonders häufigen Operationen werden einzeln herausgenommen und als „Host Functions“ umgesetzt. Dann wird direkt nativer Code aufgerufen, statt die Berechnungen im WASM selbst „hart“ zu simulieren.
Konkret werden diese Dinge herausgelöst: Hashing mit Blake2b und Poseidon, Verifikation mit verify_plonk (PlonK-Beweis), verify_groth16_bn254 sowie zwei Varianten zur Signaturprüfung – verify_schnorr und verify_bls. Diese decken im Wesentlichen die kryptografischen Operationen ab, die Dusk für seine gesamte Privacy- und Konsens-Mechanik braucht. Im Effekt wird die mühsamste Arbeit als eine Art Hintertür separat erledigt – nicht über den normalen Sandbox-Pfad.
Das Design bringt zwar deutlich mehr Ausführungs- und Effizienzleistung, bedeutet aber auch, dass die Korrektheit der Host-Function-Implementierungen selbst extrem entscheidend ist. Wenn diese nativen Funktionen Schwachstellen haben, sind die Auswirkungen direkter als bei Problemen auf Software-Ebene – denn alle Contracts teilen sich denselben gemeinsamen Hardwarebeschleunigungs-Kanal.
$DUSK
#dusk @Dusk
Das, was Dusk mit der VM Piecrust macht, ist im Grunde etwas Ähnliches. Smart Contracts laufen selbst in einer WASM-Sandbox – das ist für Sicherheit und Portabilität gedacht, hat aber den Preis, dass es langsam ist. Vor allem kryptografische Operationen wie Hashes, Signaturprüfungen und Zero-Knowledge-Beweise kosten in der Sandbox richtig viel. Der Weg von Dusk: Diese paar besonders häufigen Operationen werden einzeln herausgenommen und als „Host Functions“ umgesetzt. Dann wird direkt nativer Code aufgerufen, statt die Berechnungen im WASM selbst „hart“ zu simulieren.
Konkret werden diese Dinge herausgelöst: Hashing mit Blake2b und Poseidon, Verifikation mit verify_plonk (PlonK-Beweis), verify_groth16_bn254 sowie zwei Varianten zur Signaturprüfung – verify_schnorr und verify_bls. Diese decken im Wesentlichen die kryptografischen Operationen ab, die Dusk für seine gesamte Privacy- und Konsens-Mechanik braucht. Im Effekt wird die mühsamste Arbeit als eine Art Hintertür separat erledigt – nicht über den normalen Sandbox-Pfad.
Das Design bringt zwar deutlich mehr Ausführungs- und Effizienzleistung, bedeutet aber auch, dass die Korrektheit der Host-Function-Implementierungen selbst extrem entscheidend ist. Wenn diese nativen Funktionen Schwachstellen haben, sind die Auswirkungen direkter als bei Problemen auf Software-Ebene – denn alle Contracts teilen sich denselben gemeinsamen Hardwarebeschleunigungs-Kanal.
$DUSK
#dusk @Dusk