Zusammengestellt von: 0xxz, Golden Finance
EthCC7 fand kürzlich in Brüssel statt und die Organisatoren luden Vitalik, den Gründer von Ethereum, ein, eine Grundsatzrede zu halten.
Es ist erwähnenswert, dass 2024 der 10. Jahrestag des Ethereum ICO ist. Nach Vitaliks Rede machten die drei ehemaligen Kerngrü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.
das Redethema
Stärkung von L1: Optimierung von Ethereum, um eine äußerst zuverlässige, vertrauenswürdige und erlaubnisfreie 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 im Grunde eine sehr minimalistische Basisschicht zu sein, die im Grunde nur als Beweisprüfer 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 im Grunde 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 auf der zweiten linken Seite platziert. 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ührungsschicht in ein Rollup umgewandelt wird.
Ich meine, auf der linken Seite gibt es sehr extreme Optionen und auf der rechten Seite könnte es sich um eine Basisschicht handeln, aber man könnte auch versuchen, 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, grundlegende Rollups als primäre Arbeitsweise von L2 tatsächlich realisierbar zu machen. Wenn Sie also möchten, dass L2 ein erstklassiges Benutzererlebnis bietet, benötigen Sie eine eigene Vorbestätigung, 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 verbessern möchten, wird auch der Bedarf an L2 reduziert.
Es 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 ein Diagramm der Rechenleistung aller Bitcoin-Mining-Pools und die rechte Seite ist ein Diagramm der Ethereum-Staker.
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 Akteure 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 wertvoll, dies anzuerkennen. Das ist einer der einzigartigen Vorteile, auf die wir wirklich aufbauen können.
Zu den Robustheitsvorteilen von Ethereum gehören außerdem:
Es verfügt über ein Multi-Client-Ökosystem: Es gibt Geth-Ausführungs-Clients und Nicht-Geth-Ausführungs-Clients. Der Anteil der Nicht-Geth-Ausführungs-Clients übersteigt sogar den der Geth-Ausführungs-Clients. Eine ähnliche Situation tritt in Konsens-Client-Systemen auf;
Internationale Gemeinschaft: Menschen in vielen verschiedenen Ländern, einschließlich Projekten, L2, Teams usw.;
Multizentrisches Wissensökosystem: Es gibt die Ethereum Foundation, es gibt das Kundenteam und sogar das Reth-Team von Paradigm hat in letzter Zeit seine Führungsrolle im Bereich Open Source ausgebaut;
Kulturen, die diese Eigenschaften schätzen
Das Ethereum-Ökosystem als Basisschicht verfügt also bereits über diese sehr starken Vorteile. Ich denke, das ist etwas sehr Wertvolles und sollte nicht so leicht 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 nicht die hohen Standards und 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, wer denkt, dass der Betrieb eines Knotens zu schwierig ist, und wer denkt, dass das größte Hindernis darin besteht, dass man seine ETH nicht in DeFi investieren kann 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 Hindernisse, auf die man sich einstimmig geeinigt hat, die Mindestanforderung von 32 ETH und die Schwierigkeit des Knotenbetriebs sind. Es ist immer wichtig, sich dessen bewusst zu sein.
Wenn wir beginnen, uns mit der Frage zu befassen, wie wir die Möglichkeit für Menschen maximieren können, ihre Sicherheiten in DeFi-Protokollen doppelt zu nutzen, stellen wir fest, dass eine große Anzahl von Menschen DeFi-Protokolle überhaupt nicht nutzen. 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 und jede Einheit verfügt über eine Einzahlung von 32 ETH. 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 es auf 100.000 Validatoren reduzieren wollen, dann muss die Mindestanforderung möglicherweise 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 Zusammenfassen 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 wäre, das Abstecken oder die Endgültigkeit zuzulassen, ohne dass jeder Validator 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 belaufen sich, berechnet auf die gekürzte ETH-Menge, auf 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 langem. Eine weitere mögliche Option besteht darin, einen binären Hash-Baum ähnlich 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 dann eine ZKVM vom Typ 1 hinzufügen, die den gesamten Ethereum-Block stark verifizieren kann, sodass Sie beliebig große Ethereum-Blöcke durch Herunterladen von Daten oder sogar Stichprobendaten zur Datenverfügbarkeit verifizieren können und dann nur noch einen Beweis verifizieren müssen.
Wenn Sie dies tun, wird die Ausführung des Knotens einfacher. Eines der sehr ärgerlichen Dinge bei zustandslosen Clients ist derzeit, dass Sie, wenn Sie Hardware- oder Softwareeinstellungen ändern möchten, normalerweise entweder ganz 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 wäre ein Schlagabtausch. Wenn wir staatenlose Kunden 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 sowohl die Schwelle von 32 ETH als auch die Schwierigkeit des Knotenbetriebs 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 z. B. Risiken im Zusammenhang mit dem Liquiditätseinsatz und Risiken im Zusammenhang mit MEV. Dies sind ebenfalls wichtige Fragen, die es weiterhin zu berücksichtigen gilt. Darüber denken unsere Forscher 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 wirklich zu einem 51-Prozent-Angriff kommt?
Ethereum kann einen 51-Prozent-Angriff erleiden, Bitcoin kann einen 51-Prozent-Angriff erleiden und eine Regierung kann ebenfalls einen 51-Prozent-Angriff erleiden, 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 meinen Privatjet gekauft hatte, habe ich einen 51-Prozent-Angriff durchgeführt, meine Bitcoins zurückbekommen und konnte meinen Privatjet behalten und herumfliegen.
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 überprüfbare Beweise dafür, dass mindestens ein Drittel der Knoten etwas sehr, sehr Falsches getan haben, und sie wurden bestraft.
Und bei einem Zensurangriff lässt sich das nicht prozessual nachvollziehen, 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,
Eine weitere Herausforderung bei der Zensur besteht darin, dass jemand, der angreifen möchte, dies tun kann, indem er Transaktionen und Blockaden, die er nicht mag, um 30 Sekunden verzögert, dann um eine Minute, dann um zwei Minuten und dann nicht einmal einen Konsens darüber haben, wann man antworten soll.
Ich sage also, dass Zensur tatsächlich das größere Risiko darstellt.
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. Deshalb müssen wir uns auf den 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 Online-Knoten bringt. Das Argument, das ich hier zu vermitteln versuche, 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 ist das Ergebnis auch hier mathematisch unmöglich, zumindest könnte jeder, der zu diesem Zeitpunkt offline war, nicht 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, sollten sie sich zusammenschließen 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 sind es statt 34 % der Knoten, die offline gehen und die Endgültigkeit stoppen, 21 % der Knoten, die offline gehen und die Endgültigkeit stoppen.
Es bestehen Risiken. 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 gibt es Vorfälle, bei denen 20 bis 33 % der Knoten offline sind? 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 % steigt, dann steigt unter der Annahme, dass der Anteil, den ein Kunde erreichen muss, von 67 % auf 80 %, dann der Wert einer kleinen Anzahl von Kunden oder 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 der Einschlussliste 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.
Ich denke, von den verschiedenen Ideen, über die ich gesprochen habe, betraf wahrscheinlich etwa die Hälfte speziell Ethereum und konzentrierte sich auf L2, aber die andere Hälfte bezog sich im Wesentlichen auf L2 als Basisschicht für Ethereum-Benutzer und L1 oder sozusagen direkt für Benutzeranwendungen als Benutzer.
Verwenden Sie überall Light-Clients
In vielerlei Hinsicht ist es irgendwie traurig, wie wir mit dem Raum interagieren. Wir sind dezentralisiert, wir haben kein Vertrauen. Wer in diesem Raum betreibt einen Light-Client auf seinem Computer, 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, wenn Sie Infura nicht vertrauen müssen, ist das eigentlich gut für Infura, weil es ihnen den Aufbau und die Bereitstellung von Infrastruktur erleichtert, aber wir haben Tools, um die Vertrauensvoraussetzung 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. Darüber hinaus benötigen wir auch eine äquivalente Lösung 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 sich um ein Basis-Rollup handelt, 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, gibt es 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 und einen Sicherheitsausschuss verfügen, der sie im Falle einer Schwachstelle abdecken kann, aber der Sicherheitsausschuss muss eine sehr hohe Abstimmungsschwelle überwinden. B. 75 % von 8 Personen, wird die Größe von Arbitrum auf 15 Personen ansteigen. 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.
Quantenresistente Strategien
Die Zeit bis zum Quantencomputing wird immer kürzer. 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.
Eine quantenresistente Alternative zu Verkle Tree ist Starked Poseidon Hash. Wenn wir konservativer sein wollen, können wir Blake-Konsenssignaturen verwenden. Derzeit verwenden wir BLS-Aggregatsignaturen, die durch Stark-Aggregatsignaturen ersetzt werden können. Blob verwendet KZG und kann mithilfe der separaten Codierung des Merkle-Baums Stark nachgewiesen werden. 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 diese haben, kann der Benutzer seinen eigenen Signaturalgorithmus einrichten, im Wesentlichen unter Verwendung 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. Das Protokoll basiert derzeit auf Bloom-Filtern, die nicht gut funktionieren und nicht schnell genug sind. Daher müssen Verbesserungen am Protokoll vorgenommen werden, um eine stärkere Unveränderlichkeit hinzuzufügen, was wir bereits auf der zustandslosen Seite tun, wodurch der Status von grundsätzlich eingeschränkt wird jeder Block Ansichten.
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 einzigartige Vorteile, darunter einige, die Bitcoin nicht bietet, 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 vollständig mit der aggressiven L1-Roadmap kompatibel.
Eines der Dinge, mit denen ich an Ethereum und insbesondere am Kernentwicklungsprozess am meisten zufrieden bin, 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. Derzeit ist es zu teuer, Poseidon-Hashes im EVM zu überprüfen. 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, weil dort Beweise billiger überprüft werden können, und besser für Layer 1-Anwendungen, weil Datenschutzprotokolle wie zk SNARKs billiger sind.
Wer hat die Datenschutzvereinbarung genutzt? Wer möchte mit einer Datenschutzvereinbarung 40 statt 80 Gebühren zahlen? mehr Leute. Die zweite Gruppe kann auf Layer 2 eingesetzt werden, und Layer 1 kann erhebliche Kosteneinsparungen erzielen.
Die „Großen Drei“ von Ethereum vereinen sich wieder
2024 ist der 10. Jahrestag von Ethereum IC0. Das EthCC 2024 lud alle drei ehemaligen Kerngründer von Ethereum, Vitalik Buterin, Joseph Lubin und Gavin Wood, zur Teilnahme an dem Treffen ein.
Nach Vitaliks Rede wurden sie zu einem gemeinsamen Gruppenfoto eingeladen:
Die Großen Drei geben sich erneut die Hand
