Ich bin letzte Nacht noch einmal durch die Dokumentation von Dusk gegangen, insbesondere Abschnitt 6 zur Implementierung, und habe mich dabei eher darauf konzentriert, wie die einzelnen Teile zusammenpassen, als auf große Schlagzeilen.
Zuerst ist mir der PVM aufgefallen, eine virtuelle Maschine, die um WebAssembly (WASM) herum gebaut ist. Mein Verständnis ist, dass das Ziel eine kompakte, modulare und leichte Umgebung zum Ausführen von Smart Contracts ist, wobei WASM die Portierbarkeit unterstützt und die Ausführung dennoch kontrolliert bleibt. Aber ich frage mich immer noch: Wie viel der Sicherheit kommt aus dem Design der VM, und wie viel hängt von den Contracts selbst ab?
Anschließend ging die Dokumentation in die Genesis-Contracts über. Der Transfer-Contract behandelt DUSK-Überweisungen, prüft die Gültigkeit von Transaktionen und berücksichtigt die Ausführungskosten. Der Stake-Contract verwaltet gesperrtes DUSK fürs Staking, verfolgt den relevanten Zustand und unterstützt Withdrawals nach Ablauf der Sperrfrist. Das hat mich stärker darüber nachdenken lassen, wie viel grundlegendes Netzwerkverhalten direkt in Contracts kodiert ist.
In Abschnitt 6.3 werden außerdem zukünftige Contracts erwähnt, darunter Zedger für regulierte Wertpapiere und RWAs sowie ein Clock-Contract für zeitbasierte Validierung.
Meine Fragen sind also: Wie werden diese Contracts gesteuert und aktualisiert, und was passiert, wenn einer zu einem Sicherheits-Engpass wird? Wie dezentral ist diese Kontrolle in der Praxis?
@Dusk $DUSK
#Dusk
Zuerst ist mir der PVM aufgefallen, eine virtuelle Maschine, die um WebAssembly (WASM) herum gebaut ist. Mein Verständnis ist, dass das Ziel eine kompakte, modulare und leichte Umgebung zum Ausführen von Smart Contracts ist, wobei WASM die Portierbarkeit unterstützt und die Ausführung dennoch kontrolliert bleibt. Aber ich frage mich immer noch: Wie viel der Sicherheit kommt aus dem Design der VM, und wie viel hängt von den Contracts selbst ab?
Anschließend ging die Dokumentation in die Genesis-Contracts über. Der Transfer-Contract behandelt DUSK-Überweisungen, prüft die Gültigkeit von Transaktionen und berücksichtigt die Ausführungskosten. Der Stake-Contract verwaltet gesperrtes DUSK fürs Staking, verfolgt den relevanten Zustand und unterstützt Withdrawals nach Ablauf der Sperrfrist. Das hat mich stärker darüber nachdenken lassen, wie viel grundlegendes Netzwerkverhalten direkt in Contracts kodiert ist.
In Abschnitt 6.3 werden außerdem zukünftige Contracts erwähnt, darunter Zedger für regulierte Wertpapiere und RWAs sowie ein Clock-Contract für zeitbasierte Validierung.
Meine Fragen sind also: Wie werden diese Contracts gesteuert und aktualisiert, und was passiert, wenn einer zu einem Sicherheits-Engpass wird? Wie dezentral ist diese Kontrolle in der Praxis?
@Dusk $DUSK
#Dusk
