Ursprünglicher Autor: Vitalik Buterin

Originalkompilierung: bayemon.eth, ChainCatcher

Besonderer Dank geht an Mike Neuder, Justin Drake und andere für ihr Feedback und ihre Bewertungen. Siehe auch: Frühere Beiträge von Mike Neuder, Dankrad Feist und arixon.eth zu ähnlichen Themen.

Man kann sagen, dass der aktuelle Entwicklungsstand von Ethereum eine große Anzahl von zweistufigen Einsätzen umfasst. Der hier erwähnte zweistufige Einsatz bezieht sich auf ein Einsatzmodell mit zwei Arten von Teilnehmern.

• Node-Betreiber: Betreibt einen Node und nutzt seine eigene Reputation oder einen bestimmten Betrag seines eigenen Kapitals als Sicherheit.

• Agent Delegator: Agenten verpfänden eine bestimmte Menge an Ethereum, ohne Mindestbetrag und ohne zusätzliche Einschränkungen für andere Beteiligungsmethoden außer Sicherheiten.

Dieses entstehende doppelte Staking entsteht durch die starke Beteiligung an Staking-Pools, die Liquidität für Staking-Tokens (LST) bereitstellen. (Rocket Pool und Lido befinden sich beide in diesem Modus).

Das derzeitige Doppelversprechen weist jedoch zwei Mängel auf:

• Zentralisierungsrisiko der Knotenbetreiber: Der aktuelle Auswahlmechanismus der Knotenbetreiber in allen Stake-Pools ist immer noch übermäßig zentralisiert.

• Unnötiger Konsensaufwand: Ethereum L1 muss etwa 800.000 Signaturen pro Epoche verifizieren, was für einen einzelnen Slot eine enorme Belastung darstellt. Da Liquiditäts-Stake-Pools außerdem mehr Mittel erfordern, profitiert das Netzwerk selbst nicht vollständig von dieser Belastung. Wenn das Ethereum-Netzwerk daher eine angemessene Dezentralisierung und Sicherheit erreichen kann, ohne dass jeder Staker entsprechend der Periode unterzeichnen muss, kann die Community eine solche Lösung übernehmen und so die Anzahl der Signaturen pro Periode effektiv reduzieren.

In diesem Artikel wird eine Lösung für die beiden oben genannten Probleme beschrieben. Erstens wird davon ausgegangen, dass der größte Teil des Kapitals von denjenigen gehalten wird, die nicht bereit sind, die Absteckknoten in ihrer aktuellen Form persönlich zu verwalten, die Informationen auf jedem Slot zu unterzeichnen und die Einzahlungen zu sperren und sie an diejenigen umverteilen, deren Mittel gekürzt wurden. Welche Rolle können diese Personen in diesem Fall spielen, um dennoch einen sinnvollen Beitrag zur Dezentralisierung und Sicherheit des Netzwerks zu leisten?

Wie funktionieren Doppelsicherheiten derzeit?

Derzeit sind die beiden beliebtesten Absteckpools Lido und RocketPool. Was Lido betrifft, sind die beiden teilnehmenden Parteien:

• Knotenbetreiber: Von Lido DAO gewählt, was bedeutet, dass er tatsächlich von LDO-Inhabern gewählt wird. Wenn jemand ETH in das Lido-Smart-Contract-System einzahlt, wird stETH erstellt und der Knotenbetreiber kann es in den Pfandpool aufnehmen (aber weil die Das Auszahlungszertifikat ist an die Smart-Contract-Adresse gebunden, der Betreiber kann nicht nach Belieben Geld abheben)

• Agent: Wenn jemand ETH im Lido-Smart-Contract-System einzahlt, wird stETH generiert, und der Knotenbetreiber kann es als Pfand verwenden (da der Auszahlungsgutschein jedoch an die Smart-Contract-Adresse gebunden ist, kann der Betreiber nicht nach Belieben Geld abheben).

Für Rocket Pool sind dies:

• Knotenbetreiber: Jeder kann Knotenbetreiber werden, indem er 8 ETH und eine bestimmte Anzahl an RPL-Tokens einreicht.

• Agent: Wenn jemand ETH in das Smart-Contract-System von Rocket Pool einzahlt, wird rETH generiert, und der Knotenbetreiber kann es als Pfand verwenden (auch weil der Auszahlungsbeleg an die Smart-Contract-Adresse gebunden ist, kann der Betreiber nicht nach Belieben Bargeld abheben). ).

