Vitalik: Kurzfristige und mittelfristige Pläne zur Verbesserung der Erlaubnisfreiheit und Dezentralisierung von Ethereum

Originalautor: Vitalik

Originalübersetzung: Deng Tong, Golden Finance

Ich sitze hier und schreibe dies am letzten Tag des Kenya Ethereum Developer Interop, und wir haben große Fortschritte bei der Implementierung und Ausarbeitung der technischen Details wichtiger bevorstehender Ethereum-Verbesserungen gemacht, insbesondere bei PeerDAS, dem Übergang zum Verkle-Baum und einem dezentralen Ansatz zur Speicherung des Verlaufs im Kontext von EIP 4444. Aus meiner Sicht wächst das Tempo der Ethereum-Entwicklung und unsere Fähigkeit, große und wichtige Funktionen bereitzustellen, die das Erlebnis sowohl für Knotenbetreiber als auch für (L1- und L2-)Benutzer deutlich verbessern können, weiter.

Ethereum-Clientteams arbeiten zusammen, um Pectra Devnet bereitzustellen

Angesichts der zunehmenden Leistungsfähigkeit der Technologie stellt sich die wichtige Frage: Sind wir auf dem richtigen Weg? Eine Reihe verärgerter Tweets des langjährigen Geth-Kernentwicklers Peter Szilagyi hat uns kürzlich dazu veranlasst, über diese Frage nachzudenken:

Diese Bedenken sind alle berechtigt. Sie werden von vielen in der Ethereum-Community geäußert. Ich persönlich habe mir über diese Probleme schon oft Sorgen gemacht. Allerdings glaube ich auch nicht, dass die Situation so hoffnungslos ist, wie Peters Tweet vermuten lässt. Im Gegenteil, viele der Probleme werden bereits durch laufende Protokollfunktionen angegangen, während viele andere durch sehr realistische Anpassungen der aktuellen Roadmap angegangen werden können.

Um zu verstehen, was das in der Praxis bedeutet, sehen wir uns die drei Beispiele an, die Peter angeführt hat. Diese Probleme sind für viele Community-Mitglieder ein häufiges Anliegen, und es ist wichtig, sie anzusprechen.

MEV- und Builder-Abhängigkeiten

In der Vergangenheit wurden Ethereum-Blöcke von Minern erstellt, die einen relativ einfachen Algorithmus zur Erstellung von Blöcken verwendeten. Benutzer senden Transaktionen an ein öffentliches P2P-Netzwerk, das oft als Mempool (oder Txpool) bezeichnet wird. Miner hören den Speicherpool ab, akzeptieren gültige Transaktionen und zahlen Gebühren. Sie schließen Transaktionen ein, die ausgeführt werden können, und wenn nicht genügend Speicherplatz vorhanden ist, werden sie in der Reihenfolge der höchsten Gebühr zuerst priorisiert.

Es ist ein sehr einfaches System und es ist dezentralisierungsfreundlich: Als Miner führen Sie einfach die Standardsoftware aus und erhalten aus einem Block die gleichen Gebühreneinnahmen wie aus einer hochprofessionellen Mining-Farm. Um 2020 herum begannen die Leute jedoch, den sogenannten Miner Extractable Value (MEV) zu nutzen: Einnahmen, die nur durch die Ausführung komplexer Strategien erzielt werden können, die die Aktivitäten innerhalb verschiedener DeFi-Protokolle verstehen.

Betrachten wir beispielsweise eine dezentrale Börse wie Uniswap. Angenommen, zum Zeitpunkt T beträgt der USD/ETH-Kurs an zentralisierten Börsen und Uniswap $3000. Zum Zeitpunkt T+11 steigt der USD/ETH-Kurs an zentralisierten Börsen auf $3005. Aber Ethereum hat den nächsten Block noch nicht. Zum Zeitpunkt T+12 hat es ihn. Wer auch immer den Block erstellt hat, seine erste Transaktion könnte eine Reihe von Uniswap-Käufen sein, bei denen alle verfügbaren ETH auf Uniswap zu Preisen zwischen $3000 und $3004 gekauft werden. Dies ist zusätzliches Einkommen, genannt MEV. Andere Anwendungen als DEXs haben ähnliche Probleme. Das 2019 veröffentlichte Flash Boys 2.0-Papier behandelt dies ausführlich.

