#dusk $DUSK @Dusk Ich war schon immer neugierig, wie der Entwicklungsfonds im Dusk-Ökosystem konkret funktioniert – entscheiden die Teams selbst, oder gibt es einen Prozess, mit dem auch externe Personen diese Mittel beantragen können? Nachdem ich mir die Erklärungen zur Governance genauer angesehen hatte, stellte ich fest: Dieser Prozess ist formeller, als ich ursprünglich gedacht hatte.
Die Mittelherkunft ist recht direkt: Für jeden produzierten Block im Mainnet wird ein fester Anteil aus der Belohnung herausgeschnitten und über die Zeit in diesem Fonds-Pool angesammelt. Er ist speziell dafür da, die anschließende Ökosystem-Entwicklung und Forschungsarbeiten zu unterstützen – nicht über kurzfristige Spendenaktionen oder weil ein Team „aus eigener Tasche“ zahlt.
Die eigentliche Dezentralisierung liegt im Genehmigungsprozess: Änderungen, die direkt mit dem Protokoll selbst zusammenhängen – etwa zu einem konkreten technischen Verbesserungsvorschlag – laufen über eine Linie aus Einreichung, Begutachtung und Entscheidung, ob diese Maßnahme übernommen wird. Dabei werden an das Format relativ strenge Anforderungen gestellt; es muss wie ein formelles technisches Vorschlagsdokument ausgearbeitet sein – nicht einfach nur ein Beitrag posten und es gilt dann als entschieden. Ausgaben, die keinen direkten Bezug zum Protokollcode haben – zum Beispiel die Entwicklung eines Wallet-Tools oder zweckgebundene Forschungsmittel für ein bestimmtes Forschungsthema – laufen über eine andere Genehmigungslinie. Dafür wird von einer Governance-Gruppe, die speziell für die Zuteilung dieser Gelder zuständig ist, bewertet und entschieden. Theoretisch können auch Mitglieder der externen Community über den Prozess der Wahlen in diese Gruppe einbezogen werden und so am Genehmigungsprozess partizipieren.
Ich hatte ursprünglich gedacht, dass das im Kern ein „Black-Box-Prozess der internen Team-Genehmigung“ ist. Aber nachdem ich die Unterlagen gelesen hatte, sah ich: Zumindest auf Dokumentenebene sind diese beiden Linien ziemlich klar getrennt. Außerdem gibt es jeweils Einstiegspunkte, über die externe Personen Anträge einreichen und sogar an der Begutachtung teilnehmen können – nicht völlig verschlossen. Allerdings sind Dokumentenbeschreibung und tatsächliche Ausführung zwei verschiedene Dinge. Welche Projekte in den letzten Jahren genehmigt wurden, wie hoch die Genehmigungsquote ungefähr war und welcher Anteil auf von extern eingereichte Anträge entfällt – konkrete Ausführungsdaten dazu habe ich derzeit in der Hand nicht gefunden. Man kann also sagen: Vom Prozessdesign her ist das System offen, aber ob und wie transparent die tatsächliche Umsetzung ist, ist noch nicht klar genug; dafür bräuchte es mehr historische Aufzeichnungen zur Überprüfung. Im Moment kann ich keine endgültige, belastbare Einschätzung abgeben.
Die Mittelherkunft ist recht direkt: Für jeden produzierten Block im Mainnet wird ein fester Anteil aus der Belohnung herausgeschnitten und über die Zeit in diesem Fonds-Pool angesammelt. Er ist speziell dafür da, die anschließende Ökosystem-Entwicklung und Forschungsarbeiten zu unterstützen – nicht über kurzfristige Spendenaktionen oder weil ein Team „aus eigener Tasche“ zahlt.
Die eigentliche Dezentralisierung liegt im Genehmigungsprozess: Änderungen, die direkt mit dem Protokoll selbst zusammenhängen – etwa zu einem konkreten technischen Verbesserungsvorschlag – laufen über eine Linie aus Einreichung, Begutachtung und Entscheidung, ob diese Maßnahme übernommen wird. Dabei werden an das Format relativ strenge Anforderungen gestellt; es muss wie ein formelles technisches Vorschlagsdokument ausgearbeitet sein – nicht einfach nur ein Beitrag posten und es gilt dann als entschieden. Ausgaben, die keinen direkten Bezug zum Protokollcode haben – zum Beispiel die Entwicklung eines Wallet-Tools oder zweckgebundene Forschungsmittel für ein bestimmtes Forschungsthema – laufen über eine andere Genehmigungslinie. Dafür wird von einer Governance-Gruppe, die speziell für die Zuteilung dieser Gelder zuständig ist, bewertet und entschieden. Theoretisch können auch Mitglieder der externen Community über den Prozess der Wahlen in diese Gruppe einbezogen werden und so am Genehmigungsprozess partizipieren.
Ich hatte ursprünglich gedacht, dass das im Kern ein „Black-Box-Prozess der internen Team-Genehmigung“ ist. Aber nachdem ich die Unterlagen gelesen hatte, sah ich: Zumindest auf Dokumentenebene sind diese beiden Linien ziemlich klar getrennt. Außerdem gibt es jeweils Einstiegspunkte, über die externe Personen Anträge einreichen und sogar an der Begutachtung teilnehmen können – nicht völlig verschlossen. Allerdings sind Dokumentenbeschreibung und tatsächliche Ausführung zwei verschiedene Dinge. Welche Projekte in den letzten Jahren genehmigt wurden, wie hoch die Genehmigungsquote ungefähr war und welcher Anteil auf von extern eingereichte Anträge entfällt – konkrete Ausführungsdaten dazu habe ich derzeit in der Hand nicht gefunden. Man kann also sagen: Vom Prozessdesign her ist das System offen, aber ob und wie transparent die tatsächliche Umsetzung ist, ist noch nicht klar genug; dafür bräuchte es mehr historische Aufzeichnungen zur Überprüfung. Im Moment kann ich keine endgültige, belastbare Einschätzung abgeben.