Letztes Jahr zu dieser Zeit habe ich noch mit Leuten gestritten—„Validierungslogik außerhalb der WASM-Sandbox laufen lassen? Grabt ihr euch da nicht selbst ein Loch.“ Damals hatte ich gerade einen Re-Report zu einer bestimmten Chain gelesen, der wegen Schwachstellen im Smart Contract komplett ausgeplündert wurde. In meinem Kopf war nur noch der Gedanke: „Weniger Code ist sicherer“.
Der dicke Plan: Wo liegt der Callback-Punkt—hat BTC noch Aufwärtspotenzial?
Später, als ich dann wirklich anfing, Dusk-Node(s) selbst laufen zu lassen, merkte ich: So einfach ist das nicht.
Ich habe mir den Testcode ihres Piecrust-Setups angesehen und auch gezielt den viel zitierten Performance-Artikel nachgeschlagen—die messen nämlich die Overheads von WASM gegenüber nativen Implementierungen unter verschiedenen Instruktions-Sets; in Kryptokontexten kann das auf 255% hochschießen. Denk mal drüber nach: Die BLS-Signaturen und ZK-Beweise, mit denen Dusk täglich zu tun hat—welcher Teil davon ist kein Rechnungskostendickschiff? Jede Transaktion führt die Logik im WASM aus. Das ist, als hättest du bei 100 Kilometern Fahrt 25 Tankstellen-Liter Verbrauch—der Tankstellenboss lacht, während dein Wallet zuerst die Grätsche macht.
Darum machen sie die häufigen kryptografischen Rechenoperationen zu „host functions“ und rufen direkt die native Implementierung auf. Ganz offen gesagt ist das die Strategie: Die oft genutzten Wege werden nicht mit Zäunen verbarrikadiert, die seltenen Wege werden gelegentlich streng überprüft.
Risiken gibt es natürlich—der Vertrauensradius schrumpft von „der ganzen WASM-Sandbox“ auf „ob diese paar Zeilen C-Code sauber genug geschrieben sind“. Ersteres ist Sicherheitsgefühl auf dem Niveau physischer Isolation, letzteres hängt im Grunde davon ab, ob die Engineers mit ihrem Handwerk sauber umgehen. Ich hab mir extra in der Ecke der offiziellen Website ihren Auditbericht für Q3 2024 herausgesucht—zumindest damals sind die getesteten Randfälle nicht explodiert. Aber wie gesagt: Solche Bugs werden nie einfach „getestet und gefunden“, sie werden von Menschen mit Daten gefüttert. Irgendwann steckt jemand einen sorgfältig konstruierten Beweis hinein und triggert einen Integer-Overflow, den in keiner host function jemand auf dem Schirm hatte—puh, dieses Bild will ich mir vorerst nicht live vorstellen.
Wenn du aber nach maximaler Fehlerfreiheit strebst, lass uns kein Public-Chain-Zeugs machen—geh zurück und schreib lieber ein Offline-/Single-User-Programm, das ist deutlich entspannter. Die Leute von Dusk rechnen mit einer anderen Rechnung: Performance-Halsabschneider ist das Thema von heute, Sicherheitsprobleme kann man morgen noch nachbessern. Ich bin drei Jahre Node gelaufen und habe bei den Ketten, die gestorben sind, zu mindestens neun von zehn Fällen gesehen: wegen zu hohem Gas, das niemand nutzen wollte; oder weil sie direkt durch einen Angriff gekapert wurden und dann auf null gesetzt wurden—jedenfalls habe ich es nicht aus erster Hand gesehen.
Also ist meine Haltung jetzt nicht mehr so hart. Früher, beim Essen mit Freunden, hab ich noch trotzig gesagt: „Erst mal beobachten, beobachten…“ Und als ich wieder daheim war, habe ich still und leise die Node-Version auf die neueste nachgezogen. Projekte, die der Sandbox ein Loch aufmachen, gibt es nicht viele—Dusk zählt dazu. #dusk $DUSK @Dusk
Der dicke Plan: Wo liegt der Callback-Punkt—hat BTC noch Aufwärtspotenzial?
Später, als ich dann wirklich anfing, Dusk-Node(s) selbst laufen zu lassen, merkte ich: So einfach ist das nicht.
Ich habe mir den Testcode ihres Piecrust-Setups angesehen und auch gezielt den viel zitierten Performance-Artikel nachgeschlagen—die messen nämlich die Overheads von WASM gegenüber nativen Implementierungen unter verschiedenen Instruktions-Sets; in Kryptokontexten kann das auf 255% hochschießen. Denk mal drüber nach: Die BLS-Signaturen und ZK-Beweise, mit denen Dusk täglich zu tun hat—welcher Teil davon ist kein Rechnungskostendickschiff? Jede Transaktion führt die Logik im WASM aus. Das ist, als hättest du bei 100 Kilometern Fahrt 25 Tankstellen-Liter Verbrauch—der Tankstellenboss lacht, während dein Wallet zuerst die Grätsche macht.
Darum machen sie die häufigen kryptografischen Rechenoperationen zu „host functions“ und rufen direkt die native Implementierung auf. Ganz offen gesagt ist das die Strategie: Die oft genutzten Wege werden nicht mit Zäunen verbarrikadiert, die seltenen Wege werden gelegentlich streng überprüft.
Risiken gibt es natürlich—der Vertrauensradius schrumpft von „der ganzen WASM-Sandbox“ auf „ob diese paar Zeilen C-Code sauber genug geschrieben sind“. Ersteres ist Sicherheitsgefühl auf dem Niveau physischer Isolation, letzteres hängt im Grunde davon ab, ob die Engineers mit ihrem Handwerk sauber umgehen. Ich hab mir extra in der Ecke der offiziellen Website ihren Auditbericht für Q3 2024 herausgesucht—zumindest damals sind die getesteten Randfälle nicht explodiert. Aber wie gesagt: Solche Bugs werden nie einfach „getestet und gefunden“, sie werden von Menschen mit Daten gefüttert. Irgendwann steckt jemand einen sorgfältig konstruierten Beweis hinein und triggert einen Integer-Overflow, den in keiner host function jemand auf dem Schirm hatte—puh, dieses Bild will ich mir vorerst nicht live vorstellen.
Wenn du aber nach maximaler Fehlerfreiheit strebst, lass uns kein Public-Chain-Zeugs machen—geh zurück und schreib lieber ein Offline-/Single-User-Programm, das ist deutlich entspannter. Die Leute von Dusk rechnen mit einer anderen Rechnung: Performance-Halsabschneider ist das Thema von heute, Sicherheitsprobleme kann man morgen noch nachbessern. Ich bin drei Jahre Node gelaufen und habe bei den Ketten, die gestorben sind, zu mindestens neun von zehn Fällen gesehen: wegen zu hohem Gas, das niemand nutzen wollte; oder weil sie direkt durch einen Angriff gekapert wurden und dann auf null gesetzt wurden—jedenfalls habe ich es nicht aus erster Hand gesehen.
Also ist meine Haltung jetzt nicht mehr so hart. Früher, beim Essen mit Freunden, hab ich noch trotzig gesagt: „Erst mal beobachten, beobachten…“ Und als ich wieder daheim war, habe ich still und leise die Node-Version auf die neueste nachgezogen. Projekte, die der Sandbox ein Loch aufmachen, gibt es nicht viele—Dusk zählt dazu. #dusk $DUSK @Dusk