Zum Inhalt springen
Financial Context Wiki

Rollups

Wie Rollups Transaktionen ausführen, Daten und Commitments veröffentlichen, Zustandsübergänge prüfen, auf einer Basisschicht abwickeln und eigene Betriebsrisiken schaffen.

Aktualisiert

Nur zu Bildungszwecken; keine Finanz-, Anlage-, Bridge- oder Sicherheitsberatung. Die Garantien eines Rollups hängen von den bereitgestellten Verträgen, dem Beweissystem, der Datenverfügbarkeit, Betreiberrechten, Governance und Basisschicht ab; all dies kann sich ändern.

Direkte Antwort

Ein Rollup ist ein Blockchain-Skalierungsdesign, das Transaktionen außerhalb einer Basisschicht ausführt, diese aber zur Veröffentlichung protokolldefinierter Daten oder Commitments und zur Abwicklung bestrittener oder bewiesener Zustandsübergänge nutzt. Viele Transaktionen teilen die Kosten für Daten und Abwicklung. Ein Rollup ist daher mehr als Transaktionskompression; eine State Root allein liefert nicht die Daten zur Rekonstruktion der Chain.

Optimistic Rollups akzeptieren Zustandsbehauptungen üblicherweise, sofern eine erfolgreiche Fault-Proof-Anfechtung den Übergang nicht als ungültig erweist. ZK-Rollups reichen Validity Proofs ein, die der Abwicklungsvertrag prüft. Diese Begriffe beschreiben die Annahme von Zustandsübergängen, nicht allgemeine Garantien für Sequencer-Dezentralisierung, Speicherung, Upgrade-Kontrolle, Gebühren oder Auszahlungsdauer.

Funktionsweise

  • Ordnen und ausführen. Ein Sequencer oder anderer Mechanismus wählt und ordnet Transaktionen und berechnet den Rollup-Zustand. Nutzer können vor der Basisschicht-Bestätigung eine schnelle Quittung erhalten.
  • Daten veröffentlichen. Das System veröffentlicht ausreichende Eingabedaten, meist als Calldata oder Blobs, auf der Basisschicht oder nutzt ein separates Datenverfügbarkeitsdesign. Davon hängt die unabhängige Rekonstruktion und Prüfung ab.
  • Zustand festschreiben. Das Rollup veröffentlicht State Roots oder andere Commitments, die es an ein Ausführungsergebnis binden. Ein Commitment ist kompakt, aber nicht die zugrunde liegende Transaktionshistorie.
  • Übergänge prüfen. Optimistic Designs benötigen ein Anfechtungsfenster und ein bereitgestelltes Fault-Proof-Verfahren; ZK-Designs einen Validity Proof und Onchain-Verifier. Fehler, Rechte und Verfügbarkeit des Beweissystems bleiben relevant.
  • Abwickeln und auszahlen. Basisschicht-Verträge bestimmen Annahme und Finalisierung von Nachrichten und Assets. Kanonische Auszahlungen können durch Beweis, Anfechtung oder Finalität verzögert sein; eine schnelle Bridge bringt Liquiditätsanbieter- und Gegenparteirisiko hinzu.
  • Aktualisieren und wiederherstellen. Governance, Sicherheitsräte, Guardians oder Administratoren können Verträge pausieren oder aktualisieren. Timelock, Fluchtweg und erzwungene Einbeziehung sind für die konkrete Bereitstellung zu prüfen.

Beispiel

Ein Batch enthalte 1,000 Transaktionen. Nutzer zahlen zusammen 0.8 ETH, Basisschichtdaten kosten 0.5 ETH und die Rollup-Ausführung 0.2 ETH. Der unerklärte Rest beträgt 0.8 - 0.5 - 0.2 = 0.1 ETH oder 0.1 / 1,000 = 0.0001 ETH je Transaktion, noch vor Beweiserzeugung, Infrastruktur, fehlgeschlagenen Batches, Kapitalkosten und Erstattungen. Dies ist eine Kostenabstimmung, kein Betreibergewinn.

Vor einer Finalitätsannahme ist zu prüfen, ob die Quittung nur Sequencer-bestätigt ist, Daten und Commitment die Basisschicht erreichten, das Fault-Proof-Fenster endete oder der Validity Proof angenommen wurde und die Auszahlungsnachricht separat ausführbar wurde.

Risiken

  • Ein zentraler Sequencer kann Transaktionen zensieren, umordnen oder vorübergehend stoppen.
  • Fehlende oder nicht verfügbare Batchdaten können Rekonstruktion und Ausstiege verhindern.
  • Fault-Proof-Programme, Validity Circuits, Verifier oder Clients können Fehler enthalten.
  • Challenger oder Beweiserzeuger können offline, zensiert, unterfinanziert oder falsch berechtigt sein.
  • Überlastung, Reorganisation oder Ausfall der Basisschicht kann Veröffentlichung, Beweis und Abwicklung verzögern.
  • Upgrade-Schlüssel, Guardians oder Governance können Code, Parameter oder Bridge-Verhalten ändern.
  • Kanonische Bridges und Token-Zuordnungen können trotz korrekter Rollup-Ausführung scheitern.
  • Gebühren, Beweiszeiten und Auszahlungsverzögerungen unterscheiden sich und können sich nach Upgrades ändern.

Häufige Missverständnisse

  • Alle Rollups speichern alles dauerhaft auf der Basisschicht. Veröffentlichungsformat und Archivgarantien variieren; Blobs sind etwa kein permanenter Speicher.
  • Eine Sequencer-Quittung ist endgültige Abwicklung. Sie kann nur ein frühes Ordnungsversprechen sein.
  • ZK bedeutet privat. Validity Proofs beweisen korrekte Berechnung; Transaktionsprivatsphäre ist eine separate Designentscheidung.
  • Optimistic bedeutet ohne Prüfung. Korrektheit erfordert reproduzierbare Daten, ein funktionierendes Fault-Proof-System und anfechtungsfähige Teilnehmer.
  • Niedrigere Durchschnittsgebühren beseitigen Betriebsrisiken. Geteilte Abwicklung kann Kosten senken, doch Abhängigkeiten von Sequencer, Beweisen, Governance, Bridge und Datenverfügbarkeit bleiben.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...