Autor: Vitalik Buterin
Zusammengestellt von: Deng Tong, Golden Finance
Besonderer Dank geht an Justin Drake, Hsiao-wei Wang, @antonttc und Francesco für ihr Feedback und ihre Bewertungen.
Ursprünglich bezog sich „Merge“ auf das wichtigste Ereignis in der Geschichte des Ethereum-Protokolls seit seiner Einführung: den lang erwarteten und hart erkämpften Übergang vom Proof-of-Work zum Proof-of-Stake. Heute ist Ethereum seit fast zwei Jahren ein stabiles und funktionierendes Proof-of-Stake-System, das in Bezug auf Stabilität, Leistung und Vermeidung von Zentralisierungsrisiken äußerst gute Leistungen erbracht hat. Es gibt jedoch noch einige wichtige Bereiche, in denen der Nachweis des Einsatzes verbessert werden muss.
Meine Roadmap für 2023 gliedert sie in mehrere Teile: Verbesserungen technischer Funktionen wie Stabilität, Leistung und Zugänglichkeit für kleinere Validatoren sowie wirtschaftliche Änderungen zur Bewältigung von Zentralisierungsrisiken. Ersterer übernahm den Titel „Merge“, während Letzterer Teil von „The Scourge“ wurde.
Dieser Artikel konzentriert sich auf den „Zusammenführen“-Teil: Was kann am technischen Design des Proof of Stake noch verbessert werden, und welche Möglichkeiten gibt es, diese Verbesserungen zu erreichen?
Dies ist keine erschöpfende Liste von Verbesserungen, die am Proof of Stake vorgenommen werden könnten; es handelt sich vielmehr um eine Liste von Ideen, die aktiv in Betracht gezogen werden.
Endgültigkeit eines einzelnen Slots und Demokratisierung des Einsatzes
Welches Problem lösen wir?
Heutzutage dauert es 2-3 Epochen (~15 Minuten), um einen Block abzuschließen, und es sind 32 ETH erforderlich, um ein Staker zu werden. Dabei handelte es sich ursprünglich um einen Kompromiss, um eine Balance zwischen drei Zielen zu finden:
Maximieren Sie die Anzahl der Validatoren, die am Einsatz teilnehmen können (dies bedeutet direkt, die für den Einsatz erforderliche Mindest-ETH zu minimieren).
Minimieren Sie die Fertigstellungszeit
Minimieren Sie den Overhead laufender Knoten
Diese drei Ziele stehen im Widerspruch zueinander: Um wirtschaftliche Endgültigkeit zu erreichen (d. h. ein Angreifer müsste eine große Menge ETH zerstören, um einen finalisierten Block wiederherzustellen), müsste jeder Validator zwei Nachrichten pro Finalisierung signieren. Wenn Sie also viele Validatoren haben, wird es entweder lange dauern, alle Signaturen zu verarbeiten, oder Sie benötigen sehr leistungsstarke Knoten, um alle Signaturen gleichzeitig zu verarbeiten.
Beachten Sie, dass dies alles von einem Hauptziel von Ethereum abhängt: sicherzustellen, dass selbst ein erfolgreicher Angriff dem Angreifer hohe Kosten verursacht. Das ist es, was mit dem Begriff „wirtschaftliche Endgültigkeit“ gemeint ist. Wenn wir dieses Ziel nicht haben, können wir dieses Problem lösen, indem wir zufällig ein Komitee auswählen (wie es Algorand tut), um jeden Slot fertigzustellen. Das Problem bei diesem Ansatz besteht jedoch darin, dass ein Angreifer, wenn er tatsächlich 51 % der Validatoren kontrolliert, mit sehr geringen Kosten angreifen kann (Wiederherstellung finalisierter Blöcke, Zensur oder Verzögerung der Finalisierung): Nur ein Teil der Knoten des Komitees kann als teilnehmend erkannt werden in Angriffen und bestraft, entweder durch Hiebe oder eine Handvoll weicher Gabeln. Dies bedeutet, dass ein Angreifer die Kette viele Male wiederholt angreifen kann. Wenn wir also wirtschaftliche Endgültigkeit wollen, wird ein einfacher ausschussbasierter Ansatz nicht funktionieren, und auf den ersten Blick brauchen wir eine vollständige Gruppe von Validatoren, um daran teilzunehmen.
Im Idealfall wollen wir die wirtschaftliche Endgültigkeit bewahren und gleichzeitig den Status quo auf zwei Arten verbessern:
Schließen Sie Blöcke innerhalb eines Zeitfensters ab (behalten Sie idealerweise die aktuelle Länge von 12 Sekunden bei oder reduzieren Sie sie sogar) statt innerhalb von 15 Minuten
Validatoren erlauben, mit 1 ETH zu setzen (von 32 ETH auf 1 ETH reduziert)
Das erste Ziel wird durch zwei Ziele belegt, die beide als „Anpassung der Eigenschaften von Ethereum an die von (zentralisierteren) leistungsorientierten L1-Ketten“ angesehen werden können.
Erstens stellt es sicher, dass alle Ethereum-Benutzer von einem höheren Sicherheitsniveau profitieren, das durch den Finalisierungsmechanismus erreicht wird. Heutzutage genießen die meisten Benutzer diese Garantie nicht, da sie nicht bereit sind, 15 Minuten zu warten. Mit einem Single-Slot-Abschlussmechanismus können Benutzer die Transaktion fast sofort nach Bestätigung der Transaktion abgeschlossen sehen. Zweitens vereinfacht es das Protokoll und die umgebende Infrastruktur, wenn Benutzer und Anwendungen sich keine Sorgen über die Möglichkeit eines Ketten-Rollbacks machen müssen (mit Ausnahme des relativ seltenen Falles von Inaktivitätslecks).
Das zweite Ziel beruht auf dem Wunsch, einzelne Stakeholder zu unterstützen. Eine Umfrage nach der anderen hat wiederholt gezeigt, dass das Minimum von 32 ETH der Hauptgrund dafür ist, dass mehr Menschen davon abgehalten werden, sich allein zu engagieren. Eine Senkung des Mindestbetrags auf 1 ETH würde dieses Problem soweit lösen, dass andere Probleme zum Hauptfaktor werden, der den individuellen Einsatz begrenzt.
Es gibt eine Herausforderung: Die Ziele einer schnelleren Endgültigkeit und eines stärker demokratisierten Einsatzes stehen beide im Widerspruch zum Ziel der Minimierung des Overheads. Tatsächlich ist diese Tatsache der einzige Grund, warum wir den Single-Slot-Determinismus überhaupt nicht übernehmen. Aktuelle Forschungsergebnisse deuten jedoch auf einige mögliche Lösungen für dieses Problem hin.
Was ist das und wie funktioniert es?
Bei der Single-Slot-Finalität wird ein Konsensalgorithmus verwendet, der Blöcke innerhalb eines Slots finalisiert. An sich ist das kein unerreichbares Ziel: Viele Algorithmen (wie etwa der Tendermint-Konsens) erreichen dies bereits mit optimalen Eigenschaften. Eine wünschenswerte, einzigartige Eigenschaft von Ethereum, die Tendermint nicht unterstützt, ist der Inaktivitätsverlust, der es der Kette ermöglicht, weiter zu funktionieren und sich schließlich zu erholen, selbst wenn mehr als ein Drittel der Validatoren offline sind. Glücklicherweise wurde dieser Wunsch bereits erfüllt: Es gibt bereits Vorschläge, den Konsens im Tendermint-Stil zu ändern, um Inaktivitätslecks zu berücksichtigen.
Führender Vorschlag zur Endgültigkeit einzelner Slots
Der schwierigste Teil des Problems besteht darin, herauszufinden, wie die Single-Slot-Finalität mit sehr hohen Validatorzahlen funktioniert, ohne dass ein extrem hoher Node-Operator-Overhead entsteht. Hierfür gibt es mehrere führende Lösungen:
Option 1: Brute Force – Arbeiten Sie an einem besseren Protokoll zur Signaturaggregation, möglicherweise unter Verwendung von ZK-SNARKs, das es uns im Wesentlichen ermöglichen würde, Signaturen von Millionen von Validatoren pro Slot zu verarbeiten.
Horn, eines der vorgeschlagenen Designs für bessere Aggregationsprotokolle.
Option 2: Orbit-Komitee – Ein neuer Mechanismus, der es einem zufällig ausgewählten mittelgroßen Komitee ermöglicht, für die Fertigstellung der Kette verantwortlich zu sein, jedoch auf eine Weise, die die von uns gesuchten Angriffskosteneigenschaften beibehält.
Eine Möglichkeit, über Orbit SSF nachzudenken, besteht darin, dass es einen Raum von Kompromissoptionen eröffnet, der von x=0 (Komitee im Algorand-Stil, keine wirtschaftliche Endgültigkeit) bis x=1 (aktuelle Situation von Ethereum) reicht und einen Punkt in der Mitte eröffnet , Ethereum Es gibt immer noch genug wirtschaftliche Endgültigkeit, um extreme Sicherheit zu erreichen, aber gleichzeitig gewinnen wir den Effizienzvorteil, dass nur eine mittelgroße Zufallsstichprobe von Validatoren für die Teilnahme an jeder Epoche erforderlich ist.
Orbit nutzt die bereits bestehende Heterogenität der Validator-Einzahlungsgrößen, um so viel wirtschaftliche Endgültigkeit wie möglich zu erreichen und gleichzeitig kleinen Validatoren eine relevante Rolle zuzuweisen. Darüber hinaus nutzt Orbit eine langsame Ausschussrotation, um ein hohes Maß an Überlappung zwischen benachbarten Quoren zu gewährleisten und so sicherzustellen, dass seine wirtschaftliche Endgültigkeit weiterhin für die Grenzen der Ausschussrotation gilt.
Option 3: Zweistufiger Einsatz – ein Mechanismus, bei dem die Spieler in zwei Kategorien eingeteilt werden, eine mit höheren Einzahlungsanforderungen und die andere mit niedrigeren Einzahlungsanforderungen. Nur Stufen mit höheren Einzahlungsanforderungen sind direkt an der Bereitstellung wirtschaftlicher Endgültigkeit beteiligt. Es gibt verschiedene Vorschläge, welche Rechte und Pflichten genau für Stufen mit geringeren Einzahlungsanforderungen gelten würden (siehe beispielsweise den Beitrag zum Rainbow Staking). Zu den gängigen Ideen gehören:
Das Recht, Interessen an übergeordnete Anteilseigner zu delegieren
Ein zufällig ausgewählter Stakeholder auf niedrigerer Ebene wird zertifiziert und muss jeden Block abschließen
Recht zur Erstellung einer Einschlussliste
Welche Bezüge gibt es zur bestehenden Forschung?
Wege zur Single-Slot-Finalität (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality
Konkreter Vorschlag für das Single-Slot-Finalitätsprotokoll von Ethereum (2023): https://eprint.iacr.org/2023/280
Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
Weitere Analyse der Mechanik im Orbit-Stil: https://notes.ethereum.org/@anderselowsson/Vorbit_SSF
Horn, Signature Aggregation Protocol (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
Signaturenzusammenführung für einen groß angelegten Konsens (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
Von Khovratovich et al. vorgeschlagenes Signaturaggregationsprotokoll: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
STARK-basierte Signaturaggregation (2022): https://hackmd.io/@vbuterin/stark_aggregation
Regenbogen-Einsatz: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683
Was bleibt noch zu tun? Welche Kompromisse gibt es?
Es gibt vier mögliche Hauptpfade (wir können auch Hybridpfade wählen):
den Status Quo beibehalten
Umlaufbahn SSF
Leistungsstarkes SSF
SSF mit zwei Einsatzebenen
(1) bedeutet, dass man keine Arbeit verrichtet und das Abstecken unverändert beibehält, aber dies würde die Sicherheitserfahrung und die Zentralisierungseigenschaften von Ethereum schlechter machen, als es sonst der Fall wäre.
(2) Vermeiden Sie „Hightech“ und lösen Sie das Problem, indem Sie die Protokollannahmen geschickt überdenken: Wir haben die Anforderung der „wirtschaftlichen Endgültigkeit“ gelockert, sodass wir hohe Angriffskosten verlangen, akzeptieren jedoch, dass die Angriffskosten möglicherweise zehnmal niedriger sind als jetzt (Zum Beispiel betragen die Kosten des Angriffs 2,5 Milliarden US-Dollar, nicht 25 Milliarden US-Dollar). Es wird allgemein davon ausgegangen, dass Ethereum heute über weitaus mehr wirtschaftliche Endgültigkeit verfügt, als es sein müsste, und dass seine größten Sicherheitsrisiken woanders liegen, sodass dies wohl ein akzeptables Opfer ist.
Der Hauptaufwand besteht darin, zu überprüfen, ob der Orbit-Mechanismus sicher ist und die von uns gewünschten Eigenschaften aufweist, und ihn dann vollständig zu formalisieren und zu implementieren. Darüber hinaus ermöglicht EIP-7251 (Increase Maximum Valid Balance) eine freiwillige Konsolidierung des Validator-Guthabens, was den Aufwand für die Kettenvalidierung sofort reduziert und als effektive Anfangsphase für die Einführung von Orbit dient.
(3) Cleveres Umdenken vermeiden und stattdessen Probleme mit Hochtechnologie brutal erzwingen. Dazu ist das Sammeln einer großen Anzahl von Unterschriften (über 1 Million) in sehr kurzer Zeit (5–10 Sekunden) erforderlich.
(4) Vermeidet cleveres Umdenken und Hochtechnologie, schafft aber ein zweistufiges Abstecksystem, das immer noch Risiken einer Zentralisierung birgt. Das Risiko hängt stark von den spezifischen Rechten ab, die die unteren Einsatzstufen erwerben. Zum Beispiel:
Wenn Staker auf niedrigerer Ebene ihre Zertifizierungsrechte an Staker auf höherer Ebene delegieren müssen, wird die Delegation möglicherweise zentralisiert, und am Ende haben wir zwei stark zentralisierte Einsatzebenen.
Wenn für die Genehmigung jedes Blocks eine zufällige Stichprobe niedrigerer Ebenen erforderlich ist, kann ein Angreifer eine kleine Menge ETH ausgeben, um die Endgültigkeit zu verhindern.
Wenn Staker auf niedriger Ebene nur Einschlusslisten erstellen können, kann die Proof-Schicht immer noch zentralisiert sein. An diesem Punkt kann ein 51-prozentiger Angriff auf die Proof-Schicht die Einschlussliste selbst zensieren.
Es können mehrere Strategien kombiniert werden, wie zum Beispiel:
(1 + 2): Fügt Orbit hinzu, ohne Einzelplatz-Finalität durchzuführen.
(1 + 3): Verwenden Sie Brute-Force-Techniken, um die Mindesteinzahlungsgröße zu reduzieren, ohne die Endgültigkeit eines einzelnen Slots zu erzwingen. Die erforderliche Polymerisationsmenge ist 64-mal geringer als im reinen (3)-Fall, sodass das Problem einfacher wird.
(2 + 3): Führen Sie Orbit SSF mit konservativen Parametern aus (z. B. 128k Validator Committee statt 8k oder 32k) und nutzen Sie Brute-Force-Techniken, um es supereffizient zu machen.
(1 + 4): Fügt Regenbogen-Einsatz hinzu, ohne die Endgültigkeit eines einzelnen Slots zu erzwingen.
Wie interagiert es mit anderen Teilen der Roadmap?
Neben anderen Vorteilen verringert die Single-Slot-Finalität das Risiko bestimmter Arten von Multiblock-MEV-Angriffen. Darüber hinaus müssen in einer Single-Slot-Finalitätswelt das Design der Prover-Proposer-Trennung und andere protokollinterne Blockproduktionspipelines anders gestaltet werden.
Die Schwäche von Brute-Force-Strategien besteht darin, dass sie es schwieriger machen, die Slot-Zeit zu verkürzen.
Wahl eines einzigen geheimen Anführers
Welches Problem versuchen wir zu lösen?
Heute ist im Voraus bekannt, welcher Validator den nächsten Block vorschlagen wird. Dadurch entsteht eine Sicherheitslücke: Ein Angreifer könnte das Netzwerk überwachen, identifizieren, welche Validatoren welchen IP-Adressen entsprechen, und einen DoS-Angriff auf die Validatoren starten, wenn diese im Begriff sind, eine Blockierung vorzuschlagen.
Was ist das? Wie funktioniert es?
Der beste Weg, das DoS-Problem zu lösen, besteht darin, die Informationen darüber zu verbergen, welcher Validator den nächsten Block generiert, zumindest bis der Block tatsächlich generiert wird. Beachten Sie, dass dies einfach ist, wenn wir die „Einzel“-Anforderung entfernen: Eine Lösung wäre, den nächsten Block von jedem erstellen zu lassen, Randao jedoch weniger als 2256/N offenzulegen. Im Durchschnitt erfüllt nur ein Validator diese Anforderung – manchmal sind es aber auch zwei oder mehr, manchmal sogar null. Das Erfordernis der „Vertraulichkeit“ mit dem Erfordernis der „Einzigartigkeit“ zu verbinden, war schon immer ein schwieriges Problem.
Das Single-Secret-Leader-Wahlprotokoll löst dieses Problem, indem es einige kryptografische Techniken verwendet, um für jeden Validator eine „blinde“ Validator-ID zu erstellen, und dann vielen Antragstellern die Möglichkeit gibt, den Pool blinder IDs zu mischen und neu zu verblinden (dies ähnelt How hybride Netzwerke funktionieren). In jeder Periode wird eine zufällige Blind-ID ausgewählt. Nur der Besitzer der Blind-ID kann einen gültigen Nachweis generieren, um einen Block vorzuschlagen, aber niemand weiß, welchem Validator die Blind-ID entspricht.
Whisk SSLE-Protokoll
Welche Links gibt es zu bestehenden Forschungsergebnissen?
Dan Bonehs Artikel (2020): https://eprint.iacr.org/2020/025.pdf
Whisk (ein praktischer Vorschlag für Ethereum, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
Single-Secret-Leader-Wahl-Tag auf ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election
Vereinfachtes SSLE mit Ringsignaturen: https://ethresear.ch/t/simplified-ssle/12315
Was bleibt noch zu tun? Welche Kompromisse gibt es?
Eigentlich müssen wir nur noch ein Protokoll finden und implementieren, das einfach genug ist, damit wir es problemlos im Mainnet implementieren können. Wir nehmen Ethereum als recht einfaches Protokoll sehr ernst und wollen nicht, dass die Komplexität noch weiter zunimmt. Die SSLE-Implementierungen, die wir gesehen haben, fügten Hunderte Zeilen kanonischen Codes hinzu und führten neue Annahmen in der komplexen Verschlüsselung ein. Die Suche nach einer ausreichend effizienten Implementierung von quantenresistentem SSLE ist ebenfalls ein offenes Problem.
Es kann irgendwann passieren, dass die „marginale zusätzliche Komplexität“ von SSLE nur dann abnimmt, wenn wir aus anderen Gründen (z. B. Staatsbäume, ZK-EVM) einen allgemeinen Zero-Knowledge-Proof-Mechanismus auf L1 des Ethereum-Protokolls auf ein ausreichend niedriges Niveau einführen.
Eine andere Möglichkeit besteht darin, SSLE überhaupt zu ignorieren und stattdessen Abhilfemaßnahmen außerhalb des Protokolls (z. B. auf der P2P-Ebene) zu nutzen, um DoS-Probleme zu beheben.
Wie interagiert es mit anderen Teilen der Roadmap?
Wenn wir einen APS-Mechanismus (Prover-Proposer Separation) wie Ausführungstickets hinzufügen, ist für die Ausführung von Blöcken (d. h. Blöcke, die Ethereum-Transaktionen enthalten) kein SSLE erforderlich, da wir uns auf spezialisierte Blockersteller verlassen können. Für Konsensblöcke (d. h. Blöcke, die Protokollnachrichten enthalten (z. B. Beweise, möglicherweise Teile von Listen usw.)) werden wir jedoch weiterhin von SSLE profitieren.
Schnellere Transaktionsbestätigung
Welches Problem lösen wir?
Es lohnt sich, die Transaktionsbestätigungszeiten von Ethereum von 12 Sekunden auf 4 Sekunden weiter zu verkürzen. Dadurch wird die Benutzererfahrung auf L1- und Aggregationsbasis erheblich verbessert und gleichzeitig das Defi-Protokoll effizienter. Dies erleichtert auch die Dezentralisierung von L2, da es einer großen Anzahl von L2-Anwendungen ermöglicht, auf aggregationsbasierter Ordnung zu arbeiten, wodurch die Notwendigkeit für L2 verringert wird, eine eigene ausschussbasierte dezentrale Ordnung aufzubauen.
Was ist das? Wie funktioniert es?
Hier gibt es grob zwei Techniken:
Reduzieren Sie die Slot-Zeit, beispielsweise auf 8 Sekunden oder 4 Sekunden. Dies bedeutet nicht unbedingt 4 Sekunden Endgültigkeit: Endgültigkeit erfordert im Wesentlichen drei Kommunikationsrunden, sodass wir jede Kommunikationsrunde zu einem separaten Block machen könnten, mit mindestens einer vorläufigen Bestätigung nach 4 Sekunden.
Antragsteller können während des Slots Vorabbestätigungen ausstellen. Im Extremfall könnten Antragsteller die Transaktionen, die sie sehen, in Echtzeit in ihre Blöcke integrieren und sofort eine Vorbestätigungsnachricht für jede Transaktion veröffentlichen („Meine erste Transaktion war 0x1234…“, „I Die zweite Transaktion ist 0×5678.“ ..“). Die Situation, in der ein Antragsteller zwei widersprüchliche Bestätigungen ausstellt, kann auf zwei Arten gehandhabt werden: (i) indem der Antragsteller gekürzt wird oder (ii) indem Prüfer eingesetzt werden, um darüber abzustimmen, welche Bestätigung früher ist.
Welche Links gibt es zu bestehenden Forschungsergebnissen?
Basierend auf Vorbestätigungen: https://ethresear.ch/t/based-preconfirmations/17353
Protocol Enforced Proposer Commitments (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
Gestaffelte Zeiträume auf parallelen Ketten (Ideen für niedrige Latenz im Jahr 2018): https://ethresear.ch/t/staggered-periods/1793
Was bleibt noch zu tun und welche Kompromisse gibt es?
Es ist unklar, wie praktisch die reduzierte Slot-Zeit sein wird. Auch heute noch haben Spieler in vielen Teilen der Welt Schwierigkeiten, schnell genug Beweise zu erhalten. Der Versuch einer Slot-Zeit von 4 Sekunden birgt das Risiko, dass der Validatorsatz konzentriert wird und es aufgrund der Latenz unpraktisch wird, ein Validator außerhalb einiger privilegierter Regionen zu werden.
Die Schwäche der Methode zur Vorbestätigung des Antragstellers besteht darin, dass sie die durchschnittliche Aufnahmezeit für den Fall erheblich verbessert, nicht jedoch die Aufnahmezeit für den schlimmsten Fall: Wenn der aktuelle Antragsteller gut läuft, wird Ihre Transaktion in 0,5 Sekunden vorab bestätigt, während dies (im Durchschnitt) nicht der Fall ist. Es dauert ca. 6 Sekunden, um aufgenommen zu werden, aber wenn der aktuelle Antragsteller offline ist oder keine gute Leistung erbringt, müssen Sie immer noch volle 12 Sekunden warten, bevor der nächste Slot beginnen und einen neuen Antragsteller bereitstellen kann.
Darüber hinaus bleibt die Frage offen, wie Anreize für die Vorbestätigung geschaffen werden können. Antragsteller haben einen Anreiz, ihre Optionen so lange wie möglich zu maximieren. Wenn der Prüfer die Rechtzeitigkeit der Vorabbestätigung unterzeichnet, kann der Absender der Transaktion einen Teil der Gebühr von der unmittelbaren Vorbestätigung abhängig machen. Dies stellt jedoch eine zusätzliche Belastung für den Prüfer dar und kann es für den Prüfer schwieriger machen, dies auch weiterhin zu tun als neutrales „Dummes Rohr“ fungieren.
Wenn wir dies andererseits nicht versuchen und die Finalisierungszeit bei 12 Sekunden (oder länger) halten, wird das Ökosystem mehr Wert auf den Vorbestätigungsmechanismus legen, der von Schicht 2 umgesetzt wird, und Interaktionen über Schicht 2 hinweg werden dauern Längere Zeit.
Wie interagiert es mit anderen Teilen der Roadmap?
Die auf dem Antragsteller basierende Vorbestätigung basiert tatsächlich auf APS-Mechanismen (Prover-Proposer Separation) wie z. B. Ausführungstickets. Andernfalls kann der Druck, Vorbestätigungen in Echtzeit bereitzustellen, zu einem zu zentralisierten Druck auf reguläre Validatoren führen.
Andere Forschungsbereiche
51 % Angriffswiederherstellung
Es wird allgemein angenommen, dass im Falle eines 51-Prozent-Angriffs (einschließlich Angriffen, die kryptografisch nicht nachgewiesen werden können, wie z. B. Zensur) die Community zusammenkommt, um einen Soft Fork für Minderheiten zu implementieren, der sicherstellt, dass die Guten gewinnen und die Bösen gewinnen aufgrund von Inaktivität durchgesickert oder eingeschränkt. Allerdings ist dieses Maß an übermäßiger Abhängigkeit von der sozialen Schicht wohl ungesund. Wir können versuchen, die Abhängigkeit von der sozialen Ebene zu verringern und den Wiederherstellungsprozess so automatisiert wie möglich zu gestalten.
Eine vollständige Automatisierung ist nicht möglich, da dies sonst als >50 % fehlertoleranter Konsensalgorithmus gelten würde und wir bereits die (sehr strengen) mathematisch beweisbaren Einschränkungen solcher Algorithmen kennen. Aber wir können eine teilweise Automatisierung erreichen: Beispielsweise kann ein Kunde automatisch die Annahme einer Kette als endgültig ablehnen oder sich sogar weigern, sie als Leiter einer Fork-Auswahl zu akzeptieren, wenn der Kunde eine Transaktion überprüft hat, die er schon lange gesehen hat genug. Ein wichtiges Ziel besteht darin, sicherzustellen, dass die Bösewichte im Angriff nicht zumindest einen schnellen Sieg erringen.
Erhöhen Sie die Quorumsschwelle
Heute wird ein Block endgültig, wenn 67 % der Staker ihn unterstützen. Manche halten das für zu radikal. In der gesamten Geschichte von Ethereum gab es nur einen (sehr kurzen) endgültigen Misserfolg. Wenn dieser Prozentsatz auf 80 % erhöht würde, wäre die Anzahl der erweiterten Nicht-Endgültigkeitsepochen relativ gering, Ethereum würde jedoch an Sicherheit gewinnen: Insbesondere würden viele der umstritteneren Situationen zu einer vorübergehenden Aufhebung der Endgültigkeit führen. Dies scheint viel gesünder zu sein, als wenn die „falsche Seite“ sofort gewinnt, unabhängig davon, ob die falsche Seite der Angreifer ist oder ob auf der Client-Seite ein Fehler vorliegt.
Damit ist auch die Frage „Was bringt ein separater Staker?“ beantwortet. Heutzutage setzt die Mehrheit der Staker ihre Einsätze bereits über Pools ab, und es erscheint unwahrscheinlich, dass ein einzelner Staker bis zu 51 % der eingesetzten ETH erhält. Es scheint jedoch möglich, einen Einzelspieler dazu zu bringen, eine Minderheit zu erreichen, die die Mehrheit blockiert, wenn wir uns anstrengen, insbesondere wenn die Mehrheit 80 % erreicht (also nur 21 % erforderlich sind, um die Mehrheit zu blockieren). Solange einzelne Staker nicht an einem 51-Prozent-Angriff teilnehmen (sei es eine Umkehrung der Endgültigkeit oder eine Überprüfung), wird dieser Angriff keinen „sauberen Sieg“ erringen, und einzelne Staker werden aktiv bei der Organisation von Soft Forks für Minderheiten mithelfen.
Quantenwiderstand
Metaculus geht derzeit davon aus, dass Quantencomputer, wenn auch mit großer Fehlertoleranz, wahrscheinlich irgendwann in den 2030er Jahren damit beginnen werden, die Kryptographie zu durchbrechen:
Auch Quantencomputing-Experten wie Scott Aaronson nehmen seit Kurzem die Möglichkeit ernster, dass Quantencomputer mittelfristig tatsächlich funktionieren werden. Dies hat Auswirkungen auf die gesamte Ethereum-Roadmap: Es bedeutet, dass jeder Teil des Ethereum-Protokolls, der derzeit auf elliptischen Kurven basiert, eine Art Hash-basierte oder andere quantenresistente Alternative benötigt. Dies bedeutet insbesondere, dass wir nicht davon ausgehen können, dass wir uns jemals auf die überlegenen Eigenschaften der BLS-Aggregation verlassen können, um Signaturen großer Mengen von Validatoren zu verarbeiten. Dies rechtfertigt den Konservatismus bei den Leistungsannahmen des Proof-of-Stake-Designs und ist ein Grund, aggressiver quantenresistente Alternativen zu entwickeln.