Das Diagramm im Dokument „Flash Boys 2.0“ zeigt die Höhe der Einnahmen, die mit den oben genannten verschiedenen Methoden erzielt werden können.

Das Problem besteht darin, dass dadurch der eigentliche Grund zunichte gemacht wird, warum Mining (oder Blockvorschläge nach 2022) „fair“ sein können: Jetzt können große Akteure mit besseren Fähigkeiten zur Optimierung solcher Extraktionsalgorithmen in jedem Block bessere Belohnungen erhalten.

Seitdem gibt es eine anhaltende Debatte zwischen zwei Strategien, die ich als MEV-Minimierung und MEV-Segregation bezeichne. MEV-Minimierung gibt es in zwei Formen: (i) aktive Entwicklung MEV-freier Alternativen zu Uniswap (z. B. Cowswap) und (ii) Aufbau von In-Protocol-Techniken wie verschlüsselten Mempools, die die den Blockproduzenten zur Verfügung stehenden Informationen und damit den von ihnen erzielbaren Umsatz reduzieren. Insbesondere verhindern verschlüsselte Mempools Strategien wie Sandwich-Angriffe, bei denen Transaktionen vor und nach den Transaktionen eines Benutzers platziert werden, um sie wirtschaftlich auszunutzen („Front-Running“).

MEV-Segregation funktioniert, indem MEV akzeptiert wird, aber versucht wird, seine Auswirkungen auf die Staking-Zentralisierung zu begrenzen, indem der Markt in zwei Arten von Teilnehmern aufgeteilt wird: Validatoren sind für die Bestätigung und Vorschlagung von Blöcken verantwortlich, aber die Aufgabe, Blockinhalte auszuwählen, wird über ein Auktionsprotokoll weitergegeben. Einzelne Staker müssen sich nun nicht mehr selbst um die Optimierung der DeFi-Arbitrage kümmern; sie nehmen einfach am Auktionsprotokoll teil und akzeptieren das höchste Gebot. Dies wird als Proposer/Builder Separation (PBS) bezeichnet. Dieser Ansatz hat in anderen Branchen Präzedenzfälle: Einer der Hauptgründe, warum Restaurants so dezentralisiert bleiben konnten, ist, dass sie dazu neigen, sich für verschiedene Vorgänge auf ziemlich zentralisierte Lieferanten zu verlassen, die enorme Skaleneffekte haben. Bisher war PBS recht erfolgreich darin, sicherzustellen, dass kleine und große Validatoren gleiche Wettbewerbsbedingungen haben, zumindest was MEV betrifft. Es bringt jedoch ein weiteres Problem mit sich: Die Aufgabe, auszuwählen, welche Transaktionen einbezogen werden sollen, wird zentralisierter.

Meine Meinung dazu war schon immer, dass die Minimierung des MEV gut ist und wir sie verfolgen sollten (ich persönlich verwende Cowswap sehr häufig!) – obwohl es viele Herausforderungen mit Krypto-Mempools gibt, reicht die Minimierung des MEV möglicherweise nicht aus; der MEV wird nicht auf Null oder auch nur annähernd Null fallen. Daher brauchen wir auch eine Art MEV-Isolierung. Dies führt zu einer interessanten Aufgabe: Wie machen wir die MEV-Isolationsbox so klein wie möglich? Wie geben wir den Erbauern so wenig Macht wie möglich und ermöglichen ihnen dennoch, die Rolle der Optimierung von Arbitrage und anderen Formen der MEV-Sammlung zu übernehmen?

Wenn Builder die Möglichkeit haben, Transaktionen vollständig aus Blöcken auszuschließen, können leicht Angriffe erfolgen. Nehmen wir an, Sie haben eine besicherte Schuldposition (CDP) in einem DeFi-Protokoll, die durch einen Vermögenswert abgesichert ist, dessen Preis rapide fällt. Sie möchten Ihre Sicherheiten erhöhen oder Ihre CDP beenden. Ein böswilliger Builder könnte versuchen, sich abzusprechen, um die Aufnahme Ihrer Transaktion zu verweigern und sie dadurch zu verzögern, bis der Preis so weit fällt, dass Ihre CDP liquidiert werden muss. Wenn dies geschieht, müssen Sie eine hohe Strafe zahlen und der Builder erhält einen großen Teil davon. Wie verhindern wir also, dass Builder Transaktionen ausschließen und solche Angriffe durchführen?

