Sovereign-Rollups vs. Smart-Contract-Rollups im modularen Blockchain-Stack

Definition

Ein Rollup ist eine Skalierungslösung der zweiten Schicht (Layer 2), die Transaktionen außerhalb der Kette ausführt und diese dann zu einem einzigen Stapel bündelt, um sie an eine Layer-1-Blockchain zu übermitteln, wodurch der Durchsatz erheblich gesteigert und Gebühren reduziert werden.

Ein Smart-Contract-Rollup ist eine Art von Rollup, bei dem die Sicherheit und Finalität seines Zustands direkt durch einen Smart Contract erzwungen wird, der auf einer Layer-1-Blockchain bereitgestellt ist. Dieser Vertrag validiert Beweise (Betrugs- oder Gültigkeitsbeweise) und verwaltet Abhebungen, wodurch der Zustand des Rollups von der Konsensfindung der L1 abhängt.

Ein Sovereign-Rollup ist eine unabhängige Blockchain, die eine andere Kette ausschließlich für die Datenverfügbarkeit und potenziell für den Konsens nutzt, aber ihre eigene Zustandsvalidierung und Upgrades selbst verwaltet. Es verlässt sich nicht auf einen Smart Contract auf einer Layer-1 für seine Sicherheit oder seinen kanonischen Zustand und behält somit die volle Souveränität über seine Ausführungsumgebung.

Kernaussage

Der grundlegende Unterschied zwischen Sovereign-Rollups und Smart-Contract-Rollups liegt in ihrer Beziehung zur zugrunde liegenden Layer-1-Blockchain, insbesondere hinsichtlich der Abwicklung und Souveränität. Smart-Contract-Rollups leiten ihre Sicherheit und Zustandsfinalität direkt von einem L1-Smart-Contract ab, wodurch sie in das Sicherheitsmodell der L1 "eingebettet" sind. Im Gegensatz dazu sind Sovereign-Rollups unabhängige Ketten, die eine L1 oder eine andere Kette lediglich für die Datenverfügbarkeit (DA) nutzen, was bedeutet, dass sie ihre Transaktionsdaten dort veröffentlichen, aber ihre eigenen Zustandsübergänge validieren und ihre eigenen Upgrades ohne L1-Smart-Contract-Durchsetzung verwalten. Dies verleiht Sovereign-Rollups größere Flexibilität und Anpassbarkeit, verlagert aber die Verantwortung für die Zustandsvalidierung auf die eigenen Netzwerkteilnehmer des Rollups.

Mechanik

Smart-Contract-Rollups funktionieren, indem sie Transaktionsdaten und Zustands-Roots an einen Bridge-Contract auf einer Layer-1-Blockchain, wie Ethereum, übermitteln. Dieser Vertrag ist dafür verantwortlich, die Korrektheit der Zustandsübergänge des Rollups zu überprüfen, entweder durch Betrugsbeweise (bei Optimistic Rollups) oder Gültigkeitsbeweise (bei ZK-Rollups). Wird ein Betrugsbeweis erfolgreich eingereicht, kann der L1-Vertrag einen ungültigen Zustandsübergang rückgängig machen. Bei ZK-Rollups garantiert der Gültigkeitsbeweis kryptografisch die Korrektheit des Zustandsübergangs, den der L1-Vertrag dann verifiziert. Der L1-Smart-Contract fungiert als ultimativer Schiedsrichter des kanonischen Zustands des Rollups und stellt sicher, dass Vermögenswerte auf dem Rollup dieselben Sicherheitseigenschaften wie die auf der L1-Kette teilen. Diese enge Kopplung bedeutet, dass die Sicherheit des Rollups direkt von der L1 geerbt wird und alle Upgrades oder Änderungen an der Logik des Rollups über den L1-Smart-Contract genehmigt und implementiert werden müssen.

