Redner: Vitalik Buterin, Gründer von Ethereum. Zusammengestellt von: 0xxz, Golden Finance EthCC7 fand kürzlich in Brüssel statt. Der Veranstalter lud Vitalik, Gründer von Ethereum, ein, eine Grundsatzrede zu halten. Es ist erwähnenswert, dass 2024 der 10. Jahrestag von Ethereums IC0 ist. Nach Vitaliks Rede machten die drei Hauptgründer von Ethereum, Vitalik Buterin, Joseph Lubin und Gavin Wood, noch einmal gemeinsam ein Gruppenfoto, um diesen Anlass zu feiern. Dieser Artikel ist die Grundsatzrede, die Vitalik, der Gründer von Ethereum, kürzlich bei EthCC7 gehalten hat und die von Golden Finance 0xxz zusammengestellt wurde. Vortragsthema Stärkung L1: Optimierung von Ethereum, um eine äußerst zuverlässige, vertrauenswürdige und erlaubnislose Layer-2-Basisschicht zu werden

Ethereum-Vision-Spektrum
Ich denke, es gibt ein Spektrum möglicher unterschiedlicher Arbeitsteilungen hinsichtlich der Rolle, die die Ethereum-Basisschicht in den nächsten fünf bis zehn Jahren im Ökosystem spielen könnte. Man kann es sich als Spektrum von links nach rechts vorstellen. Auf der linken Seite des Spektrums versucht es grundsätzlich, eine sehr minimalistische Basisschicht zu sein, die im Grunde nur als Beweisvalidator für alle L2 fungiert. Bietet möglicherweise auch die Möglichkeit, ETH zwischen verschiedenen L2s zu übertragen. Aber ansonsten ist es im Grunde alles. Auf der rechten Seite des Spektrums gibt es grundsätzlich eine Neuausrichtung auf dApps, die hauptsächlich auf L1 laufen, wobei L2 nur für einige sehr spezifische und leistungsstarke Transaktionen verwendet wird. In der Mitte des Spektrums gibt es einige interessante Optionen. Ich habe Ethereum als Basisschicht von L2 an zweiter Stelle von links angegeben. Ich habe eine extreme Version ganz links eingefügt. Die extreme Version besteht darin, dass wir den Ausführungs-Client-Teil von Ethereum vollständig aufgeben, nur den Konsens-Teil beibehalten und einige wissensfreie Validatoren hinzufügen, wodurch im Grunde die gesamte Ausführungsebene in ein Rollup umgewandelt wird. Ich meine, die extremsten Optionen befinden sich auf der linken Seite, und auf der rechten Seite könnte es sich um eine Basisschicht handeln, aber versuchen Sie auch, L2 mehr Funktionalität zu geben. Eine Idee in diese Richtung besteht darin, die Swap-Zeit von Ethereum, die derzeit 12 Sekunden beträgt, möglicherweise auf 2-4 Sekunden zu reduzieren. Der Zweck besteht darin, basierte Rollups als primäre Methode des L2-Betriebs möglich zu machen. Wenn Sie also möchten, dass L2 ein erstklassiges Benutzererlebnis bietet, benötigen Sie eine eigene Vorvalidierung, also entweder einen zentralen Sortierer oder Ihren eigenen dezentralen Sortierer. Wenn sich ihr Konsens beschleunigt, muss L2 dies nicht mehr tun. Wenn Sie die Skalierbarkeit von L1 wirklich erhöhen möchten, wird auch L2 weniger benötigt. Das ist also ein Spektrum. Im Moment konzentriere ich mich hauptsächlich auf die Version zwei von links, aber die Dinge, die ich hier vorschlage, gelten auch für andere Visionen, und die Ratschläge hier behindern andere Visionen nicht wirklich. Das ist meiner Meinung nach sehr wichtig. Der Robustheitsvorteil von Ethereum
Ein großer Vorteil von Ethereum besteht darin, dass es über ein großes und relativ dezentralisiertes Staking-Ökosystem verfügt.

