Die L1-vs.-L2-Landschaft: Designunterschiede, Kompromisse und Endgames verstehen

Konkrete Erkenntnisse

• Verfügbare Grundbausteine und technische Grenzen verstehen: Verschaffe dir ein tiefes Verständnis der grundlegenden Bausteine und technischen Feinheiten. Dieses Wissen ist entscheidend, um zu erkennen, wie diese Faktoren die Funktionalität und Skalierbarkeit deiner Anwendung und letztlich deines Unternehmens beeinflussen. So kannst du bei der Blockchain-Entwicklung fundierte Entscheidungen treffen.
• Infrastruktur und Liquidität bewerten: Bewerte die verfügbare Infrastruktur und Liquidität von L1- und L2-Lösungen sowie alternativen Ausführungsumgebungen für das Deployment. Leite Prognosen zum Zustand der Infrastruktur aus Grundprinzipien ab. Verstehe die tatsächlichen Vertrauens- und Dezentralisierungsannahmen ausgehend von Grundprinzipien.
• Für die User Experience optimieren: Optimiere konsequent für die User Experience. Berücksichtige dabei Benutzerfreundlichkeit, Transaktionsgeschwindigkeit und die Gesamteffizienz jeder Chain. Schaffe eine nahtlose und benutzerfreundliche Umgebung. Unterscheide dabei, was heute bereits live ist und wohin die Roadmaps führen.

Einführung

Die Blockchain-Landschaft entwickelt sich ständig weiter. Dadurch wird die Entscheidung, wo Anwendungen entwickelt werden sollen, für Entwickler immer komplexer. Dieser Bericht untersucht die Unterschiede zwischen Layer-1- (L1) und Layer-2-Lösungen (L2) für universelle Smart-Contract-Plattformen und ihre Folgen für Nutzerinteraktion, wirtschaftliche Margen und Unternehmenswachstum.

Trotz der Vielfalt und Fortschritte in der Blockchain-Branche bleibt die Nutzerbasis im Vergleich zu etablierten digitalen Plattformen überschaubar. Krypto erreicht derzeit beispielsweise täglich rund 5,5 Millionen eindeutig zuordenbare Adressen, während Plattformen wie Facebook täglich etwa 2 Milliarden Nutzer verzeichnen.

Die heutigen Kunden von Blockchains sind Entwickler. Blockchains verkaufen Blockspace an Anwendungsentwickler, damit diese neuartige Produkte entwickeln können. Die Wahl der Plattform für deine Anwendung gehört heute zu den wichtigsten Entscheidungen eines Entwicklers. Aus geschäftlicher Sicht ist diese Wahl besonders folgenreich, da sie sich auf potenzielle Nutzer, Liquidität und Kultur auswirkt. Systeme nach dem Launch zu migrieren, ist technisch wie sozial schwierig, aber nicht unmöglich. Teams wie dydx sind erfolgreich von Ethereum zu einer Cosmos-Appchain migriert. y00ts hatte dagegen Probleme bei der Migration von Solana zu Polygon und nun zu Ethereum.

Dieser Bericht soll in der aktuellen Debatte zwischen modularen und integrierten Ansätzen keine Position beziehen. Stattdessen bietet er Entwicklern, angehenden Entwicklern und Führungskräften einen praxisnahen Überblick über die L1/L2-Landschaft. Konkrete Beispiele zeigen die Kompromisse bestimmter Anwendungsdesigns.

Eigenschaften einer Blockchain

Bevor wir die Unterschiede zwischen L1s und L2s behandeln, müssen wir zunächst die Eigenschaften einer Blockchain definieren.

Eine Blockchain ist eine deterministische replizierte Zustandsmaschine. Dieses komplexe System soll Konsens herstellen und in einem verteilten Netzwerk einen einheitlichen, sicheren Datensatz verwalten.

Deterministisch

Die Prozesse innerhalb einer Blockchain werden durch das zugrunde liegende Protokoll vorgegeben. Wird die „Zustandsübergangsfunktion“ (STF) einer Blockchain mit einer bestimmten Eingabe und dem aktuellen Zustand ausgeführt, erzeugt sie auf allen Nodes denselben neuen Zustand. Dieser deterministische Charakter sorgt dafür, dass das Ergebnis gleich bleibt – unabhängig davon, wer die Funktion ausführt oder welcher Node die Transaktion verarbeitet. Deterministische Prozesse garantieren Zuverlässigkeit und Vorhersagbarkeit im Netzwerkbetrieb.

Repliziert

Blockchains nutzen ein Netzwerk aus Nodes, von denen jeder eine Kopie des gesamten Blockchain-Zustands verwaltet. Diese Replikation fördert die Dezentralisierung und schützt vor Datenverlust und Manipulation. Da jeder Node eine Kopie des Zustands besitzt, müssten historische Datensätze auf der Mehrheit der Nodes gleichzeitig geändert werden. In einem ausreichend großen und verteilten Netzwerk ist das praktisch unmöglich.

Zustandsmaschine

Im Kern ist eine Blockchain ein System zur Verwaltung von Zuständen. Das sind Momentaufnahmen eines bestimmten Zeitpunkts, die alle vereinbarten Informationen enthalten, etwa Kontostände, Zustände von Smart Contracts und Eigentumsnachweise. Die Blockchain wechselt durch Transaktionen von einem Zustand zum nächsten. Transaktionen sind Anforderungen, den Zustand zu ändern. Die im Blockchain-Protokoll codierten Regeln steuern diese Übergänge.

Diese Eigenschaften ergeben ein Ledger, in dem jeder lesen und schreiben kann. Wie Balaji 2019 feststellte, sind öffentliche Blockchains globale Datenbanken mit mehreren Clients, in denen jeder Nutzer ein Root-Nutzer ist. Dadurch entsteht ein globaler Überblick darüber, wie viele Assets (Token, NFTs usw.) jeder Nutzer besitzt. Zugleich wird erlaubnisfreie Innovation rund um den öffentlichen, global geteilten Zustand möglich.

Teilnehmer am Blockchain-Marktplatz

Blockchains ermöglichen einen globalen Marktplatz für vereinbarte Informationen, der auf dezentralem Vertrauen basiert. Ein Blockchain-Netzwerk hat zwei zentrale Interessengruppen:

• Vertrauensanbieter: Staker, Validatoren, Miner (je nachdem, ob das Netzwerk PoW oder PoS verwendet)
• Vertrauenskonsumenten: Anwendungen (die Transaktionen häufig bündeln und die marginalen Betriebskosten an den Nutzer weitergeben)

Anders gesagt: Blockchains ermöglichen wie jeder andere Wirtschaftsmarkt einen zweiseitigen Marktplatz zwischen Käufern und Verkäufern. Angebot und Nachfrage bestimmen den Preis für den Handel zwischen beiden Seiten.

Öffentliche Blockchains benötigen Gebühren, um Spam zu verhindern und knappe Ressourcen zuzuteilen. Diese Gebühren sind die wichtigste Vergütung beziehungsweise Einnahmequelle für Validatoren und Miner. Sie decken laufende Kosten für Geräte, Strom und andere Ressourcen. Die Preisbildungsmechanismen unterscheiden sich je nach Protokoll, doch alle großen öffentlichen Blockchains integrieren Gas auf irgendeine Weise in ihr Protokoll. Irgendwo auf der Welt betreibt jemand Rechenhardware und muss dafür vergütet werden.

Definition von L1s und L2s

Nachdem wir besser verstehen, was eine Blockchain ist und ermöglicht, können wir L1 und L2 formal definieren.

Eine umfassende, präzise Definition von L1s und L2s samt ihren jeweiligen Implikationen wird unter Forschern und in der breiteren Krypto-Community kontrovers diskutiert. Es sind verschiedene Arten von Rollups entstanden – etwa Optimistic, Zero-Knowledge und Enshrined – mit unterschiedlichen Implementierungsdetails und Vertrauensannahmen, darunter Validiums, Volitions und Sovereign Rollups.

Bevor wir die Kompromisse zwischen L1s und L2s betrachten, müssen wir sie definieren.

Layer 1s (L1s)