Hier kommen Include-Listen ins Spiel.

Quelle: ethresear.ch

Inklusionslisten ermöglichen es Blockvorschlaggebern (also Beteiligten), auszuwählen, welche Transaktionen in einen Block aufgenommen werden müssen. Ersteller können Transaktionen weiterhin neu anordnen oder eigene einfügen, aber sie müssen die Transaktion des Vorschlaggebers einschließen. Schließlich wurden Inklusionslisten geändert, um den nächsten Block statt des aktuellen Blocks einzuschränken. In beiden Fällen nehmen sie Erstellern die Möglichkeit, Transaktionen vollständig aus einem Block zu entfernen.

MEV ist ein komplexes Problem; selbst die obige Beschreibung lässt viele wichtige Nuancen aus. Wie es heißt: „Sie suchen vielleicht nicht nach MEV, aber MEV sucht nach Ihnen.“ Ethereum-Forscher sind sehr konsequent in ihrem Ziel geblieben, „die isolierte Box zu minimieren“ und den Schaden zu minimieren, den Builder anrichten können (z. B. durch Ausschließen oder Verzögern von Transaktionen als Möglichkeit, eine bestimmte Anwendung anzugreifen).

Dennoch denke ich, dass wir noch weiter gehen können. In der Vergangenheit wurden Inklusionslisten oft als „Sonderfall-Feature“ betrachtet: Normalerweise denkt man nicht über sie nach, aber sie bieten einem einen „zweiten Ausweg“, falls ein böswilliger Builder verrückte Dinge tut. Diese Einstellung spiegelt sich in aktuellen Designentscheidungen wider: Im aktuellen EIP liegt das Gaslimit für Inklusionslisten bei etwa 2,1 Mio. Aber wir können unsere Denkweise über Inklusionslisten philosophisch ändern: Betrachten Sie die Inklusionsliste als Block und die Rolle des Builders als Hilfsfunktion, die einige Transaktionen hinzufügt, um MEV zu sammeln. Was wäre, wenn der Builder ein Gaslimit von 2,1 Mio. hätte?

Ich finde die Idee in diese Richtung – die Quarantänebox wirklich so klein wie möglich zu machen – sehr interessant und bin dafür, in diese Richtung zu gehen. Dies ist eine Abkehr von der Philosophie der Ära 2021: In der Philosophie der Ära 2021 sind wir begeisterter von der Idee, dass wir jetzt, da wir Builder haben, ihre Funktionalität überladen und sie den Benutzern auf komplexere Weise dienen lassen können, z. B. durch die Unterstützung von ERC-4337-Gebührenmärkten. In dieser neuen Philosophie muss der Transaktionsüberprüfungsteil von ERC-4337 in das Protokoll integriert werden. Glücklicherweise ist das ERC-4337-Team zunehmend begeistert von dieser Richtung.

Zusammenfassung: Die MEV-Überlegungen haben sich wieder in Richtung einer Stärkung der Blockproduzenten bewegt, einschließlich der Möglichkeit, Blockproduzenten die Einbeziehung von Benutzertransaktionen direkt sicherzustellen. Vorschläge zur Kontoabstraktion haben sich wieder in Richtung einer Beseitigung der Abhängigkeit von zentralisierten Relayern und sogar Bundlern bewegt. Es gibt jedoch ein gutes Argument dafür, dass wir noch nicht weit genug gegangen sind, und ich denke, der Druck, die Entwicklung in diese Richtung voranzutreiben, ist sehr willkommen.

Liquiditäts-Staking

Heutzutage machen einzelne Staker nur einen relativ kleinen Prozentsatz aller eingesetzten Ethereum-Werte aus, und die meisten Einsätze werden von einer Vielzahl von Anbietern durchgeführt – einigen zentralisierten Betreibern und anderen DAOs wie Lido und RocketPool.

Ich habe meine eigenen Nachforschungen angestellt – verschiedene Umfragen, Befragungen, persönliche Gespräche, und die Frage gestellt: „Warum staken Sie – speziell Sie – heute nicht alleine?“ Für mich ist ein starkes Solo-Staking-Ökosystem bei weitem mein bevorzugtes Ergebnis für Ethereum-Staking, und eines der besten Dinge an Ethereum ist, dass wir tatsächlich versuchen, ein starkes Solo-Staking-Ökosystem zu unterstützen, anstatt einfach der Delegation nachzugeben. Von diesem Ergebnis sind wir jedoch noch weit entfernt. In meinen Umfragen und Befragungen gibt es einige konsistente Trends:

Die überwiegende Mehrheit derjenigen, die nicht alleine staken, nennen das Minimum von 32 ETH als Hauptgrund.

Der größte Grund für die Nennung anderer Gründe waren die technischen Herausforderungen beim Betrieb und der Wartung eines Validierungsknotens.

Der Verlust der sofortigen Verfügbarkeit von ETH, die Sicherheitsrisiken „heißer“ privater Schlüssel und der Verlust der Möglichkeit, gleichzeitig an DeFi-Protokollen teilzunehmen, sind allesamt bedeutende, aber kleinere Probleme.

Die Farcaster-Umfrage hat die Hauptgründe aufgezeigt, warum Leute nicht alleine spielen.

Die Staking-Forschung muss sich mit zwei zentralen Fragen befassen:

Wie gehen wir mit diesen Bedenken um?

Wenn die meisten Leute trotz effizienter Lösungen für die meisten Probleme immer noch nicht individuell staken wollen, wie können wir das Protokoll dann trotzdem stabil und robust gegen Angriffe halten?

Zahlreiche laufende Forschungs- und Entwicklungsprojekte zielen auf die Lösung dieser Probleme ab:

Verkle-Bäume in Verbindung mit EIP-4444 ermöglichen den Betrieb von abgesteckten Knoten mit sehr geringem Festplattenbedarf. Darüber hinaus ermöglichen sie eine nahezu sofortige Synchronisierung abgesteckter Knoten, was den Einrichtungsprozess und Vorgänge wie den Wechsel von einer Implementierung zu einer anderen erheblich vereinfacht. Sie machen Ethereum Light-Clients auch praktikabler, indem sie die Datenbandbreite reduzieren, die zum Bereitstellen von Nachweisen für jeden Statuszugriff erforderlich ist.

Forschung (wie diese Vorschläge) zu Möglichkeiten, größere Validator-Sets zu ermöglichen (was kleinere Mindesteinsätze ermöglicht) und gleichzeitig den Overhead des Konsensknotens zu reduzieren. Diese Ideen könnten als Teil der Single-Slot-Finalität umgesetzt werden. Dies würde auch die Sicherheit von Light-Clients erhöhen, da sie den gesamten Signatursatz überprüfen könnten, anstatt sich auf ein Synchronisierungskomitee verlassen zu müssen.

Trotz dieser wachsenden Geschichte reduzieren laufende Ethereum-Clientoptimierungen weiterhin die Kosten und den Aufwand für den Betrieb eines Validierungsknotens.

Die Erforschung von Strafobergrenzen könnte möglicherweise Bedenken hinsichtlich des Risikos privater Schlüssel lindern und es Stakern ermöglichen, ihre ETH gleichzeitig in DeFi-Protokollen einzusetzen, wenn sie dies wünschen.

0x 01 Auszahlungsgutschein ermöglicht es Stakern, ihre ETH-Adresse als Auszahlungsadresse festzulegen. Dies macht dezentrale Staking-Pools praktikabler und verschafft ihnen einen Vorteil gegenüber zentralisierten Staking-Pools.

Wir können jedoch noch mehr tun. Theoretisch ist es möglich, Validierern schnellere Auszahlungen zu ermöglichen: Casper FFG wäre auch dann noch sicher, wenn sich der Validierersatz bei jeder Finalisierung (also einmal pro Epoche) um einige Prozentpunkte ändert. Wir können den Zyklus also deutlich verkürzen, wenn wir uns genug anstrengen. Wenn wir die Mindesteinzahlungsgröße deutlich reduzieren möchten, können wir harte Entscheidungen treffen und in andere Richtungen Kompromisse eingehen. Wenn wir beispielsweise die Finalisierungszeit um das Vierfache erhöhen, verringert sich die Mindesteinzahlungsgröße um das Vierfache. Die Single-Slot-Finalität wird dieses Problem später lösen, indem sie über das Modell, bei dem jeder Staker an jeder Epoche teilnimmt, hinausgeht.

