Ich las die W3sper-Dokumentation von @Dusk Dusk und hielt DuskVM-Queries zunächst für eine gewöhnliche JSON-API. Beim Forge-Kompilieren von Contracts werden gleichzeitig data-driver-WASM erzeugt; die Anwendung registriert sich bei W3sper anhand der Contract-ID. Der Driver kodiert die Eingaben in ABI-Bytes, und dekodiert dann die vom Knoten zurückgegebenen Werte.

Ich behandelte es wie eine Übersetzer-Schalterstelle am Flughafen. Wenn Reisende JSON sagen, erkennt der Vorfeldbereich nur ein festes Ladeformat; die Schalterstelle verpackt nach Schema, und auf der Rückreise trennt sie wieder Ausgaben und Events. Wenn HTTP Raw-Bytes sendet, werden sie direkt an den Contract übergeben; wenn JSON gesendet wird, erfolgt die automatische Konvertierung nur, wenn der Driver verfügbar ist. Mit get_version kann man die Version abfragen.

Bitte versteckt das erst nach dem Upgrade. Alte Driver können möglicherweise „Erfolg“ zurückgeben, aber die Daten anhand einer veralteten ABI interpretieren. Die Metadaten driver_available und driver_signature helfen mir nur dabei, die Identität des Drivers zu bestätigen. Ich fixiere den Dateihash und vergleiche im Testnet mit derselben Eingabe die ursprünglichen Bytes und das dekodierte Ergebnis. Eine nur-lesbare Seite belegt lediglich, dass die Übersetzungskette durchläuft; der Asset-Status muss dennoch unabhängig verifiziert werden.

#dusk $DUSK