Besonderer Dank geht an Mike Neuder, Justin Drake und andere für ihr Feedback und ihre Rezension. Siehe auch: frühere Beiträge zu ähnlichen Themen von<a href="https://notes.ethereum.org/ @mikeneuder /goldilocks">Mike Neuder, Dankrad Feist und arixon.eth .

Der Status quo von Ethereum kann so beschrieben werden, dass er einen großen Anteil neu entstehender zweistufiger Einsätze umfasst. Mit zweistufigem Abstecken meine ich hier ein Absteckmodell, bei dem es zwei Klassen von Teilnehmern gibt:

1. Knotenbetreiber, die Knoten betreiben und entweder ihre Reputation oder einen festen Betrag ihres eigenen Kapitals als Sicherheit hinterlegen
2. Delegierte, die eine gewisse Menge an ETH hinterlegen, ohne Mindestverpflichtung und ohne strikte Verpflichtung, sich auf andere Weise als mit der Einbringung ihrer Sicherheiten zu beteiligen

Dieses entstehende zweistufige Abstecken entsteht durch die Aktionen eines großen Teils der Staker, die an Absteckpools teilnehmen, die Liquid Staking Tokens (LSTs) anbieten, z. Rocket Pool und Lido.

Der Status quo weist zwei Hauptmängel auf:

• Zentralisierungsrisiko bei Knotenbetreibern. Die Mechanismen zur Auswahl von Knotenbetreibern in bestehenden Absteckpools sind entweder nicht sehr dezentralisiert oder weisen andere Mängel auf.
• Unnötige Belastung der Konsensschicht. Das Ethereum L1 verifiziert etwa 800.000 Signaturen pro Epoche und mit<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality">einzeln Slot-Endgültigkeit, die auf 800.000 pro Slot steigen kann. Das ist eine große Ladung. Darüber hinaus kann das Netzwerk aufgrund des hohen Anteils an liquiden Einsätzen nicht den vollen Nutzen daraus ziehen, diese Belastung zu bewältigen. Wenn das Netzwerk einigermaßen dezentralisiert und sicher gestaltet werden kann, ohne dass sich jeder Staker in jedem Slot abmelden muss, könnten wir uns viel stärker auf diese Lösung stützen und die Anzahl der Signaturen pro Slot auf z. 10.000.

In diesem Beitrag werden mögliche Lösungen für diese beiden Probleme beschrieben. Dabei geht es vor allem um den folgenden Aspekt: Nehmen wir an, wir gehen davon aus, dass das meiste Kapital von Leuten gehalten wird, die nicht bereit sind, persönlich Staking-Knoten in ihrer aktuellen Form zu betreiben, Nachrichten an jedem Slot zu signieren, ihre Einlagen zu sperren und einer Kürzung zu unterziehen . Welche andere Rolle können sie spielen, um einen sinnvollen Beitrag zur Dezentralisierung und Sicherheit des Netzwerks zu leisten?

Wie funktioniert das zweistufige Abstecken heute?

Die beiden derzeit beliebtesten dezentralen Absteckpools, Lido und RocketPool, schaffen beide aufstrebende zweistufige Absteck-Ökosysteme. Im Fall von Lido sind die Stufen:

• Knotenbetreiber: Diese werden durch eine Abstimmung im Lido DAO ausgewählt, also effektiv von LDO-Inhabern
• Delegierte: Personen, die stETH besitzen. stETH wird erstellt, wenn jemand ETH in das Lido-Smart-Contract-System einzahlt, was es Knotenbetreibern ermöglicht, es zu verpfänden (aber, weil die<a href="https://notes.ethereum.org/ @launchpad /withdrawals-faq">Abhebung Anmeldeinformationen sind an eine Smart-Contract-ETH-Adresse gebunden, sie können diese nicht für sich selbst übernehmen)

Im Fall von Rocket Pool sind die Stufen:

• Knotenbetreiber: Jeder kann Knotenbetreiber werden, indem er eine Einzahlung von 8 ETH plus einen Betrag an RPL-Tokens hinterlegt
• Delegierte: Personen, die rETH besitzen. rETH entsteht, wenn jemand ETH in das Smart-Contract-System von Rocket Pool einzahlt, was es Knotenbetreibern ermöglicht, es zu verpfänden (aber nicht für sich selbst zu nehmen).

