Ein DuskVM-Vertrag kann einen Node-Failover überleben, während meine App plötzlich vergisst, wie sie mit ihm sprechen soll.
Der Grund liegt außerhalb der Kette. Forge erstellt zwei WASM-Artefakte aus derselben Quelle: den Vertrag, der in DuskVM läuft, und einen Daten-Driver, der lesbares JSON in rkyv-Codierung und -Dekodierung umwandelt. Dieser Driver wird nicht als Teil des On-Chain-Vertrags bereitgestellt.
Wenn ich möchte, dass Rusk’s JSON-Vertrags-Routen diese Übersetzung übernehmen, registriert der Vertragseigentümer den Driver bei dieser Node.
So kann ich einmal bereitstellen, gegen Node A testen, saubere lesbare Aufrufe sehen und dann auf Node B failovern und in einen seltsamen Zustand geraten. Der Vertrag ist da. Die Kette ist gesund. Aber driver_available kann false sein, sodass der Anwendung die Dekodierungsoberfläche verloren geht, auf die sie sich beim Aufbau verlassen hat.
Das ist die Produktions-Falle für mich. Der Konsens ist nicht fehlgeschlagen. Der Vertrag ist nicht fehlgeschlagen. Mein Failover hat eine Off-Chain-Abhängigkeit verändert, die ich so behandelt hatte, als würde sie mit dem Vertrag mitreisen.
Ich würde die Verfügbarkeit des Drivers als Bestandteil der Node-Bereitschaft machen und sie an jedem Rusk-Endpunkt verifizieren, bevor der Traffic dort ankommt.
In DuskVM kann der Vertrag einen Failover überleben, während sein Übersetzer nicht überlebt.
#dusk $DUSK @Dusk
Der Grund liegt außerhalb der Kette. Forge erstellt zwei WASM-Artefakte aus derselben Quelle: den Vertrag, der in DuskVM läuft, und einen Daten-Driver, der lesbares JSON in rkyv-Codierung und -Dekodierung umwandelt. Dieser Driver wird nicht als Teil des On-Chain-Vertrags bereitgestellt.
Wenn ich möchte, dass Rusk’s JSON-Vertrags-Routen diese Übersetzung übernehmen, registriert der Vertragseigentümer den Driver bei dieser Node.
So kann ich einmal bereitstellen, gegen Node A testen, saubere lesbare Aufrufe sehen und dann auf Node B failovern und in einen seltsamen Zustand geraten. Der Vertrag ist da. Die Kette ist gesund. Aber driver_available kann false sein, sodass der Anwendung die Dekodierungsoberfläche verloren geht, auf die sie sich beim Aufbau verlassen hat.
Das ist die Produktions-Falle für mich. Der Konsens ist nicht fehlgeschlagen. Der Vertrag ist nicht fehlgeschlagen. Mein Failover hat eine Off-Chain-Abhängigkeit verändert, die ich so behandelt hatte, als würde sie mit dem Vertrag mitreisen.
Ich würde die Verfügbarkeit des Drivers als Bestandteil der Node-Bereitschaft machen und sie an jedem Rusk-Endpunkt verifizieren, bevor der Traffic dort ankommt.
In DuskVM kann der Vertrag einen Failover überleben, während sein Übersetzer nicht überlebt.
#dusk $DUSK @Dusk