Im Gegensatz dazu funktionieren Sovereign-Rollups als wirklich unabhängige modulare Blockchains. Sie nutzen eine andere Kette, oft als Data-Availability-Schicht (DA-Schicht) bezeichnet, ausschließlich zur Veröffentlichung ihrer Transaktionsdaten. Dies stellt sicher, dass jeder den Zustand des Rollups rekonstruieren kann, eine entscheidende Komponente für die Sicherheit. Im Gegensatz zu Smart-Contract-Rollups haben Sovereign-Rollups jedoch keinen Abwicklungsvertrag auf der DA-Schicht, der ihre Zustandsübergänge erzwingt oder Beweise validiert. Stattdessen sind die Teilnehmer des Sovereign-Rollups selbst für die Validierung des Zustands der Kette und die Einigung auf ihre kanonische Historie verantwortlich. Dies bedeutet, dass die Fork-Choice-Regel und die Zustandsvalidierungslogik des Rollups vollständig in sich geschlossen sind. Diese architektonische Wahl bietet immense Flexibilität, da Sovereign-Rollups ihre Virtual Machine (VM) anpassen, ihren eigenen Sequencer-Set wählen und maßgeschneiderte Governance- und Upgrade-Mechanismen implementieren können, ohne die Genehmigung der L1 zu benötigen. Ein Sovereign-Rollup könnte beispielsweise Celestia für die Datenverfügbarkeit nutzen, aber seine eigene benutzerdefinierte Ausführungsumgebung und seinen eigenen Konsensmechanismus betreiben.

Trading-Relevanz

Für Trader ist das Verständnis des Unterschieds zwischen diesen Rollup-Typen entscheidend, um das Risikoprofil und die potenziellen Chancen der verschiedenen Layer-2-Ökosysteme zu bewerten. Smart-Contract-Rollups bieten aufgrund ihrer direkten Abwicklung auf einer robusten Layer-1 wie Ethereum ein hohes Maß an Sicherheitsvererbung. Dies kann zu größerem Vertrauen in die Sicherheit von Vermögenswerten und deren Finalität führen, was besonders für Transaktionen mit hohem Wert oder langfristige Anlagen wichtig ist. Die Abhängigkeit vom etablierten Sicherheitsmodell der L1 bedeutet, dass das Risiko eines Rollup-spezifischen Exploits oder eines unbemerkten bösartigen Zustandsübergangs erheblich reduziert ist, da der L1-Vertrag als Schutzmechanismus fungiert. Trader, die mit Anwendungen auf Smart-Contract-Rollups interagieren, können im Allgemeinen eine ähnliche Sicherheitshaltung wie die der zugrunde liegenden L1 annehmen, wenn auch mit der zusätzlichen Komplexität des Bridging von Vermögenswerten.

Sovereign-Rollups bieten zwar eine beispiellose Anpassbarkeit und potenziell einen höheren Durchsatz aufgrund ihrer Unabhängigkeit, führen aber eine andere Reihe von Überlegungen ein. Ihre Sicherheit wird nicht direkt durch einen L1-Smart-Contract erzwungen; stattdessen beruht sie auf der Wachsamkeit und Beteiligung ihrer eigenen Netzwerkvalidatoren und Benutzer. Dies bedeutet, dass sich die Vertrauensannahmen von der Sicherheit der L1 auf das eigene Gemeinschafts- und Wirtschaftsicherheitsmodell des Sovereign-Rollups verlagern. Für Trader impliziert dies die Notwendigkeit einer tiefergehenden Due Diligence bezüglich des Validatoren-Sets, der Governance-Mechanismen und der allgemeinen Dezentralisierung des spezifischen Sovereign-Rollups. Obwohl sie neuartige Anwendungen oder hochoptimierte Umgebungen für spezifische Anwendungsfälle bieten könnten, bedeutet das Fehlen einer L1-Abwicklungsschicht, dass die Last der Überprüfung des kanonischen Kettenzustands vollständig auf den Teilnehmern des Rollups liegt. Dies könnte zu unterschiedlichen Finalitätsgarantien und potenziell höheren Risiken führen, wenn das eigene Sicherheitsmodell des Rollups nicht robust oder ausreichend dezentralisiert ist.

Risiken

Das Hauptrisiko, das mit Smart-Contract-Rollups verbunden ist, ergibt sich aus ihrer Abhängigkeit von der zugrunde liegenden Layer 1. Obwohl dies Sicherheit bietet, bedeutet es auch, dass sie alle L1-Schwachstellen oder Überlastungsprobleme erben. Wenn die L1 einen kritischen Fehler oder einen erheblichen Netzwerkangriff erlebt, könnten die Abwicklung und Sicherheit des Smart-Contract-Rollups beeinträchtigt werden. Darüber hinaus könnte der L1-Smart-Contract selbst Fehler enthalten, die potenziell zu Exploits oder einer falschen Zustandsfinalisierung führen könnten. Ein weiteres Risiko betrifft die Zensurresistenz: Obwohl die L1 die Datenverfügbarkeit gewährleistet, könnte ein zentralisierter Sequencer auf dem Rollup Transaktionen immer noch zensieren, bevor sie gebündelt und an die L1 gesendet werden. Während Betrugsbeweise und Gültigkeitsbeweise viele Risiken mindern, kann die Komplexität dieser Systeme unvorhergesehene Angriffsvektoren einführen.

