Besonderer Dank geht an Karl Floersch für Feedback und Rezension

Das Ethereum-Layer-2-Ökosystem ist im letzten Jahr rasant gewachsen. Das EVM-Rollup-Ökosystem, das traditionell aus Arbitrum, Optimism und Scroll sowie in jüngerer Zeit aus Kakarot und Taiko besteht, hat sich schnell weiterentwickelt und große Fortschritte bei der Verbesserung seiner Sicherheit gemacht. Die L2beat-Seite fasst den Status jedes Projekts gut zusammen. Darüber hinaus haben wir gesehen, dass Teams, die Sidechains aufbauen, auch mit dem Aufbau von Rollups beginnen (Polygon), Layer-1-Projekte, die sich zu Validien entwickeln wollen (Celo), und völlig neue Projekte (Linea, Zeth…). Schließlich gibt es noch das Nicht-nur-EVM-Ökosystem: „Fast-EVMs“ wie Zksync, Erweiterungen wie Arbitrum Stylus und umfassendere Bemühungen wie das Starknet-Ökosystem, Fuel und andere.

Eine der unvermeidlichen Folgen davon ist, dass wir einen Trend beobachten, dass Layer-2-Projekte immer heterogener werden. Ich erwarte, dass sich dieser Trend fortsetzt, und zwar aus einigen wichtigen Gründen:

• Einige Projekte, die derzeit unabhängige Layer-1-Projekte sind, versuchen, sich dem Ethereum-Ökosystem anzunähern und möglicherweise Layer-2-Projekte zu werden. Diese Projekte werden wahrscheinlich einen schrittweisen Übergang wünschen. Wenn jetzt alles auf einmal umgestellt würde, würde dies zu einer Beeinträchtigung der Benutzerfreundlichkeit führen, da die Technologie noch nicht bereit ist, alles auf ein Rollup zu übertragen. Bei einem späteren Übergang auf einmal besteht die Gefahr, dass die Dynamik verloren geht und es zu spät ist, um sinnvoll zu sein.
• Einige zentralisierte Projekte möchten ihren Benutzern mehr Sicherheitsgarantien bieten und prüfen hierfür Blockchain-basierte Wege. In vielen Fällen handelt es sich dabei um Projekte, die in früheren Zeiten „erlaubte Konsortialketten“ untersucht hätten. Realistisch gesehen benötigen sie wahrscheinlich nur einen „Halbwegs“-Grad der Dezentralisierung. Zudem sind sie aufgrund ihres oft sehr hohen Durchsatzes selbst für Rollups zumindest kurzfristig ungeeignet.
• Nichtfinanzielle Anwendungen wie Spiele oder soziale Medien möchten dezentralisiert werden, benötigen aber nur ein halbwegs sicheres Maß. Im Fall der sozialen Medien bedeutet dies realistischerweise, dass verschiedene Teile der App unterschiedlich behandelt werden: Seltene und hochwertige Aktivitäten wie die Registrierung von Benutzernamen und die Kontowiederherstellung sollten in einem Rollup erfolgen, häufige und geringwertige Aktivitäten wie Beiträge und Abstimmungen erfordern jedoch weniger Sicherheit . Wenn ein Kettenausfall dazu führt, dass Ihr Beitrag verschwindet, ist das ein akzeptabler Kostenfaktor. Wenn ein Kettenausfall dazu führt, dass Sie Ihr Konto verlieren, ist das ein viel größeres Problem.

Ein großes Thema ist, dass Anwendungen und Benutzer, die sich heute auf der Ethereum-Schicht 1 befinden, kurzfristig problemlos kleinere, aber immer noch sichtbare Rollup-Gebühren zahlen können, Benutzer aus der Nicht-Blockchain-Welt jedoch nicht: Es ist einfacher, die Zahlung von 0,10 $ zu rechtfertigen, wenn Sie Wenn Sie vorher 1 $ bezahlt haben, als wenn Sie vorher 0 $ bezahlt hätten. Dies gilt sowohl für Anwendungen, die heute zentralisiert sind, als auch für kleinere Layer-1-Anwendungen, für die in der Regel sehr niedrige Gebühren anfallen, während ihre Benutzerbasis klein bleibt.

