Vitaliks neueste Forschung: Wie müssen sich LSDFi-Protokolle und Liquidität verändern, um die Dezentralisierung zu erhöhen und Konsensüberlastung zu reduzieren?

Dieser Artikel konzentriert sich hauptsächlich auf die aktuellen zentralisierten Risiken der Node Operator und die unnötige Konsensbelastung in LSDFi-Protokollen und Liquiditätspools.

Autor:Vitalik Buterin

Übersetzung: bayemon.eth, ChainCatcher

Der aktuelle Entwicklungsstand von Ethereum beinhaltet eine große Menge an zweistufigem Staking (two-tiered staking). Mit zweistufigem Staking ist ein Staking-Modell gemeint, bei dem es zwei Arten von Teilnehmern gibt.

• Node Operator: Betreibt einen Node und hinterlegt einen bestimmten Betrag seines eigenen Kapitals als Sicherheit, gestützt auf seinen Ruf.
• Delegator: Delegatoren staken eine bestimmte Menge an Ethereum, es gibt keinen Mindestbetrag und keine weiteren Einschränkungen bezüglich anderer Beteiligungsformen außer der Sicherheit.

Dieses neuartige zweistufige Staking entsteht durch zahlreiche Staking-Pools, die Liquid Staking Token (LST) anbieten. (Rocket Pool und Lido nutzen beide dieses Modell.)

Das aktuelle zweistufige Staking weist jedoch zwei Mängel auf:

• Zentralisierungsrisiko der Node Operator: Die Auswahlmechanismen der Node Operator in allen Staking-Pools sind derzeit immer noch übermäßig zentralisiert.
• Unnötige Konsensbelastung: Auf Ethereum L1 müssen pro Epoch etwa 800.000 Signaturen überprüft werden, was eine enorme Belastung für einen einzelnen Slot darstellt. Darüber hinaus profitiert das Netzwerk selbst nicht ausreichend von dieser Belastung, da Liquid Staking Pools eine größere Kapitalmenge benötigen. Wenn das Ethereum-Netzwerk also eine angemessene Dezentralisierung und Sicherheit erreichen kann, ohne dass jeder Staker pro Slot signieren muss, könnte die Community solche Lösungen übernehmen und so die Anzahl der Signaturen pro Slot effektiv reduzieren.

In diesem Artikel werden Lösungen für die oben genannten beiden Probleme beschrieben. Angenommen, der Großteil des Kapitals liegt bei Personen, die nicht bereit sind, Nodes in der aktuellen Form selbst zu betreiben, pro Slot zu signieren, Einlagen zu sperren und diese an Slasher weiterzugeben. Welche Rolle könnten diese Personen dann spielen, um dennoch einen sinnvollen Beitrag zur Dezentralisierung und Sicherheit des Netzwerks zu leisten?

Wie funktioniert das aktuelle zweistufige Staking?

Die derzeit beliebtesten beiden Staking-Pools sind Lido und RocketPool. Bei Lido gibt es zwei Parteien:

• Node Operator: Wird durch Abstimmung der Lido DAO gewählt, was bedeutet, dass tatsächlich die LDO-Inhaber entscheiden. Wenn jemand ETH in das Lido Smart Contract System einzahlt, wird stETH erstellt, das der Node Operator in den Staking-Pool einbringen kann (aber da das Auszahlungszertifikat an die Smart Contract-Adresse gebunden ist, kann der Operator nicht frei auszahlen).
• Delegator: Wenn jemand ETH in das Lido Smart Contract System einzahlt, wird stETH generiert, das der Node Operator als Staking verwenden kann (aber da das Auszahlungszertifikat an die Smart Contract-Adresse gebunden ist, kann der Operator nicht frei auszahlen).

Bei Rocket Pool sieht es folgendermaßen aus:

• Node Operator: Jeder kann Node Operator werden, indem er 8 ETH und eine bestimmte Menge RPL-Token hinterlegt.
• Delegator: Wenn jemand ETH in das Rocket Pool Smart Contract System einzahlt, wird rETH generiert, das der Node Operator als Staking verwenden kann (auch hier kann der Operator aufgrund der Bindung des Auszahlungszertifikats an die Smart Contract-Adresse nicht frei auszahlen).

