#dusk $DUSK @Dusk
Was Rusk als Referenzknoten von DUSK tut
Mein Großvater führte für seinen Laden ein einziges Buch — alles lief darüber: Geld rein, Geld raus, wer wem was schuldete, Bestandszählungen. Nicht weil er andere Systeme nicht gehabt hätte, sondern weil dieses eine Buch wirklich das Ding war, auf das sich alles andere bezog. $ENA
Ich nahm an, „Referenzknoten“ sei nur Marketing-Sprache für „die offizielle App“. Diese Annahme zerbrach, sobald ich nachverfolgte, was Rusk tatsächlich macht.
Die Dokumentation zu den Kernbausteinen von Dusk bezeichnet Rusk als die Rust-Implementierung von DuskDS — es führt Konsens aus, verwaltet den Kettenzustand und stellt die externen APIs bereit, darunter die HTTP-API und das RUES-Event-System, mit denen Wallets, Indexer und Integratoren tatsächlich verbunden sind. Ein separates Architekturstück beschreibt das noch deutlicher: Rusk beherbergt die Genesis-ZK-Zircuits und -Contracts, stellt Host-Funktionen für die Ausführungs-Engine bereit und verwaltet die Datenbank sowie die Netzwerkschicht unter allem anderen.
Das ist keine „App, die Dusk ausführt“. Das ist der eigentliche Bezugspunkt, gegen den jede Wallet, jeder Indexer und jede Integration aufgebaut ist. $TUT
Der echte Test für DUSK ist, ob es nachhaltig bleibt, eine einzige kanonische Referenzimplementierung beizubehalten, während immer mehr Drittanbieter-Tooling darum herum entsteht — oder ob das irgendwann zum Flaschenhals wird, an dem das Ökosystem dann vorbeirouten muss.
Was ich nicht dokumentiert gefunden habe, ist, wie Dusk vorhat, mit Versionsdrift umzugehen, falls jemals unabhängig von Rusk selbst eigene Implementierungen von Drittanbieter-Knoten entstehen.
Was Rusk als Referenzknoten von DUSK tut
Mein Großvater führte für seinen Laden ein einziges Buch — alles lief darüber: Geld rein, Geld raus, wer wem was schuldete, Bestandszählungen. Nicht weil er andere Systeme nicht gehabt hätte, sondern weil dieses eine Buch wirklich das Ding war, auf das sich alles andere bezog. $ENA
Ich nahm an, „Referenzknoten“ sei nur Marketing-Sprache für „die offizielle App“. Diese Annahme zerbrach, sobald ich nachverfolgte, was Rusk tatsächlich macht.
Die Dokumentation zu den Kernbausteinen von Dusk bezeichnet Rusk als die Rust-Implementierung von DuskDS — es führt Konsens aus, verwaltet den Kettenzustand und stellt die externen APIs bereit, darunter die HTTP-API und das RUES-Event-System, mit denen Wallets, Indexer und Integratoren tatsächlich verbunden sind. Ein separates Architekturstück beschreibt das noch deutlicher: Rusk beherbergt die Genesis-ZK-Zircuits und -Contracts, stellt Host-Funktionen für die Ausführungs-Engine bereit und verwaltet die Datenbank sowie die Netzwerkschicht unter allem anderen.
Das ist keine „App, die Dusk ausführt“. Das ist der eigentliche Bezugspunkt, gegen den jede Wallet, jeder Indexer und jede Integration aufgebaut ist. $TUT
Der echte Test für DUSK ist, ob es nachhaltig bleibt, eine einzige kanonische Referenzimplementierung beizubehalten, während immer mehr Drittanbieter-Tooling darum herum entsteht — oder ob das irgendwann zum Flaschenhals wird, an dem das Ökosystem dann vorbeirouten muss.
Was ich nicht dokumentiert gefunden habe, ist, wie Dusk vorhat, mit Versionsdrift umzugehen, falls jemals unabhängig von Rusk selbst eigene Implementierungen von Drittanbieter-Knoten entstehen.