Agenturrolle

In diesen Systemen (oder in neuen Systemen, die durch mögliche zukünftige Protokolländerungen ermöglicht werden) ist eine wichtige Frage zu stellen: Welchen Sinn hat es aus Protokollsicht, einen Agenten zu haben?

Um die tiefgreifende Bedeutung dieses Problems zu verstehen, denken wir zunächst über die im Beitrag erwähnten Protokolländerungen nach, die die Strafe auf 2 ETH begrenzen werden. Rocket Pool wird auch die Pfandsumme der Knotenbetreiber auf 2 ETH reduzieren, und Rocket Pools Der Marktanteil wird auf 100 % steigen / (für Staker und ETH-Inhaber werden fast alle ETH-Inhaber rETH-Inhaber oder Knotenbetreiber, da rETH risikofrei wird).

Unter der Annahme, dass die Rendite der rETH-Inhaber 3 % beträgt (einschließlich protokollinterner Belohnungen und Prioritätsgebühren + MEV), beträgt die Rendite der Knotenbetreiber 4 %. Wir gehen außerdem davon aus, dass das Gesamtangebot an ETH 100 Millionen beträgt.

Die Berechnungsergebnisse sind wie folgt. Um Zinseszinsberechnungen zu vermeiden, berechnen wir die Rendite täglich:

Unter der Annahme, dass Rocket Pool nicht existiert, sinkt der Mindesteinzahlungsbetrag pro Staker auf 2 ETH, die Gesamtliquidität ist auf 6,25 Millionen ETH begrenzt und die Rendite des Knotenbetreibers sinkt auf 1 %. Rechnen wir noch einmal:

Betrachten Sie beide Szenarien aus der Perspektive der Angriffskosten. Im ersten Fall wird sich der Angreifer nicht als Agent registrieren, da der Agent im Wesentlichen kein Recht hat, Geld abzuheben, sodass dies bedeutungslos ist. Daher werden sie die gesamte ETH nutzen, um sich zu engagieren und Knotenbetreiber zu werden. Um 1/3 des gesamten Einsatzbetrags zu erreichen, müssten sie 2,08 Millionen Ethereum einsetzen (was, um fair zu sein, immer noch eine ziemlich große Zahl ist). Im zweiten Fall müsste der Angreifer nur Geld einsetzen, um den zu erreichen Absteckpool Für 1/3 des Gesamtbetrags müssen sie noch 2,08 Millionen Ethereum investieren.

Aus Sicht der Einsatzökonomie und der Angriffskosten ist das Endergebnis in beiden Fällen genau das gleiche. Der Anteil des Gesamtangebots an ETH, das von Knotenbetreibern gehalten wird, steigt täglich um 0,00256 %, und der Anteil des Gesamtangebots an ETH, das von Nicht-Knotenbetreibern gehalten wird, sinkt täglich um 0,00017 %. Die Angriffskosten betragen 2,08 Millionen ETH. Daher scheint der Agent in diesem Modell zu einer bedeutungslosen Rube-Goldberg-Maschine geworden zu sein, und die rationale Gemeinschaft neigt sogar dazu, den Mittelsmann zu entfernen, die Einsatzprämien deutlich zu reduzieren und den Gesamtbetrag der eingesetzten ETH auf 6,25 Millionen zu begrenzen.

Natürlich wird in diesem Artikel nicht dafür plädiert, die Einsatzprämie um das Vierfache zu reduzieren und den Gesamtbetrag des Einsatzes auf 6,25 Millionen zu begrenzen. Der Sinn dieses Artikels besteht vielmehr darin, dass ein Schlüsselmerkmal eines gut funktionierenden Abstecksystems darin besteht, dass die Agenten im gesamten System erhebliche Verantwortung tragen sollten. Darüber hinaus wäre es unerheblich, wenn die Agenten zu einem großen Teil durch den Druck der Gemeinschaft und den Altruismus dazu motiviert wären, die richtigen Maßnahmen zu ergreifen; schließlich ist es das, was den Anreiz für dezentrale, hochsichere Abstecklösungen heute zu einer großen Kraft macht.

Verantwortlichkeiten des Agenten

Wenn Agenten eine sinnvolle Rolle im Abstecksystem spielen könnten, welche Rolle könnte diese Rolle spielen?

