Zum Inhalt springen
Financial Context Wiki

Blob-Gebühren und Rollup-Kosten

Ein prüfungsorientierter Leitfaden zu Ethereum-Blob-Gas, aktuellen Blob-Zeitplänen, Batch-Auslastung, rollupspezifischer Gebührenzuordnung und dem Unterschied zwischen L1-Veröffentlichungskosten und der Rechnung eines L2-Nutzers.

Aktualisiert

Nur zu Bildungszwecken; keine Finanz- oder Sicherheitsberatung. Blob-Parameter, Rollup-Gebührenformeln, Sequencer-Richtlinien, Wechselkurse und Annahmen zur Datenverfügbarkeit können sich ändern oder versagen.

Direkte Antwort

Eine Ethereum-Blob-Gebühr ist die Protokollgebühr für die Veröffentlichung von Blob-Daten, nicht die gesamte Gebühr eines L2-Nutzers. Eine Blob-Transaktion zahlt blob_count * 131,072 * blob_base_fee_per_blob_gas für Blob-Gas und separat reguläres Ausführungs-Gas. Anschließend kann ein Rollup diese L1-Kosten nach eigenen Regeln für Kompression, Skalare, Gemeinkosten und Betreiberpreise zuordnen. Deshalb sind der Beleg des Batch-Einreichers, die Kostenschätzung des Rollups, das Nutzerangebot und der Betreiberumsatz unterschiedliche Datensätze.

Blobs sind temporäre Daten-Sidecars, die durch versionierte KZG-Hashes gebunden werden. Die EVM kann die Commitments verwenden, aber die Blob-Bytes nicht direkt lesen. PeerDAS verändert die Verteilung und Stichprobenprüfung dieser Daten durch Ethereum-Nodes; es macht Blobs weder zu dauerhaften Archiven noch die Nutzergebührenformel eines Rollups allgemeingültig. Auch die Kapazität hängt vom Fork ab. Am 2026-08-13 zielt das Ethereum-Mainnet nach Fusaka BPO2 auf 14 blobs und erlaubt höchstens 21 blobs pro Block; damit wurden die früheren Zeitpläne 3/6 und 6/9 ersetzt.

Funktionsweise

  1. Fixiere den Messkontext: Ethereum-Netzwerk, Block oder Slot, aktiven Fork und Blob-Parameter-Only-Zeitplan, Rollup-Deployment und Version der Gebührenformel, L1-Origin, Gebühren-Token des Nutzers und Wechselkurszeitpunkt. Übertrage aktuelle Mainnet-Parameter nie auf alte Blöcke, Testnets oder künftige Forks.
  2. Identifiziere das Veröffentlichungsobjekt anhand von Chain-Daten. Erfasse Typ-3-Transaktion, Absender, Receipt, versionierte Hashes, Blob-Anzahl, blob_gas_used, codierte und nutzbare Payload-Bytes, Kompression oder Framing sowie die verwendete DA-Route: Blobs, Calldata oder eine andere Lösung.
  3. Lies beide Gebührenmärkte aus. Blob-Gas verwendet 131,072 blob gas per blob; unterscheide das realisierte blob_base_fee_per_blob_gas vom Cap max_fee_per_blob_gas des Absenders. Erfasse separat verwendetes Ausführungs-Gas, effektiven Gaspreis und Prioritätsgebühr. Nach EIP-7918 besteht bei niedrigen Blob-Preisen eine Mindestpreisbeziehung zu den Ausführungskosten, die Konten bleiben dennoch getrennt.
  4. Rekonstruiere das tatsächliche L1-Konto des Batch-Einreichers: verbrannte Blob-Gebühr, Ausführungsgebühr und Tip sowie zugehörige State-Output-, Proof-, Bridge- oder Posting-Transaktionen. Die Blob-Gebühr fällt auch bei fehlgeschlagener Ausführung an; ein nicht ausgeschöpftes Cap ist weder Kosten noch Erstattung.
  5. Reproduziere die aktuelle Formel des konkreten Rollups. Erfasse komprimierte Bytes oder eine andere Messgröße, Skalare, fixe Gemeinkosten, Betreiber- oder Prioritätsgebühren, Erstattungen und Fallback-Regeln. OP-Stack-Dokumentation belegt nur ein entsprechendes OP-Deployment; andere Rollups können Kosten anders zuordnen.
  6. Trenne vier Konten: L1-Kosten des Batchers, vom Rollup zugeordnete L1-Datenkosten, tatsächliche Nutzerbelastung und Betreiberumsatz oder -marge. Eine Gleichverteilung nach Transaktionszahl ist nur eine analytische Zuordnung. Batch-Füllstand, Padding, Transaktionsmix, verzögerte Veröffentlichung und Quersubventionen können vom Protokollangebot abweichen.
  7. Gleiche mit Receipts ab und führe Stresstests durch. Prüfe Blob-Preisspitzen, Ausführungsengpässe, ETH- und Gebühren-Token-FX, geringe Batch-Auslastung, Sequencer-Verzögerung, Calldata-Fallback, Formel-Upgrades, L1-Reorganisation, temporäre Datenhaltung und Archivfehler. Nenne bei jedem Nutzerwert Block, Einheiten, Annahmen und ungeklärte Kosten.

