O für On-Chain Governance [Polkadot von A bis Z]

Die On-Chain-Governance ist einer der wichtigsten Bestandteile von Polkadot und Kusama. Sie ist die einzige Möglichkeit, Runtime-Veränderungen vorzuschlagen. Solange die Community der DOT-Token-Inhaber der Meinung ist, dass die Veränderungen gerechtfertigt sind,und positiv abstimmt, kann die vorgeschlagene Runtime-Veränderung in Kraft gesetzt werden. Die Veränderung wird die Runtime-Logik aktualisieren, also den Code, der die Blockchain ausführt. Das ist ein großer Schritt! Die Entwickler haben nicht mehr den absoluten Einfluss auf den Code, mit dem das Netzwerk läuft. Die Macht, die Logik des Netzwerks zu verbessern, wird in die Hände der Token-Inhaber/innen gelegt. Aber wie funktioniert das alles?

Da die Token-Inhaber die Möglichkeit haben, die Runtime-Logik zu ändern, muss die On-Chain-Governance unter Berücksichtigung bestimmter Sicherheitsaspekte umgesetzt werden. Die Identifizierung der häufigsten Probleme bei der öffentlichen On-Chain-Governance und die Entwicklung effizienter Lösungen sind für einen gesunden Mechanismus unerlässlich. Der derzeitige Governance-Mechanismus ist effektiv, aber es gibt noch Raum für Verbesserungen. An der Governance 2.0, die flexibler, inklusiver, sicherer und dezentralisierter sein soll, wird derzeit gearbeitet und wir werden am Ende dieses Beitrags darauf eingehen. Um zu verstehen, was das bedeutet, müssen uns zunächst mit dem aktuellen Stand der On-Chain-Governance befassen.

Warum On-Chain-Governance so wichtig ist?

Es ist üblich, sich eine Codebasis als einen lebenden Organismus vorzustellen, der sich ständig verändert. Ihre Aktualisierung wirkt sich direkt auf ihre Gesundheit aus. Bei einem Blockchain-Netzwerk ist das nicht anders, denn es läuft schließlich auf Code. Daher liegt der Erfolg eines Blockchain-Netzwerks in seiner Flexibilität und seiner Fähigkeit, sich an Veränderungen anzupassen. Substrat-basierte Chains mit ihren gabelfreien Aktualisierungen (siehe Polkadot von A bis Z: F für Forkless, um dieses Konzept besser zu verstehen) sind so konzipiert, dass sie anpassungsfähig sind. Blockchains, die sich an Veränderungen im Ökosystem anpassen können, z. B. an Verbesserungen der Konsensmechanismen, effizientere Netzwerke, bessere Kryptografie oder andere Komponenten, aus denen eine Blockchain besteht, werden erfolgreich sein.

Für Veränderungen am Blockchain-Code vor der gabelfreien Upgrademöglichkeit mussten die Entwickler die Codebasis forken. Bei herkömmlichen Forks konnten die Entwickler der Codebasis die Runtime ändern, ohne dass es eine Einigung auf der Kette oder einen Konsens über das Update gab. BTC- oder ETH-Besitzer haben kein Mitspracherecht darüber, wie das Netzwerk entwickelt oder aktualisiert wird. Warum also nicht einen Token mit der Möglichkeit ausstatten, über Änderungen an der Laufzeit abzustimmen, die vorgenommen werden könnten? Das ist die Essenz der On-Chain-Governance.

Wenn Token-Inhaber die Möglichkeit haben, Vorschläge für Veränderungen an der Laufzeit zu erstellen und darüber abzustimmen, gibt es verschiedene Anreize. Ein Anreiz für die Token-Inhaber/innen, ein Gefühl für Fairness zu haben und sich um Änderungen an der Laufzeit zu kümmern, aber auch dafür zu sorgen, dass nur sinnvolle Veränderungen vorgenommen werden dürfen. Zweitens ein potenzieller negativer Anreiz für böswillige Teilnehmer/innen im Netzwerk, die versuchen, das System zu unterwandern, indem sie böswillige Abstimmungen vorschlagen. Das bedeutet, dass die On-Chain-Governance ein Umfeld schaffen muss, das sinnvolle Veränderungen zulässt, aber auch vor böswilligen Änderungen schützt. Zu den Komponenten des Systems gehören unter anderem: Anträge, Referenden, gewichtete Stake-Abstimmungen, adaptives Quorum Biasing, freiwilliges Locking aka Überzeugungsabstimmung und gabelfreie Upgrades. Öffnen wir also die Haube und sehen uns an, wie diese Komponenten zusammenarbeiten.

