Je länger ich mir DUSK anschaue, desto weniger denke ich bei „Governance“ an das Thema „wer abstimmen darf“.
Das ist der einfache Teil.
Was mich wirklich interessiert, ist, was nach der Diskussion passiert, nach dem Vorschlag, nachdem sich alle darauf geeinigt haben, was sie wollen.
Dann muss jemand das Netzwerk ändern.
Dusk nutzt DIPs – Dusk Improvement Proposals – um Protokolländerungen zu dokumentieren und sie vor dem Eintritt in das System einem Review zu unterziehen.
Aber ein Vorschlag ist immer noch nur ein Dokument.
Irgendwann muss daraus Code werden.
Und genau da wird es viel ernster.
Ein Upgrade kann die Regeln ändern, die Nodes verwenden, um Transaktionen zu validieren, Blöcke zu verarbeiten oder neue Funktionalität zu aktivieren. Der Rusk-Client von Dusk hat eine explizite Upgrade- und Aktivierungslogik, um mit diesen Änderungen umzugehen.
Dieses kleine Detail ist für mich wichtiger als die Governance-Seite.
Denn die eigentliche Frage lautet nicht:
„Hat die Community das genehmigt?“
Sondern:
„Ist das Netzwerk tatsächlich sauber auf die neuen Regeln umgestiegen?“
Das ist ein völlig anderes Problem.
Und es gibt noch eine weitere Ebene, die viele Leute dazu neigen zu übersehen.
Dusk versucht nicht nur, einfach eine weitere universelle Chain zu sein. Es baut Infrastruktur rund um Datenschutz und Finanzanwendungen – also Bereiche, in denen Upgrades langfristig Dinge berühren können wie Berechtigungen, Asset-Kontrollen, regulierte Workflows und das Verhalten von Smart Contracts.
In so einer Umgebung ist „Upgrade-Fähigkeit“ ein zweischneidiges Schwert.
Man braucht die Möglichkeit, Probleme zu beheben.
Man muss außerdem genau wissen, wer was ändern darf, wie diese Änderung abläuft und was das Netzwerk macht, während die Änderung stattfindet.
Darum würde ich weniger Aufmerksamkeit auf die Anzahl der Governance-Diskussionen über DUSK legen…
…und mehr auf den langweiligen Teil:
die DIP,
das Code-Commit,
die Veröffentlichung,
die Aktivierungsregel,
und schließlich der Moment, in dem Nodes damit beginnen, das neue Verhalten durchzusetzen.
Diese gesamte Kette ist Governance.
Der leise Teil ist, dass man Governance eigentlich nicht wirklich sieht, wenn alles gut läuft.
Man merkt es, wenn sich die Regeln ändern – und das Netzwerk dennoch weiterhin mit der Realität übereinstimmt.
#dusk $DUSK @Dusk
Das ist der einfache Teil.
Was mich wirklich interessiert, ist, was nach der Diskussion passiert, nach dem Vorschlag, nachdem sich alle darauf geeinigt haben, was sie wollen.
Dann muss jemand das Netzwerk ändern.
Dusk nutzt DIPs – Dusk Improvement Proposals – um Protokolländerungen zu dokumentieren und sie vor dem Eintritt in das System einem Review zu unterziehen.
Aber ein Vorschlag ist immer noch nur ein Dokument.
Irgendwann muss daraus Code werden.
Und genau da wird es viel ernster.
Ein Upgrade kann die Regeln ändern, die Nodes verwenden, um Transaktionen zu validieren, Blöcke zu verarbeiten oder neue Funktionalität zu aktivieren. Der Rusk-Client von Dusk hat eine explizite Upgrade- und Aktivierungslogik, um mit diesen Änderungen umzugehen.
Dieses kleine Detail ist für mich wichtiger als die Governance-Seite.
Denn die eigentliche Frage lautet nicht:
„Hat die Community das genehmigt?“
Sondern:
„Ist das Netzwerk tatsächlich sauber auf die neuen Regeln umgestiegen?“
Das ist ein völlig anderes Problem.
Und es gibt noch eine weitere Ebene, die viele Leute dazu neigen zu übersehen.
Dusk versucht nicht nur, einfach eine weitere universelle Chain zu sein. Es baut Infrastruktur rund um Datenschutz und Finanzanwendungen – also Bereiche, in denen Upgrades langfristig Dinge berühren können wie Berechtigungen, Asset-Kontrollen, regulierte Workflows und das Verhalten von Smart Contracts.
In so einer Umgebung ist „Upgrade-Fähigkeit“ ein zweischneidiges Schwert.
Man braucht die Möglichkeit, Probleme zu beheben.
Man muss außerdem genau wissen, wer was ändern darf, wie diese Änderung abläuft und was das Netzwerk macht, während die Änderung stattfindet.
Darum würde ich weniger Aufmerksamkeit auf die Anzahl der Governance-Diskussionen über DUSK legen…
…und mehr auf den langweiligen Teil:
die DIP,
das Code-Commit,
die Veröffentlichung,
die Aktivierungsregel,
und schließlich der Moment, in dem Nodes damit beginnen, das neue Verhalten durchzusetzen.
Diese gesamte Kette ist Governance.
Der leise Teil ist, dass man Governance eigentlich nicht wirklich sieht, wenn alles gut läuft.
Man merkt es, wenn sich die Regeln ändern – und das Netzwerk dennoch weiterhin mit der Realität übereinstimmt.
#dusk $DUSK @Dusk