Dies ist die Fortsetzung des ersten Threads zur dualen Governance 18. Der verlinkte Thread enthält einen wichtigen Kontext, also lesen Sie ihn bitte durch, wenn Sie Zeit haben.

Seit in diesem Beitrag 5 die letzte Entwurfsversion des Mechanismus vorgeschlagen wurde, haben die an DG arbeitenden Protokollmitwirkenden mehrere Iterationen durchgeführt, um das erhaltene Feedback zu integrieren und den Mechanismus einfacher, weniger anfällig und effizienter zu machen.

Bevor ich die aktualisierte Version präsentiere, möchte ich das Problem skizzieren, das wir zu lösen versuchen, und kurz die Argumentationskette nachzeichnen, die uns zu der vorgeschlagenen Lösung geführt hat.

Das Problem

Derzeit werden der Lido-Protokollcode und seine Parameter vom Lido DAO über LDO-Token-Voting gesteuert. Das Protokoll erhebt eine Gebühr von 5 % von den Einsatzprämien und leitet sie an das DAO-Finanzministerium weiter (weitere 5 % werden an die am Protokoll teilnehmenden Knotenbetreiber verteilt).

Während LDO-Inhaber im Allgemeinen motiviert sein sollten, das Wohlergehen des Protokolls aufrechtzuerhalten, da sich dies im LDO-Token-Preis widerspiegelt, bedeutet dies nicht unbedingt, dass LDO-Inhaber die Protokollbenutzer effizient vertreten. Stellen Sie sich zum Beispiel vor, dass LDO-Inhaber gemeinsam beschließen, die Protokollgebühren zu erhöhen: Dies könnte sich zwar positiv auf das unmittelbare Wohlergehen der LDO-Inhaber auswirken, steht aber eindeutig im Widerspruch zu den Interessen zumindest eines Teils der Protokollnutzer.

Dies kann als Prinzipal-Agent-Problem (PAP) zwischen dem DAO (dem Agenten) und den Protokollbenutzern (dem Prinzipal) verallgemeinert werden. Das Problem besteht darin, dass LDO-Inhaber nicht genau die gleichen Anreize haben wie Benutzer.

Darüber hinaus wird das PAP, wie Vitalik in seinem Aufsatz „Moving beyond Coin Voting 9“ hervorhebt, durch die Tatsache verschärft, dass das wirtschaftliche Interesse an den Einnahmen des Protokolls von der Regierungsmacht abgekoppelt werden kann: Man könnte die Anreize der DAO-Token-Inhaber verzerren, indem man sie besticht oder Leihen Sie sich den DAO-Abstimmungstoken auf dem freien Markt aus, um zu versuchen, genügend Stimmrecht zu erhalten, um eine Änderung voranzutreiben, die sowohl den Interessen der DAO als auch der Protokollbenutzer zuwiderläuft.

Die Präsenz des PAP ist nicht großartig, aber man kann argumentieren, dass Benutzer, wenn sie feststellen, dass der aktuelle Agent sie nicht gut genug repräsentiert, jederzeit das Protokoll verlassen und einen anderen Agenten auswählen können, der besser zu ihren Interessen passt, oder sich sogar dazu entschließen können, das Protokoll zu entfernen der Agent komplett per Solo-Einsatz.

Dies ist ein sehr wichtiger Mechanismus, der allgemein als Fußabstimmung bekannt ist. Theoretisch sollte es Benutzer vor den negativen Auswirkungen einer Fehlausrichtung der Anreize zwischen ihnen und dem DAO oder einem Angriff auf das DAO schützen. In der Praxis und im speziellen Fall des Ethereum-Liquid-Stakes ist die Effizienz der Fußabstimmung jedoch aufgrund einer Reihe von Faktoren begrenzt.

Der erste Faktor sind die Besonderheiten der Funktionsweise des Ethereum PoS. Um die ETH von einem Validator zu trennen, muss man warten, bis der Validator vollständig verlassen ist, und alle Exits des Ethereum-Validators werden über eine einzige Warteschlange mit begrenztem Durchsatz verarbeitet. Dies bedeutet, dass die zum Verlassen des Protokolls erforderliche Zeit von externen Faktoren außerhalb des Protokolls abhängt und um Größenordnungen variieren kann. Dies wiederum bedeutet, dass die Auferlegung einer statischen Zeitsperre für DAO-Entscheidungen nicht garantieren kann, dass ein Benutzer genügend Zeit hat, das Protokoll zu verlassen, bevor das DAO eine Änderung vornimmt, die nicht im Interesse des Benutzers ist.