L1-Blockchains sind grundlegende Netzwerke, die als primäre Infrastruktur einer Kryptowährung dienen. Es sind eigenständige Netzwerke mit eigenen zugrunde liegenden Protokollen, Konsensmechanismen und nativen Token. L1s werden oft als Basisschicht eines Blockchain-Ökosystems bezeichnet, da sie den grundlegenden Sicherheits- und Governance-Rahmen bereitstellen.

Ethereum führte mit seinem Launch 2015 das Konzept des modularen Vertrauens ein. Ethereum war und ist jedoch nicht für den nötigen Umfang optimiert, um Millionen von Nutzern aufzunehmen. Deshalb entstanden neue Skalierungslösungen wie Rollups, die Ethereum skalierbarer machen sollen.

Layer 2s (L2s)

L2-Lösungen bauen auf L1-Blockchains auf. Sie erhöhen Skalierbarkeit und Transaktionsdurchsatz, ohne die Basisschicht zu verändern. Rollups gehören zu den vielversprechendsten und am besten erforschten L2-Lösungen.

Rollups verlagern Transaktionen von der L1, verarbeiten sie separat und schreiben den endgültigen Zustand anschließend zurück auf die L1 – häufig als State Root. So kann das Rollup zusätzliche Transaktionen in einer separaten Zustandsumgebung günstiger ausführen als direkt auf der L1. Rollups bündeln mehrere Transaktionen zu einer einzigen Transaktion auf der L1, um Last zu reduzieren und die Effizienz zu steigern. Verschiedene L2-Lösungen haben unterschiedliche Vertrauensannahmen. Sie wollen im Allgemeinen die Sicherheits- und Dezentralisierungseigenschaften der zugrunde liegenden L1 übernehmen. Damit sollen sie eine sichere, aber skalierbarere Alternative zur Verarbeitung jeder einzelnen Transaktion auf der L1 bieten.

Celestia hat diese Definition für Rollups formalisiert:

In der Praxis besitzt Ethereum die interessantesten und nominell wertvollsten Assets im Kryptobereich. Nutzer sind bereit, Assets auf verschiedene L2-Lösungen zu übertragen. Die stärker zentralisierten Aspekte der L2s bereiten ihnen offenbar kaum Sorgen. An diesen Aspekten wird aktiv gearbeitet, sie sind aber häufig noch nicht live. Ausschlaggebend sind die deutlich niedrigeren Gebühren gegenüber dem Ethereum-Mainnet. 

Die Sicherheit ist beim Übertragen von Assets zwischen Chains ein häufiges Problem. Viele bekannte Rollup-Bridges verfügen zwar nicht über rigorose Beweissysteme und werden wegen potenziell zentralisierter Kontrollpunkte kritisiert. Dennoch erweitern sie das Ethereum-Erlebnis nahtlos – durch eine ähnliche EVM-Erfahrung und einheitliche Wallets. Rollups wie Base, Optimism und Arbitrum erhalten die bestehende Ethereum-Wallet- und Adressinfrastruktur eines Nutzers so weit wie möglich. Dadurch laufen Übergänge zwischen Mainchain und L2s deutlich nahtloser ab. Diese Bequemlichkeit und die Dominanz von ETH in DeFi- und Social-Anwendungen machen L2 für Nutzer attraktiv, die Vertrautheit und Benutzerfreundlichkeit suchen. Ethereum besitzt den beliebtesten Zustand, mit dem andere Entwickler interagieren möchten. L2s gelten als natürliche Erweiterung von Ethereum.

Kurz gesagt: Das „Übernehmen“ bestimmter Sicherheitsgarantien von Ethereum steht weit unten auf der Liste der Gründe, aus denen sich ein Team für den Launch als Ethereum-L2 oder die Migration von einer eigenständigen L1 zu einer L2 entscheidet.

Neue Entwicklungen wie Solang und Neon schließen die Lücke für Entwickler, die an Ethereums Solidity gewöhnt sind. MetaMasks Snaps erweitert zugleich die Wallet-Unterstützung auf Nicht-EVM-Chains. Diese Entwicklungen deuten auf eine Zukunft hin, in der die UX viele Komplexitäten verschiedener Ausführungsumgebungen wirksam abstrahiert.

Die Ethereum Foundation hat zwar einen Großteil der Forschung zu L2s finanziert, doch alle L2s sind unabhängige Einheiten und werden nicht von der Ethereum Foundation betrieben. Erlaubnisfreie Innovation beschränkt sich nicht auf die dezentrale Anwendungsschicht. Keine glaubwürdig neutrale L1 besitzt die technische Fähigkeit zu entscheiden, welche L2s auf ihr bereitgestellt werden dürfen.

„Typische“ Implementierungen und Architekturen von L1 und L2

Um die Kompromisse zwischen L1s und L2s zu verstehen, musst du ihre jeweiligen Lieferketten, relevanten Akteure und Vertrauensannahmen kennen.

Lebenszyklus einer L1-Transaktion

Jede L1 hat eigene Implementierungsdetails. Dennoch besitzen alle großen L1s vergleichbare Interessengruppen und Transaktionslebenszyklen. Dieser Abschnitt beschreibt den üblichen Transaktionsfluss von der Erstellung bis zur endgültigen Aufnahme.

1. Absicht

Am Anfang steht ein klares Ziel oder eine Aktion, die der Nutzer im Ethereum-Netzwerk ausführen möchte. Dazu gehören das Senden von ETH, die Interaktion mit einem Smart Contract oder der Tausch von Token. In dieser Phase entscheidet der Nutzer, was er erreichen möchte, und versteht sein Vorhaben. Damit beginnt der Weg der Transaktion.

2. Transaktionserstellung

Hier nimmt die Transaktion Gestalt an. Der Nutzer gibt meist über eine Benutzeroberfläche wie eine Wallet oder dezentrale Anwendung die erforderlichen Informationen ein. Dazu zählen die Empfängeradresse, der zu sendende Betrag oder die aufzurufende Contract-Methode. In dieser Phase wird die Absicht des Nutzers in eine strukturierte Anfrage übersetzt, die das Ethereum-Netzwerk verarbeiten kann. Nun bestimmt der Nutzer die Transaktionskosten, bestehend aus Gaspreis und Gaslimit. Das hängt stark von der Chain ab und wird häufig vom Wallet-Anbieter abstrahiert. Ethereum und Solana implementieren jeweils eine Variante aus Basisgebühr und Prioritätsgebühr (Trinkgeld). Die Implementierungen und der Grad an Determinismus bei der Transaktionsaufnahme unterscheiden sich.

3. Übertragung

Der Nutzer signiert die Transaktion mit seinem privaten Schlüssel. Diese digitale Signatur weist seine Autorisierung nach. Nach der Signatur wird die Transaktion an das Netzwerk übertragen – üblicherweise über einen in die Wallet integrierten RPC-Anbieter. Dort wartet sie meist im öffentlichen Mempool oder in privaten Orderflow-Auktionen auf die Verarbeitung.

4. Aufnahmebestätigung

In dieser letzten Phase wird die Transaktion abgeschlossen. Der Nutzer erhält die Bestätigung, dass sie erfolgreich in einen Block aufgenommen wurde. Die Finalitätsstufe hängt vom jeweiligen Protokoll ab. Die Finalität schließt den Vorgang ab und ermöglicht es Nutzern, Ergebnisse wie aktualisierte Kontostände oder Contract-Zustände zu prüfen.

Die Ethereum-Lieferkette

Ethereum will eine glaubwürdig neutrale Infrastrukturschicht für zensurresistente Anwendungen sein. Der Mechanismus seiner Lieferkette hat sich erheblich weiterentwickelt. Anfangs lief Ethereum mit Proof of Work (PoW), wobei Miner die Aufnahme und Reihenfolge von Transaktionen kontrollierten. Dadurch entstanden Priority Gas Auctions (PGAs), bei denen Sucher um Blockspace konkurrierten. Das blähte den Mempool auf und führte zu einer ineffizienten Nutzung der Chain. Flashbots Auction, ein protokollexternes Relay für MEV-Bundles, verlagerte MEV-Märkte off-chain und schwächte so einige zentralisierende Effekte von MEV ab. Das System war jedoch auf die Ehrlichkeit des Relay-Betreibers und der Miner angewiesen.

