Native Rollups vs. Based Rollups: Welche Ethereum-L2-Architektur passt 2026 zu deinem Produkt?

Based und Native Rollups lösen verschiedene Schichten desselben Ethereum-L2-Stacks. Ein Based Rollup übergibt die Transaktionsreihenfolge an Ethereum L1. Ein Native Rollup übergibt Ethereum die Verifikation von EVM-Zustandsübergängen. Das sind keine konkurrierenden Kategorien: Ein Rollup kann beides sein. Im August 2026 ist Based Sequencing live, Native Rollups bleiben Protokollforschung ohne festen Fork-Termin.

Das ist relevant, wenn du Rollup-Infrastruktur kaufst, eine Appchain planst oder prüfst, ob dein Produkt ein eigenes Layer 2 braucht. Die Architektur verändert Zensurrisiko, Bestätigungslatenz, MEV-Umsatz, Upgrade-Verantwortung und deinen Betriebsaufwand. Sie erzeugt aber nicht automatisch Nachfrage nach dem Produkt.

Was ist der Unterschied zwischen Native und Based Rollups?

Stelle zwei getrennte Fragen: Wer ordnet die Transaktionen? Und: Wer prüft, ob die Ausführung korrekt war? Based beschreibt Sequencing. Native beschreibt die Verifikation der Ausführung.

Die ursprüngliche Definition von Based Rollups auf Ethereum Research beschreibt, wie L1-Sequencing Ethereums Liveness und Dezentralisierung erbt. Auch Ethereums aktuelle Scaling-Roadmap nennt zentrale Sequencer als Zensurrisiko. Genau dieses Problem adressiert Based Sequencing.

Wie funktioniert ein Based Rollup?

Beim Based Rollup darf der nächste Ethereum-Proposer zusammen mit der bestehenden Builder-Pipeline den nächsten L2-Block permissionless in einen L1-Block aufnehmen. Das Rollup führt Transaktionen weiter off-chain aus und veröffentlicht Daten oder Commitments auf Ethereum. Geändert wird die Instanz, die Reihenfolge und Inklusion bestimmt.

Was gewinnst du?

• Liveness wie Ethereum. Ein einzelner Sequencer kann die Chain nicht durch sein Verschwinden stoppen.
• Mehr Zensurresistenz. Die Reihenfolge liegt nicht bei einem Rollup-Betreiber.
• Kleinere Sequencer-Trust-Surface. Ein separates Konsensnetz, Sequencer-Token und kritischer Escape-Hatch-Pfad können entfallen.
• Ökonomische L1-Ausrichtung. Ein Teil des MEV fließt an Ethereum statt an einen privaten L2-Sequencer.

Was gibst du auf oder baust du neu?

• Sofortige Bestätigungen sind nicht trivial. Nutzer wollen nicht auf einen L1-Slot warten. Deshalb ergänzen Produktionsdesigns Preconfirmers, die Inklusion vor dem finalen L1-Settlement versprechen.
• Sequencing-Policies werden unflexibler. First Come, First Served, private Orderflows und eigene Auktionen sind schwerer zu garantieren.
• MEV-Umsatz verändert sich. Ein Geschäftsmodell mit exklusivem Sequencing lässt sich nicht unverändert übernehmen.
• Operations verschwinden nicht. Block Building, Preconfirmation-Monitoring, Proving, Data Publishing, RPCs, Indexer und Incident Response bleiben.

Taiko ist der klarste Live-Referenzpunkt. Die offizielle Roadmap für 2025 bis 2026 beschreibt ein Type-1-Based-Rollup, whitelisted Preconfirmations auf Mainnet und den Weg zu dezentralen Bestätigungen unter einer Sekunde. Das belegt, dass Based Sequencing produktiv laufen kann. Es belegt nicht, dass jedes Preconfirmation-Design gleich reif ist.

Wie funktioniert ein Native Rollup?

