Ich dachte ursprünglich, ob ein Vertrag in der DuskVM laufen kann, hängt vor allem davon ab, ob der Rust-Code fehlerfrei kompiliert. Doch erst nachdem ich die DuskVM-Dokumentation von @Dusk gelesen hatte, wurde mir klar, dass die Stellen, an denen man am ehesten stecken bleibt, näher an der Aufruf-Schnittstelle liegen: Der Vertrag muss einen 64KB großen argbuf-Bereich freilegen, und die Einstiegsfunktion muss das Eingabeformat nach fn foo(u32) -> u32 erhalten, also die Länge entgegennehmen, die Daten verarbeiten und anschließend wieder die Ausgabelänge zurückgeben. Korrekte Code-Logik bedeutet nicht, dass externe Aufrufe die Daten auch korrekt in das Format einspeisen. Dieses Design hat meine Sicht auf den Entwicklungsaufwand verändert: DuskVM schreibt Entwicklern nicht die Business-Logik vor, aber sie gibt ihnen die Speicher-Grenzen für Ein- und Ausgabe in die Verantwortung des Vertrags. Der Aufrufer übergibt nicht einfach eine Reihe „beliebig lesbarer“ Parameter, sondern Daten, die bereits in einen Puffer gelegt wurden und deren Lesegrenze von der Länge bestimmt wird. Wenn eine einzige Stelle bei Serialisierung, Längenprüfung oder beim Zurückschreiben der Ausgaben nicht passt, zeigt sich das Problem möglicherweise nicht als offensichtlicher Business-Fehler: Das Frontend erhält dann nur einen einzigen fehlgeschlagenen Vertragsaufruf. Der Druck-/Stresstest ist dabei sehr konkret: In lokalen Tests funktioniert die Asset-App zunächst tadellos, wenn dort nur eine einfache Zahl übergeben wird. Nach dem Go-Live, wenn man stattdessen längere Anmeldeinformationen, Bestelldaten oder Berechtigungsdaten verwendet, kann der Vertrag zwar noch aufgerufen werden, liest aber nicht vollständig oder liefert nur abgeschnittene Ergebnisse zurück. Für die Nutzer wirkt es so, als ob sich der Status nicht aktualisiert. Die Entwickler müssen dann nachträglich ABI, Puffer und Daten-Driver abklären; die Kosten trägt nicht eine abstrakte virtuelle Maschine, sondern die wartenden Nutzer und das Team, das die Integration pflegt. Wenn ich mir also $DUSK s DuskVM anschaue, frage ich nicht nur, ob sie Rust oder WASM ausführen kann. Ich sehe zuerst, ob die Vertragstests die Parameterlängen, die Ausgabelängen und die Eingabegrenzen abdecken. @Dusk formuliert die Aufrufkonvention sehr eindeutig: Hinter der Performance und der Steuerbarkeit steckt auch ein Stück Speicherverantwortung. Für Dusk-Entwickler ist wirklich zu verifizieren, ob nach dem Eintritt komplexer Business-Daten in den Vertrag die Grenzen weiterhin vorhersagbar bleiben. #dusk