Es stellt sich natürlich die Frage: Welcher dieser komplizierten Kompromisse zwischen Rollups, Validiums und anderen Systemen ist für eine bestimmte Anwendung sinnvoll?

Rollups vs. Validiums vs. getrennte Systeme

Die erste Dimension von Sicherheit und Umfang, die wir untersuchen werden, lässt sich wie folgt beschreiben: Wenn Sie einen Vermögenswert haben, der auf L1 ausgegeben, dann auf L2 eingezahlt und dann an Sie übertragen wird, welchen Grad an Garantie haben Sie dann? Kann der Vermögenswert zurück zum L1 gebracht werden?

Es gibt auch eine parallele Frage: Welche Technologiewahl führt zu diesem Garantieniveau, und welche Kompromisse ergeben sich aus dieser Technologiewahl?

Wir können dies einfach anhand einer Tabelle beschreiben:

https://s3.ap-northeast-1.amazonaws.com/gimg.gateimg.com/learn/b05ca283dcc74f262ac7a71f340dc85fb3a13b11.png

Es ist erwähnenswert, dass es sich um ein vereinfachtes Schema handelt und es viele Zwischenoptionen gibt. Zum Beispiel:

• Zwischen Rollup und Validium: Ein Validium, bei dem jeder eine Zahlung in der Kette leisten kann, um die Kosten für Transaktionsgebühren zu decken. An diesem Punkt wäre der Betreiber gezwungen, einige Daten in der Kette bereitzustellen, andernfalls würde er eine Einzahlung verlieren.
• Zwischen Plasma und Validium: Ein Plasma-System bietet Rollup-ähnliche Sicherheitsgarantien mit Datenverfügbarkeit außerhalb der Kette, unterstützt jedoch nur eine begrenzte Anzahl von Anwendungen. Ein System könnte ein vollständiges EVM bieten und Benutzern, die diese komplizierteren Anwendungen nicht verwenden, Garantien auf Plasma-Ebene und Garantien auf Validium-Ebene für Benutzer bieten, die dies tun.

Diese Zwischenoptionen können als auf einem Spektrum zwischen einem Rollup und einem Validium liegend betrachtet werden. Aber was motiviert Anwendungen dazu, einen bestimmten Punkt in diesem Spektrum auszuwählen und nicht einen Punkt weiter links oder weiter rechts? Hier gibt es zwei wesentliche Faktoren:

1. Die Kosten für die native Datenverfügbarkeit von Ethereum, die mit der Zeit sinken werden, wenn sich die Technologie verbessert. Der nächste Hard Fork von Ethereum, Dencun, führt EIP-4844 (auch bekannt als „Proto-Danksharding“) ein, das eine On-Chain-Datenverfügbarkeit von ~32 kB/s bietet. Es wird erwartet, dass dieser Wert in den nächsten Jahren schrittweise zunehmen wird, da <a href="https://hackmd.io/@vbuterin/sharding_proposal"> vollständiges Danksharding eingeführt wird und schließlich eine Datenverfügbarkeit von etwa ~1,3 MB/s angestrebt wird . Gleichzeitig werden wir durch Verbesserungen bei der Datenkomprimierung mehr mit der gleichen Datenmenge erreichen können.
2. Die eigenen Anforderungen der Anwendung: Wie sehr würden Benutzer unter hohen Gebühren leiden, im Vergleich dazu, wenn etwas in der Anwendung schief geht? Finanzanwendungen würden durch Anwendungsfehler mehr verlieren; Spiele und soziale Medien beinhalten viele Aktivitäten pro Benutzer und Aktivitäten von relativ geringem Wert, sodass für sie ein anderer Sicherheitskompromiss sinnvoll ist.

Dieser Kompromiss sieht ungefähr so aus:

