#dusk $DUSK
Es gibt zwei Möglichkeiten, auf Dusk aufzubauen, und ich habe immer wieder gesehen, dass sie so erwähnt werden, als wären sie austauschbar. Wenn man jedoch die tatsächlichen Entwicklerdokumente liest, sind sie es nicht. Sie unterscheiden sich so stark, dass eine falsche Entscheidung wahrscheinlich eine Neufassung erforderlich macht.
DuskEVM ist eine EVM-kompatible Schicht, die auf DuskDS aufsetzt und OP Stack verwendet. Du schreibst Solidity oder Vyper, nutzt vertraute EVM-Tools, und deployst so, wie du es auch bei Ethereum oder Arbitrum tun würdest. Dein Smart Contract erbt DuskDS als Settlement- und Data-Availability-Schicht. Die Kosten bestehen aus zwei Gebührenebenen: der normalen EVM-Gasgebühr plus einer Data-Availability-Gebühr für das Veröffentlichen von Batch-Daten auf der darunterliegenden Kette.
DuskVM ist nativer Dusk. Du schreibst in Rust, kompilierst zu WASM und deployest direkt auf dem L1. Du erhältst Zugriff auf die nativen Transaktionsmodelle (Moonlight und Phoenix), auf Privatsphäre auf Protokollebene sowie ZK-Fähigkeiten und auf die vollständige, maßgeschneiderte Market-Logik, die ganz nahe an der Kette lebt. Keine zusätzliche Gebührenebene, keine OP-Stack-Abstraktion dazwischen.
Die Dokumentation ist direkt, wann man was wählen sollte. DuskEVM, wenn deine App von Solidity, EVM-Wallets und bestehendem Ethereum-Tooling profitiert. DuskVM, wenn deine App native Privatsphäre, ZK, Assets auf Protokollebene oder eine direkte Kontrolle über das Ausführungsmodell benötigt.
Was an dieser Einordnung ehrlich ist: Es wird nicht so getan, als wäre das eine besser. Die Entscheidung hängt komplett davon ab, was die Anwendung braucht. Eine Finanzanwendung, die eine individuelle Logik für Privatsphäre möchte, gehört wahrscheinlich auf DuskVM. Ein Solidity-Team, das DuskDS-Settlement unter einer bestehenden App nutzen möchte, gehört wahrscheinlich auf DuskEVM.
Der Trade-off, über den ich ständig nachdenke: DuskEVM bietet dir das EVM-Ökosystem, setzt aber eine Abstraktion zwischen deinem Code und den Privatsphäre-Funktionen, die Dusk interessant machen. DuskVM gibt dir den kompletten Stack, erfordert jedoch Rust und ein anderes Denkmodell.
Wenn du etwas Finanz-spezifisches auf Dusk bauen würdest: welchen Weg würdest du tatsächlich nehmen—die vertrauten EVM-Tools oder den nativen Stack mit direktem Zugriff auf die Privacy-Layer? @Dusk
$BTW
$MAGMA #dusk
Es gibt zwei Möglichkeiten, auf Dusk aufzubauen, und ich habe immer wieder gesehen, dass sie so erwähnt werden, als wären sie austauschbar. Wenn man jedoch die tatsächlichen Entwicklerdokumente liest, sind sie es nicht. Sie unterscheiden sich so stark, dass eine falsche Entscheidung wahrscheinlich eine Neufassung erforderlich macht.
DuskEVM ist eine EVM-kompatible Schicht, die auf DuskDS aufsetzt und OP Stack verwendet. Du schreibst Solidity oder Vyper, nutzt vertraute EVM-Tools, und deployst so, wie du es auch bei Ethereum oder Arbitrum tun würdest. Dein Smart Contract erbt DuskDS als Settlement- und Data-Availability-Schicht. Die Kosten bestehen aus zwei Gebührenebenen: der normalen EVM-Gasgebühr plus einer Data-Availability-Gebühr für das Veröffentlichen von Batch-Daten auf der darunterliegenden Kette.
DuskVM ist nativer Dusk. Du schreibst in Rust, kompilierst zu WASM und deployest direkt auf dem L1. Du erhältst Zugriff auf die nativen Transaktionsmodelle (Moonlight und Phoenix), auf Privatsphäre auf Protokollebene sowie ZK-Fähigkeiten und auf die vollständige, maßgeschneiderte Market-Logik, die ganz nahe an der Kette lebt. Keine zusätzliche Gebührenebene, keine OP-Stack-Abstraktion dazwischen.
Die Dokumentation ist direkt, wann man was wählen sollte. DuskEVM, wenn deine App von Solidity, EVM-Wallets und bestehendem Ethereum-Tooling profitiert. DuskVM, wenn deine App native Privatsphäre, ZK, Assets auf Protokollebene oder eine direkte Kontrolle über das Ausführungsmodell benötigt.
Was an dieser Einordnung ehrlich ist: Es wird nicht so getan, als wäre das eine besser. Die Entscheidung hängt komplett davon ab, was die Anwendung braucht. Eine Finanzanwendung, die eine individuelle Logik für Privatsphäre möchte, gehört wahrscheinlich auf DuskVM. Ein Solidity-Team, das DuskDS-Settlement unter einer bestehenden App nutzen möchte, gehört wahrscheinlich auf DuskEVM.
Der Trade-off, über den ich ständig nachdenke: DuskEVM bietet dir das EVM-Ökosystem, setzt aber eine Abstraktion zwischen deinem Code und den Privatsphäre-Funktionen, die Dusk interessant machen. DuskVM gibt dir den kompletten Stack, erfordert jedoch Rust und ein anderes Denkmodell.
Wenn du etwas Finanz-spezifisches auf Dusk bauen würdest: welchen Weg würdest du tatsächlich nehmen—die vertrauten EVM-Tools oder den nativen Stack mit direktem Zugriff auf die Privacy-Layer? @Dusk
$BTW
$MAGMA #dusk
