#dusk $DUSK @Dusk Ich dachte ursprünglich, dass die Sicherheit schon dann ausreicht, wenn Data Driver mit der Signatur des Vertragsinhabers versehen ist. Nachdem ich den Dusk-Quellcode durchgesehen habe, bleibt dieses beruhigende Gefühl nur zur Hälfte: Die Signatur beweist zwar, wer die Datei hochgeladen hat, aber nicht, für welche Version des Vertrags sie passend ist.
In Dusk ist Data Driver eine eigenständige WASM-Datei. Wallets, Börsen und Bots nutzen sie, um die maschinenlesbaren Bytes, die der Vertrag ausgibt, in Beträge, Berechtigungen und Ereignisse zu übersetzen. Gleichzeitig nutzen sie sie auch, um Benutzeraktionen in Daten zu kodieren, die der Vertrag ausführen kann. Beim Upload signiert der Vertragsinhaber den Hash der Driver-Datei, und die Knoten speichern sie anschließend anhand der Vertrags-ID.
Das Problem liegt vor allem auf der Client-Seite. W3sper registriert und cached Driver derzeit ebenfalls anhand der Vertrags-ID. Das offene Issue im offiziellen Repository weist darauf hin, dass hier noch eine starke Bindung zwischen Driver und Vertragsversion bzw. Hash fehlt.
So entsteht ein sehr Dusk-typisches Mismatch: Ein altes Terminal verwendet weiterhin den im Cache befindlichen alten Driver, während ein neues Terminal bereits den neuen Driver heruntergeladen hat. Beide Dateien können aus einem legitimen Pfad stammen, beide Seiten melden keinen Fehler, und dennoch können bei derselben Blockhöhe Beträge, Ereignisse und sogar Transaktionsparameter eine andere Bedeutung haben.
Am meisten fürchte ich genau diese Art von Störung in Transaktionen. Ein fehlgeschlagener Handel löst Alarm aus; aber wenn Daten leise falsch gelesen werden, können Wallet-Kontostand, Bot-Positionen und Aufzeichnungen der Datenplattform jeweils weiter eigene Rechnungen führen, bis die Gelder nicht mehr zusammenpassen und es auffällt.
Als Nächstes werde ich Metriken zur Bewertung von $DUSK ergänzen. Die Anzahl der Verträge lässt sich sehr leicht anhäufen, aber die Übereinstimmungsquote der Driver-Hashes ist deutlich wertvoller. Welche Version des Drivers von den gängigen Wallets, Börsen und Indexern verwendet wird, ab welcher Höhe sie wirksam wird und wann ältere Versionen ungültig werden, sollte nachvollziehbar sein.
Dusk trennt „Ausführen eines Vertrags“ und „Interpretieren eines Vertrags“ in zwei Ebenen. Das bringt zwar Flexibilität, bedeutet aber auch eine zusätzliche, eigene Verantwortung: Die Originaldatei muss ebenso beweisen, dass sie nicht abgelaufen ist. Nur so können alle beim Handeln noch entspannter sein.
$BTC
In Dusk ist Data Driver eine eigenständige WASM-Datei. Wallets, Börsen und Bots nutzen sie, um die maschinenlesbaren Bytes, die der Vertrag ausgibt, in Beträge, Berechtigungen und Ereignisse zu übersetzen. Gleichzeitig nutzen sie sie auch, um Benutzeraktionen in Daten zu kodieren, die der Vertrag ausführen kann. Beim Upload signiert der Vertragsinhaber den Hash der Driver-Datei, und die Knoten speichern sie anschließend anhand der Vertrags-ID.
Das Problem liegt vor allem auf der Client-Seite. W3sper registriert und cached Driver derzeit ebenfalls anhand der Vertrags-ID. Das offene Issue im offiziellen Repository weist darauf hin, dass hier noch eine starke Bindung zwischen Driver und Vertragsversion bzw. Hash fehlt.
So entsteht ein sehr Dusk-typisches Mismatch: Ein altes Terminal verwendet weiterhin den im Cache befindlichen alten Driver, während ein neues Terminal bereits den neuen Driver heruntergeladen hat. Beide Dateien können aus einem legitimen Pfad stammen, beide Seiten melden keinen Fehler, und dennoch können bei derselben Blockhöhe Beträge, Ereignisse und sogar Transaktionsparameter eine andere Bedeutung haben.
Am meisten fürchte ich genau diese Art von Störung in Transaktionen. Ein fehlgeschlagener Handel löst Alarm aus; aber wenn Daten leise falsch gelesen werden, können Wallet-Kontostand, Bot-Positionen und Aufzeichnungen der Datenplattform jeweils weiter eigene Rechnungen führen, bis die Gelder nicht mehr zusammenpassen und es auffällt.
Als Nächstes werde ich Metriken zur Bewertung von $DUSK ergänzen. Die Anzahl der Verträge lässt sich sehr leicht anhäufen, aber die Übereinstimmungsquote der Driver-Hashes ist deutlich wertvoller. Welche Version des Drivers von den gängigen Wallets, Börsen und Indexern verwendet wird, ab welcher Höhe sie wirksam wird und wann ältere Versionen ungültig werden, sollte nachvollziehbar sein.
Dusk trennt „Ausführen eines Vertrags“ und „Interpretieren eines Vertrags“ in zwei Ebenen. Das bringt zwar Flexibilität, bedeutet aber auch eine zusätzliche, eigene Verantwortung: Die Originaldatei muss ebenso beweisen, dass sie nicht abgelaufen ist. Nur so können alle beim Handeln noch entspannter sein.
$BTC