Wie unterscheiden sich Layer 2s wirklich von der Ausführung des Sharding?

Einer der Punkte, die ich vor zweieinhalb Jahren in meinem Beitrag gemacht habe auf "the Endgame"ist, dass die verschiedenen zukünftigen Entwicklungswege für eine Blockchain, zumindest technologisch, überraschend ähnlich aussehen. In beiden Fällen haben Sie eine sehr große Anzahl von Transaktionen onchain, deren Verarbeitung (i) eine große Menge an Berechnungen und (ii) eine große Menge an Datenbandbreite erfordert. Reguläre Ethereum-Knoten, wie z. B. die 2 TB reth Archivknotenauf dem Laptop, den ich zum Schreiben dieses Artikels verwende, sind nicht leistungsstark genug, um eine derart große Menge an Daten und Berechnungen direkt zu überprüfen, selbst mit heroischer Software-Engineering-Arbeit und Verkle Bäume. Stattdessen sowohl in „L1-Sharding“ als auch in einem rollup-zentrischWelt, ZK-SNARKswerden zur Überprüfung von Berechnungen verwendet und DASum die Datenverfügbarkeit zu überprüfen. Der DAS ist in beiden Fällen derselbe. Die ZK-SNARKs sind in beiden Fällen die gleiche Technologie, außer in einem Fall handelt es sich um Smart Contract-Code und im anderen Fall um ein fest verankertes Merkmal des Protokolls. In einem sehr realen technischen Sinne betreibt Ethereum Sharding, und Rollups sind Shards.

Das wirft eine natürliche Frage auf: Was ist der Unterschied zwischen diesen beiden Welten? Eine Antwort ist, dass die Folgen von Codefehlern unterschiedlich sind: In einer Rollup-Welt gehen Münzen verloren, und in einer Shard-Chain-Welt gibt es Konsensfehler. Aber ich erwarte, dass mit der Festigung der Protokolle und der Verbesserung der formalen Verifikationstechnologie die Bedeutung von Fehlern abnehmen wird. Was sind also die Unterschiede zwischen den beiden Visionen, von denen wir erwarten können, dass sie langfristig bestehen bleiben?

Vielfalt der Ausführungsumgebungen

Eine der Ideen, mit denen wir uns 2019 kurz in Ethereum beschäftigt haben, war AusführungsumgebungenIm Wesentlichen würde Ethereum verschiedene „Zonen“ haben, die unterschiedliche Regeln dafür haben könnten, wie Konten funktionieren (einschließlich völlig unterschiedlicher Ansätze wie UTXOs), wie die virtuelle Maschine funktioniert und andere Funktionen. Dies würde eine Vielfalt von Ansätzen in Teilen des Stapels ermöglichen, wo es schwierig wäre, dies zu erreichen, wenn Ethereum versuchen würde, alles alleine zu tun.

Am Ende haben wir einige der ehrgeizigeren Pläne aufgegeben und einfach den EVM beibehalten. Allerdings haben Ethereum L2s (einschließlich Rollups, Valdiums und Plasmas) möglicherweise die Rolle von Ausführungsumgebungen übernommen. Heutzutage konzentrieren wir uns im Allgemeinen auf EVM-äquivalente L2s, aber dies ignoriert die Vielfalt vieler alternativer Ansätze:

• Arbitrum Stylus, das eine zweite virtuelle Maschine auf Basis von WASMzusammen mit dem EVM.
• Kraftstoff, die eine Bitcoin-ähnliche (aber funktionsreichere) UTXO-basierte Architektur verwendet.
• Aztec, das eine neue Sprache und ein neues Programmierparadigma einführt, das um ZK-SNARK-basierte, die Privatsphäre wahrende Smart Contracts konzipiert ist.

UTXO-basierte Architektur. Quelle: Fuel-Dokumentation.

Wir könnten versuchen, den EVM in einen Super-VM zu verwandeln, der alle möglichen Paradigmen abdeckt, aber das hätte zu viel weniger effektiven Implementierungen jeder dieser Konzepte geführt als die Spezialisierung von Plattformen wie diesen.

Sicherheitskompromisse: Skalierbarkeit und Geschwindigkeit