Ein weiterer wichtiger Teil der gesamten Frage ist die Ökonomie des Stakings. Eine zentrale Frage ist: Wollen wir, dass Staking eine relativ nischenhafte Aktivität bleibt, oder wollen wir, dass jeder oder fast jeder sein gesamtes ETH staked? Wenn jeder staked, welche Verantwortung soll dann jeder tragen? Wenn die Leute am Ende einfach Verantwortung delegieren, weil sie faul sind, kann das in einer Zentralisierung enden. Hier gibt es wichtige und tiefgründige philosophische Fragen. Die falsche Antwort könnte Ethereum auf einen Weg der Zentralisierung führen und das traditionelle Finanzsystem mit zusätzlichen Schritten neu erschaffen; die richtige Antwort könnte ein leuchtendes Beispiel für ein erfolgreiches Ökosystem mit einer breiten und vielfältigen Palette unabhängiger Staker und hochgradig dezentralisierten Staking-Pools schaffen. Diese Fragen betreffen die Kernökonomie und die Werte von Ethereum, also brauchen wir eine vielfältigere Beteiligung.

Knotenhardwareanforderungen

Viele der zentralen Probleme im Zusammenhang mit der Dezentralisierung von Ethereum laufen letztlich auf eine Frage hinaus, die ein Jahrzehnt der Blockchain geprägt hat: Wie komfortabel wollen wir Knoten betreiben und wie können wir dies erreichen?

Heutzutage ist es schwierig, einen Knoten zu betreiben. Die meisten Leute machen das nicht. Auf dem Laptop, den ich zum Schreiben dieses Beitrags verwende, habe ich einen Reth-Knoten, der 2,1 TB belegt – bereits das Ergebnis heroischer Softwareentwicklung und -optimierung. Ich muss eine zusätzliche 4-TB-Festplatte kaufen, um diesen Knoten in meinen Laptop einzubauen. Wir alle möchten, dass das Betreiben eines Knotens einfacher ist. In meiner idealen Welt können die Leute einen Knoten auf ihren Telefonen betreiben.

Wie ich oben geschrieben habe, sind EIP-4444 und Verkle-Bäume zwei Schlüsseltechnologien, die uns diesem Ideal näher bringen. Wenn beide implementiert werden, könnten die Hardwareanforderungen für einen Knoten schließlich auf weniger als hundert Gigabyte reduziert werden und könnten nahe Null liegen, wenn wir die Verantwortung für die Speicherung des Verlaufs vollständig eliminieren (vielleicht nur für Knoten ohne Staking). Typ 1 ZK-EVM würde die Notwendigkeit beseitigen, EVM-Berechnungen selbst auszuführen, da Sie einfach Beweise dafür überprüfen können, dass die Ausführung korrekt war. In meiner idealen Welt hätten wir alle diese Technologien zusammen gestapelt, und sogar Ethereum-Browser-Erweiterungs-Wallets (z. B. Metamask, Rabby) hätten einen integrierten Knoten, um diese Beweise zu überprüfen, Datenverfügbarkeitsstichproben durchzuführen und sicherzustellen, dass die Kette korrekt ist.

Die obige Vision wird oft als „The Verge“ bezeichnet.

Dies ist alles bekannt und wird auch von denen verstanden, die Bedenken hinsichtlich der Größe der Ethereum-Knoten äußern. Es gibt jedoch ein wichtiges Problem: Wenn wir die Verantwortung für die Aufrechterhaltung des Status und die Bereitstellung von Beweisen entfernen, ist dies dann nicht ein Zentralisierungsvektor? Selbst wenn sie nicht betrügen können, indem sie ungültige Daten bereitstellen, verstößt es nicht gegen die Prinzipien von Ethereum, sich zu stark auf sie zu verlassen?

Eine neuere Version dieser Sorge ist das Unbehagen, das viele mit EIP-4444 haben: Wenn reguläre Ethereum-Knoten alte Historie nicht mehr speichern müssen, wer dann? Eine häufige Antwort lautet: Es gibt sicherlich genügend große Akteure (z. B. Block Explorer, Börsen, Layer 2), die einen Anreiz haben, diese Daten zu speichern, und die Ethereum-Kette ist klein im Vergleich zu den 100 PB, die von der Wayback Machine gespeichert werden. Daher ist die Vorstellung, dass irgendeine Historie tatsächlich verloren gehen kann, lächerlich.