Eine weitere erwähnenswerte Art der Teilgarantie sind Vorbestätigungen. Vorbestätigungen sind Nachrichten, die von einer Gruppe von Teilnehmern an einem Rollup oder Validium signiert wurden und besagen: „Wir bestätigen, dass diese Transaktionen in dieser Reihenfolge enthalten sind, und die Post-State-Wurzel ist dies.“ Es kann durchaus sein, dass diese Teilnehmer eine Vorabbestätigung unterschreiben, die nicht mit der späteren Realität übereinstimmt, aber wenn sie es tun, wird eine Anzahlung verbrannt. Dies ist nützlich für Anwendungen mit geringen Beträgen wie Verbraucherzahlungen, während Anwendungen mit höheren Beträgen wie Finanztransfers im Wert von mehreren Millionen Dollar wahrscheinlich auf eine „normale“ Bestätigung warten, die durch die vollständige Sicherheit des Systems abgesichert ist.

Vorbestätigungen können als ein weiteres Beispiel für ein Hybridsystem angesehen werden, ähnlich dem oben erwähnten „Plasma/Validium-Hybrid“, dieses Mal jedoch eine Hybridisierung zwischen einem Rollup (oder Validium), das über volle Sicherheit, aber hohe Latenz verfügt, und einem System mit einem viel niedrigere Sicherheitsstufe mit geringer Latenz. Anwendungen, die eine geringere Latenz benötigen, erhalten eine geringere Sicherheit, können aber im selben Ökosystem leben wie Anwendungen, die im Austausch für maximale Sicherheit mit einer höheren Latenz einverstanden sind.

Vertrauenslos Ethereum lesen

Eine weitere weniger beachtete, aber immer noch sehr wichtige Form der Verbindung hat mit der Fähigkeit eines Systems zu tun, die Ethereum-Blockchain zu lesen. Dazu gehört insbesondere die Möglichkeit, im Falle eines Rückfalls von Ethereum zurückkehren zu können. Um zu verstehen, warum dies wertvoll ist, betrachten Sie die folgende Situation:

Nehmen wir an, dass die Ethereum-Kette, wie im Diagramm dargestellt, zurückkehrt. Dies könnte ein vorübergehender Schluckauf innerhalb einer Epoche sein, während die Kette noch nicht abgeschlossen ist, oder es könnte sich um eine Inaktivitätsleckperiode handeln, in der die Kette über einen längeren Zeitraum nicht abgeschlossen wird, weil zu viele Validatoren offline sind.

Das Worst-Case-Szenario, das daraus entstehen kann, ist folgendes. Angenommen, der erste Block der oberen Kette liest einige Daten aus dem Block ganz links in der Ethereum-Kette. Beispielsweise zahlt jemand auf Ethereum 100 ETH in die oberste Kette ein. Dann kehrt Ethereum zurück. Die obere Kette kehrt jedoch nicht zurück. Infolgedessen folgen zukünftige Blöcke der Top-Chain korrekt neuen Blöcken aus der neu korrekten Ethereum-Chain, aber die Konsequenzen des nun fehlerhaften älteren Glieds (nämlich die Einzahlung von 100 ETH) sind immer noch Teil der Top-Chain. Dieser Exploit könnte das Drucken von Geld ermöglichen und die überbrückte ETH in der obersten Kette in eine Teilreserve verwandeln.

Es gibt zwei Möglichkeiten, dieses Problem zu lösen:

1. Die oberste Kette konnte nur abgeschlossene Ethereum-Blöcke lesen und müsste daher nie zurückgesetzt werden.
2. Die oberste Kette könnte zurückkehren, wenn Ethereum zurückkehrt. Beide verhindern dieses Problem. Ersteres ist einfacher zu implementieren, kann jedoch über einen längeren Zeitraum zu einem Funktionsverlust führen, wenn Ethereum in eine Phase des Inaktivitätslecks gerät. Letzteres ist zwar schwieriger umzusetzen, gewährleistet aber stets die bestmögliche Funktionalität.

Beachten Sie, dass (1) einen Randfall hat. Wenn ein 51-Prozent-Angriff auf Ethereum zwei neue inkompatible Blöcke erzeugt, die beide gleichzeitig als abgeschlossen erscheinen, kann es sein, dass sich die oberste Kette auf den falschen Block festlegt (d. h. diejenige, die der gesellschaftliche Konsens von Ethereum letztendlich nicht befürwortet) und müsste zurückkehren, um zur richtigen zu wechseln. Es besteht wohl keine Notwendigkeit, Code zu schreiben, um diesen Fall im Voraus zu behandeln. es könnte einfach durch eine harte Gabelung der oberen Kette gehandhabt werden.

