Geschrieben von: Vitalik Buterin

Zusammengestellt von: bayemon.eth, ChainCatcher

Man kann sagen, dass der aktuelle Entwicklungsstand von Ethereum eine große Anzahl von zweistufigen Einsätzen umfasst. Das hier erwähnte zweistufige Einsatzmodell 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. (Sowohl Rocket Pool als auch Lido haben dieses Modell).

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 also das Ethereum-Netzwerk eine angemessene Dezentralisierung und Sicherheit erreichen kann, ohne dass jeder Staker entsprechend der Periode unterschreiben muss, dann 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 unterschreiben 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 in den Pfandpool aufgenommen werden (aber weil der 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 das Abhebungszertifikat 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 das Abhebungszertifikat an die Smart-Contract-Adresse gebunden ist, kann der Betreiber nicht nach Belieben Geld 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 2ETH begrenzen und auch die Höhe der Zusagen der Knotenbetreiber an 2ETH und den Marktanteil von Rocket Pool verringern werden 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 einer Rendite von 3 % für rETH-Inhaber (einschließlich protokollinterner Belohnungen und Prioritätsgebühren + MEV) und einer Rendite von 4 % für Knotenbetreiber. 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 die Mindesteinzahlung auf 2 ETH pro Staker, 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 ihre gesamte ETH einsetzen und Knotenbetreiber 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 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 gesamten ETH-Angebots, das von Knotenbetreibern gehalten wird, steigt jeden Tag um 0,00256 %, und der Anteil des gesamten ETH-Angebots, das von Nicht-Knotenbetreibern gehalten wird, sinkt jeden Tag um 0,00017 %. Die Kosten des Angriffs betragen 2,08 Millionen ETH. Daher scheint der Agent in diesem Modell eine bedeutungslose Rube-Goldberg-Maschine zu sein, und die rationale Gemeinschaft neigt sogar dazu, den Mittelsmann auszuschalten, 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 empfohlen, die Einsatzprämie um das Vierfache zu reduzieren und den Gesamteinsatzbetrag 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 motiviert wären, die richtigen Maßnahmen zu ergreifen, denn das ist es, was den Anreiz für dezentrale, hochsichere Abstecklösungen heute so stark 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 Agentenauswahlmechanismus 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 Agentenauswahl könnte erheblich verbessert werden.

• Teilnahme am Konsensmechanismus: Die Delegierten können sich dafür entscheiden, eine bestimmte Rolle im Konsensmechanismus zu spielen. Die Verantwortung ist „leichter“ als die Vollmitgliedschaft, und es wird keine lange Ausstiegsfrist und keine Risikominderung geben, aber sie kann dennoch als Kontrolle und Ausgleich dienen für Knotenoperatoren.

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 doppelte Governance von LDO + stETH vorgelegt. Sie können einen Schutzmechanismus aktivieren, um zu verhindern, dass Knotenbetreiber hinzugefügt oder entfernt werden. 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, könnte jeder Slot idealerweise etwa 100.000 bis 1.000.000 BLS-Signaturen verarbeiten. Selbst wenn wir rekursive SNARKs verwenden, um Signaturen zu aggregieren, müssen wir für die Rückverfolgbarkeit der Signaturen jeder Signatur ein Teilnehmerbitfeld zuweisen. Wenn Ethereum zu einem globalen Netzwerk wird, wird auch eine vollständige Dezentralisierung des Speicher-Bitfelds nicht ausreichen: 16 MB in jedem Slot können nur etwa 64 Millionen Staker unterstützen.

Aus dieser Perspektive ist es sinnvoll, den Einsatz in reduzierbare Ebenen mit höherer Komplexität und Ebenen mit niedrigerer Komplexität aufzuteilen, wobei jeder Slot aktiv ist, aber nur 10.000 Teilnehmer haben darf. Ebenen mit niedrigerer Komplexität werden nur gelegentlich zur Teilnahme aufgerufen. 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 diesen Slot repräsentiert. Führen Sie die LMD GHOST-Fork-Auswahlregel mit kleinen Stakern als Eingabe aus. Wenn es eine Meinungsverschiedenheit 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 k-Slots 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, mit der Ausnahme, dass für jede Einschlussliste entweder die Transaktionen in dieser Einschlussliste enthalten sind oder eine Abstimmung einer allgemeinen 1 ausgewählten Wählerschaft darauf hinweist, dass die Einschlussliste nicht verfügbar ist, andernfalls wird die Sperre ausgeführt als ungültig angesehen werden.

Gemeinsam ist diesen kleinen Staking-Knoten, dass sie nicht an jedem Slot aktiv teilnehmen müssen, noch nicht einmal nur Light-Knoten, um die ganze 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, keine Hardwareanforderungen oder kein technisches Know-how mit sich bringen erfordern fortschrittliche Technologie wie ZK-EVM.

Auch diese „kleineren Akteure“ haben ein gemeinsames Ziel: die Transaktionszensur durch die 51-prozentige Mehrheit der Node-Betreiber zu verhindern. 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:

1. Aus Protokollsicht kann jeder Validator 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 Finalisierung eines Blocks nicht akzeptiert und der Liquiditätspool ist für die zufällige Auswahl verantwortlich ein Vertreter.

2. 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 das Reduktionsdesign muss diesen Fall behandeln.

3. Q-Tasten 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 erfahren.

• 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.

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