Ich habe diesen Film oft genug gesehen, um misstrauisch zu werden, sobald eine Blockchain behauptet, sie habe sowohl Sicherheit als auch Performance gelöst, ohne etwas aufzugeben.
Was mich bei Dusk abgeholt hat, war Piecrust. Ich bin mit der üblichen Logik reingegangen: Rechenarbeit in der WASM-Sandbox behalten, weil Isolation Teil der Sicherheitsgeschichte ist. Dann habe ich festgestellt, dass Dusk einen anderen Weg geht. Die VM läuft zwar weiterhin WASM-Verträge, aber ein Teil der schweren kryptografischen Arbeit wird über Host-seitige Funktionen zugänglich gemacht, statt alles durch die Sandbox zu pressen. Dusk selbst beschreibt Piecrust als eine WASM-VM mit nativer Unterstützung für ZK-Operationen, und die aktuelle Dokumentation rahmt DuskVM immer noch vor allem als Ausrichtung auf Privatsphäre und Zero-Knowledge-Ausführung.
Ehrlich gesagt, verstehe ich warum. Wenn Hashing, Signaturprüfungen und die Verifikation von Beweisen zu den Dingen gehören, die du weiterhin ständig machst, klingt es verschwenderisch, jedes Mal den Virtualisierungs-Overhead zu bezahlen. Natives Ausführen sollte schneller sein. Aber Geschwindigkeit ist in der Kryptografie nie kostenlos. Du zahlst normalerweise woanders.
Genau daran hänge ich noch fest. Eine Host-Funktion wird Teil der vertrauenswürdigen Grenze. Damit hört die Frage auf, nur zu lauten „Ist die VM sicher?“ und wird zu „Wie sicher ist alles, was die VM aufrufen darf?“
Ich vertraue dem noch nicht vollständig, aber ich glaube auch nicht, dass das Design rücksichts- oder leichtsinnig ist. Nachdem ich genug Chains gesehen habe, die nutzbare Performance opfern, nur um eine saubere Theorie der Dezentralisierung zu bewahren, bin ich inzwischen eher an Systemen interessiert, die anerkennen, dass es Trade-offs gibt.
Vielleicht ist das der Punkt, der sich hier anders anfühlt. Nicht, dass Dusk eine perfekte Antwort gefunden hat, sondern dass es bereit zu sein scheint, die unbequeme Ingenieursentscheidung öffentlich zu treffen.
@Dusk $DUSK #dusk
Was mich bei Dusk abgeholt hat, war Piecrust. Ich bin mit der üblichen Logik reingegangen: Rechenarbeit in der WASM-Sandbox behalten, weil Isolation Teil der Sicherheitsgeschichte ist. Dann habe ich festgestellt, dass Dusk einen anderen Weg geht. Die VM läuft zwar weiterhin WASM-Verträge, aber ein Teil der schweren kryptografischen Arbeit wird über Host-seitige Funktionen zugänglich gemacht, statt alles durch die Sandbox zu pressen. Dusk selbst beschreibt Piecrust als eine WASM-VM mit nativer Unterstützung für ZK-Operationen, und die aktuelle Dokumentation rahmt DuskVM immer noch vor allem als Ausrichtung auf Privatsphäre und Zero-Knowledge-Ausführung.
Ehrlich gesagt, verstehe ich warum. Wenn Hashing, Signaturprüfungen und die Verifikation von Beweisen zu den Dingen gehören, die du weiterhin ständig machst, klingt es verschwenderisch, jedes Mal den Virtualisierungs-Overhead zu bezahlen. Natives Ausführen sollte schneller sein. Aber Geschwindigkeit ist in der Kryptografie nie kostenlos. Du zahlst normalerweise woanders.
Genau daran hänge ich noch fest. Eine Host-Funktion wird Teil der vertrauenswürdigen Grenze. Damit hört die Frage auf, nur zu lauten „Ist die VM sicher?“ und wird zu „Wie sicher ist alles, was die VM aufrufen darf?“
Ich vertraue dem noch nicht vollständig, aber ich glaube auch nicht, dass das Design rücksichts- oder leichtsinnig ist. Nachdem ich genug Chains gesehen habe, die nutzbare Performance opfern, nur um eine saubere Theorie der Dezentralisierung zu bewahren, bin ich inzwischen eher an Systemen interessiert, die anerkennen, dass es Trade-offs gibt.
Vielleicht ist das der Punkt, der sich hier anders anfühlt. Nicht, dass Dusk eine perfekte Antwort gefunden hat, sondern dass es bereit zu sein scheint, die unbequeme Ingenieursentscheidung öffentlich zu treffen.
@Dusk $DUSK #dusk