Mit dem Wechsel zu Proof of Stake (PoS) ging die Blockproduktion von Ethereum auf Validatoren mit Stake über. Das brachte neue Dynamiken und potenzielle Zentralisierungsprobleme mit sich. Skaleneffekte bei der MEV-Extraktion könnten unter PoS zu einer Zentralisierung des Stakes führen und Ethereums Zensurresistenz gefährden.

Um Bedenken hinsichtlich der Stake-Zentralisierung zu begegnen, führte Flashbots die Proposer-Builder Separation (PBS) ein. Zunächst wurde sie als MEV-Boost umgesetzt, ein neues Modell für die Blockproduktion. In diesem System senden Sucher Bundles an Block-Builder. Diese erstellen Blöcke und geben über Block-Relays Gebote an den Proposer ab. MEV-Boost verlagert zentralisierende Kräfte auf die Ebene der Block-Builder und erfordert Vertrauen in Block-Builder und Relays. Im Dezember 2023 wurden mehr als 93 % der Ethereum-Blöcke von Validatoren vorgeschlagen, die MEV-Boost ausführten.

MEV-Boost und PBS sind jedoch nicht frei von Problemen. Das von Flashbots betriebene MEV-Boost-Relay setzt die OFAC-Compliance durch – ein unerwünschtes Gleichgewicht für ein faires, erlaubnisfreies System. Die Zentralisierung der Relays birgt das Risiko von Zensur und unehrlichem Verhalten, da Relays zu kritischen Vermittlern zwischen Buildern und Validatoren werden. Zudem besteht eine starke Abhängigkeit von protokollexterner Software wie MEV-Boost. Das macht Ethereum anfälliger für Exploits und Angriffe, wie Vorfälle à la low-carb-crusader-Exploit zeigen. Es wird darüber diskutiert, PBS fest im Protokoll zu verankern (ePBS). Dabei würde ein Großteil der von Flashbots finanzierten Arbeit übernommen. Auch die Zentralisierung der Builder ist problematisch: Einige wenige Builder dominieren den Markt und könnten Zensur ausüben oder das Netzwerk beeinflussen. Neue Lösungen wie SUAVE sollen diese Bedenken ausräumen.

Die Solana-Lieferkette

Solana startete 2020 als eigenständige L1 und führte zahlreiche Neuerungen ein. Sie sollen das Skalierungsproblem auf der Basisschicht ohne zusätzliche Lösungen von Drittanbietern wie L2s lösen. Solana konzentriert sich konsequent darauf, Anwendungen einen „gemeinsamen Zustand“ zu ermöglichen. So lassen sich Anwendungen nativ kombinieren, ohne dass Anwendungsentwickler viel zusätzliche Arbeit leisten müssen. Auch komplexe Nutzeraktionen oder zusätzliche Vertrauensannahmen wie beim Bridging entfallen.

Auf Solana besteht eine Transaktion aus drei Hauptkomponenten: einer Reihe von Anweisungen für die Transaktionsvorgänge, einer Liste der Accounts samt Berechtigungen, mit denen die Transaktion interagiert, und den zur Authentifizierung erforderlichen Signaturen. Sobald der Nutzer die Transaktion bestätigt, wird sie an einen Solana-RPC-Server gesendet. Dieser leitet sie an den aktuellen Netzwerk-Leader weiter, der für die Blockproduktion verantwortlich ist. Dieses Verfahren heißt Gulf Stream und ist eine der acht einzigartigen Innovationen von Solana.

Nach dem Empfang validiert der Leader die Transaktion und plant ihre Ausführung. Das parallele Ausführungsmodell von Solana ermöglicht die gleichzeitige Verarbeitung mehrerer Transaktionen. Das schafft Parallelität und „lokale Gebührenmärkte“. Möglich wird dies durch einen Multithread-Scheduler, der Transaktionen anhand von Prioritätsgebühren und Zeit in eine Warteschlange einordnet.

Nach der Ausführung zeichnet der Leader die Transaktion im Ledger auf und verteilt sie im Netzwerk. Anschließend wird ihr Status schrittweise aktualisiert: Nach der Ausführung gilt sie als „bestätigt“, sobald genügend Konsensstimmen vorliegen. Schließlich gilt sie als „finalisiert“, sobald die erforderliche Anzahl zusätzlicher Blöcke (31+) sicher darauf aufgebaut wurde.

Anders als Ethereum, das empirisch deutlich robustere Garantien für eine gebührenbasierte Transaktionsreihenfolge bietet, besitzt Solana keine deterministische Reihenfolge für Transaktionen. Transaktionen mit höheren Prioritätsgebühren werden in einem Block zwar meist weiter oben platziert, und in Situationen mit umkämpftem Zustand sind häufig höhere Gebühren nötig. Garantiert ist dieses Ergebnis jedoch nicht. Die Wahrscheinlichkeit solcher Vorgänge wird durch den nicht deterministischen Standard-Scheduling-Algorithmus von Solana beeinflusst. Dieser bestimmt, ob und an welcher Stelle eine Transaktion in einen Block aufgenommen wird. Das schafft Anreize für protokollexterne Aktivitäten, darunter Nebenabsprachen zwischen Suchern und Validatoren. Für den durchschnittlichen Nutzer entstehen dadurch negative externe Effekte.

MEV ist auf Ethereum zweifellos ein wesentlich größerer Markt. Seit dem Merge wurden mehr als 750 Millionen US-Dollar (373.701 ETH) extrahiert. Deshalb flossen mehr Zeit und Ressourcen in MEV. Das Thema ist erheblich besser verstanden und erforscht, und es gibt anreizkompatible Mechanismen.

Darin zeigt sich einer der grundlegenden philosophischen Unterschiede zwischen Ethereum und Solana. Er prägt die Ressourcenverteilung und Kultur der jeweiligen Ökosysteme. Ethereum investiert stark in die Erforschung und Entwicklung anreizkompatibler Mechanismen wie PBS. Dazu laufen Diskussionen über ePBS. Das Kernprotokoll von Solana wurde dagegen speziell für die Synchronisierung des globalen Zustands entwickelt. Spezialisierte Dienste und Garantien für die Reihenfolge überlässt es Ökosystem-Teams wie Jito. Anatoly, CEO von Solana Labs, vertritt klar die Ansicht, dass der aktuelle Zustand von Solana für den durchschnittlichen Nutzer ein besseres, wenn auch vorübergehendes Gleichgewicht darstellt.

User Experience (UX) auf L1s

Aus Nutzersicht gehört das Einreichen einer Transaktion an eine Layer-1-Blockchain wie Ethereum oder Solana zu den einfachsten Aktionen im Kryptobereich. Üblicherweise umfasst der Vorgang diese Schritte:

1. Wallet einrichten

Der Nutzer muss zunächst eine Wallet herunterladen. Das kann eine Software-Wallet wie MetaMask, eine mobile App oder für höhere Sicherheit eine Hardware-Wallet sein.

2. Nativen Token der L1 beschaffen

Stelle sicher, dass deine Wallet genug ETH/SOL für die Transaktion und die Gasgebühren enthält. Du kannst ETH auf verschiedenen zentralisierten Börsen kaufen. Teams und Protokolle arbeiten an Account-Abstraktion. Eine ihrer Funktionen besteht darin, Gas mit einem beliebigen Token statt nur mit dem nativen Token der jeweiligen L1 zu bezahlen. Ethereum implementiert dies über EIP-4337. Bei Solana ist die native Account-Abstraktion in das Protokoll integriert. Zudem gibt es mit Octane einen Relayer für Transaktionen ohne Gasgebühren.

3. Transaktionsdetails eingeben

Öffne deine Wallet und wähle die Option zum Senden von ETH oder Token. Gib die Ethereum-Adresse des Empfängers, den gewünschten ETH-Betrag oder die Anzahl der Token sowie bei Bedarf zusätzliche Daten ein, etwa für Interaktionen mit Smart Contracts. Bei der Interaktion mit einer Anwendung stellt der Anwendungsentwickler die Transaktion üblicherweise bereits fertig zusammen.

