Vitalik: Wie sollte sich das Ethereum -Protokoll im Surge -Stadium entwickeln?

Hinweis: Dieser Artikel ist der zweite Teil der kürzlich von Vitalik, Gründerin von Ethereum, „The Future of the Ethereum Abkommen“ veröffentlichten Artikelserie, die kürzlich veröffentlicht wurde.Mögliche Futures für das Ethereum -Protokoll, Teil 2: Der Anstieg„Der erste Teil wird im vorherigen Bericht über Bitchain Vision gezeigt“Was kann bei Ethereum POS noch verbessert werden”.

Zu Beginn gab es in der Roadmap von Ethereum zwei Skalierungsstrategien.

Einer von ihnen ist „Sharding“: Jeder Knoten muss nur einen kleinen Teil der Transaktionen überprüfen und speichern, nicht alle Transaktionen in der Kette.Auf diese Weise funktioniert jedes andere Peer-to-Peer-Netzwerk (z. B. BitTorrent), sodass wir die Blockchain auf die gleiche Weise funktionieren können.

Das andere ist das 2-Schicht-Protokoll:Die Netzwerke befinden sich über Ethereum und ermöglichen es ihnen, vollständig von ihrer Sicherheit zu profitieren, die meisten Daten zu halten und von der Hauptkette fernzuhalten.Das „Layer -2 -Protokoll“ bezieht sich auf den Statuskanal 2015, das Plasma 2017 und die Rollups 2019.Rollups sind leistungsstärker als Staatskanäle oder Plasma, benötigen jedoch viele On-Chain-Datenbandbreite.

Glücklicherweise hat Sharding Research bis 2019 das Problem der großen Überprüfung der „Datenverfügbarkeit“ angesprochen.Infolgedessen haben sich die beiden Wege verschmolzen und wir haben eine rollup-zentrierte Roadmap erhalten, die heute noch die Skalierungsstrategie von Ethereum ist.

The Surge, 2023 Roadmap Edition.

Die rollup-zentrierte Roadmap schlägt eine einfache Arbeitsteilung vor: Ethereum L1 konzentriert sich darauf, eine starke und dezentrale Grundschicht zu werden, während L2 die Aufgabe übernimmt, der Ökosystemskala zu helfen.Dies ist ein wiederkehrendes Muster in der Gesellschaft (metaphorisch und buchstäblich) Mars.

In diesem Jahr hat die rollup-zentrierte Roadmap einen signifikanten Erfolg erzielt: Die Datenbreite von Ethereum L1 hat durch EIP-4844-Blobs erheblich zugenommen, und mehrere EVM-Rollups sind jetzt in Phase 1.Sehr heterogene und diversifizierte Implementierungen von Shards, bei denen jedes L2 als „Fragment“ mit eigenen internen Regeln und Logik wirksam ist.Aber wie wir gesehen haben, hat dieser Weg seine eigenen Herausforderungen.daher,Jetzt ist es unsere Mission, die rollup-zentrierte Roadmap zu vervollständigen und diese Probleme zu lösen, während die Robustheit und Dezentralisierung beibehält, die Ethereum L1 auszeichnet.

Surge: Hauptziele

L1+ L2 auf 100.000+ TPS

Behalten Sie die Dezentralisierung und Robustheit von L1 bei

Mindestens einige L2s erben die Kernattribute von Ethereum (vertrauenslos, offen, zensurresistent)

Maximale Interoperabilität zwischen L2s.Ethereum sollte sich wie ein Ökosystem anfühlen, nicht 34 verschiedene Blockchains.

Die Triade der Skalierbarkeit

