#dusk $DUSK Ich habe mich entlang des offiziellen Dusk-Repositorys einer bestimmten Issue nach unten gearbeitet und dabei ein ziemlich untypisches Risiko entdeckt: Der Smart Contract kann ganz normal ausgeführt werden, aber Wallet und Exchange könnten ihn plötzlich nicht mehr lesen.
Das Problem liegt im Data Driver. Dabei handelt es sich um einen WASM-„Übersetzer“, der die vom Contract ausgespuckten Binärdaten in Beträge, Salden, Events und klickbare Aktionen übersetzt. Ohne ihn existiert zwar das On-Chain-Konto weiterhin, aber die Frontend-Seite bekommt stattdessen nur eine Aneinanderreihung von Maschinenbytes.
Die vom Integrationspartner gemeldete Anbindung ist etwas umständlich: Zuerst verbindet man sich mit W3sper, um Sitzungsinformationen zu erhalten, springt dann aus dem SDK heraus und fordert selbst eine Driver-Download-Schnittstelle beim Node an. Außerdem muss man selbst prüfen, ob die WASM-Datei passt. Selbst wenn bei regulären Aufrufen bereits ein Wechsel zwischen mehreren Nodes erfolgt, muss diese Download-Route dennoch separat um einen Fallback-Node und einen Cache ergänzt werden.
Als ich das gesehen habe, war mir erst mal mulmig. Wenn die Kette nicht wirklich „steht“, können die Node-Betreiber zwar sehen, dass die Höhe (Blockhöhe) nicht steigt, aber Exchanges und Wallets melden dann trotzdem Timeouts. Wenn der Driver verloren geht, abläuft oder die Version nicht zur passenden Vertragseinbindung passt, kann das herkömmliche Monitoring zunächst alles normal aussehen lassen—bis der Saldo auffällig wird, der Auszahlungsstatus nicht gelesen werden kann, die Clearing-Ergebnisse sich nicht mehr abrechnen lassen und das Ganze die Gelder letztlich zwingt, gestoppt zu werden.
Daher mein Vorschlag: Beim Onboarding von Dusk-Contracts darf man nicht nur testen, ob die Transaktionen erfolgreich sind. Man sollte auch absichtlich beim Download des Drivers den Haupt-RPC kappen und schauen, ob dann auf den Fallback-Node umgeschaltet werden kann. Außerdem sollte man prüfen, ob der Driver an die Contract-Version gebunden ist, ob nach einer Unterbrechung eine Wiederherstellung möglich ist und ob alter Cache den neuen Contract weiterhin falsch interpretiert.
Für $DUSK werde ich vorerst nicht allein wegen der steigenden Anzahl an Contracts die Bewertung nach oben ziehen. Die Driver-Verfügbarkeit, die Kopplung von Version und Contract-Hash, die Erfolgsquote beim Wiederherstellen über Fallback-Nodes und wie lange es nach einem Ausfall dauert, bis die Daten wieder korrekt gelesen werden können, sind näher an den tatsächlichen Einnahmen.
Die Maschine kann die Regeln ausführen—das zeigt nur, dass die technische Übergabe erledigt ist. Der Markt zahlt dauerhaft Gas, weil darauf vertraut wird, dass alle Einstiegsstellen dieselbe Byte-Sequenz nehmen und daraus dieselbe Geldtransaktion ableiten.
@Dusk_Foundation
$BTC
Das Problem liegt im Data Driver. Dabei handelt es sich um einen WASM-„Übersetzer“, der die vom Contract ausgespuckten Binärdaten in Beträge, Salden, Events und klickbare Aktionen übersetzt. Ohne ihn existiert zwar das On-Chain-Konto weiterhin, aber die Frontend-Seite bekommt stattdessen nur eine Aneinanderreihung von Maschinenbytes.
Die vom Integrationspartner gemeldete Anbindung ist etwas umständlich: Zuerst verbindet man sich mit W3sper, um Sitzungsinformationen zu erhalten, springt dann aus dem SDK heraus und fordert selbst eine Driver-Download-Schnittstelle beim Node an. Außerdem muss man selbst prüfen, ob die WASM-Datei passt. Selbst wenn bei regulären Aufrufen bereits ein Wechsel zwischen mehreren Nodes erfolgt, muss diese Download-Route dennoch separat um einen Fallback-Node und einen Cache ergänzt werden.
Als ich das gesehen habe, war mir erst mal mulmig. Wenn die Kette nicht wirklich „steht“, können die Node-Betreiber zwar sehen, dass die Höhe (Blockhöhe) nicht steigt, aber Exchanges und Wallets melden dann trotzdem Timeouts. Wenn der Driver verloren geht, abläuft oder die Version nicht zur passenden Vertragseinbindung passt, kann das herkömmliche Monitoring zunächst alles normal aussehen lassen—bis der Saldo auffällig wird, der Auszahlungsstatus nicht gelesen werden kann, die Clearing-Ergebnisse sich nicht mehr abrechnen lassen und das Ganze die Gelder letztlich zwingt, gestoppt zu werden.
Daher mein Vorschlag: Beim Onboarding von Dusk-Contracts darf man nicht nur testen, ob die Transaktionen erfolgreich sind. Man sollte auch absichtlich beim Download des Drivers den Haupt-RPC kappen und schauen, ob dann auf den Fallback-Node umgeschaltet werden kann. Außerdem sollte man prüfen, ob der Driver an die Contract-Version gebunden ist, ob nach einer Unterbrechung eine Wiederherstellung möglich ist und ob alter Cache den neuen Contract weiterhin falsch interpretiert.
Für $DUSK werde ich vorerst nicht allein wegen der steigenden Anzahl an Contracts die Bewertung nach oben ziehen. Die Driver-Verfügbarkeit, die Kopplung von Version und Contract-Hash, die Erfolgsquote beim Wiederherstellen über Fallback-Nodes und wie lange es nach einem Ausfall dauert, bis die Daten wieder korrekt gelesen werden können, sind näher an den tatsächlichen Einnahmen.
Die Maschine kann die Regeln ausführen—das zeigt nur, dass die technische Übergabe erledigt ist. Der Markt zahlt dauerhaft Gas, weil darauf vertraut wird, dass alle Einstiegsstellen dieselbe Byte-Sequenz nehmen und daraus dieselbe Geldtransaktion ableiten.
@Dusk_Foundation
$BTC