4. Gaspreis und Limit festlegen

Die Wallet legt diese Werte automatisch fest oder lässt dich auswählen. Die genaue Gas-Implementierung hängt von der L1 ab, mit der du interagierst.

5. Signieren und einreichen

Signiere die Transaktion mit deiner Wallet. Der genaue Vorgang hängt von der Wallet ab. Anschließend überträgt deine Wallet die Transaktion an das Netzwerk, üblicherweise über einen RPC-Node.

6. Bestätigung

Sobald deine Transaktion in einen Block aufgenommen und der Blockchain hinzugefügt wurde, ist sie bestätigt. Die meisten Wallets informieren dich über den Abschluss. Du kannst die Transaktion auch mit einem Blockchain-Explorer wie Etherscan oder Solscan verfolgen.

User Experience (UX) auf L2s

Bei der Interaktion mit einer L2 gibt es deutliche UX-Unterschiede. So würde ein neuer Nutzer bei Optimism, einer der größten Ethereum-L2s, einsteigen:

1. Wallet herunterladen

Falls du noch keine hast, lade eine Wallet herunter und richte sie ein. Nutzer verwenden in EVM-Ökosystemen üblicherweise dieselbe Wallet, etwa Metamask.

2. Optimism-Netzwerk hinzufügen

3. ETH bei Optimism einzahlen

• Bei großen L2s ist dies häufig direkt in der Wallet möglich.
• Alternativ kannst du die offizielle Optimism-Bridge besuchen.
• Wähle die Menge an ETH aus, die du zu Optimism übertragen möchtest, und bestätige die Transaktion.

4. In deiner Wallet zum Optimism-Netzwerk wechseln

Öffne deine Wallet und wähle im Netzwerk-Dropdown-Menü „Optimism“ aus.

5. Mit Optimism-kompatiblen Anwendungen und Frontends interagieren

Wähle bei Anwendungen, die das Optimism-Netzwerk unterstützen, „Optimism“ aus.

L2s haben bei der UX Fortschritte gemacht, insbesondere bei nativen Assets und beim Onboarding. Circle, der Betreiber von USDC, bietet auf den meisten großen L2s native USDC-Versionen an. Dadurch entfällt das zusätzliche Gegenparteirisiko, das normalerweise mit Bridges und Wrapped Token verbunden ist. Der Vertriebsvorteil von Coinbase hat außerdem enge Integrationen zwischen der Coinbase-Plattform und Base ermöglicht. Base ist eine Ethereum-L2, deren einziger Sequencer-Betreiber Coinbase ist.

L2-Komponenten

Nachdem Nutzer Guthaben auf eine bestimmte L2 übertragen haben – was je nach L2 undurchsichtig und kompliziert sein kann –, ähnelt die User Experience bei Transaktionen auf einer L2 häufig der einer L1. Früher nutzten L2s Ethereum hauptsächlich für verschiedene Teile des Blockchain-Stacks. Heute verfolgen viele L2s jedoch einen „modularen“ Ansatz. Dieser erlaubt es, verschiedene Ökosysteme und Infrastrukturen zu kombinieren. Dabei werden die zentralen Komponenten einer L2 getrennt: Ausführung, Abwicklung und Datenverfügbarkeit. Zuvor verwendeten L2s Ethereum für alles außer der Ausführung. Neue Lösungen für Abwicklung und Datenverfügbarkeit ändern das jedoch schnell. L1s stellen dagegen alle Komponenten integriert und nach festen Vorgaben bereit. Entwickler können ohne Zustimmung der Governance keine gewünschte Architektur wählen.

Ausführung

Bei der Ausführung wird eine Zustandsübergangsfunktion auf den Ausgangszustand angewendet, um den Folgezustand zu erzeugen. Verschiedene virtuelle Maschinen (VMs) wie die Ethereum Virtual Machine (EVM), Solanas Sealevel (SVM), MoveVM oder FuelVM dienen als Standards für diese Zustandsübergänge. Jede VM bietet eigene Funktionen, die sich auf Kompatibilität, verfügbare Entwicklerwerkzeuge und die Effizienz der Transaktionsverarbeitung auswirken. Sie schaffen die Umgebung für die Ausführung von Smart Contracts und Protokollen.

Auf der Ausführungsschicht stellen Anwendungsentwickler ihren Code bereit, Transaktionen finden statt und Nutzer interagieren mit dem Zustand der Blockchain. Diese Schicht verarbeitet Transaktionen schnell und delegiert Sicherheit und Datenverfügbarkeit an andere spezialisierte Schichten.

Die virtuelle Maschine der L2 muss nicht mit der virtuellen Maschine der L1 übereinstimmen. Historisch war das meist der Fall – die meisten L2s sind EVM- oder EVM-kompatible Rollups. Inzwischen erkunden jedoch mehr Teams diesen Designraum mit unterschiedlichen virtuellen Maschinen, die über Ethereum „abwickeln“, darunter Eclipse und Movement Labs.

Abwicklung

Viele betrachten „Abwicklung“ inzwischen als überladenen Begriff. Um Abwicklung zu verstehen, musst du zwischen der Perspektive des „Rollups“ und der „Bridge“ unterscheiden. Bridges folgen häufig einem einwöchigen Finalisierungsprozess, doch die Bridge ist nicht das Rollup. Aus Sicht des Rollups erfolgt die Finalisierung, nachdem der Zustandsübergang geprüft und die relevanten Daten auf einer Datenverfügbarkeitsschicht veröffentlicht wurden.

Abwicklungsschichten erfüllen für Rollups mehrere zentrale Funktionen:

• Verifizierung und Streitbeilegung: Sie dienen als Plattformen, auf denen Rollups ihre Beweise zur externen Validierung veröffentlichen. Das ist entscheidend für Optimistic Rollups, die auf interaktive Fehlerbeweise angewiesen sind.
• Bridge-Hub: Als zentraler Knotenpunkt verbinden Abwicklungsschichten Rollups miteinander. Separate Bridges zwischen jedem einzelnen Rollup werden dadurch überflüssig.
• Liquiditätsquelle: Alle zugehörigen Rollups können auf die Liquidität der Abwicklungsschicht zugreifen. Das erleichtert Transaktionen und Interaktionen.

Wie erwähnt, besitzt Ethereum die interessantesten und nominell wertvollsten Assets im Kryptobereich. Menschen möchten mit dem Zustand auf Ethereum interagieren. Ethereum wird als „Abwicklungsschicht“ genutzt, weil Nutzer klar bevorzugen, über eine fest verankerte Bridge mit einer separaten Chain zu interagieren – der jeweiligen Ethereum-L2. Der Markt bewertet L1-zu-L1-Bridges nicht genauso, wahrscheinlich wegen früherer Hacks und einer komplizierteren UX. L1-zu-L2-Bridging lässt sich oft eng in eine einzige Wallet integrieren. Die UX verbessert sich schnell: Wallets wie Phantom unterstützen Ethereum und Solana, während Metamask Snaps veröffentlicht hat. Formaler ausgedrückt akzeptieren Nutzer die fest verankerte Bridge, die das jeweilige Rollup definiert.

Das Nutzerverhalten verändert sich schnell. Wormhole hat in den letzten 30 Tagen ein Volumen von mehr als 500 Millionen US-Dollar bewegt und nähert sich damit dem 30-Tage-Bridge-Volumen von Optimism in Höhe von 825 Millionen US-Dollar.

Man kann argumentieren, dass L1-L1-Bridges aufgrund von Pfadabhängigkeit Schwierigkeiten hatten. Dazu trugen große Hacks wie der Wormhole-Hack Anfang 2022 bei. Die gemeinsame Nutzung von DA ermöglicht zwar besondere technische Vertrauensannahmen, doch die tatsächlichen Implementierungen von L1-L2- und L1-L1-Bridges werden häufig durch ein Multisig abgesichert.