Ein Native Rollup soll verhindern, dass jedes L2-Team einen eigenen kritischen EVM-Verifikationsstack wartet. Ethereum würde prüfen, ob ein L2-Block demselben Execution-Programm folgt, das Ethereum selbst anerkennt. Sequencing, Gebühren, Gas-Token, Governance und Messaging bleiben rund um diese gemeinsame Ausführungsregel konfigurierbar.

Der Vorschlag hat sich wesentlich verändert. Draft EIP-8079 beschreibt ein EXECUTE-Precompile und lässt zentrale Bereiche als TBD offen. Der neuere Vorschlag für Native Proof Verification geht in Richtung Proof-carrying Transactions und programmagnostischer Verifikation in Ethereums Consensus-Infrastruktur. Das ist eine wichtige Entwicklung, bleibt aber Forschung.

Was könnte Native Verification entfernen?

• Rollup-spezifische Verifier Contracts, Proof Router und einen Teil der Upgrade-Macht von Security Councils.
• Separate EVM-Circuit-Upgrades bei jeder Änderung von Ethereums Ausführungsregeln.
• Einen Teil des Bridge-Risikos, das entsteht, wenn ein eigener Verifier einen falschen State Transition akzeptiert.

Welche Grenzen bleiben?

• EVM-Äquivalenz zählt. Eigene Opcodes, Precompiles und Transaktionstypen erschweren oder blockieren die Migration zum ursprünglichen EIP-8079-Pfad.
• Sequencing bleibt deine Entscheidung. Native bedeutet nicht automatisch dezentral geordnete Transaktionen.
• Data Availability und Messaging bleiben kritisch. Eine korrekte State Root hilft nicht, wenn Nutzer den Zustand nicht rekonstruieren oder Assets nicht sicher bewegen können.
• Proof Economics sind offen. Propagation, Aggregation, Pricing, Backend-Diversität und Resource Limits brauchen noch Entscheidungen.

Der aktuelle Native-Rollup-Research-Tracker von L2BEAT ist eindeutig: Die Arbeit ist in keinem geplanten Ethereum-Hard-Fork enthalten, EIP-8079 bleibt ein Draft und Proof-carrying Transactions sind ein Forschungsvorschlag. Du kannst 2026 einen Migrationspfad erhalten. Du kannst Native Verification nicht ehrlich auf eine verbindliche Launch-Checkliste setzen.

Kann ein Rollup gleichzeitig based und native sein?

Ja. Denke in einer Matrix mit zwei Achsen, nicht in einem Entweder-oder.

So vermeidest du einen typischen Einkaufsfehler. Ein Anbieter, der „native“ sagt, hat noch nicht beantwortet, wer Transaktionen ordnet. Ein Anbieter, der „based“ sagt, hat noch nicht beantwortet, wer Verifier oder Bridge upgraden darf. Stelle beide Fragen.

Welche L2-Architektur soll dein Produkt wählen?

• Wähle Based Sequencing, wenn Zensurresistenz, permissionless Inklusion und glaubwürdige Neutralität zum Produktkern gehören und du den Preconfirmation-Pfad unter Fehlerbedingungen testen kannst.
• Wähle einen dedizierten Sequencer, wenn UX unter einer Sekunde, deterministische Reihenfolge, private Transaktionen oder Sequencing-Umsatz launchkritisch sind. Dokumentiere den Weg aus Zensur und Ausfall.
• Entwirf native-kompatibel, wenn du EVM-Äquivalenz, eine langlebige Chain und später weniger eigene Verifier-Governance willst. Kapsle eigene Execution-Erweiterungen hinter klaren Grenzen.
• Starte kein eigenes L2, wenn ein öffentliches L2 bereits Kosten, Durchsatz, Distribution und Compliance abdeckt. Eine Chain ist ein dauerhaftes Operations-Produkt neben deinem eigentlichen Produkt.