Die Fähigkeit einer Kette, Ethereum vertrauenswürdig zu lesen, ist aus zwei Gründen wertvoll:

1. Es reduziert Sicherheitsprobleme, die mit der Überbrückung von auf Ethereum (oder anderen L2s) ausgegebenen Token zu dieser Kette verbunden sind
2. Es ermöglicht Kontoabstraktions-Wallets, die die Shared-Keystore-Architektur nutzen, um Vermögenswerte in dieser Kette sicher aufzubewahren.
3. ist wichtig, obwohl dieser Bedarf wohl bereits allgemein anerkannt ist. (2) ist ebenfalls wichtig, denn es bedeutet, dass Sie über eine Wallet verfügen können, die einen einfachen Schlüsselwechsel ermöglicht und Vermögenswerte über eine große Anzahl verschiedener Ketten hinweg speichert.

Macht Sie eine Brücke zu einem Validium?

Angenommen, die oberste Kette beginnt als separate Kette und dann schließt jemand einen Brückenvertrag auf Ethereum ab. Ein Bridge-Vertrag ist einfach ein Vertrag, der Blockheader der Top-Chain akzeptiert, überprüft, ob jeder an ihn übermittelte Header mit einem gültigen Zertifikat versehen ist, aus dem hervorgeht, dass er vom Konsens der Top-Chain akzeptiert wurde, und diesen Header einer Liste hinzufügt. Darauf können Anwendungen aufbauen, um Funktionalitäten wie das Ein- und Auszahlen von Token zu implementieren. Bietet eine solche Brücke, sobald sie vorhanden ist, die zuvor erwähnten Garantien für die Sicherheit von Vermögenswerten?

Bisher noch nicht! Aus zwei Gründen:

1. Wir überprüfen, ob die Blöcke signiert wurden, aber nicht, ob die Zustandsübergänge korrekt sind. Wenn Sie also einen auf Ethereum ausgegebenen Vermögenswert in der obersten Kette hinterlegt haben und die Validatoren der obersten Kette unkontrolliert agieren, können sie einen ungültigen Zustandsübergang unterzeichnen, der diese Vermögenswerte stiehlt.
2. Die Top-Chain hat immer noch keine Möglichkeit, Ethereum zu lesen. Daher können Sie nicht einmal Ethereum-native Vermögenswerte in der obersten Kette hinterlegen, ohne sich auf eine andere (möglicherweise unsichere) Drittanbieter-Brücke zu verlassen.

Machen wir die Brücke nun zu einer validierenden Brücke: Sie prüft nicht nur den Konsens, sondern auch einen ZK-SNARK, der beweist, dass der Zustand jedes neuen Blocks korrekt berechnet wurde.

Sobald dies erledigt ist, können die Validatoren der Top-Kette Ihr Geld nicht mehr stehlen. Sie können eine Sperre mit nicht verfügbaren Daten veröffentlichen und damit verhindern, dass jeder abheben kann, aber sie können nicht stehlen (außer indem sie versuchen, ein Lösegeld für die Benutzer zu erpressen, als Gegenleistung für die Offenlegung der Daten, die es ihnen ermöglichen, abzuheben). Dies ist das gleiche Sicherheitsmodell wie ein Validium.

Allerdings haben wir das zweite Problem immer noch nicht gelöst: Die Top-Chain kann Ethereum nicht lesen.

Dazu müssen wir eines von zwei Dingen tun:

1. Platzieren Sie einen Brückenvertrag zur Validierung der fertigen Ethereum-Blöcke in der oberen Kette.
2. Lassen Sie jeden Block in der oberen Kette einen Hash eines aktuellen Ethereum-Blocks enthalten und verfügen Sie über eine Fork-Choice-Regel, die die Hash-Verknüpfungen erzwingt. Das heißt, ein Top-Chain-Block, der mit einem Ethereum-Block verknüpft ist, der sich nicht in der kanonischen Kette befindet, ist selbst nicht kanonisch, und wenn ein Top-Chain-Block mit einem Ethereum-Block verknüpft ist, der zunächst kanonisch war, dann aber nicht kanonisch wird, Der obere Kettenblock muss ebenfalls nicht kanonisch werden.