Dieses Argument basiert jedoch auf einer kleinen Anzahl großer Akteure. In meiner Taxonomie von Vertrauensmodellen ist dies eine 1-zu-N-Annahme, aber N ist sehr klein. Dies birgt gewisse Risiken. Eine Möglichkeit besteht darin, alte Historien in einem Peer-to-Peer-Netzwerk zu speichern, in dem jeder Knoten nur einen kleinen Teil der Daten speichert. Ein solches Netzwerk hätte immer noch genügend Replikation, um Robustheit zu gewährleisten: Es gäbe Tausende von Kopien jedes Datenelements, und in Zukunft könnten wir Erasure Coding verwenden (und zwar indem wir die Historie in Blobs im EIP-4844-Stil einfügen, in die Erasure Coding bereits integriert ist), um die Stabilität weiter zu verbessern.

Blobs verfügen über Erasure Coding innerhalb und zwischen Blobs. Der einfachste Weg, ultrastabilen Speicher für die gesamte Ethereum-Geschichte bereitzustellen, besteht wahrscheinlich darin, Beacons und Ausführungsblöcke in Blobs zu platzieren. Bildquelle: codex.storage

Diese Arbeit wurde zu lange auf die lange Bank geschoben. Das Portalnetzwerk existiert, hat aber nicht die Aufmerksamkeit erhalten, die seiner Bedeutung für die Zukunft von Ethereum angemessen wäre. Glücklicherweise gibt es jetzt die Dynamik, mehr Ressourcen in eine Minimalversion des Portals zu stecken, die sich auf verteilte Speicherung und Zugänglichkeit der Historie konzentriert. Wir sollten darauf aufbauen und zusammenarbeiten, um EIP-4444 so schnell wie möglich zu implementieren, gepaart mit einem starken dezentralen Peer-to-Peer-Netzwerk zum Speichern und Abrufen alter Historie.

Mit Status und ZK-EVM ist dieser verteilte Ansatz schwieriger. Um einen effizienten Block zu erstellen, müssen Sie nur den vollständigen Status haben. In diesem Fall bevorzuge ich persönlich einen pragmatischen Ansatz: Wir definieren und halten uns an ein gewisses Maß an Hardwareanforderungen, die erforderlich sind, um einen Knoten zu haben, der alles macht. Das ist höher als die (idealerweise immer geringer werdende) Kostenkette einfacher Validierungsknoten, aber immer noch niedrig genug, dass es sich Hobbyisten leisten können. Wir verlassen uns auf die Annahme 1 in N und stellen sicher, dass N ziemlich groß ist.

ZK-EVM-Beweise sind wahrscheinlich der schwierigste Teil, und ein Live-ZK-EVM-Beweiser wird wahrscheinlich leistungsfähigere Hardware erfordern als ein Archivknoten, selbst mit Fortschritten wie Binius und Worst-Case-Grenzen für mehrdimensionales Gas. Wir könnten an einem verteilten Beweisnetzwerk arbeiten, in dem jeder Knoten die Verantwortung übernimmt, beispielsweise ein Prozent der Blockausführung zu beweisen, und der Blockproduzent am Ende nur noch hundert Beweise aggregieren muss. Beweisaggregationsbäume könnten mehr helfen. Aber wenn das nicht gut funktioniert, dann wäre ein weiterer Kompromiss, die Hardwareanforderungen für Beweise höher werden zu lassen, aber sicherzustellen, dass der Knoten, der alles macht, Ethereum-Blöcke schnell genug direkt verifizieren kann (ohne Beweise), um effektiv am Netzwerk teilzunehmen.

Zusammenfassen

Ich denke, die Ethereum-Denkweise im Jahr 2021 ist wirklich darauf ausgerichtet, die Verantwortung auf einige wenige große Akteure zu verlagern, solange es einen Marktmechanismus oder ein Zero-Knowledge-Beweissystem gibt, das die zentralisierten Akteure zu ehrlichem Handeln zwingt. Solche Systeme funktionieren im Durchschnitt normalerweise gut, versagen aber im schlimmsten Fall katastrophal.