Die linke Seite des Bildes oben ist das Hash-Rate-Diagramm aller Bitcoin-Mining-Pools und die rechte Seite ist das Ethereum-Staker-Diagramm. Die Verteilung der Rechenleistung von Bitcoin ist derzeit nicht sehr gut. Zwei Mining-Pools machen zusammen mehr als 50 % der Rechenleistung aus, und vier Mining-Pools kommen auf mehr als 75 %. Und die Situation von Ethereum ist tatsächlich besser, als die Grafik zeigt, denn der zweite große Teil des grauen Teils ist tatsächlich nicht identifiziert, was bedeutet, dass es sich möglicherweise um eine Kombination vieler Menschen handelt und es möglicherweise sogar viele unabhängige Staker gibt. Der blaue Teil, Lido, ist eigentlich eine seltsame, lose koordinierte Struktur, die aus 37 verschiedenen Validatoren besteht. Ethereum verfügt also tatsächlich über ein relativ dezentralisiertes Staking-Ökosystem, das recht gut funktioniert. Wir können in diesem Bereich viele Verbesserungen vornehmen, aber ich denke, es ist immer noch sinnvoll, dies anzuerkennen. Das ist eine der einzigartigen Stärken, auf die wir wirklich aufbauen können.

Zu den Robustheitsvorteilen von Ethereum gehören außerdem: ● Ein Multi-Client-Ökosystem: Es gibt Geth-Ausführungs-Clients und Nicht-Geth-Ausführungs-Clients, und der Anteil der Nicht-Geth-Ausführungs-Clients übersteigt sogar den der Geth-Ausführungs-Clients. Eine ähnliche Situation tritt auch im Konsens-Client-System auf. ● Internationale Gemeinschaft: Menschen sind in vielen verschiedenen Ländern, einschließlich Projekten, L2, Teams usw.; ● Multizentrisches Wissensökosystem: Es gibt die Ethereum Foundation und es gibt Client-Teams. Sogar Teams wie das Reth-Team von Paradigm haben in letzter Zeit ihre Führungsrolle im Bereich Open Source ausgebaut. Daher verfügt das Ethereum-Ökosystem als Basisschicht bereits über diese sehr starken Vorteile. Ich denke, das ist eine sehr wertvolle Sache und sollte nicht einfach aufgegeben werden. Ich würde sogar sagen, dass es klare Schritte gibt, die unternommen werden können, um diese Stärken zu stärken und sogar unsere Schwächen anzugehen. Wo erfüllt Ethereum L1 die hohen Standards nicht? Wie kann es verbessert werden?
Hier ist eine Umfrage, die ich vor etwa einem halben Jahr auf Farcaster durchgeführt habe: Wenn Sie nicht Solo-Einsätze tätigen, was hält Sie dann davon ab, Solo-Einsätze zu tätigen? Ich kann die Frage an diesem Ort wiederholen: Wer macht Solo-Einsätze? Wer von Ihnen ist ohne Solo-Einsatz der Meinung, dass die Schwelle von 32 ETH das größte Hindernis darstellt? DeFi-Protokoll gleichzeitig? Wer glaubt, dass das größte Hindernis die Angst ist, private Schlüssel auf einem laufenden Knoten ablegen zu müssen, wo sie leichter gestohlen werden können? Es ist ersichtlich, dass die beiden größten vereinbarten Hindernisse sind: die Mindestanforderung von 32 ETH und die Schwierigkeit des Knotenbetriebs. Es ist immer wichtig, sich dessen bewusst zu sein. Wenn wir anfangen zu untersuchen, wie wir die Möglichkeit für Menschen maximieren können, ihre Sicherheiten in DeFi-Protokollen doppelt zu nutzen, stellen wir oft fest, dass es eine große Anzahl von Menschen gibt, die DeFi-Protokolle überhaupt nicht verwenden. Konzentrieren wir uns also auf die Hauptprobleme und darauf, was wir tun können, um sie zu lösen. Beginnen Sie mit dem Betrieb eines Validierungsknotens, d. h. beginnen Sie mit dem Schwellenwert von 32 ETH. Tatsächlich hängen diese beiden Fragen zusammen, da sie beide Funktionen der Anzahl der Validatoren im Proof of Stake von Ethereum sind. Heute haben wir etwa 1 Million Validierungseinheiten mit jeweils 32 ETH-Einlagen. Wenn die Mindestanforderung also auf 4 ETH geändert würde, hätten wir 8 Millionen oder vielleicht mehr als 8 Millionen, vielleicht 9 Millionen oder 10 Millionen Validatoren. Wenn wir auf 100.000 Validatoren herunterkommen wollten, würde die Mindestanforderung wahrscheinlich auf etwa 300 ETH steigen. Es ist also ein Kompromiss. Ethereum hat in der Vergangenheit versucht, sich in der Mitte des Kompromisses zu befinden. Wenn wir jedoch Möglichkeiten finden, es zu verbessern, verfügen wir über zusätzliche Statistikpunkte, die wir optional nutzen können, um die Mindestanforderungen zu reduzieren oder den Betrieb eines Knotens zu vereinfachen. Tatsächlich denke ich mittlerweile, dass das Aggregieren von Signaturen nicht einmal die Hauptschwierigkeit beim Betrieb eines Knotens darstellt. Am Anfang konzentrieren wir uns vielleicht mehr auf die Reduzierung der Mindestanforderungen, aber irgendwann wird es beides umfassen. Es gibt also zwei Techniken, die diese beiden Aspekte verbessern können. Eine Technik besteht darin, das Abstecken oder die Endgültigkeit zuzulassen, ohne dass jeder Prüfer unterschreiben muss.Grundsätzlich benötigen Sie eine Art Zufallsstichprobe von genügend Knoten, um eine erhebliche wirtschaftliche Sicherheit zu erreichen. Ich denke, wir haben im Moment mehr als genug wirtschaftliche Sicherheit. Die Kosten für die Durchführung eines 51-Prozent-Angriffs betragen bei Slash ETH ein Drittel von 32 Millionen ETH, was etwa 11 Millionen ETH entspricht. Wer würde 11 Millionen ETH ausgeben, um die Ethereum-Blockchain zu zerstören? Niemand, nicht einmal die US-Regierung, will das. Diese Probenahmetechniken ähneln denen, wenn Sie ein Haus hätten und die Vordertür durch vier Stahlschichten geschützt wäre, das Fenster jedoch nur ein Stück minderwertiges Glas wäre, das jemand leicht mit einem Baseballschläger zerbrechen könnte. Ich denke, dass es bei Ethereum bis zu einem gewissen Grad so ist: Wenn man einen 51-Prozent-Angriff durchführen will, muss man 11 Millionen ETH verlieren. Aber in Wirklichkeit gibt es viele andere Möglichkeiten, das Protokoll anzugreifen, und wir sollten diese Abwehrmaßnahmen wirklich stärker stärken. Wenn Sie also stattdessen eine Untergruppe von Validatoren haben, die die Endgültigkeit prüfen, ist das Protokoll immer noch sicher genug und Sie können den Grad der Dezentralisierung wirklich erhöhen. Die zweite Technik ist eine bessere Signaturaggregation. Sie könnten etwas Fortgeschrittenes wie Starks machen, und anstatt 30.000 Signaturen pro Slot zu unterstützen, könnten wir vielleicht irgendwann mehr Signaturen unterstützen. Dies ist der erste Teil. Der zweite Teil besteht darin, das Ausführen von Knoten zu vereinfachen. Der erste Schritt ist der Ablauf des Verlaufs. Tatsächlich hat es in dieser Hinsicht große Fortschritte gegeben, EIP-4444. Der zweite Schritt ist der zustandslose Client. Verkle gibt es schon seit langer Zeit. Eine weitere mögliche Option besteht darin, einen binären Hash-Baum wie Poseidon zu erstellen, eine Stark-freundliche Hash-Funktion. Sobald Sie dies haben, benötigen Sie zur Verifizierung von Ethereum-Blöcken keine Festplatte mehr. Sie können auch später eine ZKVM vom Typ 1 hinzufügen, die ganze Ethereum-Blöcke stark verifizieren kann, sodass Sie beliebig große Ethereum-Blöcke durch Herunterladen von Daten oder sogar Datenverfügbarkeits-Stichprobendaten verifizieren können und dann nur einen Beweis verifizieren müssen. Wenn Sie dies tun, wird die Ausführung des Knotens einfacher. Eines der derzeit sehr ärgerlichen Dinge bei zustandslosen Clients ist, dass Sie, wenn Sie Hardware- oder Softwareeinstellungen ändern möchten, normalerweise entweder von vorne beginnen und einen Tag verlieren müssen, oder Sie müssen etwas sehr Gefährliches tun und die Schlüssel in zwei Teile stecken wird irgendwo geslasht, und wenn wir einen zustandslosen Client haben, müssen Sie dies nicht mehr tun. Sie können einfach einen neuen eigenständigen Client starten, den alten schließen, die Schlüssel verschieben und den neuen starten. Sie verlieren nur eine Epoche. Sobald Sie ZKVM haben, sinken die Hardwareanforderungen praktisch auf nahezu Null. Daher können beide Probleme, die Schwelle von 32 ETH und die Schwierigkeit, Knoten zu betreiben, technisch gelöst werden. Ich denke, dass dies viele weitere Vorteile mit sich bringt. Es wird unsere Fähigkeit, die individuellen Einsätze der Menschen zu erhöhen, wirklich verbessern, es wird uns ein besseres individuelles Einsatz-Ökosystem bieten und die Risiken einer Zentralisierung der Einsätze vermeiden. Proof of Stake birgt weitere Herausforderungen, wie zum Beispiel Risiken im Zusammenhang mit Liquid Staking und Risiken im Zusammenhang mit MEV. Dies sind ebenfalls wichtige Fragen, die es weiterhin zu berücksichtigen gilt. Unsere Forscher denken darüber nach. Erholen Sie sich von einem 51 %-Angriff
Ich begann wirklich ernsthaft und gründlich nachzudenken. Es ist überraschend, wie viele Menschen sich überhaupt keine Gedanken über dieses Thema machen und es einfach wie eine Black Box behandeln. Was passiert, wenn es tatsächlich zu einem 51-Prozent-Angriff kommt? Ethereum kann einem 51-Prozent-Angriff ausgesetzt sein, Bitcoin kann einem 51-Prozent-Angriff ausgesetzt sein und eine Regierung kann ebenfalls einem 51-Prozent-Angriff ausgesetzt sein, beispielsweise durch den Kauf von 51 Prozent der Politiker. Ein Problem besteht darin, dass Sie sich nicht nur auf die Prävention verlassen möchten, sondern auch einen Wiederherstellungsplan haben möchten. Ein weit verbreitetes Missverständnis ist, dass die Leute denken, dass es bei 51 % der Angriffe darum geht, die Endgültigkeit umzukehren. Die Leute achten darauf, weil Satoshi Nakamoto dies im Weißbuch betont hat. Sie können doppelt ausgeben, nachdem ich einen Privatjet gekauft hatte, habe ich einen 51-Prozent-Angriff durchgeführt, meine Bitcoins zurückbekommen und auch meinen Privatjet behalten und bin herumgeflogen. Ein realistischerer Angriff könnte darin bestehen, Einzahlungen auf Börsen vorzunehmen und beispielsweise DeFi-Protokolle zu kompromittieren. Aber eine Umkehr ist nicht wirklich das Schlimmste. Das größte Risiko, über das wir uns Sorgen machen sollten, ist tatsächlich die Zensur. 51 % der Knoten akzeptierten keine Blöcke mehr von den anderen 49 % der Knoten oder von Knoten, die versuchten, irgendeine Art von Transaktion einzudämmen. Warum ist dies das größte Risiko? Da die Endgültigkeitsumkehr Slash hat, gibt es in der Kette sofort einen überprüfbaren Beweis dafür, dass mindestens ein Drittel der Knoten etwas sehr, sehr Falsches getan haben und bestraft wurden. Und bei einem Zensurangriff lässt sich das nicht verfahrenstechnisch zuordnen, es gibt keine unmittelbaren prozessualen Beweise dafür, wer etwas Schlimmes getan hat. Wenn Sie nun ein Online-Knoten sind und sehen möchten, dass eine bestimmte Transaktion nicht innerhalb von 100 Blöcken enthalten ist, wir aber noch nicht einmal Software geschrieben haben, um diese Prüfung durchzuführen, besteht eine weitere Herausforderung bei der Überprüfung darin, ob jemand dies wünscht Bei Angriffen können sie Folgendes tun: Sie beginnen damit, Transaktionen und Blöcke, die sie nicht mögen, um 30 Sekunden zu verzögern, dann um eine Minute und dann um zwei Minuten, und Sie sind sich nicht einmal einig, wann Sie reagieren sollen . Ich sage also, Zensur ist tatsächlich das größere Risiko. In der Blockchain-Kultur gibt es das Argument, dass sich die Community im Falle eines Angriffs zusammenschließt und offensichtlich ein paar Soft Forks durchführt und die Angreifer ausschaltet. Das mag heute wahr sein, aber es beruht auf vielen Annahmen über Koordination, Ideologie und alle möglichen anderen Dinge, und es ist unklar, wie wahr so ​​etwas in 10 Jahren sein wird. Was also viele andere Blockchain-Gemeinschaften anfangen zu tun, ist, sagen sie, wir haben Dinge wie Zensur, wir haben diese Fehler, die eher nicht zuzuschreibender Natur sind. Daher müssen wir uns auf einen gesellschaftlichen Konsens verlassen. Verlassen wir uns also ausschließlich auf den gesellschaftlichen Konsens und geben wir stolz zu, dass wir ihn zur Lösung unserer Probleme nutzen werden. ​Tatsächlich plädiere ich dafür, in die entgegengesetzte Richtung zu gehen. Wir wissen, dass es mathematisch unmöglich ist, automatisierte Reaktionen vollständig zu koordinieren und die Mehrheit der untersuchten Angreifer automatisch abzuspalten. Aber wir können dem so nahe wie möglich kommen. Sie können einen Fork erstellen, der basierend auf einigen Annahmen über die Netzwerkbedingungen tatsächlich mindestens die Mehrheit der Knoten online bringt. Das Argument, das ich hier vorbringen möchte, ist, dass wir eigentlich versuchen wollen, die Reaktion auf einen 51-Prozent-Angriff so automatisiert wie möglich zu gestalten. Wenn Sie ein Validator sind, sollte auf Ihrem Knoten eine Software ausgeführt werden, die, wenn sie feststellt, dass Transaktionen zensiert werden oder bestimmte Validatoren zensiert werden, den Großteil der Kette automatisch dezensiert und alle ehrlichen Knoten automatisch aufgrund ihres laufenden Codes koordiniert werden die gleichen wenigen weichen Gabeln. Natürlich gibt es auch hier ein mathematisch unmögliches Ergebnis, zumindest wäre jemand, der zu diesem Zeitpunkt offline war, nicht in der Lage zu sagen, wer Recht und wer Unrecht hatte. Es gibt viele Einschränkungen, aber je näher man diesem Ziel kommt, desto weniger Arbeit muss der gesellschaftliche Konsens leisten. Stellen Sie sich vor, was ein 51-Prozent-Angriff tatsächlich passiert. Es wird nicht so sein, dass Lido, Coinbase und Kraken irgendwann um 5:46 Uhr plötzlich einen Blog-Beitrag veröffentlichen werden, in dem es im Grunde heißt: „Hey Leute, wir machen jetzt eine Rezension.“ Was tatsächlich passieren könnte, ist, dass es gleichzeitig zu einem Social-Media-Krieg und gleichzeitig zu allen möglichen anderen Angriffen kommt. Wenn es tatsächlich zu einem 51-Prozent-Angriff kommt, sollten wir übrigens nicht davon ausgehen, dass Lido, Coinbase und Kraken in 10 Jahren an der Macht sein werden. Das Ethereum-Ökosystem wird immer mehr zum Mainstream werden und muss sich entsprechend anpassen können.Wir möchten, dass die Belastung für die soziale Ebene so gering wie möglich ist. Das bedeutet, dass die technische Ebene zumindest einen klaren Siegerkandidaten hervorbringen muss, und wenn sie aus einer Kette, die gerade überprüft wird, austreten möchte, sollte sie sich sammeln etwa eine Handvoll weicher Gabeln überlegen. Ich plädiere dafür, dass wir mehr recherchieren und eine ganz konkrete Empfehlung aussprechen. Vorschlag: Anhebung der Quorumsschwelle auf 75 % oder 80 %
Ich denke, der Schwellenwert für das Quorum (Hinweis: Der Quorum-Mechanismus ist ein Abstimmungsalgorithmus, der häufig in verteilten Systemen verwendet wird, um Datenredundanz und letztendliche Konsistenz sicherzustellen) kann von heute zwei Drittel auf 75 % oder etwa 80 % angehoben werden. Das Grundargument ist, dass die Wiederherstellung sehr, sehr schwierig wird, wenn eine bösartige Kette wie eine Zensurkette angreift. Welche Risiken bestehen jedoch, wenn Sie den Anteil des Quorums erhöhen? Wenn das Quorum 80 % beträgt, dann wären es statt 34 % der Knoten, die offline gehen und die Endgültigkeit stoppen, 21 % der Knoten, die offline gehen und die Endgültigkeit stoppen. Das ist riskant. Mal sehen, wie es in der Praxis aussieht? Soweit ich weiß, war die Endgültigkeit meiner Meinung nach nur einmal für etwa eine Stunde ins Stocken geraten, weil mehr als ein Drittel der Knoten offline waren. Und gab es dann Vorfälle, bei denen 20 bis 33 % der Knoten offline waren? Ich denke höchstens einmal und mindestens null Mal. Da in der Praxis nur sehr wenige Validatoren offline gehen, halte ich das Risiko dafür für ziemlich gering. Die Vorteile bestehen im Wesentlichen darin, dass die Messlatte, die ein Angreifer erreichen muss, erheblich erhöht wird und dass die Anzahl der Szenarien, in denen die Kette im Falle einer clientseitigen Schwachstelle in den abgesicherten Modus wechselt, erheblich zunimmt, sodass Menschen tatsächlich zusammenarbeiten können, um herauszufinden, was passiert ging schief. Wenn der Schwellenwert des Quorums von 67 % auf 80 % ansteigt und angenommen wird, dass der Anteil, den ein Kunde erreichen muss, von 67 % auf 80 % steigt, dann ist der Wert einer kleinen Anzahl von Kunden bzw. der Wert, den eine kleine Anzahl von Kunden erreicht Kunden bieten können, beginnt wirklich zu wachsen. Andere Zensurbedenken Weitere Zensurbedenken betreffen entweder Aufnahmelisten oder Alternativen zu Aufnahmelisten. Wenn die ganze Sache mit den multiparallelen Antragstellern funktioniert, könnte sie sogar ein Ersatz für Einschlusslisten werden. Sie benötigen entweder eine Kontoabstraktion, Sie benötigen eine Kontoabstraktion innerhalb einer Art Protokoll. Der Grund dafür, dass Sie es brauchen, ist, dass Smart-Contract-Wallets derzeit nicht wirklich von Einschlusslisten profitieren. Smart-Contract-Wallets profitieren nicht wirklich von irgendeiner Zensurresistenzgarantie auf der Protokollebene. Sie würden davon profitieren, wenn es innerhalb des Protokolls eine Kontoabstraktion gäbe. Es gibt also viele Dinge, tatsächlich sind viele dieser Dinge für die Vision des L2-Zentrums und die Vision des L1-Zentrums wertvoll. Von den verschiedenen Ideen, die ich besprochen habe, beziehen sich etwa die Hälfte wahrscheinlich speziell auf L2-Lösungen für Ethereum, die andere Hälfte ist jedoch grundsätzlich auf Ethereum-Benutzer mit L2 als Basisschicht und L1 oder direkt an den Benutzer gerichteten Anwendungen anwendbar. Nutzen Sie Light Clients überall In vielerlei Hinsicht ist es irgendwie traurig, wie wir mit der Branche interagieren. Wir sind dezentralisiert, wir haben kein Vertrauen. Wer in diesem Raum betreibt auf seinem Computer einen Light-Client, der den Konsens bestätigt? selten. Wer nutzt Ethereum, indem er der Browser-Wallet von Infura vertraut? In fünf Jahren würde ich mir wünschen, dass sich die Zahl der erhobenen Hände umkehrt. Ich würde gerne Geldbörsen sehen, die Infura in keiner Weise vertrauen. Wir müssen Light-Clients integrieren. Infura kann weiterhin Daten bereitstellen. Ich meine, es ist eigentlich gut für Infura, wenn man Infura nicht vertrauen muss, weil es für sie einfacher ist, Infrastruktur aufzubauen und bereitzustellen, aber wir haben Tools, um die Vertrauenspflicht zu beseitigen. Was wir tun können, ist, dass wir ein System haben können, bei dem der Endbenutzer so etwas wie einen Helios Light-Client betreibt. Es sollte eigentlich direkt im Browser laufen und den Ethereum-Konsens direkt validieren. Wenn er etwas in der Kette verifizieren möchte, beispielsweise mit der Kette interagieren, dann verifizieren Sie einfach den Merkle-Beweis direkt. Wenn Sie dies tun, gewinnen Sie tatsächlich ein gewisses Maß an Vertrauenslosigkeit in Ihren Interaktionen mit Ethereum. Dies ist für L1. Zusätzlich benötigen wir ein äquivalentes Schema für L2. In der L1-Kette gibt es Blockheader, Zustände, Synchronisationskomitees und Konsens. Wenn Sie den Konsens überprüfen und wissen, was der Blockheader ist, können Sie durch den Merkle-Zweig gehen und sehen, wie der Status ist. Wie können wir also leichte Client-Sicherheitsgarantien für L2s bereitstellen? Die Statuswurzel von L2 ist vorhanden. Wenn es auf Rollup basiert, gibt es einen Smart Contract, und dieser Smart Contract speichert den Blockheader von L2. Wenn Sie über eine Vorbestätigung verfügen, verfügen Sie über einen intelligenten Vertrag, der speichert, wer die Vorbestätigung ist. Sie bestimmen also, wer die Vorbestätigung ist, und warten dann auf zwei Drittel der Unterschriften. Sobald Sie also den Ethereum-Block-Header haben, verfügen Sie über eine ziemlich einfache Vertrauenskette, den Hash, den Merkle-Zweig und die Signatur, die Sie überprüfen können, und Sie können eine leichte Client-Verifizierung erhalten. Das Gleiche gilt für jedes L2. Ich habe dies in der Vergangenheit anderen Leuten zur Sprache gebracht, und oft war die Antwort: „Oh mein Gott, das ist interessant, aber was hat das für einen Sinn?“Ein Großteil von L2 ist Multisignatur. Warum vertrauen wir nicht auf Mehrfachsignaturen, um Mehrfachsignaturen zu überprüfen? Glücklicherweise ist dies seit letztem Jahr tatsächlich nicht mehr der Fall. Optimism und Arbitrum befinden sich in der ersten Rollup-Phase, was bedeutet, dass sie tatsächlich über Proof-Systeme in der Kette verfügen und über ein Sicherheitskomitee verfügen, das sie im Falle einer Schwachstelle abdecken kann, aber das Sicherheitskomitee muss eine sehr hohe Abstimmungsschwelle überwinden. , sagen wir 75 % von 8 Personen, wird die Größe von Arbitrum auf 15 Personen anwachsen. Im Fall von Optimismus und Arbitrum handelt es sich also nicht nur um Multisigs, sie verfügen über tatsächliche Beweissysteme, und diese Beweissysteme spielen tatsächlich eine Rolle, zumindest im Hinblick darauf, dass sie die Mehrheit der Macht bei der Entscheidung haben, welche Kette richtig oder falsch ist . EVM geht sogar noch weiter. Ich glaube, es gibt nicht einmal ein Sicherheitskomitee und ist daher völlig vertrauenswürdig. Wir fangen wirklich an, hier voranzukommen, und ich weiß, dass auch viele andere L2-Unternehmen Fortschritte machen. L2 ist also mehr als nur Multisig, sodass das Konzept der Light-Clients für L2 tatsächlich Sinn macht. Heute können wir den Merkle-Zweig bereits verifizieren, schreiben Sie einfach den Code. Morgen können wir auch ZKVM validieren, sodass Sie Ethereum und L2 in Ihrem Browser-Wallet vollständig validieren können. Wer möchte ein vertrauenswürdiger Ethereum-Benutzer in einer Browser-Wallet sein? fabelhaft. Wer wäre lieber ein vertrauenswürdiger Ethereum-Benutzer auf seinem Mobiltelefon? Wie wäre es mit einem Raspberry Pi? Wie wäre es mit einer Smartwatch? Von der Raumstation? Wir werden das auch beheben. Was wir also benötigen, ist das Äquivalent einer RPC-Konfiguration, die nicht nur die Server enthält, mit denen Sie kommunizieren, sondern auch die tatsächlichen Anweisungen zur Light-Client-Authentifizierung. Darauf können wir hinarbeiten. Anti-Quanten-Strategie
Die Zeit bis zum Quantencomputing verkürzt sich. Metaculous geht davon aus, dass Quantencomputer Anfang der 2030er Jahre auf den Markt kommen werden, manche gehen sogar schon früher davon aus. Wir brauchen also eine quantenresistente Strategie. Wir haben eine quantenresistente Strategie. Es gibt vier Teile von Ethereum, die für Quantencomputing anfällig sind, und für jeden gibt es natürliche Alternativen. Die quantenresistente Alternative zu Verkle Tree ist Starked Poseidon Hash. Wenn wir konservativer sein möchten, können wir die Blake-Konsenssignatur verwenden. Derzeit verwenden wir die BLS-Aggregatsignatur, die durch die Stark-Aggregatsignatur ersetzt werden kann. Blob verwendet KZG, was mithilfe der trennungscodierten Merkle-Bäume Stark nachgewiesen werden kann. Benutzerkonten verwenden derzeit ECDSA SECP256K1, das durch Hash-basierte Signaturen und Kontoabstraktion und -aggregation, Smart Contract Wallets ERC 4337 usw. ersetzt werden kann. Sobald Sie dies haben, kann der Benutzer seinen eigenen Signaturalgorithmus einrichten, im Wesentlichen mithilfe einer Hash-basierten Signatur. Ich denke, wir müssen wirklich darüber nachdenken, tatsächlich Hash-basierte Signaturen zu erstellen, damit Benutzer-Wallets problemlos auf Hash-basierte Signaturen umgestellt werden können. Vereinfachung des Protokolls Wenn Sie eine robuste Basisschicht wünschen, muss das Protokoll einfach sein. Es sollte keine 73 zufälligen Hooks und eine gewisse Abwärtskompatibilität haben, die auf eine zufällige dumme Idee zurückzuführen ist, die ein zufälliger Typ namens Vitalik im Jahr 2014 hatte. Es lohnt sich also, zu versuchen, die technischen Schulden wirklich zu vereinfachen und tatsächlich zu beseitigen. Protokolle basieren derzeit auf Bloom-Filtern, die nicht gut funktionieren und nicht schnell genug sind. Daher sind Protokollverbesserungen erforderlich, um eine stärkere Unveränderlichkeit hinzuzufügen, was wir bereits auf der zustandslosen Seite tun, wodurch der Status jeder Blockansicht grundsätzlich begrenzt wird. Ethereum ist im Moment eine unglaubliche Sammlung, es gibt RLP, es gibt SSZ, es gibt API, und im Idealfall sollten wir nur SSZ verwenden, aber zumindest RLP, Status und den binären Merkle-Baum loswerden, sobald wir den binären Merkle-Baum haben Das gesamte Ethereum befindet sich in einem binären Merkle-Baum. Fast Finality, Single Slot Finality (SSF), bereinigt ungenutzte Precompiler, wie den ModX-Precompiler, der häufig Konsensfehler verursacht. Es wäre schön, wenn wir ihn entfernen und durch leistungsstarken Soliditätscode ersetzen könnten. Zusammenfassen Als robuste Basisschicht verfügt Ethereum über ganz einzigartige Vorteile, darunter einige, die Bitcoin nicht hat, wie z. B. Konsens-Dezentralisierung und umfangreiche Untersuchungen zur 51-prozentigen Wiederherstellung nach Angriffen. Ich denke, dass es notwendig ist, diese Stärken wirklich zu stärken. Erkennen und korrigieren Sie auch unsere Mängel, um sicherzustellen, dass wir sehr hohe Standards erfüllen. Diese Ideen sind voll kompatibel mit einer aggressiven L1-Roadmap. Eines der Dinge, mit denen ich an Ethereum am meisten zufrieden bin, insbesondere der Kernentwicklungsprozess, ist, dass sich unsere Fähigkeit, parallel zu arbeiten, deutlich verbessert hat. Das ist eine Stärke, wir können tatsächlich an vielen Dingen parallel arbeiten. Die Beschäftigung mit diesen Themen hat also keinen Einfluss auf die Fähigkeit, das L1- und L2-Ökosystem zu verbessern. Beispielsweise die Verbesserung des L1-EVM, um die Kryptografie einfacher zu machen. Die Validierung von Poseidon-Hashes im EVM ist derzeit zu teuer. Auch die 384-Bit-Kryptographie ist zu teuer. Es gibt also einige Ideen zusätzlich zu EOF, wie SIMD-Opcodes, EVM max usw. Es besteht die Möglichkeit, diesen Hochleistungs-Coprozessor an das EVM anzuschließen. Dies ist besser für Layer 2, da die Überprüfung von Beweisen kostengünstiger sein kann, und besser für Layer 1-Anwendungen, da Datenschutzprotokolle wie zk SNARKs günstiger sind. Wer hat die Datenschutzvereinbarung genutzt? Wer möchte eine Gebühr von 40 $ statt 80 $ zahlen? Mehr Menschen werden sich für Ersteres entscheiden. Eine zweite Benutzergruppe kann auf Layer 2 Transaktionen durchführen, während Layer 1 die Kosten deutlich senken kann. ​