Das im Jahr 2017 vorgeschlagene Skalierbarkeit unmögliches Dreieck ist eine Spannung zwischen den drei Eigenschaften der Blockchain: Dezentralisierung (insbesondere: niedrige Kosten für laufende Knoten), Skalierbarkeit (genauer (Insbesondere: Ein Angreifer muss die meisten Knoten im gesamten Netzwerk zerstören, um eine einzelne Transaktion ausfällt).

Es ist erwähnenswert, dass das Triad -Dilemma kein Theorem ist und die Beiträge, die das Triad -Dilemma einführen, nicht mit mathematischer Beweis geliefert werden.Es gibt ein heuristisches mathematisches Argument: Wenn ein dezentraler freundlicher Knoten (wie ein Verbraucher -Laptop) N -Transaktionen pro Sekunde verifizieren kann, und Sie eine Kette haben, die K*n -Transaktionen pro Sekunde verarbeitet, ist (i) jede Transaktion nur zu sehen Durch 1/K -Knoten, was bedeutet, dass ein Angreifer nur ein paar Knoten brechen kann, um schlechte Transaktionen zu treiben, oder (ii) Ihr Knoten wird stark und Ihre Kette ist nicht dezentralisiert.Der Zweck dieses Artikels ist es, niemals zu zeigen, dass das Brechen der Triade unmöglich ist.

Im Laufe der Jahre haben einige Hochleistungsketten häufig behauptet, dass sie die Triade gelöst haben, ohne clevere Maßnahmen auf der Infrastrukturebene zu ergreifen, häufig durch die Verwendung von Software-Engineering-Fähigkeiten zur Optimierung der Knoten.Dies ist immer irreführend, und es ist immer viel schwieriger als in Ethereum.In diesem Beitrag werden viele Feinheiten darüber untersucht, warum dies geschieht (und warum L1 Client Software Engineering das Ethereum selbst nicht allein skalieren kann).

Jedoch,Die Kombination aus Datenverfügbarkeitstichpläne (DAS) und SNark löst die Triade: Es ermöglicht dem Client zu überprüfen, ob eine bestimmte Datenmenge verfügbar ist und ob eine bestimmte Anzahl von Berechnungsschritten korrekt ausgeführt wird, während nur ein kleiner Teil dieser Daten heruntergeladen wird und die Anzahl der ausgeführten Berechnungen viel geringer ist.Snark ist nicht glaubwürdig.Die Datenverfügbarkeitsabtastung verfügt über ein subtiles Minderheit und ein Vertrauensmodell, behält jedoch die grundlegenden Eigenschaften bei, die nicht skalierbare Ketten haben, und sogar 51% der Angriffe können das Netzwerk nicht dazu zwingen, schlechte Blöcke zu akzeptieren.

Eine andere Möglichkeit, die Triade zu lösen, ist die Plasma -Architektur, die mit cleveren Techniken die Verantwortung für die Überwachung der Datenverfügbarkeit der Benutzer für Benutzer auf eine kompatible Weise vorantreibt.Bereits in den Jahren 2017-2019 waren die Sicherheitsfunktionen von Plasma nur sehr begrenzt, als alles, was wir mussten, Betrugsbeweis war, aber das Mainstreaming von Snark wurde Plasmakörnern besser für eine breitere Reihe von Anwendungsfällen als zuvor geeignet.

Weitere Fortschritte bei DAS

Welche Probleme wollen wir lösen?

Bis zum 13. März 2024, als das Dencun-Upgrade live ging, hatte die Ethereum Blockchain 3 „Blobs“ von etwa 125 KB alle 12-Sekunden-Zeiten oder etwa 375 KB Daten verfügbare Bandbreite pro Zeitraum.Unter der Annahme, dass Transaktionsdaten direkt in die Kette veröffentlicht werden, beträgt die ERC20 -Übertragung etwa 180 Bytes, sodass die maximalen TPs von Rollups auf Ethereum:

375000 / 12/180 = 173,6 tps

Wenn wir Ethereums CallData hinzufügen (theoretisches Maximum: 30 Millionen Gas pro Schlitz / 16 Gas pro Byte = 1.875.000 Bytes pro Schlitz), wird dies zu 607 tps.Für Peerdas ist geplant, das Ziel des Blob Count auf 8-16 zu erhöhen, was uns einen Calldata von 463-926 TPS ermöglicht.

Dies ist eine signifikante Verbesserung gegenüber Ethereum L1, aber das reicht nicht aus.Wir wollen mehr Skalierbarkeit.Unser mittelfristiges Ziel ist 16 MB pro Schlitz, was in Kombination mit Verbesserungen der Sinkdatenkomprimierung ungefähr 58.000 tps erhalten wird.

Was ist Peerdas und wie funktioniert es?

Peerdas ist eine relativ einfache Implementierung von „eindimensionaler Stichproben“.Jeder Blob in Ethereum ist ein Polynom von 4096 Ordnung auf der 253-Bit-Prime-Domäne.Wir übertragen die „Aktien“ des Polynoms, wobei jede Aktie aus 16 Bewertungen an benachbarten 16 Koordinaten besteht, die aus einem Gesamtsatz von 8192 Koordinaten stammen.Der Blob kann durch alle 4096 von 8192 Bewertungen wiederhergestellt werden (unter Verwendung der derzeit empfohlenen Parameter: alle 64 von 128 möglichen Proben).

Peerdas arbeitet, indem jeder Client ein kleines Quantennetzwerk anhört, in dem das I-TH-Subnetz die I-te-Probe eines jeden Blobs übernimmt und auch die benötigten für andere Subnetze verlangt, indem sie Kollegen im globalen P2P-Netzwerk fragen Hören Sie sich verschiedene Subnetze an).Die konservativere Version von SubNetdas verwendet nur den Subnetzmechanismus und hat keine zusätzlichen Anforderungen Peer -Ebenen.Die aktuelle Empfehlung lautet, dass die an dem Beweis für die Beteiligten teilnehmenden Knoten Subnetdas und die anderen Knoten (d. H. Der „Client“) Peerdas verwenden.

Theoretisch können wir 1D -Stichproben ziemlich weit skalieren: Wenn wir die Blob -Anzahl maximal auf 256 erhöhen (also ist das Ziel 128), werden wir das 16 -MB -Ziel erreichen, während die Datenverfügbarkeitsabtastung nur 16 pro Knotenproben kostet* 128 Blobs* 512 Bytes pro Blob pro Probe = 1 MB Datenbandbreite pro Slot.Dies liegt nur in unserer Toleranz: Es ist machbar, aber es bedeutet, dass die von Bandbreiten begrenzten Kunden nicht probieren können.Wir können dies optimieren, indem wir die Anzahl der Blobs reduzieren und die Größe der Blobs erhöhen. Dies macht den Rekonstruktion jedoch teurer.

Letztendlich wollen wir noch einen Schritt weiter gehen und eine 2D -Stichprobe durchführen, die nicht nur zufällig innerhalb des Blob, sondern auch zwischen Blobs probiert.Die von KZG versprochenen linearen Eigenschaften werden verwendet, um den in einem Block eingestellten Blob von redundant codierten neuen „virtuellen Blobs“ -Listen zu „verlängern“.

2D -Probenahme

Entscheidend ist, dass die rechnerisch versprochene Skalierung keine Blobs erfordert, daher ist das System grundsätzlich freundlich zu verteiltem Blockgebäude.Die Knoten, die den Block tatsächlich bauen, müssen nur Blob KZG versprechen und können sich auf DAS verlassen, um die Verfügbarkeit von Blobs zu überprüfen.1D DAS ist auch im Wesentlichen freundlich zu verteiltem Blockbau.

Was sind die Verbindungen zu bestehenden Forschung?

Originalartikel zur Einführung von Datenverfügbarkeit (2018):https://github.com/ethereum/research/wiki/a-note-on-data-AVailability-and-serasure-coding

Follow-up-Papiere:https://arxiv.org/abs/1809.09044

Interpreter Post für DAS, Paradigma:https://www.paradigm.xyz/2022/08/das

KZG versprach 2D -Verfügbarkeit:https://ethresear.ch/t/2d-data-AVailability-with-kate-commitments/8081

Peerdas auf ethresear.ch:https://ethresear.ch/t/peerdas-a–Simpler-das-approach-using-battle-tested-p2p-components/16541Und Papiere:https://eprint.iacr.org/2024/1362

EIP-7594:https://eips.ethereum.org/eips/eip-7594

Subnetdas auf ethresear.ch:https://ethresear.ch/t/subnetdas-an-intermediate-das-apploach/17169