Sovereign-Rollups stehen aufgrund ihrer Unabhängigkeit vor einer anderen Reihe von Risiken. Das bedeutendste Risiko ist das Fehlen einer L1-erzwungenen Sicherheit für Zustandsübergänge. Wenn die Validatoren des Rollups kolludieren oder kompromittiert werden, könnten sie potenziell einen ungültigen Zustand finalisieren, ohne auf einen L1-Smart-Contract zurückgreifen zu können. Obwohl sie eine L1 oder DA-Schicht für die Datenverfügbarkeit nutzen, garantiert dies nur, dass die Daten veröffentlicht werden, nicht dass sie vom eigenen Netzwerk des Rollups korrekt interpretiert oder validiert werden. Dies legt eine größere Last auf die Community des Rollups, Full Nodes zu betreiben und die Kette aktiv zu validieren. Darüber hinaus sind Upgrade-Fähigkeit und Governance in einem Sovereign-Rollup vollständig selbstverwaltet. Obwohl dies Flexibilität bietet, bedeutet es auch, dass umstrittene Upgrades oder Governance-Fehler zu Hard Forks oder einem Verlust des Konsenses innerhalb der Rollup-Community führen könnten, was potenziell ihr Ökosystem fragmentiert. Das wirtschaftliche Sicherheitsmodell eines Sovereign-Rollups, einschließlich seiner Validatoren-Anreize und Slashing-Mechanismen, muss robust sein, um bösartiges Verhalten zu verhindern.

Geschichte und Beispiele

Das Konzept der Rollups entstand als eine entscheidende Lösung für die Skalierbarkeitsprobleme, mit denen frühe Blockchains wie Ethereum konfrontiert waren. Mit der wachsenden Nachfrage nach dezentralen Anwendungen wurden die Einschränkungen des Layer-1-Durchsatzes offensichtlich, was zu hohen Transaktionsgebühren und langsamen Bestätigungszeiten führte. Optimistic Rollups und ZK-Rollups wurden entwickelt, um Transaktionen Off-Chain zu verarbeiten und dann komprimierte Daten an die L1 zu senden, wobei die Sicherheit der L1 für die Abwicklung genutzt wurde. Frühe Beispiele für Smart-Contract-Rollups sind Arbitrum und Optimism (beide Optimistic Rollups, die auf Ethereum abwickeln), sowie zkSync und StarkNet (ZK-Rollups, die ebenfalls auf Ethereum abwickeln). Diese Plattformen zeigten die Machbarkeit der Skalierung von Ethereum bei gleichzeitiger Aufrechterhaltung einer starken Sicherheitsbindung an das Mainnet. Polygon CDK ermöglicht auch den Bau von ZK-Rollups, die auf Ethereum abwickeln und es als DA-Schicht nutzen.

Sovereign-Rollups stellen eine neuere Entwicklung im modularen Blockchain-Paradigma dar, angetrieben durch den Wunsch nach größerer Anpassbarkeit und Unabhängigkeit für anwendungsspezifische Ketten. Während die theoretischen Grundlagen seit einiger Zeit diskutiert werden, hat ihre praktische Umsetzung mit dem Aufkommen dedizierter Datenverfügbarkeitsschichten wie Celestia an Bedeutung gewonnen. Celestia bietet beispielsweise eine hochskalierbare und sichere Schicht für die Datenverfügbarkeit, die es Sovereign-Rollups ermöglicht, ihre Transaktionsdaten zu veröffentlichen, ohne sich für die Abwicklung auf eine L1 zu verlassen. Dies ermöglicht Entwicklern den Bau hochspezialisierter Blockchains, die ihre eigenen Ausführungsumgebungen (z.B. verschiedene Virtual Machines), Konsensmechanismen und Governance-Modelle wählen können, ohne durch das Design der L1 eingeschränkt zu sein. Projekte, die Sovereign-Rollups erforschen oder implementieren, streben oft maximale Flexibilität und Kontrolle über ihren gesamten Stack an, um maßgeschneiderte Umgebungen zu schaffen, die genau auf die Bedürfnisse ihrer Anwendung zugeschnitten sind. Nomos ist ein weiteres Beispiel für eine Plattform, die den Bau von Sovereign-Rollups erleichtern soll.