Die Rolle des Delegators

In diesen Systemen (oder in neuen Systemen, die durch zukünftige Protokolländerungen ermöglicht werden), stellt sich eine Schlüsselfrage: Welchen Sinn hat die Einrichtung von Delegatoren aus Sicht des Protokolls?

Um die tiefere Bedeutung dieser Frage zu verstehen, überlegen wir zunächst: Für die im Beitrag erwähnte Protokolländerung, bei der die Slashing-Strafe auf 2 ETH begrenzt wird, würde Rocket Pool auch den Staking-Betrag der Node Operator auf 2 ETH senken, und der Marktanteil von Rocket Pool würde auf 100% steigen (für Staker und ETH-Inhaber würde rETH risikofrei, sodass praktisch alle ETH-Inhaber rETH-Inhaber oder Node Operator werden würden).

Angenommen, die Rendite für rETH-Inhaber beträgt 3% (einschließlich Protokollbelohnungen und Prioritätsgebühren + MEV), die Rendite für Node Operator beträgt 4%. Wir nehmen außerdem an, dass das gesamte ETH-Angebot 100 Millionen beträgt.

Das Ergebnis der Berechnung ist wie folgt. Um Zinseszinsen zu vermeiden, berechnen wir die Rendite pro Tag:

Nehmen wir nun an, Rocket Pool existiert nicht, der Mindesteinzahlungsbetrag für jeden Staker sinkt auf 2 ETH, das Liquiditätsvolumen ist auf 6,25 Millionen ETH begrenzt, und die Rendite für Node Operator sinkt auf 1%. Berechnen wir erneut:

Betrachten wir die beiden Fälle aus Sicht der Angriffskosten. Im ersten Fall wird ein Angreifer sich nicht als Delegator registrieren, da Delegatoren im Wesentlichen kein Auszahlungsrecht haben, was keinen Sinn ergibt. Daher würden sie ihr gesamtes ETH zum Staking verwenden und Node Operator werden. Um ein Drittel des gesamten Staking-Volumens zu erreichen, müssten sie 2,08 Millionen ETH einsetzen (fairerweise ist das immer noch eine ziemlich große Zahl). Im zweiten Fall müsste der Angreifer nur Kapital einsetzen, um ein Drittel des gesamten Staking-Pools zu erreichen, was ebenfalls 2,08 Millionen ETH erfordert.

Aus Sicht der Staking-Ökonomie und der Angriffskosten ist das Endergebnis in beiden Fällen identisch. Der Anteil des von Node Operator gehaltenen ETH am Gesamtangebot steigt täglich um 0,00256%, der Anteil des von Nicht-Node Operator gehaltenen ETH sinkt täglich um 0,00017%. Die Angriffskosten betragen 2,08 Millionen ETH. In diesem Modell erscheint der Delegator wie eine sinnlose Rube-Goldberg-Maschine, und eine rationale Community würde sogar dazu neigen, den Mittelsmann zu entfernen, die Staking-Belohnungen drastisch zu senken und das gesamte gestakte ETH auf 6,25 Millionen zu begrenzen.

Natürlich plädiert dieser Artikel nicht dafür, die Staking-Belohnungen um das Vierfache zu senken und das Staking-Volumen auf 6,25 Millionen festzulegen. Vielmehr ist die Ansicht, dass ein gut funktionierendes Staking-System ein zentrales Merkmal haben sollte: Delegatoren sollten eine wichtige Verantwortung im gesamten System übernehmen. Und selbst wenn Delegatoren in hohem Maße durch sozialen Druck und Altruismus motiviert werden, das Richtige zu tun, ist das in Ordnung; schließlich ist dies heute die Hauptkraft, die Menschen dazu bewegt, dezentralisierte und hochsichere Staking-Lösungen zu fördern.

Die Verantwortung der Delegatoren

Wenn Delegatoren im Staking-System eine sinnvolle Rolle spielen können, wie könnte diese aussehen?