Subtile Unterschiede in der Wiederherstellung in der 2D -Probenahme:https://ethresear.ch/t/nuancesof-data-recoverability-in-data-AVailability-samping/16256

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Der nächste Schritt besteht darin, die Implementierung und Rollout von Peerdas zu vervollständigen.Seitdem ist die Erhöhung der Blob -Anzahl von Peerdas eine allmähliche Anstrengung, während das Netzwerk sorgfältig beobachtet und die Software für die Sicherheit verbessert wird.Gleichzeitig hoffen wir, mehr akademische Arbeiten an der Formalisierung von DAS und anderen Versionen von DAS und seiner Interaktion mit Problemen wie der Sicherheit der Gabelauswahlregeln zu leisten.

In Zukunft müssen wir mehr tun, um die ideale Version von 2D DAS herauszufinden und seine Sicherheitsfunktionen zu beweisen.Wir hoffen auch, schließlich von KZG zu einer Alternative zu wandern, die ohne ein vertrauenswürdiges Setup gegen Quantenresistent resistent ist.Im Moment wissen wir nicht, welche Kandidaten mit verteiltem Blockgebäude freundlich sind.Sogar die teure „starke“ Technik, um rekursive Stark zu verwenden, um Gültigkeitsbeweise für den Wiederaufbau von Zeilen und Säulen zu erzeugen, reicht nicht aus ), Stark ist eigentlich fast so groß wie der gesamte Ort.

Auf lange Sicht denke ich, dass der Realitätspfad:

• Ideales 2D -DAS -Werkzeug;

• Halten Sie sich an 1D DAS, opfern Sie die Effizienz der Abtastbandbreite für Einfachheit und Robustheit und akzeptieren niedrigere Datenkappen;

• (Hard Pivot) Geben Sie DA auf und umarmen Sie Plasma vollständig als Hauptarchitektur der Tier 2, auf die wir uns konzentrieren.

Wir können uns diese ansehen, indem wir den Umfang abwägen:

Beachten Sie, dass diese Auswahl auch dann bestehen bleibt, wenn wir die Ausführung direkt auf L1 erweitern.Dies liegt daran -Evm und Das) und L1.

Wie interagiert es mit dem Rest der Roadmap?

Wenn die Datenkomprimierung implementiert wird (siehe unten), wird die Nachfrage nach 2D -DAS reduziert oder zumindest verzögert, und wenn das Plasma weit verbreitet ist, wird die Nachfrage nach 2D -DAS weiter reduziert.DAS stellt außerdem Herausforderungen für verteilte Blockbauprotokolle und -mechanismen vor: Obwohl DAS theoretisch mit dem verteilten Rekonstruktion freundlich freundlich ist, muss es in der Praxis mit dem Gabelauswahlmechanismus kombiniert werden, der Listenvorschläge und ihre Umgebung enthält.

Datenkomprimierung

Welche Probleme wollen wir lösen?

Jede Transaktion in Rollup nimmt viel On-Chain-Datenraum ein: Die ERC20-Übertragung dauert ungefähr 180 Bytes.Dies schränkt die Skalierbarkeit des Schicht -2 -Protokolls auch bei der Verwendung idealer Daten zur Datenverfügbarkeit ein.16 MB pro Slot bekommen wir:

16000000 / 12/180 = 7407 tps

Was ist, wenn wir den Nenner zusätzlich zur Lösung des Zählers lösen und jede Transaktion in Rollup weniger Bytes in der Kette einnehmen können?

Was ist es und wie funktioniert es?

Ich denke, die beste Erklärung ist dieses Bild von vor zwei Jahren:

Die einfachste Verstärkung ist die Null-Byte-Komprimierung: Ersetzen Sie jede lange Null-Byte-Sequenz durch zwei Bytes, die die Anzahl von Null-Byten darstellen.Weiter ausnutzen wir die spezifischen Eigenschaften der Transaktion:

• Signaturaggregation– Wir wechseln von der ECDSA -Signatur zur BLS -Signatur, die Eigenschaften aufweist, die viele Signaturen zu einer einzigen Signatur bilden können, die die Gültigkeit aller ursprünglichen Signaturen beweist.L1 berücksichtigt dies nicht, da die Rechenkosten der Validierung (auch die Verwendung der Aggregation) höher sind, aber in Daten, die knapp sind, wie L2, sind sie wohl sinnvoll.Die Aggregationsfunktion von ERC-4337 bietet eine Möglichkeit, dies zu erreichen.

• Die Adresse durch Zeiger ersetzen-Wenn Sie zuvor eine Adresse verwendet haben, können wir die 20-Byte-Adresse durch einen 4-Byte-Zeiger an den historischen Ort ersetzen.Dies ist notwendig, um den maximalen Gewinn zu erzielen, obwohl es Anstrengungen erfordert, um zu erreichen, da die Geschichte der Blockchain (zumindest ein Teil) erforderlich ist, um effektiv Teil des Landes zu sein.

• Benutzerdefinierte Serialisierung von Transaktionswerten– Die meisten Transaktionswerte haben beispielsweise nur sehr wenige Zahlen.0,25 ETH werden als 250.000.000.000.000.000.000 Wei ausgedrückt.Gas Max-BaseFees funktioniert ähnlich wie Prioritätsgebühren.Daher können wir benutzerdefinierte Dezimal -Gleitpunktformate oder sogar Wörterbücher von besonders gemeinsamen Werten verwenden, die die meisten Währungswerte sehr kompakt darstellen.

Was sind die Verbindungen zur vorhandenen Forschung?

Erkundung von Sequence.xyz:https://sequence.xyz/blog/compressing-calldata

CallData -Optimierungsverträge für L2 von Scopelift:https://github.com/scopelift/l2-optimizooors

Eine andere Strategie – Rollup (auch bekannt als Zkrollup) basierend auf dem Gültigkeitsnachweis für die Unterschiede zur Freisetzungstatus anstelle von Transaktionen:https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-toce-rece-l2-data-footprint-on-l1/9975-L2-Daten Fußabdruck

BLS Wallet – BLS -Aggregation über ERC -4337:https://github.com/getwax/bls-wallet

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Die Hauptaufgabe ist die Implementierung des obigen Planes.Die wichtigsten Kompromisse sind:

• Das Umschalten auf BLS -Signaturen erfordert große Anstrengungen und verringert die Kompatibilität mit vertrauenswürdigen Hardware -Chips, die die Sicherheit verbessern.Es kann durch den ZK-Snark-Wrapper anderer Signaturschemata ersetzt werden.

