#dusk $DUSK
Der Name „Rusk“ tauchte in der Dokumentation von Dusk immer wieder auf, ohne eine klare Erklärung, was er eigentlich ist. Dabei handelt es sich um die Referenz-Node-Implementierung — und zu verstehen, was ein „Node“ in diesem Kontext abdeckt, lohnt sich, um es präzise zu machen.
Überraschender Teil: Rusk leitet nicht nur Blöcke weiter. Es führt das gesamte Konsensprotokoll aus, einschließlich Blockerzeugung und Komitee-Abstimmung. Es verwaltet den vollständigen Chain-State. Es führt DuskVM-Verträge aus. Es stellt APIs und Events bereit, die Anwendungen nutzen können.
Das Boreas-Upgrade, das Rusk v1.7.0 entspricht, war Mitte 2026 auf dem Testnet aktiv — die nächste protokollbezogene Aktualisierung nach Aegis (März 2026). Jedes Upgrade wird zuerst im Testnet bereitgestellt, bevor es ins Mainnet geht, damit Betreiber Zeit zur Validierung haben.
Auf Ethereum ist die Node-Software getrennt vom Execution-Client. Rusk vereint beides in einer einzigen Referenzimplementierung: Es ist sowohl der Konsens-Teilnehmer als auch der Smart-Contract-Executor. In demselben Prozess werden beide Ebenen abgewickelt.
Vergleichen kann man das mit einer geschichteten Architektur wie Ethereum+Geth: Das Protokoll und der Execution-Client werden separat gepflegt und können ausgetauscht werden. Rusk ist eine einzelne Referenzimplementierung. Das macht Upgrades zwar einfacher zu koordinieren, schafft aber auch eine einzige Abhängigkeitskette für Betreiber.
Ich finde die Entscheidung für eine einzelne Referenzimplementierung tatsächlich interessant für eine Chain, die auf regulierte Märkte abzielt — regulierte Infrastrukturen bevorzugen normalerweise Client-Diversität, um Bugs in einer einzigen Implementierung zu vermeiden.
Hat Dusk Pläne für alternative Node-Implementierungen, oder ist Rusk per Design der einzige Production-Client? @Dusk
$DUSK #dusk
Der Name „Rusk“ tauchte in der Dokumentation von Dusk immer wieder auf, ohne eine klare Erklärung, was er eigentlich ist. Dabei handelt es sich um die Referenz-Node-Implementierung — und zu verstehen, was ein „Node“ in diesem Kontext abdeckt, lohnt sich, um es präzise zu machen.
Überraschender Teil: Rusk leitet nicht nur Blöcke weiter. Es führt das gesamte Konsensprotokoll aus, einschließlich Blockerzeugung und Komitee-Abstimmung. Es verwaltet den vollständigen Chain-State. Es führt DuskVM-Verträge aus. Es stellt APIs und Events bereit, die Anwendungen nutzen können.
Das Boreas-Upgrade, das Rusk v1.7.0 entspricht, war Mitte 2026 auf dem Testnet aktiv — die nächste protokollbezogene Aktualisierung nach Aegis (März 2026). Jedes Upgrade wird zuerst im Testnet bereitgestellt, bevor es ins Mainnet geht, damit Betreiber Zeit zur Validierung haben.
Auf Ethereum ist die Node-Software getrennt vom Execution-Client. Rusk vereint beides in einer einzigen Referenzimplementierung: Es ist sowohl der Konsens-Teilnehmer als auch der Smart-Contract-Executor. In demselben Prozess werden beide Ebenen abgewickelt.
Vergleichen kann man das mit einer geschichteten Architektur wie Ethereum+Geth: Das Protokoll und der Execution-Client werden separat gepflegt und können ausgetauscht werden. Rusk ist eine einzelne Referenzimplementierung. Das macht Upgrades zwar einfacher zu koordinieren, schafft aber auch eine einzige Abhängigkeitskette für Betreiber.
Ich finde die Entscheidung für eine einzelne Referenzimplementierung tatsächlich interessant für eine Chain, die auf regulierte Märkte abzielt — regulierte Infrastrukturen bevorzugen normalerweise Client-Diversität, um Bugs in einer einzigen Implementierung zu vermeiden.
Hat Dusk Pläne für alternative Node-Implementierungen, oder ist Rusk per Design der einzige Production-Client? @Dusk
$DUSK #dusk