Die Rolle der Delegierten

In diesen Systemen (oder neuen Systemen, die durch mögliche zukünftige Protokolländerungen ermöglicht werden) ist eine wichtige Frage zu stellen: Welchen Sinn hat es aus der Sicht des Protokolls überhaupt, Delegatoren zu haben?

Um zu sehen, warum die Frage sinnvoll ist, betrachten wir die folgende Welt. Die in diesem aktuellen Beitrag vorgeschlagene Protokolländerung, die Strafen auf 2 ETH zu begrenzen, wird umgesetzt. Als Reaktion darauf reduziert Rocket Pool die Einzahlung des Knotenbetreibers auf 2 ETH. Der Marktanteil von Rocket Pool steigt auf 100 % (nicht nur unter den Stakern, sondern auch unter den ETH-Inhabern: Da rETH risikofrei wird, werden fast alle ETH-Inhaber zu rETH-Inhabern oder Knotenbetreibern).

Nehmen wir an, dass rETH-Inhaber eine Rendite von 3 % erhalten (einschließlich protokollinterner Belohnungen und Prioritätsgebühren + MEV) und Knotenbetreiber eine Rendite von 4 % erhalten. Nehmen wir außerdem an, dass das Gesamtangebot an ETH 100 Millionen beträgt.

So funktioniert die Rechnung. Um die Aufzinsung zu vermeiden, betrachten wir die täglichen Renditen statt die jährlichen, sodass Terme zweiter Ordnung so klein werden, dass sie ignoriert werden können:

Betrachten wir nun eine andere Welt. Rocket Pool existiert nicht. Die Mindesteinzahlung jedes Stakers wird auf 2 ETH reduziert und die Gesamtmenge der gestaketen ETH ist auf 6,25 Mio. begrenzt. Außerdem verringert sich die Rendite des Knotenbetreibers auf 1 %. Lass uns rechnen:

Betrachten wir nun die beiden Situationen aus der Perspektive der Angriffskosten. Im ersten Fall würden sich Angreifer nicht als Delegierende anmelden: Delegierte haben keine Macht, daher macht es keinen Sinn. Daher würden sie ihre gesamte ETH dafür einsetzen, sich als Knotenbetreiber anzumelden. Um auf 1/3 des gesamten Einsatzes zu kommen, müssten sie 2,08 Mio. ETH investieren (was fairerweise immer noch ziemlich viel ist! z. B. siehe<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality#Idea-1-super-committees">dieses Diskussion über Superkomitees, ein Vorschlag zur Skalierung des Einsatzes, der auch die Angriffskosten auf einen ähnlichen Wert gesenkt hätte). Im zweiten Fall würden die Angreifer einfach wetten, und um an ein Drittel des gesamten Einsatzes zu kommen, müssten sie … 2,08 Mio. ETH einsetzen.

Sowohl aus der Perspektive der Einsatzökonomie als auch aus der Perspektive der Angriffskosten ist das Endergebnis in beiden Fällen genau das gleiche. Der Anteil eines Knotenbetreibers am gesamten ETH-Angebot steigt um 0,00256 % pro Tag, und der Anteil eines Nicht-Knotenbetreibers am gesamten ETH-Angebot sinkt um 0,00017 % pro Tag. Die Kosten des Angriffs betragen 2,08 Millionen ETH. Daher fühlt es sich an, als würde die Delegation in diesem Modell zu einer sinnlosen Rube-Goldberg-Maschine werden: Wir könnten genauso gut den Mittelsmann ausschalten und die Einsatzprämien drastisch reduzieren und den gesamten ETH-Einsatz auf 6,25 Mio. begrenzen.

Der Zweck dieses Arguments besteht nicht darin, eine Reduzierung der Einsatzprämien um das Vierfache und eine Begrenzung der gesamten eingesetzten ETH auf 6,25 Millionen zu befürworten. Vielmehr geht es darum, auf eine Schlüsseleigenschaft hinzuweisen, die ein gut funktionierendes Abstecksystem haben sollte: nämlich, dass die Delegierten etwas tun sollten, das wirklich wichtig ist. Darüber hinaus ist es in Ordnung, wenn die Delegierten zu einem großen Teil durch den Druck der Gemeinschaft und den Altruismus motiviert werden, richtig zu handeln. Schließlich ist dies die Hauptkraft, die Menschen heute dazu motiviert, sich auf dezentralisierte, die Sicherheit erhöhende (aber mit höherem Aufwand verbundene) Art und Weise statt auf zentralisierte, die Sicherheit gefährdende (aber mit geringerem Aufwand) Art und Weise zu engagieren.

Wenn Delegierte eine sinnvolle Rolle spielen können, welche Rolle könnte das sein?

Ich sehe zwei Klassen von Antworten:

• Auswahl der Delegierten: Delegierte können auswählen, an welche Knotenbetreiber sie ihren Anteil delegieren. Knotenbetreiber hätten im Konsens ein „Gewicht“, das proportional zum ihnen übertragenen Gesamtanteil ist. Die Delegiertenauswahl existiert bereits heute in begrenzter Form in dem Sinne, dass rETH- oder stETH-Inhaber ihre ETH abheben und zu einem anderen Pool wechseln können, aber die praktische Verfügbarkeit der Delegiertenauswahl könnte erheblich verbessert werden.
• Konsensbeteiligung: Den Delegierten könnte die Möglichkeit eingeräumt werden, eine Rolle im Konsens zu übernehmen, die „leichter“ wäre als der vollständige Einsatz und nicht mit langen Rückzugsfristen und Kürzungsrisiken verbunden wäre, aber dennoch als Kontrolle für Knotenbetreiber fungieren würde. Viele Delegierte würden dies nicht tun wollen und würden die einfachste Schnittstelle von allen bevorzugen, bei der sie einen ERC20 halten und nichts anderes tun, aber einige würden die Option in Anspruch nehmen.

Erweiterung der Auswahlbefugnisse der Delegierten

Es gibt drei Möglichkeiten, die Auswahlbefugnisse der Delegierten zu erweitern:

• Bessere Abstimmungstools innerhalb von Pools
• Mehr Wettbewerb zwischen Pools
• Verankerte Delegation

Abstimmungen innerhalb von Pools gibt es heute nicht mehr wirklich: Im Rocket Pool kann jeder Knotenbetreiber werden, und in Lido stimmen die LDO-Inhaber ab, nicht die ETH-Inhaber. Lido hat einen Vorschlag für eine LDO + stETH-Dual-Governance, die stETH-Inhabern ein Mitspracherecht in dem Sinne geben würde, dass sie ein Gadget aktivieren könnten, das neue Stimmen blockiert und somit verhindert, dass Knotenbetreiber hinzugefügt oder entfernt werden. Allerdings ist dies begrenzt und könnte viel stärker sein.

Heutzutage gibt es einen Pool-übergreifenden Wettbewerb, der jedoch schwach ist. Die größte Herausforderung besteht darin, dass die Staking-Tokens kleinerer Stake-Pools (i) weniger liquide, (ii) schwerer zu vertrauen sind und (iii) von Anwendungen weniger unterstützt werden.

Wir können die ersten beiden Probleme verbessern, indem wir die drastischen Strafen auf einen geringeren Betrag begrenzen, z. 2 oder 4 ETH. Die verbleibende (unzerbrechliche) ETH könnte dann sofort sicher eingezahlt und abgehoben werden, wodurch ein auf dieser ETH basierender LST auch für die kleinsten Pools in beide Richtungen mit der ETH konvertierbar wäre. Wir könnten das dritte Problem verbessern, indem wir einen zentralen Ausgabevertrag für LSTs schaffen – ähnlich wie ERC-4337 und ERC-6900 für Wallets, sodass wir garantieren können, dass alle über diesen Vertrag ausgegebenen Stake-Token sicher sind. Anwendungen (z. B. eine Version von RAI , die abgesteckte ETH unterstützt) könnten dringend dazu ermutigt werden, alle über dieses Register ausgegebenen Abstecktoken zu unterstützen.

Eine verankerte Delegation existiert derzeit nicht im Protokoll, könnte aber möglicherweise eingeführt werden. Es würde eine ähnliche Logik wie die oben genannten Ideen erfordern, jedoch auf Protokollebene implementiert. In diesem Beitrag finden Sie die Vor- und Nachteile der Verankerung von Dingen.

Alle diese Ideen stellen eine Verbesserung gegenüber dem Status quo dar, aber der Nutzen, den sie bieten können, ist begrenzt. Die Governance der Token-Abstimmung ist scheiße, und letztendlich ist jede Form der Delegiertenauswahl ohne Anreize nur eine Art Token-Abstimmung. Dies war von Anfang an der Hauptgrund für mein Unbehagen beim delegierten Nachweis des Einsatzes. Daher erscheint es sinnvoll, auch darüber nachzudenken, stärkere Formen der Konsensbeteiligung zu ermöglichen.

Konsensbeteiligung

Auch ohne Berücksichtigung der aktuellen Probleme rund um das Liquid Staking stößt der aktuelle Ansatz beim Solo-Staking an seine Grenzen. Unter der Annahme der Endgültigkeit eines einzelnen Slots gehen unsere besten Schätzungen von einer Grenze von etwa 100.000 bis 1 Mio. BLS-Signaturen aus, die pro Slot verarbeitet werden könnten, und das setzt eine deutliche Verlängerung der Slot-Zeit voraus. Selbst wenn wir rekursive SNARKs verwenden, um Signaturen zu aggregieren, erfordert die Signaturverantwortung (zu Zwecken der Kürzung), dass für jede Signatur ein Bitfeld der Teilnehmer verfügbar ist. Wenn Ethereum zu einem globalen Netzwerk wird, würde selbst die Verwendung von vollständigem Danksharding zur Speicherung der Bitfelder nicht ausreichen: 16 MB pro Slot würden nur etwa 64 Millionen Staker unterstützen.

Auch aus dieser Perspektive ist es sinnvoll, das Staking in eine Stufe mit höherer Komplexität aufzuteilen, die an jedem Slot beteiligt ist, aber möglicherweise nur 10.000 Teilnehmer hat, und eine Stufe mit niedrigerer Komplexität, die nur gelegentlich zur Teilnahme aufgerufen wird. Die Stufe mit der niedrigeren Komplexität könnte vollständig von der Kürzung ausgenommen sein oder ihren Teilnehmern nach dem Zufallsprinzip die Möglichkeit geben, vorübergehend (d. h. für ein paar Slots) einzahlen und einer Kürzung unterliegen.

In der Praxis könnte dies durcheineErhöhung umgesetzt werden die Validator-Guthabenobergrenze und die spätere Implementierung eines Guthabenschwellenwerts (z. B. 2048 ETH), um zu bestimmen, welche vorhandenen Validatoren in die höhere oder niedrigere Komplexitätsstufe eintreten.

Hier sind ein paar Ideen, wie diese Small-Stake-Rollen funktionieren könnten:

• Für jeden Slot werden 10.000 kleine Spieler nach dem Zufallsprinzip ausgewählt, und sie können den ihrer Meinung nach Leiter dieses Slots unterzeichnen. Eine LMD GHOST-Fork-Choice-Regel wird unter Verwendung der Small-Stakers als Eingabe ausgeführt. Wenn die vom Small-Staker gesteuerte Fork-Auswahl und die vom Knotenbetreiber gesteuerte Fork-Auswahl jemals voneinander abweichen, akzeptiert der Client des Benutzers keinen Block als abgeschlossen und zeigt einen Fehler an. Dies zwingt die Gemeinschaft, in der Situation zu vermitteln.
• Ein Delegierender kann eine Transaktion senden, in der er dem Netzwerk erklärt, dass er online ist und bereit ist, für die nächste Stunde als kleiner Spieler zu fungieren. Damit eine Nachricht (Blockierung oder Bestätigung) von einem Knoten zählt, müssen sich sowohl der Knoten als auch ein zufällig ausgewählter Delegierer abmelden.
• Ein Delegierender kann eine Transaktion senden, in der er dem Netzwerk erklärt, dass er online ist und bereit ist, für die nächste Stunde als kleiner Spieler zu fungieren. In jeder Epoche werden 10 zufällige Delegierte als Anbieter von Aufnahmelisten und 10.000 weitere als Wähler ausgewählt. Diesen werden im Voraus k Slots ausgewählt und ein K-Slot-Fenster zur Veröffentlichung einer Nachricht in der Kette bereitgestellt, die bestätigt, dass sie online sind. Jeder bestätigte ausgewählte Einschlusslistenanbieter kann eine Einschlussliste veröffentlichen, und ein Block ist ungültig, es sei denn, für jede Einschlussliste enthält er entweder (i) die Transaktionen in dieser Einschlussliste oder (ii) er enthält Stimmen von der Hälfte der ausgewählten Wähler, die angeben, dass die Aufnahmeliste nicht verfügbar ist.

Diese Small-Stake-Rollen haben alle gemeinsam, dass sie nicht die aktive Teilnahme an jedem Slot erfordern, nicht kürzbar sind (und daher ein sehr geringes Schlüsselmanagementrisiko aufweisen) und in dem Sinne sehr „leicht“ sind, dass sie nicht einmal eine erfordern Vollständiger Knoten zum Ausführen. Es würde ausreichen, nur die Konsensschicht zu überprüfen. Daher könnten sie über Apps oder Browser-Plugins implementiert werden, die größtenteils passiv sind und einen sehr geringen Rechenaufwand, Hardware-Anforderungen oder technischen Know-how-Anforderungen haben, und das alles, ohne dass technische Fortschritte wie ZK-EVMs überhaupt vorausgesetzt werden müssten.

Diese Small-Stake-Rollen haben auch alle ein gemeinsames Ziel: Sie verhindern, dass eine 51-prozentige Mehrheit der Knotenbetreiber Transaktionszensur betreibt. Das erste und das zweite verhindern auch, dass sich eine Mehrheit auf eine Umkehrung der Endgültigkeit einlässt. Der dritte Schwerpunkt konzentriert sich direkter auf die Zensur, ist jedoch anfälliger für die Möglichkeit, dass sich eine Mehrheit der Knotenbetreiber auch für die Zensur von Bestätigungsnachrichten der Anbieter von Aufnahmelisten entscheidet.

Diese Ideen wurden aus der Perspektive einer im Protokoll implementierten zweistufigen Abstecklösung geschrieben, könnten aber auch als Absteckpoolfunktionen implementiert werden. Hier einige konkrete Umsetzungsideen:

Schlussfolgerungen

Wenn es richtig gemacht wird, könnten Optimierungen am Absteckdesign zwei Fliegen mit einer Klappe lösen:

1. Geben Sie Menschen, die nicht über die Ressourcen oder die Fähigkeit verfügen, heute alleine zu partizipieren, die Möglichkeit, sich an der Absteckung zu beteiligen, die mehr Macht in ihren Händen hält: sowohl (i) die Macht zu wählen, welche Knoten sie unterstützen, als auch (ii) die Macht, sich aktiv daran zu beteiligen Konsens in gewisser Weise, der einfacher ist als der vollständige Einsatz eines Knotenknotens, aber dennoch sinnvoll. Nicht alle Teilnehmer würden eine oder beide Optionen wählen, aber jede, die dies tut, würde die Situation im Vergleich zum Status quo deutlich verbessern.
2. Reduzieren Sie die Anzahl der Signaturen, die die Ethereum-Konsensschicht in jedem Slot verarbeiten muss, selbst in einem Single-Slot-Finalitätsregime, auf eine kleinere Zahl wie etwa ~10.000. Dies würde auch die Dezentralisierung unterstützen, da es für jeden viel einfacher wäre, einen Validierungsknoten zu betreiben.

Für viele dieser Lösungen gibt es verschiedene Abstraktionsebenen, auf denen die Lösung des Problems angesiedelt sein könnte: Befugnisse, die den Benutzern innerhalb eines Absteckpoolprotokolls gewährt werden, Benutzerwahl zwischen Absteckpoolprotokollen und protokollinterne Verankerung. Diese Wahl sollte sorgfältig abgewogen werden, und eine minimale praktikable Verankerung, die sowohl die Komplexität des Protokolls als auch den Grad der Änderung der Protokollökonomie minimiert und gleichzeitig das gewünschte Ziel erreicht, ist im Allgemeinen am besten.

Haftungsausschluss:

1. Dieser Artikel wurde von [ <a href="https://notes.ethereum.org/@vbuterin/staking_2023_10"> notes.ethereum.org] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [notes.ethereum.org]. 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.