Ich denke, es gibt zwei Arten von Antworten:

• Delegatorenauswahl: Delegatoren können wählen, welchen Node Operator sie ihre Interessen anvertrauen. Das "Gewicht" eines Node Operators im Konsensmechanismus ist proportional zur Gesamtmenge des ihm anvertrauten Stakings. Derzeit ist der Auswahlmechanismus für Delegatoren noch begrenzt, d.h. rETH- oder stETH-Inhaber können ihr ETH abziehen und in einen anderen Pool wechseln, aber die tatsächliche Verfügbarkeit der Delegatorenauswahl kann erheblich verbessert werden.
• Konsensbeteiligung: Delegatoren können wählen, im Konsensmechanismus eine bestimmte Rolle zu spielen, mit weniger Verantwortung als beim vollständigen Betrieb eines Staking-Nodes, ohne lange Ausstiegsfristen und Slashing-Risiko, aber dennoch als Gegengewicht zu den Node Operator.

Stärkung der Delegatorenauswahl

Es gibt drei Möglichkeiten, die Auswahlmöglichkeiten der Delegatoren zu stärken:

• Verbesserung der Abstimmungstools innerhalb des Pools
• Erhöhung des Wettbewerbs zwischen den Pools
• Verfestigung der Delegatorrechte

Derzeit ist die Abstimmung innerhalb des Pools praktisch nicht umsetzbar: Bei Rocket Pool kann jeder Node Operator werden, bei Lido entscheiden die LDO-Inhaber und nicht die ETH-Inhaber. Lido hat einen Vorschlag für eine doppelte Governance mit LDO + stETH gemacht, bei dem ein Schutzmechanismus aktiviert werden kann, um neue Abstimmungen zu verhindern und so das Hinzufügen oder Entfernen von Node Operator zu blockieren, was stETH-Inhabern ein gewisses Mitspracherecht gibt. Dennoch ist diese Macht begrenzt und könnte gestärkt werden.

Der Wettbewerb zwischen den Pools existiert heute bereits, ist aber relativ schwach. Die Hauptprobleme sind, dass kleinere Staking-Pools weniger liquide Staking-Token haben, weniger Vertrauen genießen und weniger von Anwendungen unterstützt werden.

Wir können die ersten beiden Probleme verbessern, indem wir die Slashing-Strafe auf einen kleinen Betrag, z.B. 2 oder 4 ETH, begrenzen. Der verbleibende ETH kann dann sicher eingezahlt und sofort abgezogen werden, sodass der bidirektionale Austausch auch für kleinere Staking-Pools möglich bleibt. Wir können das dritte Problem durch die Schaffung eines Gesamt-Emissionsvertrags verbessern, der für die Verwaltung von LST dient (ähnlich wie ERC-4337 und ERC-6900 für Wallets), sodass wir garantieren können, dass alle über diesen Vertrag ausgegebenen Staking-Token sicher sind.

Derzeit gibt es im Protokoll noch keine verfestigten Delegatorrechte, aber solche Szenarien könnten in Zukunft möglich sein. Dies würde eine ähnliche Logik wie die oben genannten Ideen beinhalten, jedoch auf Protokollebene. Für Vor- und Nachteile der Verfestigung siehe diesen Artikel.

Diese Ideen sind allesamt Verbesserungen des Status quo, aber die Vorteile, die sie bieten können, sind begrenzt. Token-basierte Abstimmungsgovernance hat Probleme, und letztlich ist jede Form der nicht-inzentivierten Delegatorenauswahl nur eine Form der Token-Abstimmung; das war schon immer mein Hauptkritikpunkt an Delegated Proof of Stake. Daher ist es auch wertvoll, über eine stärkere Konsensbeteiligung nachzudenken.

Konsensbeteiligung