Die wichtigste Erkenntnis: Rollups „wickeln über Ethereum ab“ – genauer gesagt finalisieren sie eine fest verankerte Bridge zu Ethereum –, um für Nutzer und Liquidität ausdrücklich auf den Zustand von Ethereum zuzugreifen. Die Abwicklung selbst ist für Ethereum kein profitables Geschäft. Rollups wie Optimism zahlen weniger als 50 US-Dollar pro Tag in ETH an Ethereum für die Abwicklung. Mehr als 80 % der Rollup-Kosten entfallen auf die Veröffentlichung von Daten als calldata in Ethereum-L1-Blöcken. Deshalb herrscht heute ein so starker Wettbewerb bei Lösungen für die Datenverfügbarkeit. Insgesamt machen L2s etwa ~6 % der Ethereum-L1-Gebühren aus, wenn Ethereum für die Datenverfügbarkeit genutzt wird.

Datenverfügbarkeit (DA)

Datenverfügbarkeit bezeichnet bei Blockchains die Garantie, dass alle Daten eines Blocks tatsächlich veröffentlicht und für das Netzwerk zugänglich sind. Dieses Konzept ist für die Funktionsfähigkeit und Sicherheit von Blockchains entscheidend, insbesondere bei ihrer Skalierung. Ein Block besteht üblicherweise aus einem Header und den Transaktionsdaten. Full Nodes laden jede Transaktion herunter und validieren sie. Ressourcenschonendere Light Clients nutzen dagegen nur den Block-Header und gehen davon aus, dass die Transaktionen gültig sind. Das Datenverfügbarkeitsproblem entsteht, wenn ein Blockproduzent einen Block-Header veröffentlicht, aber einen Teil oder alle Transaktionsdaten zurückhält.

Angriffe durch das Zurückhalten von Daten sind bisher nicht aufgetreten, stellen aber eine Bedrohung für Blockchain-Netzwerke dar. Bei einem solchen Angriff hält ein böswilliger Blockproduzent absichtlich einen Teil der Transaktionsdaten eines neuen Blocks zurück. Dadurch können andere Netzwerkteilnehmer die Transaktionen des Blocks nicht validieren. Die Folgen reichen von Netzwerkstörungen bis hin zu schwerwiegenderen Problemen wie betrügerischen Transaktionen. Schwere und Auswirkungen hängen von der Struktur der Blockchain – Layer 1 oder Layer 2 – und davon ab, ob die Datenverfügbarkeit on-chain oder off-chain verwaltet wird. Das Risiko unterstreicht, wie wichtig robuste Mechanismen zur Sicherstellung der Datenverfügbarkeit und wirksame Strategien gegen solche Angriffe sind.

Zur Lösung des Datenverfügbarkeitsproblems können alle Full Nodes sämtliche Daten herunterladen, was viele Ressourcen verbrauchen kann. Innovative Ansätze umfassen Beweise der Datenverfügbarkeit und Data Availability Sampling (DAS). Diese Beweise verwenden Techniken wie Erasure Coding. So können Clients die Datenverfügbarkeit prüfen, indem sie nur einen kleinen Teil des Blocks herunterladen.

Ein echtes „Ethereum-Rollup“ muss nach der aktuellsten Terminologie Ethereum für die Datenverfügbarkeit nutzen. Damit es als Rollup gilt, muss es Transaktionsdaten als calldata auf der Ethereum-L1 veröffentlichen. Ethereum arbeitet derzeit an der Implementierung von EIP-4844. Damit entsteht ein separater Markt für Blobspace (Transaktionsdaten), auf dem Daten-Blobs zu einem nochmals reduzierten Preis veröffentlicht werden können. Selbst wenn 4844 live ist, erhöht es die Datenverfügbarkeit nur um den Faktor ~7. Das entspricht über alle Rollups hinweg etwa 100 TPS (Transaktionen pro Sekunde). Zum Vergleich: Die Nachfrage von Solana nach Blockspace liegt bei rund 500 TPS. Solana hat zudem gezeigt, dass es mehr als 2000 TPS bewältigen kann. Darüber hinaus ist Solana so konzipiert, dass es mit Hardware gemäß dem Mooreschen Gesetz und Softwarefortschritten wie Firedancer skaliert.

Die Datenverfügbarkeit kann zwar gewisse kleine Netzwerkeffekte aufweisen, doch der Wettbewerb dürfte die Kosten für die Veröffentlichung von Daten in einer Datenverfügbarkeitslösung sehr nahe an die marginalen Betriebskosten drücken.

DA stellt sicher, dass alle für die Rekonstruktion des Zustands einer L2 erforderlichen Transaktionsdaten über einen vordefinierten Zeitraum zugänglich sind. Kurzfristig nutzen Validiums und Volitions separate Datenverfügbarkeitsschichten. Ethereums langfristige Roadmap sieht dagegen eine verbesserte Datenverfügbarkeitslösung durch Upgrades wie EIP-4844 vor. Alternative Lösungen für die Datenverfügbarkeit – etwa Polygon Avail, Celestia und EigenDA – dürften eine wichtige Rolle spielen und verschiedene DA-Designs weiter erschließen. Mit Ausnahme von Celestia sind diese Lösungen jedoch noch nicht live. Celestia hat gerade sein Mainnet gestartet, doch bislang veröffentlicht dort noch kein Rollup Daten. Alle basieren auf neuartigen Systemen und haben ihre Skalierbarkeit im Produktivbetrieb noch nicht bewiesen. Zudem weisen sie ein breites Spektrum eigener Sicherheits- und Vertrauensannahmen auf. Diese Lösungen bieten eine Zwischenlösung, bis Ethereums umfassende Datenverfügbarkeitsschicht einsatzbereit ist. Möglicherweise zeigen sie selbst nach der Ethereum-Integration Netzwerkeffekte.

Lebenszyklus einer L2-Transaktion

Der Lebenszyklus einer Transaktion auf Arbitrum, einem Layer-2-Protokoll, umfasst von der Initiierung bis zur Bestätigung und Finalisierung mehrere Phasen:

1. Sequencer empfängt die Transaktion

Transaktionen beginnen beim Sequencer. L2-Transaktionen erreichen ihn entweder direkt beziehungsweise off-chain, Einzahlungen dagegen von der L1 über die Delayed Inbox.

2. Sequencer ordnet die Transaktion off-chain ein

Der Sequencer ordnet die Transaktion in seiner Off-chain-Inbox ein und führt sie mit der Arbitrum Nitro VM aus. Dabei stellt er dem Client eine „sofortige“ Bestätigung aus. Die Finalität dieser Phase hängt vom Vertrauen in den Sequencer ab.

3. Sequencer veröffentlicht die Transaktion in einem Batch on-chain

Der Sequencer veröffentlicht regelmäßig Batches von L2-Transaktionen auf der L1 und fügt die relevanten Daten als calldata hinzu. Nimmt der Sequencer eine Transaktion nicht auf, kann der Client ihre Aufnahme nach einer Verzögerung erzwingen, also eine erzwungene Aufnahme auslösen. Solange mindestens ein korrekt handelnder aktiver Arbitrum-Validator vorhanden ist, entspricht die Finalität der Transaktion in dieser Phase der einer Ethereum-Transaktion.

4. Validator bestätigt einen Rollup-Block (RBlock) mit der Transaktion

Validatoren bestätigen in regelmäßigen Abständen den Zustand der L2-Chain auf der L1. RBlock-Bestätigungen enthalten Aussagen über den Zustand der Outbox für Nachrichten von L2 zu L1. Bei einer Anfechtung: Im Streitfall führen Validatoren einen detaillierten Prüfprozess bis hinunter zu einem einzelnen Vorgang durch. Contracts auf der L1 fungieren dabei als Schiedsrichter.‍

5. RBlock wird auf L1 bestätigt

Nach der Streitbeilegung und einem ausreichend langen Zeitfenster wird der RBlock auf L1 bestätigt und die Outbox-Root aktualisiert.

Dieser Prozess stellt sicher, dass die darin enthaltene L2-Transaktion nach der Bestätigung einer L1-Transaktion, die einen Batch aufzeichnet, dieselbe Finalität wie eine reguläre Ethereum-Transaktion besitzt. Enthält die Transaktion Nachrichten von L2 zu L1, können sie erst nach der RBlock-Bestätigung auf L1 ausgeführt werden.