• Dynamische Komprimierung (z. B. das Ersetzen von Adresse durch Zeiger) kompliziert den Client -Code.

• Die Posting -Statusunterschiede zu einer Kette und nicht zu einer Transaktion verringern die Auditierbarkeit und machen viele Software (z. B. Blockbrowser) nicht verarbeitbar.

Wie interagiert es mit dem Rest der Roadmap?

Die Einführung von ERC-4337 und die ultimative Einbeziehung einiger seiner Inhalte in L2 EVM können den Einsatz der Aggregationstechnologie erheblich beschleunigen.Durch die Einbeziehung von Teilen von ERC-4337 in L1 kann der Einsatz auf L2 beschleunigt werden.

Verallgemeinerter Plasma

Welche Probleme wollen wir lösen?

Selbst mit 16 MB -Blobs und Datenkomprimierung reichen 58.000 TPS nicht unbedingt aus, um die Verbraucherzahlungen, dezentrale soziale oder andere Bereiche mit hoher Bandbreite vollständig zu übernehmen.Für große Kapazitäten, Anwendungen mit niedrigem Wert, eine Option heute ist gültig, wodurch Daten nicht in Kette gesetzt werden und ein interessantes Sicherheitsmodell enthält, bei dem die Betreiber nicht die Mittel der Benutzer stehlen können, aber alle Benutzer Mittel vorübergehend oder dauerhaft einfrieren können .Aber wir können es besser machen.

Was ist es und wie funktioniert es?

Plasma ist eine Verlängerungslösung, bei der Operatoren Blöcke außerhalb des Kettens veröffentlichen und die Merkle-Wurzeln dieser Blöcke in die Kette platzieren (im Gegensatz zu Rollups legt Rollups den gesamten Block in die Kette).Für jeden Block sendet der Bediener einen Merkle -Zweig an jeden Benutzer und beweist, was passiert ist oder nichts mit den Vermögenswerten dieses Benutzers passiert.Benutzer können Vermögenswerte extrahieren, indem sie Merkle Branch bereitstellen.Wichtig ist, dass die Filiale nicht im neuesten Zustand verwurzelt sein muss. Selbst wenn die Verfügbarkeit von Daten ausfällt, können Benutzer ihre Vermögenswerte dennoch wiederherstellen, indem sie den neuesten verfügbaren Status widerrufen.Wenn ein Benutzer eine ungültige Filiale einreicht (z. B. ein Vermögenswert, den er an eine andere Person gesendet hat, oder der Bediener ein Vermögenswert aus der Luft schafft), kann der On-Chain-Herausforderungsmechanismus bestimmen, wem das Vermögenswert korrekt gehört.

Plasma -Geldkettendiagramm.Die Transaktion der Kostenmünze I wird in der I-ten Position im Baum platziert.In diesem Beispiel wissen wir unter der Annahme, dass alle früheren Bäume gültig sind, dass Eve derzeit Coin 1 besitzt, David Coin 4 und George Coin 6.

Frühe Plasmaversionen können nur Zahlungswendungsfälle für Zahlung behandeln und können nicht effektiv fördert werden.Wenn wir jedoch verlangen, dass jede Wurzel mit Snark verifiziert wird, wird Plasma stärker.Jedes Challenge -Spiel kann stark vereinfacht werden, da wir die meisten möglichen Wege für das Betrug des Bedieners beseitigen.Es wurden ebenfalls neue Wege geöffnet, sodass die Plasma -Technologie auf ein breiteres Spektrum von Anlagenklassen expandieren kann.Schließlich können Benutzer sofort Geld abheben, ohne auf eine Woche der Herausforderung zu warten, ohne auf die Herausforderungsperiode zu warten.

Eine Möglichkeit, EVM-Plasmaketten zu machen (nicht der einzige Weg): Erstellen Sie einen parallelen UTXO-Baum mit ZK-Snark, reflektieren die von EVM vorgenommenen Gleichgewichtsänderungen und definieren, was die einzigartige Zuordnung von „gleicher Münze“ in der Geschichte ist.Dann können Sie die Plasmastruktur auf dieser Grundlage bauen.

Ein wichtiger Einblick ist, dass Plasma -Systeme nicht perfekt sein müssen.Selbst wenn Sie nur einen Teil Ihres Vermögens schützen können (z. B., auch wenn es sich nur um Token handelt, die in der vergangenen Woche nicht mehr bewegt wurden), haben Sie den Status quo von hyperzerzbaren EVMs erheblich verbessert, was eine Validierung ist.

Eine andere Art von Struktur ist eine hybride Plasma-/Rollups -Struktur wie Intmax.Diese Strukturen setzen eine sehr geringe Datenmenge in eine Kette (z. B. 5 Bytes). Auf diese 16 MB Welt, die theoretische Kapazität beträgt ungefähr 16.000.000 / 12/5 = 266.667 tps.

Was sind die Verbindungen zu bestehenden Forschung?

Originalplasmapapier:https://plasma.io/plasma-teprecated.pdf

Plasmageld:https://ethresear.ch/t/plasma-cash-plasma-with-much-ant-per-user-data-check/1298

Plasma -Cashflow:https://hackmd.io/dgzmjirjszcyvl4lujzxnq?view#-exit

Intmax (2023):https://eprint.iacr.org/2023/1082

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Die verbleibende Hauptaufgabe besteht darin, das Plasmasystem in die Produktion zu bringen.Wie oben erwähnt, sind „Plasma und Validium“ keine binären Oppositionen: Jedes Validium kann mindestens ein wenig Sicherheitsleistung verbessern, indem die Plasma -Funktionalität zum Ausgangsmechanismus hinzugefügt wird.Die Forschung zielt teilweise darauf ab, die besten Attribute der EVM (in Bezug auf Vertrauensanforderungen, Worst-Case-L1-Gaskosten und DOS-Verwundbarkeit) und alternative anwendungsspezifische Strukturen zu erhalten.Darüber hinaus weist Plasma im Vergleich zu Rollups eine größere konzeptionelle Komplexität auf und muss direkt gelöst werden, indem ein besserer allgemeiner Rahmen untersucht und aufgebaut wird.