Wenn du noch zwischen öffentlichem EVM-L2 und einer anderen Chain entscheidest, beginne mit unserem Gas-Kosten- und Chain-Selection-Rückblick aus 21 Web3-Mandaten. Bei einem Non-EVM-Move zeigt der Teardown der Ethereum-zu-Solana-Migration, warum ein Chain-Wechsel zum partiellen Rewrite wird. Treibt Interoperabilität die Entscheidung, lies zuerst die Security-Entscheidung zu Cross-Chain-Bridges.

Was solltest du einen Rollup-as-a-Service-Anbieter fragen?

1. Sequencing: Wer kann eine Transaktion aufnehmen, umordnen oder zensieren, und was passiert bei einem Ausfall?
2. Verifikation: Wer kontrolliert heute Verifier-Upgrades, wie lang ist das Exit Window und was darf das Security Council ändern?
3. Preconfirmations: Was wird versprochen, welches Collateral sichert es und wie erholt sich der Client von einem gebrochenen Versprechen?
4. Data Availability: Liegen vollständige Transaktionsdaten in Ethereum-Blobs oder auf einem Alt-DA-Layer mit anderen Recovery-Annahmen?
5. Ökonomie: Wer erhält Base Fees und MEV, und welche L1-Kosten bleiben variabel?
6. Migration: Welche eigenen Opcodes, Precompiles, Deposit-Typen oder Bridge-Regeln blockieren später Native Verification?
7. Operations: Wer betreibt Prover, RPCs, Indexer, Relayer, Monitoring, Upgrades und 24/7 Incident Response?

Die Ethereum Foundation empfiehlt in ihrer L1- und L2-Richtung vom März 2026 für trust-minimizing L2s mindestens Stage 1 und einen „Walkaway“-Pfad. Native Rollups, Interoperabilität und Stage 2 sind Ziele für besonders enge L1-Integration. Das ist ein guter Nordstern, aber kein Ersatz für ein launchfähiges Threat Model.

Was ist die pragmatische Empfehlung für 2026?

Wenn du dieses Jahr auslieferst, starte mit einem reifen EVM-Rollup-Stack und entscheide Sequencing separat. Nutze Based Sequencing, wenn Neutralität und Liveness die zusätzliche Preconfirmation- und Integrationsarbeit rechtfertigen. Halte Execution möglichst EVM-äquivalent, damit Native Verification später eine Migration und kein Rewrite wird. Mache deinen Launch nicht von einem ungeplanten Hard Fork abhängig.

Wavects Blockchain-Engineering-Team wählt die Chain erst, wenn Workload, Asset Custody, Latenz, Compliance und Recovery-Anforderungen klar sind. So kaufst du keine permanente Infrastruktur, bevor das Produkt ihren Bedarf beweist.

FAQ: Ist ein Based Rollup automatisch ein ZK-Rollup?

Nein. Based beschreibt Sequencing. Ein Based Rollup kann Validity Proofs, Fraud Proofs oder ein anderes Verifikationsdesign verwenden. ZK versus optimistic und based versus dediziert sind getrennte Achsen.

FAQ: Sind Native Rollups auf Ethereum live?

Nein, nicht als die hier beschriebene protokollnative Architektur. Es gibt Forschungsprototypen, aber Native Proof Verification ist am 11. August 2026 in keinem geplanten Ethereum-Hard-Fork enthalten.

FAQ: Bedeutet „Based Rollup“ Coinbase Base?

Nein. „Based“ bedeutet L1-sequenced. Coinbase Base ist der Eigenname eines bestimmten L2. Die Wörter kollidieren, die Architekturkategorie ist aber unabhängig von diesem Netzwerk.

FAQ: Braucht ein Startup ein eigenes L2?

Meist nicht. Nutze ein bestehendes L2, bis dedizierter Blockspace, eigene Compliance, Chain-Level-Gebühren oder spezialisierte Execution messbaren Produktwert erzeugen. Sonst finanzierst du Sequencer, Prover, Bridges und Operations, bevor sie ein Moat sind.