Die beweglichen Elemente

Die Governance muss fair und gerecht und im Falle von Blockchain-Systemen ausreichend dezentralisiert sein. Das bringt Herausforderungen mit sich: Wie stellen wir sicher, dass die Inhaber von Token gerecht vertreten sind und dass nicht eine einzelne Gruppe von Token-Inhabern das Governance-System auf der Grundlage ihrer Anteile kontrolliert. Die On-Chain-Governance von Substrate-basierten Chains wie Polkadot und Kusama besteht aus mehreren Schritten und bestimmten Komponenten, die zusammenarbeiten, um einen gut repräsentierten Abstimmungszyklus der Token-Inhaber über mögliche Änderungen an der Runtime zu gewährleisten. Bei der Idee eines Ursprungs gibt es verschiedene Instanzen, die an der Governance teilnehmen können. Die Ursprünge nutzen die Demokratie-Palette in Substrate und ermöglichen so eine On-Chain-Governance und die Aktualisierung der Runtime.

Ursprünge, die an der Governance teilnehmen können:

1. DOT-Token-Inhaber
2. Rat
3. Technischer Ausschuss

Der On-Chain-Governance-Zyklus in chronologischer Reihenfolge ist:

1. Vorschlag
2. Referenden
3. Abstimmen
4. Inkraftsetzung

Um die On-Chain-Governance zu verstehen, müssen wir die ursprünglichen Instanzen, die Komponenten im Kreislauf und ihr Zusammenspiel verstehen.

Rat

Der Rat ist ein On-Chain-Ursprung, dessen Aufgabe es ist, passive Token-Inhaber zu vertreten. Obwohl es sich um eine zentrale Autoritätsgruppe handelt, müssen die Kandidaten von den Token-Inhabern in den Rat gewählt werden. Um einen Sitz im Rat zu gewinnen, ist es also wichtig, sich in der Community einen guten Ruf zu erarbeiten. Die Ratsmitglieder haben einige wichtige Aufgaben: Sie initiieren sinnvolle Referenden, annullieren unumstrittene, schädliche und böswillige Referenden, verwalten den Treasury und wählen Mitglieder für den technischen Ausschuss. Derzeit gibt es auf Polkadot 13 Ratssitze mit Platz für bis zu 20 Nachrücker (die darauf warten, Ratsmitglieder zu werden). Auf Kusama gibt es 19 Sitze mit Platz für bis zu 19 Nachrücker/innen. Der Rat rotiert alle 7 Tage auf Polkadot und alle 24 Stunden auf Kusama (die Ratsmitglieder werden wiedergewählt).

Technischer Ausschuss

Der Technische Ausschuss ist eine Gruppe von Teams, die ihr technisches Wissen durch die erfolgreiche Implementierung einer Polkadot-Runtime bewiesen haben. Teams können durch einfache Mehrheitsabstimmung im Rat hinzugefügt oder entfernt werden.

Zweck des technischen Ausschusses ist es, sich vor böswilligen Abstimmungen zu schützen, Fehler zu beheben, fehlerhafte Runtime-Updates rückgängig zu machen oder neue, bereits getestete Funktionen hinzuzufügen. Diese Veränderungen werden durch den technischen Ausschuss im Schnellverfahren zur Abstimmung und Umsetzung gebracht.

Anträge

Es kann zwei Arten von Anträgen On-Chain geben. Öffentliche Anträge, die von Token-Inhabern gestellt werden. Und Ratsanträge, die in Form von externen Anträgen gestellt werden, entweder von einem Ratsmitglied oder einem Token-Inhaber. Der Rat hat auch einen speziellen internen Antrag, aber diese werden nicht zum Referendum gebracht. Interne Anträge benötigen keine Funktionalität der Demokratie-Palette, d.h. sie behandeln Angelegenheiten, die keine Runtime-Veränderungen erfordern, wie z.B. die Behandlung von Anträgen für den Treasury oder die Wahl von Mitgliedern des technischen Ausschusses. Öffentliche Anträge können gestellt werden, indem man die Mindestmenge an Token bindet (derzeit 100 DOT auf Polkadot). Sobald der Antrag On-Chain veröffentlicht wurde, signalisieren die Token-Inhaber ihre Unterstützung, indem sie den Antrag befürworten. Für die Befürwortung müssen sie die gleiche Menge an Token binden wie der Account, der den Antrag ursprünglich gepostet hat. Die Anzahl der gebundenen Token ist der entscheidende Faktor bei der Entscheidung, welche Anträge zu Referenden werden. Ein Antrag mit 3 Accounts, die jeweils 10 DOTs binden, ist wichtiger als 29 Accounts, die jeweils 1 DOT binden. Die gebundenen Token werden an die ursprünglichen Accounts zurückgegeben, wenn der Antrag zu einem Referendum wird.