Ich denke, es gibt zwei Kategorien von Antworten:

• Agentenauswahl: Agenten können wählen, welchen Knotenbetreibern sie ihre Anteile anvertrauen möchten. Das Gewicht der Knotenbetreiber im Konsensmechanismus ist proportional zum ihnen anvertrauten Gesamtanteil. Derzeit ist der Proxy-Auswahlmechanismus noch begrenzt, d. h. rETH- oder stETH-Inhaber können ihre ETH abheben und zu einem anderen Pool wechseln, aber die tatsächliche Verfügbarkeit der Proxy-Auswahl könnte erheblich verbessert werden.

• Teilnahme am Konsensmechanismus: Delegierte können sich dafür entscheiden, eine bestimmte Rolle im Konsensmechanismus zu spielen. Die Verantwortung ist „leichter“ als bei einem vollständigen Abonnement, und es wird keine lange Austrittsfrist und keine Risikominderung geben, aber sie kann dennoch als Kontrolle und Ausgleich dienen Knotenoperatoren. Wirkung.

Erweitern Sie die Agenturoptionen

Es gibt drei Möglichkeiten, die Entscheidungsbefugnis Ihres Vertreters zu erhöhen:

• Verbesserte Abstimmungstools im Pool

• Erhöhen Sie den Wettbewerb zwischen Pools

• Fixieren Sie das Vertretungsrecht

Derzeit ist die Abstimmung im Pool nicht wirklich praktikabel: Im Rocket Pool kann jeder Knotenbetreiber werden, und in Lido entscheiden die LDO-Inhaber und nicht die ETH-Inhaber über die Abstimmung. Lido hat einen Vorschlag für eine duale Governance von LDO + stETH vorgelegt. Sie können einen Schutzmechanismus aktivieren, um neue Abstimmungen zu verhindern und so zu verhindern, dass Knotenbetreiber hinzugefügt oder entfernt werden. Dies gibt den stETH-Inhabern ein gewisses Mitspracherecht. . Diese Leistung ist jedoch begrenzt und kann stärker sein.

Der Pool-übergreifende Wettbewerb existiert bereits heute, ist jedoch relativ schwach. Die größte Herausforderung besteht darin, dass die Abstecktoken kleinerer Absteckpools weniger liquide sind, schwerer Vertrauen zu gewinnen sind und von Anwendungen weniger unterstützt werden.

Wir können die ersten beiden Probleme verbessern, indem wir den Strafbetrag auf einen kleineren Betrag begrenzen, beispielsweise 2 oder 4 ETH. Die verbleibende ETH kann dann sofort sicher eingezahlt und abgehoben werden, so dass auch bei kleineren Einsatzpools weiterhin bidirektionale Konvertierungen möglich sind. Wir können das dritte Problem lösen, indem wir einen Gesamtausgabevertrag für die Verwaltung von LST erstellen (ähnlich den ERC-4337- und ERC-6900-Verträgen, die für Wallets verwendet werden), sodass wir garantieren können, dass alle durch diesen Vertrag ausgegebenen Stake-Token sicher sind.

Derzeit sieht das Abkommen keine konkreten Vertretungsbefugnisse vor, eine solche Situation dürfte jedoch in Zukunft bestehen. Es wird eine ähnliche Logik wie die obige Idee beinhalten, jedoch auf Protokollebene implementiert. Lesen Sie diesen Artikel über die Vor- und Nachteile der Verfestigung von Dingen.

Diese Ideen stellen Verbesserungen gegenüber dem Status quo dar, bieten jedoch begrenzte Vorteile. Es gibt Probleme mit der Governance der Token-Abstimmung, und letztendlich ist jede Form der Proxy-Auswahl ohne Anreize nur eine Form der Token-Abstimmung; das war schon immer mein Hauptkritikpunkt bei Delegated Proof of Stake. Daher ist es auch sinnvoll, über Möglichkeiten nachzudenken, wie eine stärkere Konsensbeteiligung erreicht werden kann.

Konsensbeteiligung