Ethereum L1 bietet eine wirklich starke Sicherheitsgarantie. Wenn sich ein Datenstück in einem Block befindet, der auf L1 finalisiert ist, arbeitet der gesamte Konsens (einschließlich in extremen Situationen des sozialen Konsenses) daran sicherzustellen, dass die Daten nicht in einer Weise bearbeitet werden, die gegen die Regeln der Anwendung verstößt, die die Daten dort platziert hat, dass jede durch die Daten ausgelöste Ausführung nicht rückgängig gemacht wird und dass die Daten zugänglich bleiben. Um diese Garantien zu erreichen, ist Ethereum L1 bereit, hohe Kosten zu akzeptieren. Zum Zeitpunkt der Abfassung dieses Textes sind die Transaktionsgebühren relativ niedrig: Layer 2s kosten weniger als einen Centpro Transaktion, und selbst die L1 liegt unter 1 USD für eine einfache ETH-Überweisung. Diese Kosten können in Zukunft niedrig bleiben, wenn die Technologie schnell genug verbessert wird, dass der verfügbare Blockraum wächst, um mit der Nachfrage Schritt zu halten - aber das mag nicht der Fall sein. Und selbst 0,01 USD pro Transaktion sind für viele nichtfinanzielle Anwendungen wie z. B. soziale Medien oder Spiele zu hoch.

Aber soziale Medien und Spiele erfordern nicht dasselbe Sicherheitsmodell wie L1. Es ist in Ordnung, wenn jemand eine Million Dollar zahlen kann, um einen Datensatz umzukehren, in dem er ein Schachspiel verloren hat, oder einen Ihrer Twitter-Beiträge so aussehen lassen kann, als wäre er drei Tage nach dem tatsächlichen Datum veröffentlicht worden. Und so sollten diese Anwendungen nicht die gleichen Sicherheitskosten tragen müssen. Ein L2-zentrierter Ansatz ermöglicht dies, indem er eine Vielzahl von Datenverfügbarkeitsansätzen unterstützt vonRollupszuPlasmazuvalidiums.

Verschiedene L2-Typen für unterschiedliche Anwendungsfälle. Lesen Sie mehr hier.

Ein weiterer Sicherheitskompromiss ergibt sich rund um die Frage der Übertragung von Vermögenswerten von L2 zu L2. Im Extremfall (5-10 Jahre in die Zukunft) erwarte ich, dass alle Rollups ZK-Rollups sein werden und hyper-effiziente Beweissysteme wie Binius und Kreis STARKsmitSuchanfragen, plus Beweisaggregationsschichten, wird es L2s ermöglichen, in jedem Slot finalisierte Zustandsroots bereitzustellen. Derzeit haben wir jedoch eine komplizierte Mischung aus optimistischen Rollups und ZK-Rollups mit verschiedenen Beweiszeitfenstern. Wenn wir die Ausführungsschichtung im Jahr 2021 implementiert hätten, wäre das Sicherheitsmodell zur Aufrechterhaltung der Ehrlichkeit der Shards optimistische Rollups gewesen, nicht ZK - und daher hätte L1 das verwalten müssen.systemisch-komplexBetrugsbeweislogik on-chain und haben eine einwöchige Auszahlungsfrist für die Übertragung von Vermögenswerten von Shard zu Shard. Aber wie bei Code-Bugs denke ich, dass dieses Problem letztendlich vorübergehend ist.

Eine dritte, und einmal mehr dauerhafte, Dimension des Sicherheitskompromisses ist die Transaktionsgeschwindigkeit. Ethereum hat alle 12 Sekunden Blöcke und ist nicht bereit, viel schneller zu gehen, weil das das Netzwerk übermäßig zentralisieren würde. Viele L2s erforschen jedoch Blockzeiten von einigen hundert Millisekunden. 12 Sekunden ist bereits nicht so schlecht: Im Durchschnitt muss ein Benutzer, der eine Transaktion abschickt, ~6-7 Sekunden warten, um in einen Block aufgenommen zu werden (nicht nur 6, weil die Möglichkeit besteht, dass der nächste Block sie nicht einschließt). Dies ist vergleichbar mit dem, was ich warten muss, wenn ich eine Zahlung mit meiner Kreditkarte mache. Aber viele Anwendungen erfordern eine viel höhere Geschwindigkeit, und L2s bieten sie.