Häufige Missverständnisse

Ein häufiges Missverständnis ist, dass alle Rollups auf die gleiche Weise inhärent "Layer 2s" sind, was identische Sicherheitsgarantien und Abwicklungsmechanismen impliziert. Obwohl sowohl Smart-Contract-Rollups als auch Sovereign-Rollups Skalierungslösungen sind, ist ihre Beziehung zur zugrunde liegenden Layer 1 (oder DA-Schicht) grundlegend unterschiedlich. Smart-Contract-Rollups werden oft als "eingebettete" Layer 2s betrachtet, da ihre Sicherheit und ihr kanonischer Zustand direkt durch einen Smart Contract auf der L1 erzwungen werden. Dies bedeutet, dass die L1 den Zustand des Rollups aktiv validiert oder anfechten kann. Im Gegensatz dazu ähneln Sovereign-Rollups eher unabhängigen Blockchains, die eine andere Kette lediglich für die Datenverfügbarkeit nutzen, sich aber nicht auf diese Kette für ihre eigene Zustandsvalidierung oder Sicherheitsdurchsetzung verlassen. Sie sind "souverän", weil ihre Zustandsübergänge von ihren eigenen Netzwerkteilnehmern validiert werden, nicht von einem L1-Smart-Contract.

Ein weiteres häufiges Missverständnis ist, dass Sovereign-Rollups weniger sicher sind als Smart-Contract-Rollups, weil sie nicht auf einer L1 abwickeln. Dies ist eine Vereinfachung. Obwohl Sovereign-Rollups keine L1-Sicherheit für die Zustandsvalidierung erben, ist ihr Sicherheitsmodell einfach anders, nicht unbedingt minderwertig. Ihre Sicherheit beruht auf der Robustheit ihres eigenen Konsensmechanismus, des Validatoren-Sets und der aktiven Beteiligung ihrer Community beim Betrieb von Full Nodes und der Überprüfung von Zustandsübergängen. Die Wahl zwischen beiden läuft oft auf einen Kompromiss zwischen L1-abgeleiteter Sicherheit und maximaler Flexibilität/Anpassbarkeit hinaus. Ein gut konzipiertes und ausreichend dezentralisiertes Sovereign-Rollup kann ein hohes Maß an Sicherheit erreichen, erfordert jedoch andere Vertrauensannahmen und Community-Engagement als ein Smart-Contract-Rollup. Der Aspekt der "Abwicklung" ist entscheidend: Smart-Contract-Rollups wickeln auf der L1 ab, während Sovereign-Rollups auf sich selbst abwickeln und die L1/DA-Schicht nur für die Datenverfügbarkeit nutzen.

Zusammenfassung

Sovereign-Rollups und Smart-Contract-Rollups repräsentieren zwei unterschiedliche, aber leistungsstarke Paradigmen innerhalb des modularen Blockchain-Ökosystems, die jeweils einzigartige Vorteile und Kompromisse bieten. Smart-Contract-Rollups nutzen die Sicherheit und Finalität einer Layer-1-Blockchain, indem sie ihre Zustandsübergänge über einen L1-Smart-Contract abwickeln und so die robusten Sicherheitsgarantien der L1 erben. Dies macht sie ideal für Anwendungen, die etablierte Sicherheit und eine nahtlose Integration mit der Vermögensbasis der L1 priorisieren. Umgekehrt agieren Sovereign-Rollups als unabhängige Blockchains, die eine andere Kette ausschließlich für die Datenverfügbarkeit nutzen, während sie die volle Kontrolle über ihre eigene Zustandsvalidierung, Governance und Ausführungsumgebung behalten. Diese architektonische Wahl bietet beispiellose Flexibilität und Anpassbarkeit und ermöglicht die Schaffung hochspezialisierter anwendungsspezifischer Ketten. Die Entscheidung zwischen diesen beiden Ansätzen hängt von den spezifischen Anforderungen eines Projekts ab, wobei das Bedürfnis nach L1-abgeleiteter Sicherheit mit dem Wunsch nach ultimativer Souveränität und Designfreiheit abgewogen wird.