Gleichzeitig halte ich es für wichtig zu betonen, dass sich die aktuellen Ethereum-Protokollvorschläge deutlich von diesem Modell entfernt haben und die Notwendigkeit eines wirklich dezentralisierten Netzwerks viel ernster nehmen. Ideen rund um zustandslose Knoten, MEV-Minderung, Single-Slot-Finalität und ähnliche Konzepte sind in diese Richtung weiter gegangen. Vor einem Jahr wurde die Idee der Datenverfügbarkeitsabtastung über Relais als halbzentralisierte Knoten ernsthaft in Betracht gezogen. In diesem Jahr haben wir uns von der Notwendigkeit, dies zu tun, entfernt, und PeerDAS hat überraschend große Fortschritte gemacht.

Wir können jedoch viel tun, um in dieser Richtung bei allen drei zentralen Themen, die ich oben angesprochen habe, sowie bei vielen anderen wichtigen Themen weiter voranzukommen. Helios hat große Fortschritte bei der Bereitstellung eines „echten Light Clients“ für Ethereum gemacht. Jetzt müssen wir ihn standardmäßig in Ethereum-Wallets einbinden und RPC-Anbieter Beweise und ihre Ergebnisse bereitstellen lassen, damit sie überprüft werden können, und die Light-Client-Technologie auf Layer-2-Protokolle ausweiten. Wenn Ethereum über eine Rollup-zentrierte Roadmap skaliert, muss Layer 2 die gleichen Sicherheits- und Dezentralisierungsgarantien erhalten wie Layer 1. Es gibt viele andere Dinge, die wir in einer Rollup-zentrierten Welt ernster nehmen sollten; dezentrale und effiziente Cross-L2-Brücken sind eines von vielen Beispielen. Viele Dapps erhalten ihre Protokolle über zentralisierte Protokolle, weil Ethereums natives Protokoll-Scanning zu langsam geworden ist. Wir können dies mit dedizierten dezentralen Unterprotokollen verbessern; hier ist einer meiner Vorschläge, wie das zu erreichen ist.

Es gibt eine nahezu unendliche Anzahl von Blockchain-Projekten, die auf den Markt „Wir können superschnell sein, über Dezentralisierung denken wir später nach“ abzielen. Ich glaube nicht, dass Ethereum sich dieser Party anschließen sollte. Ethereum L1 kann und sollte sicherlich eine starke Basisschicht für Layer-2-Projekte sein, die einen Hyperscale-Ansatz verfolgen und Ethereum als Rückgrat für Dezentralisierung und Sicherheit verwenden. Selbst ein Layer-2-zentrierter Ansatz erfordert, dass Layer 1 selbst skalierbar genug ist, um eine große Anzahl von Vorgängen zu verarbeiten. Aber wir sollten die Funktionen, die Ethereum einzigartig machen, zutiefst respektieren und weiterhin daran arbeiten, diese Funktionen beizubehalten und zu verbessern, während Ethereum skaliert.

Dieser Artikel stammt aus dem Internet: Vitalik: Kurzfristige und mittelfristige Pläne zur Verbesserung der Erlaubnisfreiheit und Dezentralisierung von Ethereum

Verwandt: Ist Zero-Knowledge-Maschinenlernen (zkML) die Zukunft der On-Chain-KI? (mit einer Einführung in Qualitätsprojekte)

Originalautor | @DistilledCrypto Compilation | Golem Seit der Popularität großer Sprachmodelle wie ChatGPT ist das Ausführen ähnlicher Modelle des maschinellen Lernens in dezentralen Netzwerken zu einem der Hauptthemen von Blockchain + KI geworden. Wir können jedoch nicht darauf vertrauen, dass dezentrale Netzwerke bestimmte ML-Modelle zum Schlussfolgern verwenden, wie wir seriösen Unternehmen wie OpenAI vertrauen, also müssen wir dies überprüfen. In Anbetracht des Datenschutzes ist Zero-Knowledge-Maschinenlernen (zkML) im Allgemeinen optimistisch, wird es also die Zukunft der On-Chain-KI sein? In diesem Artikel wird Odaily Planet Daily kurz die Grundlagen von zkML vorstellen, die zkML-Projekte, die der Aufmerksamkeit wert sind, und abschließend kurz die Einschränkungen von zkML und alternative Lösungen erläutern. Grundlagen von zkML Zero-Knowledge-Maschinenlernen (zkML) ähnelt einem Vertraulichkeitsansatz in der Computertechnik.…