Rollups existieren außerhalb von Ethereum. Das darf nicht mit der Tatsache verwechselt werden, dass viele Rollups heute auf der EVM aufbauen oder EVM-äquivalent sind. Deshalb müssen in der Transaktionslieferkette zusätzliche Aspekte und Beteiligte berücksichtigt werden. Arbitrum und Optimism, die heute dominierenden Rollups auf Ethereum, weisen folgende Merkmale auf:

• Zentralisierter Sequencer: Arbitrum und Optimism, die größten Optimistic Rollups für Ethereum, arbeiten derzeit jeweils mit einem einzigen zentralisierten Sequencer. Dieser Sequencer ordnet alle Transaktionen. Künftig soll diese Rolle dezentralisiert und möglicherweise von L2-Nodes übernommen werden, über die die Community abstimmt. Details und Zeitpläne sind jedoch noch unklar. Nutzer vertrauen darauf, dass der Sequencer keinen Orderflow verkauft, Transaktionen nicht neu ordnet und auch auf andere Weise kein MEV extrahiert. Fehlerbeweise stehen auf der Roadmap, sind für erlaubnisfreie Anfechtungen aber noch nicht live.
• Vertrauensannahme: Die Finalität hängt in dieser Phase vom Vertrauen in den Sequencer ab. Der Sequencer kann Transaktionen nur ordnen oder verzögern, aber nicht verändern. Bei Arbitrum können Transaktionen, die länger als 24 Stunden verzögert wurden, zwangsweise aufgenommen werden. Optimism nimmt L1-Transaktionen dagegen automatisch in den nächsten verfügbaren L2-Block auf.
• L1-Reorgs: Wenn eine L1-Reorg auftritt, ist nicht ausdrücklich festgelegt, wie L2-Blöcke fortgeführt und behandelt werden. Dadurch bleibt die Transaktionsfinalität während L1-Reorgs mit Unsicherheit behaftet.
• Finalität: Sequencer bündeln L2-Transaktionen und veröffentlichen sie als calldata auf Ethereum. So erreichen sie eine „harte Finalität“, die der Finalität des Ethereum-Blocks entspricht, in den sie aufgenommen wurden. Anschließend wird die Root des L2-State-Trees, die den neuesten Zustand des Rollups darstellt, auf L1 aktualisiert. Das gewährleistet unumkehrbare Zustandsänderungen.
• Anfechtungsfrist und Auszahlung: Validatoren auf Arbitrum können State Roots anfechten und damit einen Streitbeilegungsprozess auslösen. Bleibt eine Zustandszusage innerhalb des festgelegten Zeitraums unangefochten, wird sie final. Nach Ablauf der Anfechtungsfrist sind Auszahlungen von L2 zu L1 auf Grundlage des finalen Zustands möglich.
• Bridging: Bridging-Protokolle berücksichtigen unterschiedliche Finalitätsstufen – von sofortigen Bestätigungen unter „weicher Finalität“ bis zu gebündelter calldata unter „harter Finalität“. Je nach Transaktionstyp, Anforderungen des Clients und Risikobewertung können Bridges eine schnellere Nachrichtenübermittlung wählen oder strengere Finalitätsstandards einhalten.

Wo L2s sinnvoll sind

L2s sind zustandsbehaftete Systeme. Jede zusätzliche L2 fragmentiert den Zustand über die verschiedenen L2s hinweg. Zwar geht die atomare Komponierbarkeit verloren – deren Bedeutung möglicherweise überschätzt wird –, doch für manche Anwendungen ist die Bereitstellung auf einer L2 sinnvoll. Außerdem ist die Wahl der richtigen L2 sehr wichtig, selbst wenn sie auf einer beliebten Ausführungsumgebung wie der EVM basiert. Die Benutzererfahrung, Integrationen und Distribution unterscheiden sich zwischen L2s erheblich.

Ohne zu sehr ins technische Detail zu gehen, lassen sich L2s grob in anwendungsspezifische Rollups und universelle Rollups unterteilen.

Anwendungsspezifische Rollups

Anders als L1s und andere zuvor erwähnte L2s teilen anwendungsspezifische Rollups ihren Blockspace nicht mit anderen Anwendungen. Stattdessen sind sie dedizierte Blockchains für eine bestimmte Anwendung oder eine Gruppe von Anwendungen. Daher bist du für den Betrieb der gesamten zugehörigen Infrastruktur verantwortlich.

Einige Teams sind zwar vertikal integriert und betreiben ihre Infrastruktur tatsächlich selbst (dydx), doch das ist ein enormer technischer Aufwand. In der Regel gelingt dies nur Teams, die bereits Product-Market-Fit (PMF) erreicht haben. dydx verfügt über Product-Market-Fit, eine starke Community und genügend Ressourcen dafür – nachdem das Projekt zunächst auf Ethereum und später auf einer Ethereum-L2 PMF erreicht hatte. Andere Projekte wie Maker untersuchen Konzepte wie eine SVM-App-Chain. In der Praxis betreiben die meisten Teams keine eigene Hardware. Stattdessen verlassen sie sich auf Rollup-as-a-Service-Anbieter (RaaS), die diese Lücke schließen wollen, etwa Caldera und Conduit.

Es ist offen, ob anwendungsspezifische Chains langfristig genug Umsatz erzielen können, um profitabel zu sein. In diesen Fällen musst du das Kontrahentenrisiko und die Kostenstruktur der RaaS-Anbieter verstehen. RaaS-Anbieter verlangen oft eine feste Gebühr – je nach Anwendungsgröße häufig zwischen $5.000 und $100.000 – sowie einen Anteil am Gewinn des Sequencers. Die meisten RaaS-Anbieter nutzen etablierte Standards wie den OP Stack, um einen „Lock-in“ zu vermeiden. Selbst wenn der RaaS-Anbieter ausfällt, kannst du deine eigene Hardware weiter betreiben, sofern du den kurzfristigen Ausfall der Verfügbarkeit überbrücken kannst.

Da Gaming ein spezialisierterer Anwendungsfall ist, werden aktiv neue Implementierungen und Protokolle entwickelt, etwa Argus’ World Engine. Am 5. Dezember startete Dark Frontiers als Ausführungs-Shard auf Argus’ EVM-L2 für vollständig On-Chain laufende Spiele. Das unterscheidet sich von heutigen On-Chain-Spielen, die lediglich einfache Spielgegenstände On-Chain veröffentlichen. Auch wenn sich das noch zeigen muss, scheint dieses Modell irgendwo zwischen anwendungsspezifischen und universellen Rollups zu liegen.

Universelle Rollups

Da Rollups isolierte Umgebungen mit weniger wirtschaftlichem Kapital im Risiko sind, haben sie einen gewissen Anreiz, mit einzelnen Schichten des Stacks zu experimentieren, etwa auf Ausführungs- und Konsensebene, um ein differenziertes Produkt anzubieten. Die meisten Rollups sind jedoch Standardversionen bestehender VMs – mit Ausnahme von Fuel. Der Grund: Sie wollen es bestehenden Anwendungen so einfach wie möglich machen, ihre L2 zu nutzen. Dadurch starten Teams, die auf Ausführungs- und Konsensebene innovativ sind, eher ihre eigene L1, etwa Monad.

Weitere Experimente auf der Ausführungsebene könnten bevorstehen, da die Zahl der Rollups ein sinnvolles Gleichgewicht bei Weitem übersteigt. Das gilt besonders für Rollups, die Schwierigkeiten haben, Nutzer und Liquidität zu gewinnen.

Aktueller Stand universeller Rollups