Rechenbeispiele

  • Blob-Gebühr des Protokolls. Zwei Blobs verbrauchen 2 * 131,072 = 262,144 blob gas. Bei 30 gwei per blob gas beträgt die Gebühr 262,144 * 30 * 10^-9 = 0.00786432 ETH. Bei $2,500 per ETH entspricht dies $19.6608. Die reguläre Ausführungsgebühr der Transaktion ist nicht enthalten.
  • Zwei Gebührenkonten einer Transaktion. Verwendet dieselbe Typ-3-Transaktion 120,000 execution gas zu effektiven 22 gwei, kostet die Ausführung 120,000 * 22 * 10^-9 = 0.00264 ETH. Die gesamte L1-Belastung beträgt 0.00786432 + 0.00264 = 0.01050432 ETH beziehungsweise $26.2608 zum angegebenen Kurs. Blob- und Ausführungs-Gas bleiben getrennte Eingaben.
  • Batch-Auslastung und Zuordnung. Hinzu kommen $4.0000 abgeglichene Proof- und Posting-Kosten, sodass die analytischen Batch-Kosten $30.2608 betragen. Bei 2,000 included transactions ergibt die Gleichverteilung $30.2608 / 2,000 = $0.0151304 per transaction; bei nur 800 sind es $30.2608 / 800 = $0.0378260. Keine Zahl ist automatisch das Nutzerangebot oder die realisierte Betreibermarge.
  • Aktuelle Kapazität und Byte-Einheiten. Im datumsbezogenen Zeitplan 14/21 betragen Ziel und Maximum 14 * 131,072 = 1,835,008 und 21 * 131,072 = 2,752,512 blob-gas units; dies entspricht 1.75 MiB und 2.625 MiB codierten Blobs. Da beliebige Payload typischerweise 31 von 32 Bytes je Feldelement nutzt, beträgt die nutzbare Payload vor Kompression und Framing 14 * 126,976 = 1.6953125 MiB am Ziel und 21 * 126,976 = 2.54296875 MiB am Maximum.

Risiken

  • Verwendung eines veralteten Forks oder Blob-Parameter-Only-Zeitplans.
  • Vermischung von Mainnet-, Testnet- oder Fremdnetzparametern.
  • Verwechslung von Blob-Gas, Ausführungs-Gas, codierten und nutzbaren Bytes.
  • Behandlung von max_fee_per_blob_gas als realisierte Basisgebühr.
  • Auslassung regulärer Ausführungsgebühr und Tip der Typ-3-Transaktion.
  • Annahme, fehlgeschlagene Ausführung erstatte die Blob-Gebühr.
  • Verwendung einer veralteten RPC-Schätzung statt Inclusion-Block und Receipt.
  • Gebührenänderung während verzögerter Batch-Veröffentlichung.
  • Unterschätzung von Blob-Preisspitzen oder Mindestpreisverhalten.
  • Ignorieren von L1-Ausführungsengpässen bei billigem Blob-Gas.
  • Zuordnung unterfüllter oder gepaddeter Batches wie voller Batches.
  • Falsche Annahmen zu Kompression, Framing oder Transaktionsmix.
  • Doppelte Erfassung von Proof-, State-Output-, Bridge- oder Posting-Transaktionen.
  • Anwendung veralteter Skalar-, Gemeinkosten- oder Betreiberformeln.
  • Verwechslung von Angebot, tatsächlicher Belastung, Erstattung und Betreiberumsatz.
  • Teurer Calldata-Fallback oder Wechsel zu einem anderen DA-Sicherheitsmodell.
  • Umrechnung von ETH und Gebühren-Token mit falschem Kurs oder Zeitpunkt.
  • Verlust oder Fehlzuordnung eines Batches nach Ersetzung oder L1-Reorganisation.
  • Gleichsetzung temporärer PeerDAS-Verfügbarkeit mit dauerhafter Archivabfrage.
  • Ignorieren von Sequencer-, Validitäts-, Finalitäts-, Bridge- oder Exit-Fehlern trotz verfügbarer Blobs.

Häufige Irrtümer

  • Die Blob-Basisgebühr ist die gesamte L2-Gebühr eines Nutzers.
  • max_fee_per_blob_gas ist der tatsächlich belastete Betrag.
  • Alle 131,072 codierten Bytes eines Blobs sind beliebige Nutzer-Payload.
  • Eine niedrigere Blob-Basisgebühr senkt sofort jede L2-Nutzergebühr um denselben Prozentsatz.
  • Blob-Daten werden dauerhaft in der EVM gespeichert und jedes Rollup nutzt eine feste Kapazität von 3/6 oder 6/9.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...