Die violetten Links können entweder Hash-Links oder ein Brückenvertrag sein, der den Konsens von Ethereum überprüft.

Ist das genug? Wie sich herausstellt, immer noch nein, aufgrund einiger kleiner Randfälle:

1. Was passiert, wenn Ethereum zu 51 % angegriffen wird?
2. Wie gehen Sie mit Ethereum-Hard-Fork-Upgrades um?
3. Wie gehen Sie mit Hard-Fork-Upgrades Ihrer Kette um?

Ein 51-Prozent-Angriff auf Ethereum hätte ähnliche Folgen wie ein 51-Prozent-Angriff auf die Top-Chain, allerdings in umgekehrter Reihenfolge. Bei einem Hard Fork von Ethereum besteht die Gefahr, dass die Brücke von Ethereum innerhalb der Top-Chain nicht mehr gültig ist. Eine soziale Verpflichtung zur Wiederherstellung, wenn Ethereum einen endgültigen Block zurücksetzt, und zur Hard Fork, wenn Ethereum eine Hard Fork durchführt, ist der sauberste Weg, dieses Problem zu lösen. Eine solche Verpflichtung muss möglicherweise nie tatsächlich umgesetzt werden: Sie könnten ein Governance-Gerät in der obersten Kette aktivieren lassen, wenn es Beweise für einen möglichen Angriff oder einen Hard Fork sieht, und nur dann einen Hard Fork für die oberste Kette durchführen, wenn das Governance-Gerät ausfällt.

Die einzig praktikable Antwort auf (3) besteht leider darin, eine Art Governance-Gadget auf Ethereum zu haben, das den Bridge-Vertrag auf Ethereum auf Hard-Fork-Upgrades der Top-Chain aufmerksam machen kann.

Zusammenfassung: Zwei-Wege-Validierungsbrücken reichen fast aus, um eine Kette zu einem Validium zu machen. Der wichtigste verbleibende Bestandteil ist eine soziale Verpflichtung, dass die andere Kette als Reaktion darauf einen Hard Fork durchführen wird, wenn in Ethereum etwas Außergewöhnliches passiert, das dazu führt, dass die Brücke nicht mehr funktioniert.

Schlussfolgerungen

Es gibt zwei Schlüsseldimensionen der „Verbundenheit mit Ethereum“:

1. Sicherheit beim Abheben auf Ethereum
2. Sicherheit beim Lesen von Ethereum

Diese sind beide wichtig und haben unterschiedliche Überlegungen. In beiden Fällen gibt es ein Spektrum:

Beachten Sie, dass es für beide Dimensionen jeweils zwei unterschiedliche Möglichkeiten gibt, sie zu messen (es gibt also eigentlich vier Dimensionen?): Die Sicherheit beim Abheben kann anhand (i) der Sicherheitsstufe und (ii) gemessen werden, wie viel Prozent der Benutzer oder Anwendungsfälle von der höchsten Sicherheit profitieren Das Niveau und die Sicherheit des Lesens können daran gemessen werden, (i) wie schnell die Kette die Blöcke von Ethereum lesen kann, insbesondere abgeschlossene Blöcke im Vergleich zu beliebigen Blöcken, und (ii) die Stärke des sozialen Engagements der Kette, Randfälle wie 51 %-Angriffe zu bewältigen und harte Gabeln.

Projekte in vielen Bereichen dieses Designbereichs sind wertvoll. Für einige Anwendungen sind hohe Sicherheit und enge Verbindungen wichtig. Für andere ist etwas Lockereres als Ersatz für eine größere Skalierbarkeit akzeptabel. In vielen Fällen kann es durchaus optimal sein, heute mit einer lockereren Kopplung zu beginnen und im Laufe des nächsten Jahrzehnts mit der Verbesserung der Technologie zu einer engeren Kopplung überzugehen.

Haftungsausschluss:

1. Dieser Artikel ist ein Nachdruck von [Vitalik Buterin]. Alle Urheberrechte liegen beim Originalautor [Vitalik Buterin]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen 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, Verbreiten oder Plagiieren der übersetzten Artikel verboten.