Selbst wenn man die aktuellen Probleme beim Liquiditätseinsatz außer Acht lässt, gibt es Einschränkungen bei den aktuellen unabhängigen Einsatzmethoden. Geht man von der Endgültigkeit eines einzelnen Slots aus, kann jeder Slot idealerweise etwa 100.000 bis 1.000.000 BLS-Signaturen verarbeiten. Selbst wenn wir rekursive SNARKs zum Aggregieren von Signaturen verwenden, muss für die Rückverfolgbarkeit der Signatur jeder Signatur das Bitfeld eines Teilnehmers zugewiesen werden. Wenn Ethereum zu einem globalen Netzwerk wird, werden vollständig dezentrale Speicherbitfelder nicht ausreichen: 16 MB in jedem Steckplatz können nur etwa 64 Millionen Staker unterstützen.

Aus dieser Perspektive ist es sinnvoll, das Abstecken in reduzierbare Ebenen mit höherer Komplexität und Ebenen mit niedrigerer Komplexität zu unterteilen, wobei jeder Slot wirksam wird, aber nur 10.000 Teilnehmer haben darf oder Ebenen mit niedrigerer Komplexität nur gelegentlich zur Teilnahme aufgerufen werden. Ebenen mit geringerer Komplexität könnten vollständig von Ermäßigungen ausgenommen werden, oder Teilnehmer könnten nach dem Zufallsprinzip die Möglichkeit erhalten, innerhalb weniger Slots einzuzahlen und von Ermäßigungen betroffen zu sein.

In der Praxis kann dies erreicht werden, indem die Obergrenze des Validator-Guthabens und anschließend die Guthabenschwelle (z. B. 2048 ETH) erhöht wird, um zu bestimmen, welche vorhandenen Validatoren in höhere oder niedrigere Komplexitätsstufen wechseln.

Hier sind einige Vorschläge, wie diese kleinen Einsatzrollen funktionieren könnten:

• Für jeden Slot werden 10.000 kleine Spieler nach dem Zufallsprinzip ausgewählt und können unterschreiben, was ihrer Meinung nach für den Slot repräsentativ ist. Führt die LMD GHOST-Fork-Choice-Regel mit kleinen Stakern als Eingabe aus. Wenn es Unstimmigkeiten zwischen der von kleinen Stakern gesteuerten Fork-Auswahl und der von Node-Betreibern gesteuerten Fork-Auswahl gibt, akzeptiert der Client des Benutzers keinen Block als endgültige Bestätigung und zeigt einen Fehler an. Dies zwingt die Gemeinschaft, einzugreifen, um die Situation zu lösen.

• Agenten können Transaktionen senden, in denen sie dem Netzwerk mitteilen, dass sie online sind und bereit sind, in der nächsten Stunde als kleine Staker zu fungieren. Die Berechnung der vom Knoten gesendeten Nachricht (Block oder Beweis) erfordert, dass sowohl der Knoten als auch ein zufällig ausgewählter Agent die Bestätigungsinformationen des Knotens signieren.

• Agenten können Transaktionen senden, in denen sie dem Netzwerk mitteilen, dass sie online sind und bereit sind, in der nächsten Stunde als kleine Staker zu fungieren. In jeder Epoche werden 10 zufällige Agenten als Anbieter von Aufnahmelisten und 10.000 weitere Agenten als Wähler ausgewählt. Diese werden vor dem K-Slot ausgewählt und erhalten ein K-Slot-Fenster, um eine Nachricht in der Kette zu veröffentlichen, die ihre Online-Präsenz bestätigt. Jeder bestätigte ausgewählte Anbieter von Einschlusslisten kann eine Einschlussliste veröffentlichen, es sei denn, für jede Einschlussliste sind entweder die in dieser Einschlussliste enthaltenen Transaktionen enthalten oder eine Abstimmung von im Allgemeinen 1 ausgewählten Wählerschaft gibt an, dass die Einschlussliste nicht verfügbar ist. Andernfalls wird die Sperrung in Betracht gezogen ungültig.

Diesen kleinen Absteckknoten ist gemeinsam, dass sie nicht an jedem Slot aktiv teilnehmen müssen oder sogar nur leichte Knoten benötigen, um die gesamte Arbeit zu erledigen. Daher erfordert die Knotenbereitstellung lediglich eine Überprüfung der Konsensschicht, die Knotenbetreiber durch Anwendungen oder Browser-Plug-Ins erreichen können, die größtenteils passiv sind und keinen Rechenaufwand, Hardwareanforderungen oder technisches Know-how erfordern. Sehr niedrig und nicht einmal erfordern fortschrittliche Technologie wie ZK-EVM.

