Dusk: Ein abendlicher Abendspaziergang – spät am Abend zwei Vertragsschaltungen, die auf den ersten Blick funktional identisch wirkten, setzten sich mit deutlich unterschiedlichen Gas-Fußabdrücken durch. Meine erste Annahme war, dass eine davon einfach komplexere Logik enthielt. Das stellte sich als falsch heraus.
Beim weiteren Nachforschen fand ich heraus, dass der Unterschied darauf zurückging, wie jeder Vertrag seinen kryptografischen Verifizierungsschritt handhabte. Der eine Weg löste eine Host-Funktion aus – nativen Code, den die Laufzeit direkt außerhalb des WASM-Sandkastens ausführt – während der andere eine Verifizierungsroutine ausführte, die selbst in WASM kompiliert war. Dusk behält Host-Funktionen für bestimmte Operationen wie Hashing und Proof-Verifikation vor, und die Gas-Lücke war im Grunde eine Sichtbarkeits-Lücke, die genau diese Trennung deutlich machte.
Das brachte etwas, das ich bisher als eine Kategorie behandelt hatte, neu in den Fokus: „On-Chain-Berechnung“. Ich hatte sandboxierte Ausführung und native Ausführung zu einer Einheit zusammengefasst, als ob Kosten und Verhalten für beide ähnlich skalierten. Das tun sie nicht. Native Calls umgehen den Overhead der WASM-Interpretation; das bedeutet, dass Designentscheidungen auf der einen Seite still und leise bestimmen, welchen Ausführungspfad eine Transaktion später einschlägt.
Was mir unklar ist, ist, wie Dusk entscheidet, welche zukünftigen kryptografischen Primitiven zu Host-Funktionen „aufsteigen“ und welche stattdessen innerhalb von WASM bleiben. Gibt es eine festgelegte Performance-Schwelle, oder wird es fallweise bewertet, wenn neue Verifikationsschemata hinzukommen? Diese Unklarheit wird umso wichtiger, je länger die Liste der Primitiven wächst.
In der Zukunft beobachte ich, wie konsistent sich die Gaskosten für logisch ähnliche Verträge clustern, und ob Entwickler-Tools diese Ausführungstrennung bereits vor dem Deployment sichtbar machen – statt erst danach. Wiederkehrende Muster würden mir zeigen, ob das eine stabile Design-Grenze ist oder etwas, das sich Vertragsautoren auf die harte Tour erst aneignen müssen.
Ich weiß immer noch nicht, ob diese Trennung absichtlich eng bleiben soll oder sich ausweiten wird, während das Protokoll weiter reift. Und ich bin mir nicht sicher, welches Ergebnis tatsächlich für Builder im Netzwerk gesünder wäre.
@Dusk_Foundation #Dusk
$ACE
$DUSK
$BOME
Beim weiteren Nachforschen fand ich heraus, dass der Unterschied darauf zurückging, wie jeder Vertrag seinen kryptografischen Verifizierungsschritt handhabte. Der eine Weg löste eine Host-Funktion aus – nativen Code, den die Laufzeit direkt außerhalb des WASM-Sandkastens ausführt – während der andere eine Verifizierungsroutine ausführte, die selbst in WASM kompiliert war. Dusk behält Host-Funktionen für bestimmte Operationen wie Hashing und Proof-Verifikation vor, und die Gas-Lücke war im Grunde eine Sichtbarkeits-Lücke, die genau diese Trennung deutlich machte.
Das brachte etwas, das ich bisher als eine Kategorie behandelt hatte, neu in den Fokus: „On-Chain-Berechnung“. Ich hatte sandboxierte Ausführung und native Ausführung zu einer Einheit zusammengefasst, als ob Kosten und Verhalten für beide ähnlich skalierten. Das tun sie nicht. Native Calls umgehen den Overhead der WASM-Interpretation; das bedeutet, dass Designentscheidungen auf der einen Seite still und leise bestimmen, welchen Ausführungspfad eine Transaktion später einschlägt.
Was mir unklar ist, ist, wie Dusk entscheidet, welche zukünftigen kryptografischen Primitiven zu Host-Funktionen „aufsteigen“ und welche stattdessen innerhalb von WASM bleiben. Gibt es eine festgelegte Performance-Schwelle, oder wird es fallweise bewertet, wenn neue Verifikationsschemata hinzukommen? Diese Unklarheit wird umso wichtiger, je länger die Liste der Primitiven wächst.
In der Zukunft beobachte ich, wie konsistent sich die Gaskosten für logisch ähnliche Verträge clustern, und ob Entwickler-Tools diese Ausführungstrennung bereits vor dem Deployment sichtbar machen – statt erst danach. Wiederkehrende Muster würden mir zeigen, ob das eine stabile Design-Grenze ist oder etwas, das sich Vertragsautoren auf die harte Tour erst aneignen müssen.
Ich weiß immer noch nicht, ob diese Trennung absichtlich eng bleiben soll oder sich ausweiten wird, während das Protokoll weiter reift. Und ich bin mir nicht sicher, welches Ergebnis tatsächlich für Builder im Netzwerk gesünder wäre.
@Dusk_Foundation #Dusk
$ACE
$DUSK
$BOME