Der Hauptnachteil bei der Verwendung von Plasmadesigns ist, dass sie operatorabhängiger und schwieriger zu „basieren“ sind, obwohl hybride Plasma-/Rollup-Designs diese Schwäche häufig vermeiden.

Wie interagiert es mit dem Rest der Roadmap?

Je effektiver die Plasma-Lösung ist, desto weniger Spannung muss der L1 Daten zur Verfügbarkeit von Hochleistungsdaten aufweisen.Das Verschieben der Aktivität in L2 reduziert auch den MEV -Druck auf L1.

Reife L2 Proof -System

Welche Probleme wollen wir lösen?

Heute sind die meisten Rollups nicht vertrauenswürdig.In einigen Fällen existiert das Proof -System gar nicht einmal oder auch wenn es existiert, es hat nur eine „Beratungs“ -Funktion.Die führenden sind (i) einige anwendungsspezifische Rollups, wie z. Phase“.Der Grund, warum sich Rollups nicht weiter entwickelt haben, ist die Sorgen um Fehler im Code.Wir müssen Rollup vertrauen, also müssen wir dieses Problem direkt lösen.

Was ist es und wie funktioniert es?

Lassen Sie uns zunächst das „Bühnen“ -System überprüfen, das ursprünglich in diesem Artikel eingeführt wurde.Es gibt detailliertere Anforderungen, aber die Zusammenfassung lautet wie folgt:

• Stufe 0:Der Benutzer muss in der Lage sein, den Knoten auszuführen und die Kette zu synchronisieren.Wenn die Überprüfung vollständig vertrauenswürdig/zentralisiert ist.

• Phase 1:Es muss ein (vertrauensloses) Beweissystem geben, um sicherzustellen, dass nur gültige Transaktionen akzeptiert werden.Es gibt einen Sicherheitsausschuss, der das Proof -System umkippen kann, aber es gibt nur eine 75% ige Abstimmungsschwelle.Darüber hinaus muss sich der Quorum blockierende Teil des Rates (d. H. Über 26%) außerhalb der Hauptfirmen befinden, die Rollup gebaut haben.Upgrade-Mechanismen mit schwächerem Gesichtsausfall (wie DAO) sind erlaubt, aber es muss eine lange Verzögerung vorliegen, sodass Benutzer, wenn ein böswilliges Upgrade genehmigt wird, die Mittel beenden, bevor das Upgrade live geht.

• Phase 2:Es muss ein (nicht vertrauenswürdiges) Beweissystem geben, um sicherzustellen, dass nur gültige Transaktionen akzeptiert werden.Der Rat darf nur eingreifen, wenn beispielsweise ein nachgewiesener Fehler im Code vorliegt.Wenn zwei redundante Beweissysteme nicht miteinander nicht übereinstimmen oder wenn ein Proof-System zwei verschiedene Wurzeln nach dem Zustand desselben Blocks akzeptiert (oder nichts lange genug akzeptiert, z. B. eine Woche).Der Upgrade -Mechanismus ist erlaubt, aber es muss eine lange Verzögerung geben.

Unser Ziel ist es, die zweite Stufe zu erreichen.Die größte Herausforderung für das Erreichen der zweiten Phase besteht darin, genug Vertrauen zu gewinnen, um zu beweisen, dass das System tatsächlich vertrauenswürdig genug ist.Es gibt zwei wichtige Möglichkeiten, dies zu tun:

• Formelle Überprüfung:Wir können moderne mathematische und rechnerische Techniken verwenden, um zu beweisen (optimistisch oder Gültigkeit), dass das System nur Blöcke akzeptiert, die die EVM -Spezifikation übergeben.Diese Technologien gibt es schon seit Jahrzehnten, aber die jüngsten Fortschritte (wie Lean 4) machen sie praktischer, und Fortschritte bei AI-unterstützten Beweisen können diesen Trend weiter beschleunigen.

• Mehrere Korrekturader:Multiple Proof-Systeme und investieren Fonds in 2-von-3 (oder größere) Multisignaturen zwischen diesen Proof-Systemen und dem Sicherheitsrat (und/oder anderen Widgets mit Vertrauensannahmen wie TEE).Wenn nachgewiesen wird, dass das System zustimmt, hat der Rat keine Macht.Wenn sie nicht einverstanden sind, kann der Rat nur einen von ihnen auswählen und kann seine eigene Antwort nicht einseitig auferlegen.

Ein stilisiertes Diagramm von Multi-Provener, das ein optimistisches Proof-System, einen Nachweis des Effektivitätssystems und ein Sicherheitsausschuss kombiniert.

Was sind die Verbindungen zur vorhandenen Forschung?

EVM K -Semantik (formelle Überprüfungsarbeit seit 2017):https://github.com/runtimeVerification/evm-semantics

Demo über die Idee von Multi-Proven-Personen (2022):https://www.youtube.com/watch?v=6Hfvzcwt6yi

Taiko plant, mehrere Beweise zu verwenden:https://docs.taiko.xyz/core-concepts/multi-proofs/

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Es gibt viele für die formelle Überprüfung.Wir müssen eine formale validierte Version des gesamten Snark -Proofers des EVM erstellen.Dies ist ein äußerst komplexes Projekt, obwohl wir bereits begonnen haben.Es gibt einen Trick, der die Aufgaben erheblich vereinfachen kann: Wir können beispielsweise einen formell validierten Snarkprover für die kleinste virtuelle Maschine erstellen.RISC-V oder Kairo schreiben dann eine Implementierung des EVM in diesem minimalen VM (und beweisen das Äquivalent einiger anderer EVM-Spezifikationen formell).

Für mehrere Provers gibt es zwei verbleibende wichtige Teile.Erstens müssen wir genug Vertrauen in mindestens zwei verschiedene Beweissysteme haben, von denen jedes ziemlich sicher ist, und wenn sie abstürzen, stürzen sie aus verschiedenen und irrelevanten Gründen ab (so dass sie nicht gleichzeitig abstürzen).Zweitens müssen wir eine sehr hohe Sicherheit in der zugrunde liegenden Logik des Zusammensetzungssystems erhalten.Dies ist ein kleines Stück Code.Es gibt verschiedene Möglichkeiten, es sehr klein zu machen-nur Geld in einem sicheren Mehrsignaturvertrag zu lagern, dessen Unterschrift ein Vertrag ist, das ein persönliches Beweissystem darstellt-, aber dies ist zu hohen Kosten für Kettengas.Es besteht die Notwendigkeit, ein gewisses Gleichgewicht zwischen Effizienz und Sicherheit zu finden.