Diese „kleinen Akteure“ haben auch ein gemeinsames Ziel: zu verhindern, dass die 51-prozentige Mehrheit der Knotenbetreiber Transaktionszensur betreibt. Das erste und das zweite verhindern auch, dass die Mehrheit an der Finalitätsreduzierung teilnimmt. Beim dritten geht es direkter um die Zensur, sie ist jedoch anfälliger für die Entscheidungen der Mehrheitsknotenbetreiber.

Diese Ideen werden aus der Perspektive einer im Protokoll implementierten Double-Stake-Lösung geschrieben, können aber auch als Funktion von Stake-Pools implementiert werden. Hier einige konkrete Umsetzungsideen:

• Aus Protokollsicht kann jeder Verifizierer zwei Pfandschlüssel festlegen: einen kontinuierlichen Pfandschlüssel P und eine gebundene Ethereum-Adresse, die aufgerufen werden kann, und einen schnellen Pfandschlüssel Q ausgeben. Die Verfolgung der Signaturinformationen des Knotens für die Fork-Auswahl wird durch P dargestellt, und die signierten Informationen werden durch Q dargestellt. Wenn die PQ-Speicherergebnisse inkonsistent sind, wird die endgültige Bestimmung eines Blocks nicht akzeptiert und der Liquiditätspool wird nach dem Zufallsprinzip verantwortlich sein Auswahl von Vertretern.

• Das Protokoll kann weitgehend unverändert bleiben, der öffentliche Schlüssel des Validators für diesen Zeitraum wird jedoch auf P+Q gesetzt. Beachten Sie, dass bei Reduzierungen zwei reduzierbare Nachrichten möglicherweise unterschiedliche Q-Tasten haben, aber dieselbe P-Taste haben; das Reduktionsdesign muss diesen Fall behandeln.

• Q-Schlüssel können im Protokoll nur zum Signieren und Überprüfen von Einschlusslisten in Blöcken verwendet werden. In diesem Fall kann Q ein intelligenter Vertrag und kein einzelner Schlüssel sein, sodass der Einsatzpool damit eine komplexere Abstimmungslogik implementieren kann, indem er eine inklusive Liste von einem zufällig ausgewählten Anbieter oder genug akzeptiert. Zeigt an, dass die enthaltende Liste nicht für Abstimmungen verfügbar ist .

abschließend

Bei richtiger Umsetzung kann die Feinabstimmung des Proof-of-Stake-Designs zwei Probleme auf einen Schlag lösen:

• Bietet denjenigen, die heute nicht über die Ressourcen oder die Fähigkeit verfügen, einen unabhängigen Proof of Stake durchzuführen, die Möglichkeit, am Proof of Stake teilzunehmen und dadurch mehr Macht in ihren Händen zu behalten: einschließlich (i) der Macht zu wählen, welche Knoten unterstützt werden sollen und (ii) Beteiligen Sie sich aktiv am Konsens auf eine Weise, die einfacher, aber dennoch sinnvoll ist, als einen vollständigen Proof-of-Stake-Knoten zu betreiben. Nicht alle Teilnehmer werden sich für eine oder beide dieser Optionen entscheiden, aber jeder Teilnehmer, der sich für eine oder beide dieser Optionen entscheidet, wird eine deutliche Verbesserung gegenüber dem Status Quo erleben.

• Reduzieren Sie die Anzahl der Signaturen, die die Ethereum-Konsensschicht in jedem Slot verarbeiten muss, selbst unter einem Single-Slot-Finalitätsregime, auf eine kleinere Zahl wie etwa 10.000. Dies wird auch zur Dezentralisierung beitragen und es für jeden einfacher machen, Validierungsknoten zu betreiben.

Für diese Lösungen können Lösungen für das Problem auf verschiedenen Abstraktionsebenen gefunden werden: Berechtigungen, die Benutzern innerhalb von Proof-of-Stake-Protokollen gewährt werden, Benutzerauswahl zwischen Proof-of-Stake-Protokollen und Festlegung innerhalb der Protokolle. Diese Wahl sollte sorgfältig abgewogen werden, und oft ist es besser, ein minimal realisierbares Setup zu wählen, um die Komplexität des Protokolls und das Ausmaß der Änderungen an der Protokollökonomie zu minimieren und gleichzeitig die gewünschten Ziele zu erreichen.