Um diese höhere Geschwindigkeit zu erreichen, verlassen sich L2s auf Vorbestätigungsmechanismen: Die eigenen Validatoren des L2s unterzeichnen digital ein Versprechen, die Transaktion zu einem bestimmten Zeitpunkt einzuschließen, und können bei Nicht-Einschluss der Transaktion bestraft werden. Ein Mechanismus namens StakeSureverallgemeinert dies weiter.

L2 Vorbestätigungen.

Jetzt könnten wir versuchen, all dies auf Ebene 1 zu tun. Ebene 1 könnte ein System für „schnelle Vorbestätigung“ und „langsame endgültige Bestätigung“ integrieren. Es könnte verschiedene Scherben mit unterschiedlichen Sicherheitsstufen integrieren. Dies würde jedoch eine Menge Komplexität in das Protokoll einbringen. Darüber hinaus würde die Durchführung all dies auf Ebene 1 ein Risiko darstellen Überlastung des Konsenses, weil viele der skalierbaren oder schnelleren Durchsatzansätze mit höheren Zentralisierungsrisiken verbunden sind oder stärkere Formen von 'Governance' erfordern, und wenn dies auf L1 durchgeführt wird, würden die Auswirkungen dieser stärkeren Anforderungen auf den Rest des Protokolls übergreifen. Indem Ethereum diese Kompromisse über Layer 2s anbietet, kann es diese Risiken größtenteils vermeiden.

Die Vorteile von Layer 2s in Organisation und Kultur