Referenden

Ratsanträge werden zu Referenden gebracht, wenn eine einfache Mehrheit der Ratsmitglieder dem Antrag zustimmt. Auf diese Weise kann der Rat Gesetze einführen. Sobald der Antrag angenommen wurde, wird er zu einem öffentlichen Referendum. Wenn der Antrag von Token-Inhabern erstellt wurde, werden die Anträge mit der höchsten Anzahl an gebundenen Token zu öffentlichen Referenden.

Jeder Antragstyp, ob öffentlich oder vom Rat, hat seine eigene On-Chain-Warteschlange. Alle 28 Tage (auf Polkadot) werden die am meisten unterstützten Anträge zu Referenden veröffentlichen, über die abgestimmt werden kann. Der On-Chain-Mechanismus, der den nächsten Antrag für ein Referendum auswählt, wechselt zwischen der öffentlichen und der Ratswarteschlange.

Der Zeitplan für Referenden auf Polkadot sieht alle 28 Tage vor. Das bedeutet, dass alle 28 Tage der am meisten unterstützte öffentliche Antrag oder der jüngste Ratsantrag zu einem Referendum wird und den Token-Inhabern zur Abstimmung vorgelegt wird. Wenn nicht gerade ein Notfallreferendum ansteht, kann immer nur ein Referendum zur Abstimmung stehen. Wenn sich die Warteschlangen alle 28 Tage abwechseln und beide Warteschlangen mit Anträgen gefüllt sind, kommt jede Warteschlange alle 56 Tage an die Reihe. Aktive Referenden können mit Chain Explorern wie Polkadot JS UI oder Polkasembly angezeigt werden.

Abstimmung

Token-Inhaber können zwischen mehreren Stufen der Unterstützung für ein Referendum wählen, angefangen damit, dass sie keine Token binden, was ihr Stimmgewicht verringert, bis hin zur Bindung von Token für eine Reihe von Zeiträumen, um ihre Stimmkraft zu erhöhen. So wird ein Anreiz geschaffen, der vom Verkauf von Stimmrechten abhält, und gleichzeitig können auch kleinere Token-Inhaber ihre Stimmkraft erhöhen, indem sie Token für mehr als die erforderliche Mindestmenge binden. Dies wird als Überzeugungsabstimmung bezeichnet. Je nach Ergebnis der Abstimmung wird das Referendum entweder angenommen oder abgelehnt. Wenn es angenommen wird, wird es in Kraft gesetzt, d.h. das Runtime-Upgrade wird in einen der nächsten Blöcke aufgenommen.

Überzeugungsabstimmung

Einfach ausgedrückt, ist Conviction Voting, auch bekannt als freiwilliges Locking, ein Mechanismus, der es Token-Inhabern ermöglicht, ihr Stimmrecht zu erhöhen, indem sie ihre Token sicher On-Chain binden. Eingebaute Multiplikatoren haben ein Minimum von 0,1x (d.h. keine Bindung) und ein Maximum von 6x (Bindung für 896 Tage). Eine einzelne Sperrfrist entspricht dem Zeitplan eines Referendums, der 28 Tage beträgt.

Und die Gleichung zur Berechnung deiner Stimmkraft lautet:

Stimmen = Token * Überzeugungsmultiplikator

Das bedeutet, dass deine Stimme 1/10 einer regulären Stimme wert ist, wenn du deine Token nicht einsperrst. Wenn du für eine Abstimmungsperiode den gleichen Betrag wie der Urheber des Antrags bindest, ist deine Stimme 1 Stimme wert, und wenn du für 32 Perioden bindest, ist deine Stimme 6x so viel wert.

Die Überzeugungsabstimmung soll dazu beitragen, kleinere Token-Inhaber zur Kontroll- und Gegenkontrolle zu veranlassen, indem sie ihnen die Möglichkeit gibt, ihre Stimmkraft zu erhöhen.

Adaptives Quorum Biasing (Wahlbeteiligung)

