Aufzug im Wohngebiet fällt ständig aus. Jemand im Eigentümer-Chat hat einen Umbauplan gepostet. Anfangs dachte ich, dass bei vielen Stimmen der Start schnell kommen müsste. Später habe ich jedoch verstanden, dass man erst Angebote einholen, bewerten, Bau- und Testmaßnahmen durchführen und anschließend abnehmen muss. Auch die On-Chain-Regulierung ist nicht so leicht „auf schnell“ zu machen: Eine einzige, öffentlich gemachte Proposalsfassung bedeutet vor allem, dass die Diskussion einen offiziellen Träger hat. Der Code des Mainnets ändert sich dadurch nicht sofort.
Dusk bündelt Protokolländerungen in DIPs, also in Dusk Improvement Proposals. Der offizielle Ablauf beginnt mit „Idea“. Wenn die Idee Form annimmt, geht sie in „Draft“ über und bekommt eine Nummer; danach folgen ein Prototyp oder technische Ergebnisse in „Feedback“. Kurz vor der Fertigstellung wird es zu „Staging“. DIPs mit Code werden zunächst im Nocturne-Testnet bereitgestellt. Erst wenn Konsens erzielt wurde, werden sie als „Active“ markiert und die Ergebnisse in die Produktionsumgebung übernommen. #dusk
An dieser Prozesskette gefällt mir vor allem, dass DUSK-Protokolländerungen einen vollständigen Datensatz hinterlassen müssen. Das Proposal muss Motivation, technische Spezifikationen, Abwägungen, Rückwärtskompatibilität, Tests, Sicherheitsauswirkungen und Implementations-Links enthalten. Ein „Stagnant“-Proposal, das länger als sechs Monate nicht weiterentwickelt wurde, kann außerdem in „Dead“ übergehen. Wenn man später zurückblickt, kann die Community nachvollziehen, welche Risiken damals diskutiert wurden – statt nur die neue Version als Ankündigung zu sehen.
Aber „jeder kann einreichen“ kann nicht direkt bedeuten: „jeder kann die Regeln ändern“. DIP-Editoren wirken beim Review mit, vergeben Nummern, führen die Änderungen zusammen und verfolgen die Umsetzung. Außerdem müssen Knotenbetreiber die Software installieren, die die Änderungen enthält. Die aktuelle öffentliche Beschreibung liefert weder eine Abstimmungs-Schwelle, die nach $DUSK -Anteilsbesitz berechnet wird, noch schreibt sie „Konsens erreicht“ als einen klaren Prozentsatz fest. Ich werde keine offene Diskussion so verpacken, als wäre die On-Chain-Regulierung bereits abgeschlossen.
Wenn ich auf das Upgrade rund um @Dusk schaue, prüfe ich getrennt vier Dinge: In welchem Zustand befindet sich das DIP? Ist der Implementationscode öffentlich? Können die Nocturne-Testergebnisse erneut überprüft werden? Und wann übernehmen Mainnet-Knoten die Änderung. Likes im Chat zeigen nur, dass eine Idee beliebt ist. Erst „Active“ und die tatsächliche Bereitstellung zeigen, an welcher Stelle im Dusk-Regelprozess man wirklich steht.
Dusk bündelt Protokolländerungen in DIPs, also in Dusk Improvement Proposals. Der offizielle Ablauf beginnt mit „Idea“. Wenn die Idee Form annimmt, geht sie in „Draft“ über und bekommt eine Nummer; danach folgen ein Prototyp oder technische Ergebnisse in „Feedback“. Kurz vor der Fertigstellung wird es zu „Staging“. DIPs mit Code werden zunächst im Nocturne-Testnet bereitgestellt. Erst wenn Konsens erzielt wurde, werden sie als „Active“ markiert und die Ergebnisse in die Produktionsumgebung übernommen. #dusk
An dieser Prozesskette gefällt mir vor allem, dass DUSK-Protokolländerungen einen vollständigen Datensatz hinterlassen müssen. Das Proposal muss Motivation, technische Spezifikationen, Abwägungen, Rückwärtskompatibilität, Tests, Sicherheitsauswirkungen und Implementations-Links enthalten. Ein „Stagnant“-Proposal, das länger als sechs Monate nicht weiterentwickelt wurde, kann außerdem in „Dead“ übergehen. Wenn man später zurückblickt, kann die Community nachvollziehen, welche Risiken damals diskutiert wurden – statt nur die neue Version als Ankündigung zu sehen.
Aber „jeder kann einreichen“ kann nicht direkt bedeuten: „jeder kann die Regeln ändern“. DIP-Editoren wirken beim Review mit, vergeben Nummern, führen die Änderungen zusammen und verfolgen die Umsetzung. Außerdem müssen Knotenbetreiber die Software installieren, die die Änderungen enthält. Die aktuelle öffentliche Beschreibung liefert weder eine Abstimmungs-Schwelle, die nach $DUSK -Anteilsbesitz berechnet wird, noch schreibt sie „Konsens erreicht“ als einen klaren Prozentsatz fest. Ich werde keine offene Diskussion so verpacken, als wäre die On-Chain-Regulierung bereits abgeschlossen.
Wenn ich auf das Upgrade rund um @Dusk schaue, prüfe ich getrennt vier Dinge: In welchem Zustand befindet sich das DIP? Ist der Implementationscode öffentlich? Können die Nocturne-Testergebnisse erneut überprüft werden? Und wann übernehmen Mainnet-Knoten die Änderung. Likes im Chat zeigen nur, dass eine Idee beliebt ist. Erst „Active“ und die tatsächliche Bereitstellung zeigen, an welcher Stelle im Dusk-Regelprozess man wirklich steht.