Stellen Sie sich vor, ein Land wird in zwei Hälften geteilt, wobei die eine Hälfte kapitalistisch wird und die andere stark von der Regierung gesteuert wird (im Gegensatz zu früher das passiertinRealität, nehmen wir an, dass es sich bei diesem Gedankenexperiment nicht um das Ergebnis eines traumatischen Krieges handelt; vielmehr entsteht eines Tages magisch eine Grenze und das war's). Im kapitalistischen Teil werden die Restaurants alle von verschiedenen Kombinationen dezentraler Eigentumsverhältnisse, Ketten und Franchiseunternehmen geführt. Im staatlich gelenkten Teil handelt es sich um allesamt Zweigstellen der Regierung, wie Polizeiwachen. Am ersten Tag würde sich nicht viel ändern. Die Menschen folgen größtenteils ihren bestehenden Gewohnheiten, und was funktioniert und was nicht, hängt von technischen Realitäten wie Arbeitsfähigkeiten und Infrastruktur ab. Ein Jahr später würden Sie jedoch große Veränderungen erwarten, da die unterschiedlichen Anreizstrukturen und Kontrollmechanismen zu großen Veränderungen im Verhalten führen, die beeinflussen, wer kommt, wer bleibt und wer geht, was gebaut wird, was instand gehalten wird und was verfällt.

IndustrieorganisationDie Theorie umfasst viele dieser Unterscheidungen: Sie spricht nicht nur über die Unterschiede zwischen einer staatlich geführten Wirtschaft und einer kapitalistischen Wirtschaft, sondern auch zwischen einer Wirtschaft, die von großen Franchiseunternehmen dominiert wird, und einer Wirtschaft, in der z.B. jeder Supermarkt von einem unabhängigen Unternehmer geführt wird. Ich würde behaupten, dass der Unterschied zwischen einem Layer-1-zentrierten Ökosystem und einem Layer-2-zentrierten Ökosystem entlang ähnlicher Linien verläuft.

Eine „Kernentwickler führen alles“-Architektur, die sehr schief gelaufen ist.

Ich würde den wichtigsten Vorteil für Ethereum, ein Layer-2-zentrisches Ökosystem zu sein, wie folgt formulieren:

Da Ethereum ein Layer-2-zentrisches Ökosystem ist, können Sie unabhängig ein Sub-Ökosystem aufbauen, das Ihnen gehört und über einzigartige Funktionen verfügt, und gleichzeitig Teil eines größeren Ethereum ist.

Wenn Sie nur einen Ethereum-Client erstellen, sind Sie Teil eines größeren Ethereum, und obwohl Sie etwas Spielraum für Kreativität haben, ist es weitaus weniger als das, was für L2s verfügbar ist. Und wenn Sie eine völlig unabhängige Kette aufbauen, haben Sie maximalen Spielraum für Kreativität, aber Sie verlieren die Vorteile wie gemeinsame Sicherheit und gemeinsame Netzwerkeffekte. Layer 2s bilden einen glücklichen Mittelweg.

Layer 2s schaffen nicht nur eine technische Möglichkeit, um mit neuen Ausführungsumgebungen und Sicherheitsabwägungen zu experimentieren, um Skalierbarkeit, Flexibilität und Geschwindigkeit zu erreichen: Sie schaffen auch einen Anreiz: sowohl für die Entwickler, um es zu erstellen und zu pflegen, als auch für die Community, die sich darum bildet und es unterstützt.

Die Tatsache, dass jede L2 isoliert ist, bedeutet auch, dass das Bereitstellen neuer Ansätze ohne Erlaubnis erfolgt: Es ist nicht erforderlich, alle Kernentwickler davon zu überzeugen, dass Ihr neuer Ansatz für den Rest der Kette "sicher" ist. Wenn Ihre L2 scheitert, liegt das an Ihnen. Jeder kann an völlig abwegigen Ideen arbeiten (z. B. Intmaxs Ansatz für Plasma) und selbst wenn sie von den Ethereum-Kernentwicklern vollständig ignoriert werden, können sie weiterhin entwickeln und schließlich bereitstellen. L1-Funktionen und Vorabkompilierungen sind nicht so, und selbst in Ethereum hängt der Erfolg und Misserfolg in der L1-Entwicklung oft in einem höheren Maße von der Politik ab, als wir möchten. Unabhängig davon, was theoretisch gebaut werden könnte, beeinflussen die unterschiedlichen Anreize, die durch ein L1-zentriertes Ökosystem und ein L2-zentriertes Ökosystem geschaffen werden, letztendlich stark, was in der Praxis tatsächlich gebaut wird, mit welchem Qualitätsniveau und in welcher Reihenfolge.

Welche Herausforderungen hat das Layer-2-zentrierte Ökosystem von Ethereum?

Eine Layer-1- + Layer-2-Architektur, die sehr schief gelaufen ist.Quelle.

Es gibt eine Schlüsselherausforderung für diese Art von layer-2-zentrischem Ansatz, und es ist ein Problem, dem layer-1-zentrische Ökosysteme nicht annähernd in demselben Maße gegenüberstehen müssen: Koordination. Mit anderen Worten, während sich Ethereum verzweigt, besteht die Herausforderung darin, die grundlegende Eigenschaft zu bewahren, dass es sich immer noch alles wie 'Ethereum' anfühlt und die Netzwerkeffekte hat, 'Ethereum' zu sein, anstatt N separate Ketten zu sein. Heute ist die Situation in vielerlei Hinsicht suboptimal:

• Das Verschieben von Token von einer Layer-2-Lösung auf eine andere erfordert oft zentralisierte Brückenplattformen und ist für den durchschnittlichen Benutzer kompliziert. Wenn Sie Münzen auf Optimism haben, können Sie nicht einfach die Adresse von jemandem bei Arbitrum in Ihr Wallet einfügen und ihnen Geld senden.
• Die Unterstützung für Cross-Chain-Smart-Vertragsbrieftaschen ist nicht optimal - sowohl für persönliche Smart-Vertragsbrieftaschen als auch für organisatorische Brieftaschen (einschließlich DAOs). Wenn Sie Ihren Schlüssel auf einer L2 ändern, müssen Sie auch Ihren Schlüssel auf jeder anderen L2 ändern.
• Dezentrale Validierungsinfrastruktur fehlt oft. Ethereum beginnt endlich, anständige Leichtclients zu haben, wie Helios. Allerdings macht es keinen Sinn, wenn die Aktivität ausschließlich auf Layer-2s stattfindet, die alle ihre eigenen zentralisierten RPCs benötigen. Grundsätzlich ist es nicht schwierig, leichte Clients für L2s zu erstellen, sobald Sie die Ethereum-Headerkette haben; in der Praxis wird jedoch viel zu wenig Wert darauf gelegt.

Es gibt Bemühungen, um alle drei zu verbessern. Für den Austausch von Tokens zwischen Blockchains, das ERC-7683Standard ist eine aufkommende Option und im Gegensatz zu bestehenden „zentralisierten Brücken“ hat sie keinen festgelegten zentralen Betreiber, Token oder Governance. Für Cross-Chain-Accounts ist der Ansatz, den die meisten Wallets verfolgen, die Verwendung von Cross-Chain-wiederholbaren Nachrichten, um Schlüssel kurzfristig zu aktualisieren, und Keystore-Rollupsauf lange Sicht. Leichte Clients für L2s beginnen sich zu entwickeln, z. B. Beerusfür Starknet. Darüber hinaus haben kürzliche Verbesserungen im Benutzererlebnis durch Wallets der nächsten Generation bereits viele grundlegendere Probleme gelöst, wie z.B. die Notwendigkeit für Benutzer, manuell zum richtigen Netzwerk zu wechseln, um auf eine Dapp zuzugreifen.

Rabby zeigt eine integrierte Ansicht der Vermögensbilanzen über mehrere Ketten hinweg. In den nicht allzu fernen dunklen alten Tagen haben Wallets dies nicht getan!

Aber es ist wichtig zu erkennen, dass layer-2-zentrische Ökosysteme sich in gewissem Maße gegen den Strom stemmen, wenn sie versuchen zu koordinieren. Individuelle Layer 2 haben keinen natürlichen wirtschaftlichen Anreiz, die Infrastruktur zur Koordination aufzubauen: Kleine tun dies nicht, weil sie nur einen kleinen Anteil des Nutzens ihres Beitrags sehen würden, und große tun dies nicht, weil sie genauso viel oder mehr von der Stärkung ihrer eigenen lokalen Netzwerkeffekte profitieren würden. Wenn jeder Layer 2 separat sein individuelles Stück optimiert und niemand darüber nachdenkt, wie jedes Stück in das Gesamtbild passt, erhalten wir Misserfolge wie die Urbanismus-Dystopie im Bild ein paar Absätze oben.

Ich behaupte nicht, magische perfekte Lösungen für dieses Problem zu haben. Das Beste, was ich sagen kann, ist, dass das Ökosystem erkennen muss, dass die Cross-L2-Infrastruktur eine Art von Ethereum-Infrastruktur ist, neben L1-Clients, Entwicklerwerkzeugen und Programmiersprachen, und als solche wertgeschätzt und finanziert werden sollte. Wir haben Protokoll GuildVielleicht brauchen wir vielleicht die Basic Infrastructure Guild.

Schlussfolgerungen

„Layer 2s“ und „Sharding“ werden in der öffentlichen Diskussion oft als zwei entgegengesetzte Strategien zur Skalierung einer Blockchain beschrieben. Wenn man jedoch die zugrunde liegende Technologie betrachtet, ergibt sich ein Rätsel: Die tatsächlichen Ansätze zur Skalierung sind genau die gleichen. Es gibt eine Art von Datensharding. Sie haben Betrugsbeweiser oder ZK-SNARK-Beweiser. Sie haben Lösungen für die Kommunikation zwischen {Rollup, Shard}. Der Hauptunterschied besteht darin: Wer ist verantwortlich für den Aufbau und die Aktualisierung dieser Teile und wie viel Autonomie haben sie?

Ein Layer-2-zentrisches Ökosystem ist in einem sehr realen technischen Sinne Sharding, aber es ist Sharding, bei dem Sie Ihre eigene Shard mit Ihren eigenen Regeln erstellen können. Dies ist leistungsstark und ermöglicht eine Menge Kreativität und unabhängige Innovation. Es hat jedoch auch wesentliche Herausforderungen, insbesondere in Bezug auf Koordination. Damit ein layer-2-zentrisches Ökosystem wie Ethereum erfolgreich sein kann, muss es diese Herausforderungen verstehen und ihnen direkt entgegentreten, um so viele Vorteile von layer-1-zentrischen Ökosystemen wie möglich zu erlangen und so nah wie möglich an das Beste aus beiden Welten heranzukommen.

Haftungsausschluss：

1. Dieser Artikel wird von [reproduziertvitalik], Weiterleiten des Originaltitels 'Wie unterscheiden sich Layer 2s wirklich von Execution Sharding?', Bei Einwänden gegen diesen Nachdruck wenden Sie sich bitte an die Gate Learn Team, und sie werden sich umgehend darum kümmern.

2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.

3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.