Wir können uns diesen Mechanismus als einen Hebel vorstellen, der den Prozentsatz der erforderlichen absoluten Mehrheit verändert, damit ein Referendum angenommen wird. Er ist dann wichtig, wenn es keine klare Mehrheit für oder gegen ein Referendum gibt. Aufgrund der Wahlbeteiligung lässt sich dieser Mechanismus in zwei Kategorien einteilen: die positive und die negative Wahlbeteiligung, die die Variable der einfachen Mehrheit steuern.

Bei allen öffentlichen Anträgen kommt die so genannte positive Wahlbeteiligung zum Einsatz, d.h. mit zunehmender Beteiligung am Referendum sinkt der Grenzwert der erforderlichen Ja-Stimmen. Die positive Wahlbeteiligung stellt sicher, dass bei einer niedrigeren Wahlbeteiligung nur unumstrittene Anträge angenommen werden können. Bei einer niedrigen Wahlbeteiligung von 25% beispielsweise liegt die absolute Mehrheit bei 66%. Wenn die Wahlbeteiligung steigt, sinkt die erforderliche absolute Mehrheit. Liegt die Wahlbeteiligung beispielsweise bei 75%, beträgt die erforderliche absolute Mehrheit 54%.

Bei Ratsanträgen, die einstimmig angenommen werden, ist die Wahlbeteiligung negativ, d.h. es ist einfacher, sie bei einer niedrigen Wahlbeteiligung zu verabschieden, und es ist eine absolute Mehrheit erforderlich, um sie abzulehnen.

Annullierung

Es gibt verschiedene Methoden, um einen Antrag zu annullieren, die zu unterschiedlichen Zeitpunkten angewendet werden können:

1. Wenn es eine einstimmige Zustimmung gibt, kann der Fachausschuss einen Antrag annullieren.
2. Wenn der Antrag zu einem Referendum geworden ist und es in letzter Minute ein Problem gab, z. B. einen Fehler im Runtime-Code. Der Rat kann das Referendum mit einer 2/3-Mehrheit annullieren.

Die Hinterlegung eines annullierten Antrags wird verbrannt, aber in der Vergangenheit gab es Vorschläge, die verbrannten Tokens rückgängig zu machen, wenn sie umstritten waren.

Die Zukunft (On-Chain Governance 2.0)

Das aktuelle Modell ist zwar nicht perfekt, hat aber in den letzten 2 Jahren gut funktioniert. Seit den ersten Anträgen gab es bereits Überlegungen, wie einige Schwachstellen in Zukunft verbessert werden könnten. Die Community hat sich besorgt über die niedrige Wahlbeteiligung und darüber geäußert, dass der Rat und der Fachausschuss eine zentrale Autorität darstellen.

Um diese Probleme zu lösen und die Netzwerke Polkadot und Kusama noch weiter zu dezentralisieren, hat sich das Entwicklungsteam von Parity Technologies darauf konzentriert, den Rat und den technischen Ausschuss aufzulösen. Der Code, der dies ermöglichen würde, wurde bereits in die Codebasis von Substrate aufgenommen, muss aber noch auf Kusama getestet und von der Community per Runtime-Upgrade geprüft und genehmigt werden. Das Ziel von Governance 2.0 ist ein agileres, inklusiveres, sichereres und dezentralisiertes Design.

Wenn du mehr über On-Chain-Governance erfahren möchtest, schau dir diese Ressourcen an:

• Blogbeitrag über Governance 1.0
• Polkadot Wiki: Governance

Übersetzt von Daredevil3x7 und erstellt mit Unterstützung des Kusama Treasury via WagMedia

Mehr von der ELI5 Serie: Polkadot A bis Z

A für Account [Polkadot von A bis Z]

B for Brücken “Bridges” [Polkadot from A to Z]

C für “Collators” (Kollatoren) [Polkadot von A bis Z]

D für “Democracy” (Demokratie) [Polkadot von A bis Z]

E für Existentielle Einlage [Polkadot von A bis Z]

F für “Forkless” (Gabelfrei) [Polkadot von A bis Z]

G für GRANDPA [Polkadot von A bis Z]

H für Hash [Polkadot von A bis Z]

I für Interoperabilität [Polkadot von A bis Z]

J für Polkadot.js [Polkadot von A bis Z]

K für Kusama [Polkadot von A bis Z]

L für Polkadot Launch [Polkadot von A bis Z]

M für Multisig [Polkadot von A bis Z]

O für On-Chain Governance [Polkadot von A bis Z]

P für Phragmén [Polkadot von A bis Z]