Universelle Rollups wie Arbitrum, Optimism und Base zeigen starke Netzwerkeffekte. Sie haben zahlreiche bestehende und neue Anwendungen angezogen, die auf diesen L2s starten, darunter GMX und friend.tech. Da die nativen Assets und der Zustand von Ethereum auf diesen L2s verfügbar sind – und Ethereum oft zur Denominierung des Gas-Tokens dient –, erhalten Nutzer und Entwickler Zugang zu einem umfangreichen, ausgereiften Ökosystem. Dieser Zugang ist entscheidend für Anwendungen, die Liquidität sowie bestehende Ethereum-basierte Protokolle und Assets benötigen. Für eine bessere Benutzererfahrung haben Plattformen wie Coinbase native Wallet- und Zahlungsunterstützung für Base integriert, wo Coinbase den einzigen Sequencer betreibt. Dadurch wird die Nutzung nahtlos und benutzerfreundlich.

Wenn du verschiedene L2s vergleichst, solltest du alternative Ausführungsumgebungen für die Bereitstellung, die Liquidität und die L2-Infrastruktur selbst berücksichtigen. Faktoren wie die Kostenstruktur der Datenverfügbarkeit, mögliche künftige Änderungen der Netzwerkgebühren und die Entwicklung bei Infrastrukturanbietern sollten in die Entscheidung einfließen. Anwendungsentwickler müssen sowohl die aktuelle Kostenstruktur für Nutzer verstehen als auch realistische Prognosen für die Zukunft erstellen. Besonders wichtig sind dabei die Kosten der Datenverfügbarkeit. Wenn du eine Bereitstellung auf einer L2 erwägst, musst du die Feinheiten der Systeme kennen. Achte besonders auf die gewählte Ausführungsumgebung und alternative Bereitstellungsoptionen.

Neue, von der Ethereum Foundation geleitete Forschung, etwa zu von der L1 sequenzierten „Based Rollups“, bedeutet, dass sich Rollups bei Verfügbarkeit, Dezentralisierung und Benutzererfahrung weiter verbessern werden. Dezentrale Sequencer – oder zumindest eine Rotation mehrerer Sequencer für eine höhere Verfügbarkeit – befinden sich noch in der Forschungsphase. Sie versprechen jedoch Fortschritte bei der Zuverlässigkeit und könnten das aktuelle Sequencer-Risiko verringern. Heute vertrauen Nutzer darauf, dass der vom L2-Kernteam betriebene Sequencer Transaktionen fair anordnet und nicht durch deren Neuordnung böswillig MEV extrahiert. Bei Zensur durch den Sequencer können Nutzer Transaktionen über erzwungene Aufnahme auch direkt an die L1 senden.

Andererseits fehlen den heutigen Rollups einige wichtige Funktionen, die laut ihren Roadmaps aktiv entwickelt werden. Keines der großen optimistischen Rollups bietet beispielsweise erlaubnisfreie Fehlernachweise. Häufig werden diese zudem durch aktualisierbare Verträge mit Multisig-Kontrolle eingeschränkt. Vielen Rollups fehlen außerdem Notausgänge, über die Nutzer ihre Mittel bei einem böswilligen Sequencer abheben können.

Das Endgame universeller Rollups

Ein mögliches Ergebnis ist ein Endgame für universelle Rollups mit einem „leistungsstarken“ Sequencer oder einer Gruppe von Sequencern. Falls Ethereum seine Position als Chain mit dem interessantesten Zustand behält und Nutzer weiterhin L1-zu-L2-Bridges deutlich bevorzugen, können eine oder mehrere universelle Rollup-L2s erhebliche Vorteile bei der Ausführung und damit eine wesentlich bessere Benutzererfahrung bieten. 

Die L1 würde faktisch nur noch dazu dienen, die vom Rollup benötigten Eigenschaften bereitzustellen. Dadurch entfiele für die L2 das Risiko einer L1-Reorganisation. Die L2 könnte sich auf die Faktoren konzentrieren, die Endnutzer interessieren: Latenz und möglichst effiziente Aktualisierungen des Zustands, üblicherweise in Form von besseren Preisen. Ethereum – die bevorzugte L1 – spielt weiterhin eine Rolle, weil der soziale Konsens dem Ethereum-Zustand aus memetischen Gründen Wert beimisst, etwa wegen glaubwürdig dezentralisierter Beteiligter oder eines fairen Starts. Die L2 existiert als fremde Entität gegenüber der L1.

Die Rollups weisen folgende Funktionen und Eigenschaften auf:

• Erlaubnisfreie Innovation – jeder kann neue Anwendungen entwickeln und bereitstellen
• Zensurresistenz – durch erzwungene Aufnahme auf der L1
• Datenverfügbarkeit – entweder direkt auf der L1 oder über eine separate DA-Schicht
• Gültigkeit – Fehler- oder zk-Nachweise
• Parallelisierte Ausführungsumgebung – Transaktionen werden äußerst effizient verarbeitet

In diesem Endgame gibt es einige wenige (2?) Rollups mit einer relevanten Zahl von Nutzern und einem relevanten Volumen. Die nächste Anwendung entscheidet sich für dieses Rollup, weil der enorme Zugang zu Nutzern die Kosten für gemeinsam genutzten Blockspace überwiegt, die auf nahezu null amortisiert werden. Die erkennbaren Präferenzen der Nutzer zeigen, dass eine möglichst einfache UX höchste Priorität hat. Falls wir dieses Szenario jemals erreichen, hat Krypto das traditionelle Finanzwesen praktisch neu erfunden – mit mehreren entscheidenden Verbesserungen: erlaubnisfreie Innovation, Zensurresistenz, eigenständige Verwahrung und Transparenz. Nur eine kleine Gruppe von Akteuren hat Schreibzugriff auf traditionelle Finanzmärkte. Die NYSE und andere Börsen sind streng regulierte und zugangsbeschränkte Märkte, die Einzelpersonen gemäß geltenden Gesetzen und Vorschriften zensieren können.

In diesem Szenario gäbe es weiterhin Latenz und Co-Location mit Sequencern, ähnlich wie im traditionellen Finanzwesen mit Orderbuchservern. Derzeit bestimmen politische Vorgaben und Pfadabhängigkeiten, welche Entitäten die Erlaubnis zur Co-Location in den Servern der NYSE erhalten. Citadels jahrzehntelange Erfahrung mit der Optimierung von Infrastruktur und Algorithmen, die Endnutzern bessere Preise bieten, bleibt auch in einem erlaubnisfreien Umfeld relevant. In diesem Rollup-Endgame würden Einzelpersonen und Teams stattdessen ausschließlich über ihre Leistung mit allen anderen talentierten Menschen weltweit konkurrieren. Das führt zu besseren Preisen und einer besseren Erfahrung für Endnutzer.

In der Theorie klingt das alles gut, doch der heutige Zustand der L2s zeichnet ein ganz anderes Bild. Nicht nur werden die einzigen Sequencer vom Kernteam betrieben und bilden damit einen einzelnen Ausfallpunkt für die Verfügbarkeit. Häufig kontrollieren die Teams auch die wichtigsten Aktionen, etwa den Bridge-Vertrag oder zugangsbeschränkte Fehlernachweise. Viele L2s planen zwar, diese Komponenten zu dezentralisieren und die Multisig zu entfernen, doch heute ist das noch nicht Realität.

Wo L1s sinnvoll sind

Ein gemeinsamer Zustand auf Layer-1-Blockchains wie Solana und Ethereum ermöglicht erlaubnisfreie Komponierbarkeit. Anwendungen können dadurch ohne Vertrauen und sicher miteinander interagieren. Das ist unter anderem für Marketingstrategien wie gezielte Airdrops nützlich. Mithilfe des gemeinsamen Zustands kann ein Projekt beispielsweise bestimmte NFT-Communitys identifizieren und belohnen. Das ermöglicht hochgradig fokussierte und effektive Belohnungsmechanismen. Pyth, ein Multi-Chain-Orakel für Daten, hat kürzlich über einen Airdrop $PYTH auf Solana an alle verteilt, die über mehr als 40 Blockchains hinweg mit seinem Protokoll interagiert hatten. Projekte können Besitzmuster und die Beteiligung von Communitys innerhalb der Blockchain analysieren und ihre Belohnungen gezielt anpassen. Dazu zählen exklusive Tokens oder der Zugang zu neuen Diensten. So können sie bestimmte Segmente der Blockchain-Community ansprechen, Anreize schaffen und wirkungsvollere Marketingmaßnahmen entwickeln, die bei der Zielgruppe Anklang finden.