Wie interagiert es mit dem Rest der Roadmap?

Die bewegliche Aktivität in L2 reduziert den MEV -Druck auf L1.

Cross-L2-Interoperabilitätsverbesserungen

Welche Probleme wollen wir lösen?

Eine der größten Herausforderungen im heutigen L2 -Ökosystem besteht darin, dass es für Benutzer schwierig ist, manipulieren zu können.Darüber hinaus führt der einfachste Ansatz Vertrauensannahmen häufig wieder ein: zentralisierte Brücken, RPC -Kunden usw.Wenn wir die Idee nehmen, dass L2 ernsthaft Teil von Ethereum ist, müssen wir das L2 -Ökosystem wie ein einheitliches Ethereum -Ökosystem anfühlen.

Ein Beispiel für ein pathologisch schlechtes (sogar gefährlich: Ich habe hier persönlich 100 US -Dollar für die falsche Kettenauswahl verloren) in L2 UX – während dies nicht Polymarkets Schuld ist, sollte die Interoperabilität von L2 für die Community der Brieftaschen- und Ethereum -Standards (Verantwortung (ERC) (ETHEREUM Standards) sein.In einem gut geführten Ethereum-Ökosystem sollte das Senden von Token von L1 nach L2 oder von einem L2 zu einem anderen wie das Senden von Token in derselben L1 aussehen.

Was ist es und wie funktioniert es?

Es gibt viele Kategorien von Cross-L2-Interoperabilitätsverbesserungen.Im Allgemeinen ist der Weg, diese Fragen zu stellen, zu beachten und die aktuelle Ethereum L2 -Version.Hier sind einige:

• Linkspezifische Adresse:Die Kette (L1, Optimismus, Arbitrum …) sollte Teil der Adresse sein.Nach der Implementierung können Sie den Cross-L2-Sendeprozess implementieren, indem Sie einfach die Adresse in das Feld „Senden“ einlegen, und die Brieftasche kann herausfinden, wie Sie den Hintergrund einsenden (einschließlich der Verwendung des Brückenprotokolls).

• Kettenspezifische Zahlungsanfragen:Das Erstellen von Nachrichten in Form von „Senden Sie mir ein Y -Typ X -Token in der Z -Kette“ sollte einfach und standardisiert sein.Dafür gibt es zwei Hauptanwendungsfälle: (i) Zahlung, unabhängig davon, ob es sich um eine Person für eine Person oder eine Person für einen Händlerdienst handelt, und (ii) beispielsweise ein DAPP, der Gelder anfordert.Das obige Polymarket -Beispiel.

• Cross-Chain-Börse und Gaszahlung:Es sollte ein standardisiertes offenes Protokoll geben, um kreuzkettenübergreifende Operationen wie „Ich sende 1 ETH über den Optimismus an jemanden, der 0,9999 ETH auf Arbitrum sendet“ und „Ich sende 0,0001 ETH auf Optimismus“ jeder schließt dies auf Arbitrum-Transaktionen ein. 7683 ist ein Versuch für erstere, während RIP-7755 ein Versuch für letztere ist, obwohl beide allgemeiner sind als diese spezifischen Anwendungsfälle.

• Leichter Client:Benutzer sollten in der Lage sein, die Kette tatsächlich zu überprüfen, mit der sie interagieren, anstatt nur dem RPC -Anbieter zu vertrauen.Die Kryptowährung von Helios von A16Z hat dies für Ethereum selbst getan, aber wir müssen diese Vertrauenslosigkeit auf L2 ausdehnen.ERC-3668 (CCIP-Read) ist eine Strategie, um dies zu erreichen.

Wie leichte Kunden die Ansicht ihrer Ethereum Header -Kette aktualisieren.Sobald Sie eine Header -Kette haben, können Sie Merkle Proof verwenden, um jedes Zustandsobjekt zu überprüfen.Sobald Sie über das richtige L1-Statusobjekt verfügen, können Sie jedes Statusobjekt auf L2 mithilfe von Merkle Proof überprüfen (oder eine Signatur, wenn Sie die Vorbeurteilung überprüfen möchten).HeliosHabe das erstere getan.Die Ausdehnung von letzterem ist eine Herausforderung der Standardisierung.

• Keystore Wallet:Wenn Sie heute den Schlüssel aktualisieren möchten, der eine intelligente Vertragsbrieftasche steuert, müssen Sie dies auf allen N -Ketten tun, in denen sich diese Brieftasche befindet.Eine Keystore -Brieftasche ist eine Technik, mit der der Schlüssel an einem Ort (sei es auf L1 oder später L2) und dann von einem beliebigen L2 mit einer Kopie der Brieftasche gelesen wird.Dies bedeutet, dass das Update nur einmal erfolgen muss.Um die Effizienz zu verbessern, muss L2 l1 standardisierte Möglichkeiten haben, load und remotestatische Verbreitung standardisiert zu haben.

Ein stilisiertes Diagramm darüber, wie eine Keystore -Brieftasche funktioniert.

• Radikalere „gemeinsame Token Bridge“ -Voridee:Stellen Sie sich eine Welt vor, in der alle L2 ein bewährtes Rollup sind, wobei jeder Slot Ethereum gewidmet ist.Selbst in dieser Welt erfordert „lokale“ Übertragung von Vermögenswerten von einem L2 auf einen anderen Abhebung und Einlagen, was eine große Menge L1 -Gas erfordert.Eine Möglichkeit, dieses Problem zu lösen, besteht darin, ein gemeinsames Mindestrollup zu erstellen, dessen einzige Funktion darin besteht, den Gleichgewicht zu erhalten, dessen L2 die Art von Tokens hat, und diese Balancen über eine Reihe von Crossovers gemeinsam aktualisiert werden können.L2 SEND -Operation von einem beliebigen L2 initiiert.Dies ermöglicht die Übertragung über L2, ohne für L1-Gas pro Getriebe zu zahlen.

• Synchronverbesserbarkeit:Ermöglicht synchrone Aufrufe zwischen spezifischem L2 und L1 oder zwischen mehreren L2s.Dies kann dazu beitragen, die finanzielle Effizienz des Defi -Protokolls zu verbessern.Ersteres kann ohne Cross-L2-Koordination durchgeführt werden.Rollup ist automatisch zu all diesen Technologien freundlich.

Was sind die Verbindungen zur vorhandenen Forschung?

Kettenspezifische Adresse: ERC-3770:https://eips.ethereum.org/eips/eip-3770

ERC-7683:https://eips.ethereum.org/eips/eip-7683

RIP-7755:https://github.com/wilsoncusack/rips/blob/cross-l2-call-standard/Rips/rip-7755.md

Scrollen Sie Keystore Wallet -Design:https://hackmd.io/@haichen/keystore

Helios:https://github.com/a16z/helios

ERC-3668 (manchmal als CCIP-Read bezeichnet):https://eips.ethereum.org/eips/eip-3668

Der Vorschlag von Justin Drakes für „basierend auf (gemeinsam genutzter) Vorbestätigung“:https://ethresear.ch/t/based-preconfirmations/17353

L1SLOAD (RIP-7728):https://ethereum-magices.org/t/rip-7728-l1sload-precompile/20388

Optimistische Remote -Anrufe:https://github.com/ethereum-optimism/ecosystem-contributions/issues/76

Agglayer, das die Idee des Teilens der Token -Brücke enthält:https://github.com/agglayer

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Viele der oben genannten Beispiele stehen vor dem Standarddilemma, wann sie standardisiert werden sollen und welche Standardisierungschichten.Wenn die Standardisierung zu früh ist, besteht möglicherweise das Risiko von Lösungen mit schlechter Qualität.Wenn die Standardisierung zu spät ist, kann dies zu unnötigen Fragmentierung führen.In einigen Fällen gibt es kurzfristige Lösungen, die schwächer, aber einfacher zu implementieren sind, sowie langfristige Lösungen, die „endlich korrekt“ sind, aber es dauert eine ganze Weile.

Was an diesem Abschnitt einzigartig ist, ist, dass diese Aufgaben nicht nur technische Probleme sind: Sie sind (vielleicht hauptsächlich!) Soziale Probleme.Sie brauchen L2 und Brieftaschen und L1, um zusammenzuarbeiten.Unsere Fähigkeit, dieses Problem erfolgreich zu behandeln, ist ein Test unserer Fähigkeit, sich als Gemeinschaft zu vereinen.

Wie interagiert es mit dem Rest der Roadmap?

Die meisten dieser Vorschläge sind „höhere“ Strukturen und haben daher keinen großen Einfluss auf L1 -Überlegungen.Eine Ausnahme ist die gemeinsame Sortierung, die einen großen Einfluss auf MEVs hat.

Erweiterte Ausführung auf L1

Welche Probleme wollen wir lösen?

Wenn L2 sehr skalierbar und erfolgreich wird, L1 jedoch immer noch nur mit sehr kleinen Transaktionen umgehen kann, gibt es viele Risiken für Ethereum:

• Die wirtschaftliche Situation von ETH-Vermögenswerten wird gefährlicher, was wiederum die langfristige Sicherheit des Netzwerks beeinflusst.

• Viele L2s profitieren von einer engen Verbindung zum hoch entwickelten Finanzökosystem auf L1, und wenn dieses Ökosystem stark geschwächt ist, wird die Motivation, L2 (und nicht ein separater L1) zu werden, geschwächt.

• Es dauert lange, bis der L2 genau die gleiche Sicherheit wie der L1 hat.

• Wenn L2 fehlschlägt (zum Beispiel aufgrund böswilliger Operationen oder Verschwinden von Trägern), muss der Benutzer immer noch L1 durchgehen, um seine Vermögenswerte wiederherzustellen.Daher muss L1 stark genug sein, um zumindest gelegentlich mit dem Ende des hochkomplexen und chaotischen L2 umzugehen.

Aus diesen Gründen ist es wertvoll, den L1 selbst weiter zu erweitern und sicherzustellen, dass es sich weiterhin an immer mehr Verwendungen anpassen kann.

Was ist es und wie funktioniert es?

Der einfachste Weg, um sich zu erweitern, besteht darin, einfach Gasgrenzen hinzuzufügen.Dies besteht jedoch aus dem Risiko, L1 zu zentralisieren, und schwächt so ein anderes wichtiges Attribut, das Ethereum L1 so mächtig macht: seine Glaubwürdigkeit als starke zugrunde liegende Schicht.Es wurde diskutiert, wie einfache Gasbeschränkungen für nachhaltig erhöht werden, und dies wird auch je nach Umsetzung anderer Technologien variieren, um größere Blöcke zu überprüfen (z. B. historischer Ablauf, zu Staatelo, L1 EVM -Nachweis der Gültigkeit).Eine weitere wichtige Sache, die kontinuierlich verbessert werden muss, ist die Effizienz der Ethereum -Client -Software, die heute optimierter ist als vor fünf Jahren.Eine effektive Strategie zur Erhöhung der L1 -Gasbeschränkung wird die Beschleunigung dieser Überprüfungstechniken umfassen.

Eine andere Skalierungsstrategie besteht darin, bestimmte Merkmale und Computertypen zu identifizieren, die billiger werden können, ohne die Netzwerkdispersion oder deren Sicherheitseigenschaften zu beeinträchtigen.Beispiele hierfür sind:

• Eof– Ein neues EVM-Bytecode-Format, das statischere analysefreundlicher ist und eine schnellere Implementierung ermöglicht.Angesichts dieser Effizienz können der EOF -Bytecode niedrigere Gaskosten gegeben werden.

• Mehrdimensionale Gaspreise– Das Erstellen separater Grundkosten und Einschränkungen für Computer, Daten und Speicher kann die durchschnittliche Kapazität von Ethereum L1 erhöhen, ohne die maximale Kapazität zu erhöhen (und damit neue Sicherheitsrisiken zu erstellen).

• Reduzieren Sie die Gaskosten für bestimmte Opcodes und vorkompiliert– In der Vergangenheit haben wir bei bestimmten unterbewerteten Operationen mehrere Runden von Gaskostensteigerungen durchgeführt, um die Ablehnung von Dienstangaben zu vermeiden.Wir haben weniger getan, können aber mehr tun, und das dient dazu, die Gaskosten für überteuerte Operationen zu senken.Zum Beispiel ist Addition viel billiger als die Multiplikation, aber die Kosten für Add und Mul -Opcodes sind derzeit gleich.Wir können billiger und noch einfachere Opcodes (wie Push) billiger machen.Es gibt viele EOFs als Ganzes.

• EVM-MAX und SIMD: EVM-max („Modulare arithmetische Erweiterungen“) ist ein Vorschlag, der eine effizientere modulare modulare Mathematik als separates Modul für EVM ermöglicht.Werte, die durch EVM-Max-Berechnungen berechnet werden, können nur von anderen EVM-Max-Opcodes zugegriffen werden, es sei denn, es wird absichtlich exportiert.SIMD („Einzelanweisungs-Multi-Data“) ist ein Vorschlag, der eine effiziente Ausführung derselben Anweisungen für ein Array von Werten ermöglicht.Zusammen können die beiden einen leistungsstarken Coprozessor mit EVM erstellen, mit dem Verschlüsselungsvorgänge effizienter implementiert werden können.Dies ist besonders nützlich für Datenschutzprotokolle und L2 -Proof -Systeme, daher hilft es bei der Expansion der L1- und L2.

Diese Verbesserungen werden in zukünftigen Artikeln über Pracht ausführlicher erörtert.

Schließlich ist die dritte Strategie native Rollup (oder „eingebaute Rollup, verankerte Rollups“): Im Wesentlichen können viele Kopien von EVMs, die parallel laufen, ein Modell bilden, das den Modellen entspricht, die Rollups liefern können, sich jedoch stärker in das Protokoll integrieren.

Was sind die Verbindungen zu bestehenden Forschung?

Polyyas Ethereum L1 Expansion Roadmap:https://polynya.mirror.xyz/epju72rsyncfb-jk52_uyi7huhj-w_zm735ndp7alkaq

Mehrdimensionale Gaspreise:https://vitalik.eth.limo/general/2024/05/09/multidim.html

EIP-7706:https://eips.ethereum.org/eips/eip-7706

Eof:https://evmobjectFormat.org/

Evm-max:https://ethereum-magicess.org/t/eip-6601-evm-modular-arithmetic-euttses-evmmax/13168

SIMD:https://eips.ethereum.org/eips/eip-616

Native Rollup:https://mirror.xyz/ohotties.eth/p1qsccwj2fz9cqo3_6kyi4s2Chw5k5tmegogk6io1ge

Interview mit Max Resnick über den Wert der Erweiterung von L1:https://x.com/banklesshq/status/1831319419739361321

Justin Drake über die Ausdehnung mit Snark und Native Rollup:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Es gibt drei Strategien für L1 -Erweiterungen, die einzeln oder parallel ausgeführt werden können:

• Verbesserte Technologien (z. B. Client -Code, staatenloser Kunde, historischer Ablauf) erleichtern L1, zu überprüfen und dann die Gasgrenzwerte zu erhöhen

• Reduzieren Sie die Kosten eines bestimmten Betriebs und erhöhen Sie die durchschnittliche Kapazität, ohne das Worst-Case-Risiko zu erhöhen

• Native Rollup (d. H. „Erstellen Sie n parallele Replikate von EVM“, obwohl es den Entwicklern bei der Bereitstellung der Parameter von Replikaten eine Menge Flexibilität darstellt.

Es ist zu verstehen, dass dies unterschiedliche Technologien mit unterschiedlichen Kompromisse sind.Zum Beispiel hat native Rollup viele der gleichen Schwächen wie regelmäßige Rollups in Bezug auf die Komposition: Sie können keine einzige Transaktion senden, um Operationen synchron über mehrere Transaktionen hinweg durchzuführen, genau wie Sie Verträge mit demselben L1 (oder L2) verarbeiten können.Erhöhung der Gasbeschränkungen entzieht andere Vorteile, die durch die Überprüfung von L1 erzielt werden können, z. B. das Erhöhen des Prozentsatzes der Benutzer, die Überprüfungsknoten ausführen und die einzelnen Interessengruppen erhöhen.Das Erreichen spezifischer Operationen in EVM billiger (je nachdem, wie es betrieben wird), kann die Gesamtkomplexität des EVM erhöhen.

Eine große Frage, dass eine Roadmap von L1 Expansion beantwortet werden muss, ist: Was ist die ultimative Vision von L1 und L2?Offensichtlich ist es lächerlich, alles auf L1 zu tun: Die potenziellen Anwendungsfälle haben Hunderttausende von Transaktionen pro Sekunde, was L1 vollständig nicht überprüft macht (es sei denn, wir nehmen die native Rollup -Route).Wir brauchen jedoch einige Leitprinzipien, damit wir sicherstellen können, dass wir keine Situation verursachen, in der wir die Gasgrenze um das Zehn Mal erhöhen, die Dezentralisierung von Ethereum L1 ernsthaft verletzen und feststellen, dass wir nur eine Welt betreten, nicht 99 % Die Aktivität liegt bei L2 und 90% der Aktivität zu L2, sodass die Ergebnisse fast gleich aussehen, mit Ausnahme der meisten irreversiblen Verluste der Besonderheit von Ethereum L1.

Eine vorgeschlagene Ansicht über die „Arbeitsteilung“ zwischen L1 und L2

Wie interagiert es mit dem Rest der Roadmap?

Mehr Benutzer in L1 zu bringen, bedeutet, nicht nur skalieren, sondern auch andere Aspekte von L1.Dies bedeutet, dass mehr MEVs auf L1 bleiben werden (anstatt nur ein Problem mit L2), daher ist es dringlicher, explizit damit umzugehen.Es erhöht den Wert der schnellen Schlitzzeit für L1 stark.Es hängt auch stark davon ab, ob die Überprüfung von L1 („The Verge“) reibungslos verlief.

Besonderer Dank geht an Justin Drake, Francesco, Hsiao-Wei Wang, @antonttc und Georgios Konstantopoulos