Selbst ohne die aktuellen Probleme des Liquid Staking gibt es auch bei der derzeitigen Methode des unabhängigen Stakings Einschränkungen. Angenommen, wir verwenden Single-Slot Finality, könnten im Idealfall pro Slot etwa 100.000 bis 1.000.000 BLS-Signaturen verarbeitet werden. Selbst wenn wir rekursive SNARKs zur Aggregation von Signaturen verwenden, muss jeder Signatur ein Teilnehmer-Bitfeld zugeordnet werden, um die Nachverfolgbarkeit zu gewährleisten. Wenn Ethereum ein globales Netzwerk wird, reicht die vollständig dezentralisierte Speicherung des Bitfelds nicht aus: 16 MB pro Slot unterstützen nur etwa 64 Millionen Staker.

Aus dieser Perspektive ist es sinnvoll, das Staking in eine komplexere, slashing-fähige Schicht und eine weniger komplexe Schicht zu unterteilen. Die komplexe Schicht wirkt sich auf jeden Slot aus, hat aber möglicherweise nur 10.000 Teilnehmer, während die weniger komplexe Schicht nur gelegentlich zur Teilnahme aufgerufen wird. Die weniger komplexe Schicht kann völlig slashing-frei sein oder Teilnehmern zufällig die Möglichkeit geben, innerhalb weniger Slots einzuzahlen und slashing-fähig zu werden.

In der Praxis kann dies erreicht werden, indem das maximale Validator-Guthaben erhöht und anschließend der Guthabenschwellenwert (z.B. 2048 ETH) angehoben wird, um zu bestimmen, welche Validatoren in die komplexere oder weniger komplexe Schicht gelangen.

Hier sind einige Vorschläge, wie diese Kleinstaker-Rollen funktionieren könnten:

• Pro Slot werden 10.000 Kleinstaker zufällig ausgewählt, die das signieren können, was sie für den repräsentativen Inhalt des Slots halten. Die LMD GHOST Fork-Choice-Regel wird mit den Kleinstakern als Input ausgeführt. Wenn die von Kleinstakern getriebene Fork-Choice und die von Node Operator getriebene Fork-Choice deutlich auseinandergehen, akzeptiert der Client des Nutzers keinen Block als final und zeigt einen Fehler an. Dies zwingt die Community, die Situation zu lösen.
• Delegatoren können Transaktionen senden, um dem Netzwerk mitzuteilen, dass sie online sind und in der nächsten Stunde als Kleinstaker fungieren möchten. Die von Nodes gesendeten Nachrichten (Blöcke oder Beweise) müssen sowohl vom Node als auch von einem zufällig ausgewählten Delegator signiert werden, um die Bestätigung des Nodes zu gewährleisten.
• Delegatoren können Transaktionen senden, um dem Netzwerk mitzuteilen, dass sie online sind und in der nächsten Stunde als Kleinstaker fungieren möchten. In jeder Epoche werden 10 zufällige Delegatoren als Inclusion List Provider ausgewählt und 10.000 weitere Delegatoren als Wähler. Diese werden vor dem k-Slot ausgewählt und haben ein k-Slot-Fenster, um eine On-Chain-Bestätigung ihrer Online-Präsenz zu veröffentlichen. Jeder bestätigte Inclusion List Provider kann eine Inclusion List veröffentlichen. Für jede Inclusion List muss entweder eine Transaktion aus dieser Liste enthalten sein oder es muss eine ausreichende Anzahl von Wählerstimmen geben, die anzeigen, dass die Inclusion List nicht verfügbar ist, andernfalls wird der Block als ungültig betrachtet.

Diese kleinen Staking-Nodes haben gemeinsam, dass sie nicht aktiv an jedem Slot teilnehmen müssen, sondern ihre Aufgaben sogar mit einem Light Node erledigen können. Daher muss die Node-Bereitstellung nur die Konsensschicht validieren, und Node Operator können dies über Apps oder Browser-Plugins tun, die meist passiv sind und nur geringe Anforderungen an Rechenleistung, Hardware oder technisches Know-how stellen – fortschrittliche Technologien wie ZK-EVM sind nicht erforderlich.

Diese "kleinen Rollen" verfolgen ebenfalls ein gemeinsames Ziel: Sie sollen verhindern, dass 51% der Node Operator Transaktionen zensieren. Die erste und zweite Methode können auch verhindern, dass eine Mehrheit die Finalität rückgängig macht. Die dritte Methode konzentriert sich direkter auf die Zensur, ist aber anfälliger für die Auswahl durch die Mehrheit der Node Operator.