Nur ein gemeinsamer Zustand ermöglicht diese On-Chain-Zuordnung für Belohnungen und Aktionen. Jupiter, ein einheitlicher Trading-Aggregator, der Nutzern die bestmöglichen Preise garantiert, ist ein Beispiel für eine Anwendung, die nur auf einer Chain mit gemeinsamem Zustand wie Solana möglich ist.

Neben DeFi gehören Zahlungen zu den wichtigsten Anwendungsfällen für Krypto. Nutzer können beliebige Werte ohne abschöpfende Zwischenhändler wie Western Union übertragen. Zahlungen umfassen sowohl Peer-to-Peer-Transaktionen wie bei Venmo als auch Transaktionen von Unternehmen an Verbraucher, etwa beim Online-Shopping. Entscheidend ist, dass Zahlungen so günstig und schnell sind, dass Nutzer beim Geldversand nicht über Gas-Kosten nachdenken müssen. Auf Solana liegen mehr als die Hälfte aller USDC-Überweisungen unter $5. Das ist nur auf Blockchains mit extrem niedrigen Gas-Kosten wie Solana möglich.

Darauf lassen sich neue Unternehmen aufbauen, etwa Tiplink. Der Dienst ermöglicht es Menschen, Geld über eine URL zu senden, ohne eine Wallet einzurichten – sogar die Anmeldung mit Google-Zugangsdaten ist möglich. Shopify hat Solana Pay integriert, sodass Käufer ihren Einkauf auf Solana mit USDC bezahlen können. Visa entschied sich für eine Integration mit Solana, um USDC für die globalen Zahlungsabwickler Worldpay und Nuvei abzurechnen. Code hat mit dauerhaften Nonces eine pseudo-asynchrone Ausführungsumgebung geschaffen. Damit konnte das Team ein extrem schnelles System für Zahlungsbenachrichtigungen und eine nahtlose Benutzererfahrung entwickeln. Manche bezeichnen dies als L2, doch das System besitzt keine Fehlernachweise und ist ausschließlich auf eine bessere Erfahrung für Endnutzer optimiert.

Solana hat keine L2s, weil Transaktionen bereits so günstig sind und der Zustand innerhalb eines Blocks nativ getrennt und separat bepreist wird. Solana wurde von Anfang an darauf optimiert, den synchronisierten Zustand so schnell bereitzustellen, wie es die Physik erlaubt, und die Transaktionskosten so nah wie möglich an die Grenzkosten des Betriebs zu bringen. Auf Ethereum sind Transaktionen unter anderem aufgrund der Single-Thread-EVM deutlich teurer. Der Zustand kann nur dann separat bepreist werden, wenn eine weitere Instanz der virtuellen Maschine läuft – genau das leisten L2s. Solana und andere Blockchains mit parallelen VMs ermöglichen lokale Gebührenmärkte. Unterschiedliche Teile des Zustands haben abhängig davon, wie stark sie umkämpft sind, unterschiedliche Gebühren. Ein lokaler Hotspot im Zustand lässt sich verwalten, ohne Konflikte oder Gebühren auf der gesamten Blockchain zu erhöhen. In der Praxis bedeutet das, dass ein NFT-Mint oder Airdrop kaum externe Auswirkungen auf deine separate Anwendung hat. 

Anders als bei L2s steht das Endgame für Solana nicht auf der Roadmap – es ist bereits Realität. Solana wird zwar über SIMDs aktiv gewartet und verbessert, ist aber schon heute ein funktionsfähiges und glaubwürdig neutrales Asset-Ledger. Es erfordert kein zusätzliches Vertrauen in Multisigs, Alignment oder bloße Überzeugungen.

Welche Lösung ist für mich am besten?

Das hängt davon ab, worauf du optimierst. Grundsätzlich sollten Anwendungsentwickler und Unternehmen nur so viel Zeit wie unbedingt nötig in die Wartung der Blockchain-Infrastruktur investieren. Nutze den Großteil deiner Zeit stattdessen dafür, dein Produkt weiterzuentwickeln und die bestmögliche Benutzererfahrung zu schaffen. Die Frage lautet: Wie viel ist für dich notwendig?

Wenn du eine bestimmte Chain auswählst, solltest du die dort verfügbaren Grundbausteine genau untersuchen. Ein Beispiel sind Anwendungen wie Drip, auf denen bereits über 60 Millionen NFTs geprägt wurden und die 500.000 Sammler haben.

Deine Optimierungsziele grenzen die Auswahl der Chain letztlich ein. Ausgehend von der obigen Zusammenfassung der verschiedenen L1s und L2s solltest du folgende Aspekte berücksichtigen:

1. On-Chain-Nutzer
2. On-Chain-Nutzung (wenn du für eine bestimmte On-Chain-Funktion wie Trading optimierst, solltest du Chains mit niedrigen Gebühren untersuchen, etwa Solana, Sui oder Optimism. Du musst die technischen Kompromisse und Grenzen kürzerer Blockzeiten, größerer Blöcke usw. verstehen.)
3. Ausführungszeit
4. On-Chain-Liquidität
5. On-Chain-Wale/Liquidität (das EVM-Ökosystem verfügt beispielsweise aufgrund der früheren Ära der Token-Starts tendenziell über mehr Liquidität, doch das ändert sich schnell)
6. Zugang zu bestimmten On-Chain-Communitys (Künstler, Trader usw.)
7. Verfügbarkeit von Fördermitteln und Risikokapital (neuere Ökosysteme bieten mehr Fördermittel, aber weniger Risikokapital)
8. Technische Komplexität und Verwaltungsaufwand (Code benötigt beispielsweise nur zwei Entwickler, um seine Anwendung auf Solana zu betreiben, während dydx mehr als 30 Entwickler und Forscher braucht)
9. Programmierbarkeit und Souveränität bei den Chain-Regeln (z. B. spezielle Regeln für die Handelsabwicklung)
10. Zugang zu institutionellen Akteuren (z. B. Coinbase auf Base sowie Visa und Shopify auf Solana)
11. Komponierbarkeit mit anderen Anwendungen im Ökosystem (z. B. DeFi- und Zahlungsanwendungen)

Für bestimmte Anwendungen, die die zuvor genannten Eigenschaften verstehen und gezielt nutzen, kann die Bereitstellung auf bestimmten Rollup-Konstruktionen sinnvoll sein. Für die meisten Anwendungen stellt Solana die nötigen Grundbausteine für den Erfolg bereit. Seine einzigartige Designentscheidung macht es schnell, günstig und leistungsfähig. Zudem läuft Solana seit vielen Jahren produktiv.

Fazit

Um sich in der Blockchain-Landschaft zurechtzufinden und insbesondere zwischen Layer-1- (L1) und Layer-2-Plattformen (L2) zu wählen, musst du die jeweiligen Kompromisse differenziert verstehen. Die Wahl zwischen L1 und L2 ist mehr als eine technische Entscheidung. Sie ist eine entscheidende Geschäftsstrategie, die Skalierbarkeit, Sicherheit und die langfristige Tragfähigkeit eines Projekts beeinflusst. Wenn du eine gesamte Codebasis umstrukturierst, entstehen zudem weitere technische Schulden und deine Chancen auf eine erfolgreiche Anwendung sinken.

Die Bedeutung der Benutzererfahrung für die Akzeptanz von Blockchains lässt sich kaum überschätzen. Mit zunehmender Reife der Technologie sollte der Fokus immer stärker auf intuitiven, nahtlosen und benutzerfreundlichen Oberflächen liegen. Sie müssen die Lücke zwischen komplexer Blockchain-Infrastruktur und Endnutzern schließen. Unterschiedliche Anwendungen profitieren zwar von unterschiedlich hoher Flexibilität, doch die meisten Anwendungsentwickler sollten eine Plattform wählen, auf der sie möglichst viel Zeit in die Entwicklung des bestmöglichen Produkts investieren können.

Vielen Dank an Akshay, 0xIchigo und Jon Charbonneau für die Durchsicht und ihre Kommentare.