Der zweite Faktor besteht darin, dass sich ein erheblicher Teil der Nutzer für Liquid Staking entscheidet, weil sie das eingesetzte Kapital für andere Formen wirtschaftlicher Aktivitäten einsetzen möchten, was dazu führt, dass Liquid Staking Tokens (LSTs) im DeFi weit verbreitet sind, einschließlich der erforderlichen Protokolle zusätzliche Zeit zum Rückzug (z Kreditmärkte). Dies fügt eine weitere externe Abhängigkeit hinzu, die verhindern kann, dass Benutzer das Protokoll innerhalb eines vordefinierten Zeitrahmens verlassen.

Der dritte Faktor ergibt sich aus der Informationsasymmetrie zwischen der passiven Mehrheit und der aktiven gebildeten Minderheit der Nutzer: Die korrekte Einschätzung aller mit einer bestimmten Governance-Entscheidung verbundenen Risiken, einschließlich Extremrisiken, erfordert das Wissen, über das die meisten Nutzer nicht verfügen. Die Kommunikation der potenziellen negativen Auswirkungen einer DAO-Entscheidung über die soziale Ebene nimmt zusätzliche Zeit in Anspruch und verringert die Wahrscheinlichkeit, dass die passive Mehrheit das Protokoll verlässt, bevor die Entscheidung ausführbar wird.

Lido DAO hat eine Reihe von Governance-Protokollen zur Reduzierung der Informationsasymmetrie eingerichtet (z. B. das GOOSE-Framework, die Node Operators Sub-Governance Group, das LIP-Framework, die Verpflichtung zur Mindestanzahl von Audits bei jeder Änderung des Mainnet-Codes), aber sie sind alle vorhanden Vereinbarungen auf sozialer Ebene zwischen den derzeitigen LDO-Inhabern und können daher nicht vor einem externen Angriff auf das DAO schützen.

Der Lösung entgegen

Die ultimative Lösung des Problems ist die Minimierung der Governance und die eventuelle Verknöcherung des Protokollcodes und der Parameter. Es besteht kein Governance-Risiko, wenn nichts regiert wird.

Die schrittweise Minimierung des Governance-Umfangs wird von den Mitwirkenden des Protokolls in den kommenden Jahren als Notwendigkeit angesehen. Bis die Ethereum-Spezifikation jedoch erstarrt, kann die Code-Aktualisierbarkeit nur bis zu einem gewissen Grad reduziert werden (z. B siehe EIP-7002 5, EIP-7251 6). Darüber hinaus muss jeder unveränderliche Code formal auf Bytecode-Ebene überprüft werden, um die Möglichkeit auszuschließen, dass ein Compiler-Fehler eine nicht behebbare Schwachstelle verursacht.

Es gibt auch die Fungibilitätsschicht des Protokolls, die als Risiko-/Ertragsbewertungsmaschine dient und ETH auf verschiedene Validator-Teilmengen verteilt, so dass der Ertrag und die Risiken des resultierenden Validator-Sets ausgeglichen werden. Zu den Risiken gehören hier die Extremrisiken, die der Validator-Satz für das Ethereum-Netzwerk verursacht, z Zensur und damit verbundene Kürzungsrisiken. Es gibt laufende Untersuchungen (siehe diesen Bericht 6 für die neueste Ausgabe), ob diese Risiken durch das Protokoll mit Hilfe eines vertrauenswürdigen Oracle-Gadgets abgeschätzt werden können, das die erforderlichen Informationen in die Kette bringt, aber es ist ein langfristiges Unterfangen und es ist noch nicht klar, wie das geschieht Das gewünschte Ergebnis kann praktisch erreicht werden. Bis das Protokoll über einen solchen vertrauenswürdigen Mechanismus verfügt, muss es eine gewisse Governance auf der Fungibilitätsebene geben.

Ein weiterer potenzieller Forschungsbereich ist die Suche nach Möglichkeiten, ein explizites Opt-in für neue Code- und Parametersatzversionen für stETH-Inhaber und -Integrationen einzuführen. Es ist noch nicht klar, ob dies ohne Beeinträchtigung der LST-Fungibilität und der daraus resultierenden Liquiditätsfragmentierung möglich ist, was angesichts der Tatsache, dass Liquidität einer der Hauptfaktoren ist, die Benutzer zu LSTs bewegen, die Wettbewerbsfähigkeit des Protokolls gegenüber anderen dezentralen und zentralisierten Anbietern von Liquid Staking zerstören würde. Dennoch handelt es sich um eine interessante Forschungsrichtung.

