Ich bin heute Abend wieder in die technischen Dokumente von @Dusk eingestiegen, und das VM-Design ist der Teil, an den ich immer wieder denke.
Meine erste Annahme war ganz einfach: Wenn die Berechnung on-chain stattfindet, dann sollte alles Wichtige im VM bleiben. Mehr Isolation sollte mehr Sicherheit bedeuten.
Dusk geht einen anderen Weg.
Mit Piecrust kann die aufwendige kryptografische Arbeit – etwa Hashing, Signaturprüfungen und ZK-Verifikation – über native Host-Funktionen erledigt werden, statt sie vollständig in der WASM-Umgebung auszuführen.
Das Performance-Argument ist nachvollziehbar. Wenn dieselben schweren kryptografischen Operationen ständig stattfinden, kann es teuer werden, bei jedem einzelnen Durchlauf die VM-Overhead-Kosten zu zahlen. Native Ausführung kann einen Großteil dieser Reibung entfernen.
Aber da entsteht auch eine Frage, die ich nicht ignorieren kann:
Wie viel Vertrauen legen wir in diese Host-Funktionen?
Wenn man kritische Operationen aus dem Sandbox-Bereich herausverlagert, verbessert das zwar die Effizienz, aber es macht auch die native Ebene zu einem Teil der Sicherheitsgrenze. Das bedeutet, dass Qualität der Implementierung, Isolation und Auditing plötzlich noch viel wichtiger werden.
Ich sage nicht, dass Dusk die falsche Entscheidung getroffen hat. Ich finde das sogar eine interessante Abwägung.
Bei einer auf Finanzen fokussierten Kette: Würdest du lieber die Sandbox-Isolation maximal ausreizen oder eine sorgfältig kontrollierte Native-Layer akzeptieren – dafür mit deutlich besserer Performance?
Ich neige zur Effizienz – aber nur, wenn die Sicherheitsannahmen stark genug sind.
#dusk $DUSK @Dusk
Meine erste Annahme war ganz einfach: Wenn die Berechnung on-chain stattfindet, dann sollte alles Wichtige im VM bleiben. Mehr Isolation sollte mehr Sicherheit bedeuten.
Dusk geht einen anderen Weg.
Mit Piecrust kann die aufwendige kryptografische Arbeit – etwa Hashing, Signaturprüfungen und ZK-Verifikation – über native Host-Funktionen erledigt werden, statt sie vollständig in der WASM-Umgebung auszuführen.
Das Performance-Argument ist nachvollziehbar. Wenn dieselben schweren kryptografischen Operationen ständig stattfinden, kann es teuer werden, bei jedem einzelnen Durchlauf die VM-Overhead-Kosten zu zahlen. Native Ausführung kann einen Großteil dieser Reibung entfernen.
Aber da entsteht auch eine Frage, die ich nicht ignorieren kann:
Wie viel Vertrauen legen wir in diese Host-Funktionen?
Wenn man kritische Operationen aus dem Sandbox-Bereich herausverlagert, verbessert das zwar die Effizienz, aber es macht auch die native Ebene zu einem Teil der Sicherheitsgrenze. Das bedeutet, dass Qualität der Implementierung, Isolation und Auditing plötzlich noch viel wichtiger werden.
Ich sage nicht, dass Dusk die falsche Entscheidung getroffen hat. Ich finde das sogar eine interessante Abwägung.
Bei einer auf Finanzen fokussierten Kette: Würdest du lieber die Sandbox-Isolation maximal ausreizen oder eine sorgfältig kontrollierte Native-Layer akzeptieren – dafür mit deutlich besserer Performance?
Ich neige zur Effizienz – aber nur, wenn die Sicherheitsannahmen stark genug sind.
#dusk $DUSK @Dusk