Diese Ideen wurden aus der Perspektive geschrieben, zweistufige Staking-Lösungen im Protokoll zu implementieren, können aber auch als Funktionalitäten von Staking-Pools umgesetzt werden. Hier sind einige konkrete Implementierungsideen:

1. Aus Protokollsicht kann jeder Validator zwei Staking-Schlüssel festlegen: Einen permanenten Staking-Schlüssel P sowie eine gebundene, aufrufbare Ethereum-Adresse, und einen schnellen Staking-Schlüssel Q. Die von Nodes für die Fork-Choice signierten Informationen werden mit P verfolgt, die signierten Informationen mit Q. Wenn die Ergebnisse von PQ nicht übereinstimmen, wird keine Blockfinalität akzeptiert, und der Liquiditätspool ist für die zufällige Auswahl der Vertreter verantwortlich.
2. Das Protokoll kann im Wesentlichen unverändert bleiben, aber der öffentliche Schlüssel des Validators für diesen Zeitraum wird auf P+Q gesetzt. Beachten Sie, dass für Slashing zwei slashing-fähige Nachrichten unterschiedliche Q-Schlüssel, aber denselben P-Schlüssel haben können; das Slashing-Design muss dies berücksichtigen.
3. Der Q-Schlüssel kann im Protokoll nur zum Signieren und Verifizieren von Inclusion Lists in Blöcken verwendet werden. In diesem Fall kann Q ein Smart Contract und kein einzelner Schlüssel sein, sodass Staking-Pools damit komplexere Abstimmungslogiken implementieren können, z.B. Inclusion Lists von zufällig ausgewählten Providern oder genügend viele Stimmen, die anzeigen, dass eine Inclusion List nicht verfügbar ist, zu akzeptieren.

Fazit

Wenn sie richtig umgesetzt werden, können Feinabstimmungen am Proof-of-Stake-Design zwei Probleme auf einmal lösen:

• Sie bieten denen, die heute nicht die Ressourcen oder Fähigkeiten für unabhängiges Proof of Stake haben, die Möglichkeit, am Proof of Stake teilzunehmen und so mehr Macht in ihren Händen zu behalten: einschließlich (i) der Möglichkeit, zu wählen, welche Nodes sie unterstützen, und (ii) auf eine leichtere, aber dennoch sinnvolle Weise aktiv am Konsens teilzunehmen, als es beim vollständigen Betrieb eines Proof-of-Stake-Nodes der Fall wäre. Nicht alle Teilnehmer werden eine oder beide Optionen wählen, aber jeder, der eine oder beide Optionen wählt, wird im Vergleich zum Status quo erheblich profitieren.
• Sie reduzieren die Anzahl der Signaturen, die die Ethereum-Konsensschicht pro Slot verarbeiten muss, selbst im Single-Slot-Finality-Modell, auf etwa 10.000 oder eine ähnlich kleine Zahl. Dies wird auch die Dezentralisierung fördern und es jedem erleichtern, einen Validator zu betreiben.

Für diese Lösungen können auf verschiedenen Abstraktionsebenen Ansätze zur Problemlösung gefunden werden: Die Rechte, die Nutzern innerhalb des Proof-of-Stake-Protokolls gewährt werden, die Auswahlmöglichkeiten der Nutzer zwischen verschiedenen Proof-of-Stake-Protokollen und die Einrichtung im Protokoll selbst. Diese Auswahl sollte sorgfältig abgewogen werden, und in der Regel ist es am besten, die minimal praktikable Einrichtung zu wählen, um die Komplexität des Protokolls und die Auswirkungen auf die Protokollökonomie so gering wie möglich zu halten, während die gewünschten Ziele dennoch erreicht werden.

Besonderer Dank gilt Mike Neuder, Justin Drake und anderen für ihr Feedback und ihre Überprüfung. Siehe auch: Frühere Artikel von Mike Neuder, Dankrad Feist und arixon.eth zu ähnlichen Themen.