Nachdem wir nun festgestellt haben, dass das Protokoll zumindest mittelfristig mit einer Art Governance leben muss, wollen wir sehen, wie wir <a href="https://notes.ethereum.org/@mikeneuder/magnitude -und-richtung">die Risiken, die diese Governance mit sich bringt 1 .

Doppelte Regierungsführung

Wie im ersten Abschnitt hervorgehoben, lässt sich das allgemeine Problem in 1) das Vorhandensein von PAP und 2) die begrenzte Effizienz der Fußabstimmung zerlegen. Idealerweise möchten wir also einen Mechanismus einführen, der sowohl die Abstimmung zwischen dem DAO und den Protokollbenutzern als auch die Effizienz der Fußabstimmung verbessert.

Hier kommen wir zum vorgeschlagenen Dual-Governance-Design. Es zielt auf folgende Verbesserungen ab:

1. Geben Sie den Stakeholdern die Möglichkeit, glaubwürdig zu signalisieren, dass sie mit der DAO nicht einverstanden sind, und verpflichten Sie sich, das Protokoll zu verlassen, wenn die DAO bei der Lösung des Anreizkonflikts nicht kooperiert.
2. Stellen Sie ein Verhandlungsinstrument zwischen den Stakern und dem DAO bereit.
3. Führen Sie eine erweiterte dynamische Zeitsperre für DAO-Entscheidungen ein, die von einer aktiven Minderheit von Stakern ausgelöst und verlängert werden kann, wenn mehr Staker teilnehmen.
4. Verbessern Sie die Effizienz der Fußabstimmung, indem Sie den Stakern ermöglichen, das Protokoll zu verlassen, ohne neuen und ausstehenden DAO-Entscheidungen ausgesetzt zu sein.

Eine Übersicht über das vorgeschlagene Mechanismusdesign und einige Ideen für zukünftige Forschung zur Minimierung von Governance-Risiken finden Sie in dieser Notiz: <a href="https://hackmd.io/ @skozin /r17mlW2la"">https://hackmd. io/@skozin/r17mlW2la 37 .

Es ist zu beachten, dass Staker nicht die einzige Kategorie von Protokollnutzern sind; Es gibt auch Knotenbetreiber. Eine mögliche zukünftige Forschungsrichtung ist die Suche nach Möglichkeiten, auch die Effizienz der Fußabstimmung durch Knotenbetreiber zu verbessern, z Erlauben Sie einer Untergruppe von Stakern und Knotenbetreibern, ein Protokoll und einen DAO-Fork zu koordinieren, indem Sie die Anmeldeinformationen für den Validator-Entzug auf einen neuen Vertrag verweisen (derzeit nicht von der Konsensschicht unterstützt).

Eine weitere Richtung zukünftiger Forschung ist die Erforschung der Non-Token- und Hybrid-Governance 2.

Nächste Schritte

Von hier aus müssen mehrere Dinge geschehen, bevor der Entwurf fertiggestellt ist, was zu einem formelleren Lido Improvement Proposal (LIP) führt, der zur DAO-Abstimmung und dem zugehörigen Architecture Decision Record (ADR)-Dokument eingereicht wird:

1. Bewertung der Robustheit des vorgeschlagenen Mechanismus mittels Szenario- und Angriffsmodellierung.
2. Bewertung der Praktikabilität des Mechanismus durch Prototyping des Codes.
3. Sammeln des Community-Feedbacks.

Ziel dieses Threads ist es, Schritt 3 zu erreichen, während die Mitwirkenden des Protokolls an Schritt 1 und 2 arbeiten (beide sind derzeit in Arbeit). Wir freuen uns daher über jedes Feedback!

Es ist wichtig hervorzuheben, dass die duale Governance zwar (meiner Meinung nach) ein wichtiger Schritt zur Reduzierung der Governance-Risiken des Protokolls ist, aber keineswegs der letzte Schritt. Einige der Ideen für weitere Verbesserungen sind im oben verlinkten Dokument zum Mechanismusdesign zu finden, und ich lade alle Interessierten ein, diese und andere mögliche Verbesserungen zu diskutieren, indem sie ein Thema in diesem Forum veröffentlichen.

Haftungsausschluss:

1. Dieser Artikel wurde von [lido] nachgedruckt. Alle Urheberrechte liegen beim Originalautor [skozin]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.