Heute Abend habe ich die Node-Logs ausgeschüttet und einmal komplett durchgescannt, da ist mir plötzlich ein Streit aus der letzten Woche mit einem Freund eingefallen, der Audits macht.
Der Kuchen ist ein bisschen gefallen, aber der BTC-Aufwärtstrend bleibt!
Er fragte mich: „Ihr lauft Dusk und seid wirklich sicher, dass ihr die Verifikationslogik außerhalb von WASM wegwerft?“ Da hab ich damals nicht richtig aufgefangen – mit hartem Mund gesagt: „In den Whitepapern steht doch, dass es auditiert wurde“, aber innerlich war ich eigentlich unsicher. Erst heute Abend, als ich die Testfälle für den host function-Stack von Piecrust auf deren GitHub gefunden habe, habe ich das Ganze ein bisschen besser verstanden.
Kurz gesagt: Die klassische Idee „alles im selben Sandbox-Käfig komplett einsperren“ ist wie im Laden Zigaretten kaufen: Du musst erst durch die Sicherheitskontrolle, den Ausweis zeigen, die Tasche durchsuchen lassen – und erst dann darfst du bezahlen. Sicher ist es sicher, aber die Leute hinter dir werden sich die ganze Zeit aufregen. Dusk setzt auf einen anderen Weg: Hochfrequente Aktionen laufen über einen dedizierten Kanal, nur die Niedrigfrequenz-Aktionen müssen durch die Schranke.
Die von ihnen eingebundenen Drittanbieter-Daten habe ich extra im Original nachgeschaut. Das Paper testet die Performance-Einbußen von WASM gegenüber nativ unter verschiedenen Befehlssätzen; im extremsten Kryptoszenario liegt die Overhead-Zahl bei 255%. Rechne dir aus: Wie viele Transaktionen müssen bei Dusk pro Tag eine BLS-Signaturprüfung durchlaufen, und wie viele eine ZK-Generierung? Wenn jede einzelne davon WASM alles erklären lassen muss, heißt das im Ergebnis: Für jede Strecke von einem Kilometer zahlst du effektiv so viel Öl wie für zweieinhalb. Wer kann das schon tragen?
Darum machen sie diese Sachen auf dem Niveau von Systemaufrufen und rufen direkt die nativen Implementierungen. Was ist der Preis? Das Vertrauens-„Radius“ schrumpft von „dieser WASM-Sandbox-Eisenklotz“ auf „ob in den ein paar C-Zeilen der Host-Funktion sauber gearbeitet wurde“. Diese zwei Risiken sind nicht vergleichbar: Das eine ist physische Isolation, das andere ist Codequalität.
Ich habe auch den Audit-Report für 2024 Q3 durchgesehen (tief irgendwo auf der Website versteckt) – zumindest damals haben die getesteten Randfälle keine Löcher aufgerissen. Aber ehrlich gesagt: Diese Angriffsfläche wird nicht „gemessen“, sondern „ausgenutzt“. Irgendwann füttert jemand bewusst konstruierte Beweisdaten ein, triggert in einer host function einen Integer-Overflow, den niemand auf dem Schirm hatte – die Vorstellung ist zu schön, um sie mir auszumalen.
Aber umgekehrt: Wenn du wirklich „absolute Sicherheit“ suchst, dann mach keinen Public-Chain-Kram. Geh zurück und schreib ein lokales Offline-Programm – das ist am verlässlichsten. Was diese Leute bei Dusk wetten: Erst werden dir die Performance-Engpässe alles im Griff halten, und Sicherheitsprobleme kann man danach noch nachbessern. @Dusk $DUSK #dusk
Der Kuchen ist ein bisschen gefallen, aber der BTC-Aufwärtstrend bleibt!
Er fragte mich: „Ihr lauft Dusk und seid wirklich sicher, dass ihr die Verifikationslogik außerhalb von WASM wegwerft?“ Da hab ich damals nicht richtig aufgefangen – mit hartem Mund gesagt: „In den Whitepapern steht doch, dass es auditiert wurde“, aber innerlich war ich eigentlich unsicher. Erst heute Abend, als ich die Testfälle für den host function-Stack von Piecrust auf deren GitHub gefunden habe, habe ich das Ganze ein bisschen besser verstanden.
Kurz gesagt: Die klassische Idee „alles im selben Sandbox-Käfig komplett einsperren“ ist wie im Laden Zigaretten kaufen: Du musst erst durch die Sicherheitskontrolle, den Ausweis zeigen, die Tasche durchsuchen lassen – und erst dann darfst du bezahlen. Sicher ist es sicher, aber die Leute hinter dir werden sich die ganze Zeit aufregen. Dusk setzt auf einen anderen Weg: Hochfrequente Aktionen laufen über einen dedizierten Kanal, nur die Niedrigfrequenz-Aktionen müssen durch die Schranke.
Die von ihnen eingebundenen Drittanbieter-Daten habe ich extra im Original nachgeschaut. Das Paper testet die Performance-Einbußen von WASM gegenüber nativ unter verschiedenen Befehlssätzen; im extremsten Kryptoszenario liegt die Overhead-Zahl bei 255%. Rechne dir aus: Wie viele Transaktionen müssen bei Dusk pro Tag eine BLS-Signaturprüfung durchlaufen, und wie viele eine ZK-Generierung? Wenn jede einzelne davon WASM alles erklären lassen muss, heißt das im Ergebnis: Für jede Strecke von einem Kilometer zahlst du effektiv so viel Öl wie für zweieinhalb. Wer kann das schon tragen?
Darum machen sie diese Sachen auf dem Niveau von Systemaufrufen und rufen direkt die nativen Implementierungen. Was ist der Preis? Das Vertrauens-„Radius“ schrumpft von „dieser WASM-Sandbox-Eisenklotz“ auf „ob in den ein paar C-Zeilen der Host-Funktion sauber gearbeitet wurde“. Diese zwei Risiken sind nicht vergleichbar: Das eine ist physische Isolation, das andere ist Codequalität.
Ich habe auch den Audit-Report für 2024 Q3 durchgesehen (tief irgendwo auf der Website versteckt) – zumindest damals haben die getesteten Randfälle keine Löcher aufgerissen. Aber ehrlich gesagt: Diese Angriffsfläche wird nicht „gemessen“, sondern „ausgenutzt“. Irgendwann füttert jemand bewusst konstruierte Beweisdaten ein, triggert in einer host function einen Integer-Overflow, den niemand auf dem Schirm hatte – die Vorstellung ist zu schön, um sie mir auszumalen.
Aber umgekehrt: Wenn du wirklich „absolute Sicherheit“ suchst, dann mach keinen Public-Chain-Kram. Geh zurück und schreib ein lokales Offline-Programm – das ist am verlässlichsten. Was diese Leute bei Dusk wetten: Erst werden dir die Performance-Engpässe alles im Griff halten, und Sicherheitsprobleme kann man danach noch nachbessern. @Dusk $DUSK #dusk