Das „stufenlose Schalten“ im Ethereum Fusaka-Upgrade: Aufbau eines schnellen Reaktionsmechanismus für L2-Scaling

Die zukünftige Ethereum-Blockchain gleicht einem „stufenlosen Getriebe“ – die Erweiterung der Blob-Kapazität muss künftig nicht mehr an große Versions-Updates gekoppelt werden.

Autor: Zhixiong Pan

Hintergrund: Gas Limit Upgrade ohne Hard Fork

Vor dem Fusaka-Upgrade waren fast alle Kernparameter der Ethereum-Protokollschicht (wie Blockbelohnung, Schwierigkeitsanpassungsalgorithmus usw.) „hart codiert“ in der Client-Software. Das bedeutete, dass selbst für die Änderung eines einzelnen Werts ein langwieriger EIP-Vorschlag, Testnet-Übungen und die Koordination aller Netzwerkknoten für einen groß angelegten Hard Fork erforderlich waren – ein Prozess, der in der Regel ein halbes Jahr oder länger dauerte.

Vorher gab es im Ethereum-Protokoll nur eine Ausnahme: das Block Gas Limit (Block-Gas-Obergrenze). Das Gas Limit wird nicht durch einen Hard Fork festgelegt, sondern Validatoren können beim Erstellen von Blöcken kleine Anpassungen per Algorithmus vornehmen (zum Beispiel wurde es dieses Jahr von 30M auf 60M erhöht). Dieser Mechanismus verleiht dem Netzwerk eine gewisse Flexibilität.

Mit EIP-7892, BPO (Blob Parameter Only), soll diese Flexibilität nun auch auf den Datenbereich ausgeweitet werden. Die wichtigsten Parameter von Blobs werden konfigurierbar gemacht und durch den leichten BPO-Hard Fork („nur Parameter ändern, kein Code“) aktiviert. Aus Sicht der Client-Entwicklung gleicht dies fast einem Hotfix für Parameter.

Dadurch kann Ethereum beim Thema Skalierung das Muster „jedes Mal auf den nächsten großen Hard Fork warten, um die Blob-Anzahl zu ändern“ ablegen und stattdessen häufiger mit kleinen BPO-Forks die Parameter anpassen.

Warum ist die Anzahl der Blobs so wichtig?

Im Mittelpunkt dieser Anpassung steht das Blob. Seit dem Cancun-Upgrade (Dencun) schreiben die meisten Rollups ihre Transaktionsdaten nicht mehr in das teure calldata, sondern migrieren sie in das speziell dafür vorgesehene „temporäre Daten-Mounting-Areal“ namens Blob.

Die ökonomische Logik von Blobs ist sehr einfach: Blobs sind eine knappe Ressource, und die Anzahl der Blobs pro Block ist begrenzt. Ihr Preis ergibt sich aus Angebot und Nachfrage – wenn die Nachfrage von Layer 2 das Angebot übersteigt, steigt der Preis pro Blob, was wiederum die L2-Gebühren erhöht.

Daher ist es, unter Wahrung der Sicherheit, der direkteste Weg zur Senkung der L2-Nutzerkosten, das Maximum an Blobs so weit wie möglich zu erhöhen.

Kernparameter: Das Target- und Max-System

Im BPO-Anpassungsplan tauchen immer zwei Zahlenpaare auf (zum Beispiel 10/15). Diese basieren auf dem EIP-4844-Mechanismus und stellen zwei wichtige Schwellenwerte dar:

Target (Zielwert): Der „Regler“ für die Gebühren

Dies ist die von Ethereum festgelegte ideale Auslastung. Das System passt die Basisgebühr (Base Fee) für Blobs dynamisch anhand dieses Werts an. Liegt die tatsächliche Nutzung > Target, steigen die Gebühren, um die Nachfrage zu dämpfen; liegt die Nutzung < Target, sinken die Gebühren.

Der Target-Wert bestimmt die Durchsatzkapazität und das Gebührenniveau im Normalbetrieb des Netzwerks.

Max (Maximalwert): Die „Sicherung“ für die Netzwerksicherheit

Dies ist die physische Obergrenze, um einen Netzwerkausfall zu verhindern. Unabhängig von der Nachfrage schreibt das Protokoll vor, dass die Anzahl der Blobs pro Block diesen Wert nicht überschreiten darf, um zu verhindern, dass Knoten durch zu große Datenmengen abstürzen oder offline gehen.

Max ist die absolute Obergrenze der Netzwerkkapazität.

Seit Pectra folgt der Blob-Parameter auf dem Mainnet im Wesentlichen dem Muster „Max = 1,5 × Target“: 6/9, 10/15, 14/21 – immer dieses Verhältnis.

Upgrade-Roadmap: Warum setzt Fusaka auf einen „Schritt-für-Schritt“-Ansatz?

Die Skalierung erfolgt diesmal nicht auf einen Schlag am 3. Dezember (UTC+8), sondern in drei sorgfältig geplanten Phasen: „Zuerst die Technik, dann die Kapazität“.

Phase 1: Fusaka-Upgrade (3. Dezember (UTC+8))

Parameterstatus: Target: 6 / Max: 9 (identisch mit der vorherigen Pectra-Version, keine Änderung).

Mit dem Fusaka-Upgrade wird PeerDAS (Data Availability Sampling) als Schlüsseltechnologie aktiviert. Obwohl technisch die Verarbeitung größerer Datenmengen möglich ist, erhöhen die Entwickler am ersten Tag aus Sicherheitsgründen die Netzwerklast nicht. Dies ist eine „Sicherheitsbeobachtungsphase“, um die Stabilität des PeerDAS-Mechanismus unter aktueller Auslastung zu überprüfen.

Phase 2: BPO 1 (voraussichtlich 9. Dezember (UTC+8))

Parameteranpassung: Target: 10 / Max: 15

Nach etwa einer Woche stabilen Betriebs von PeerDAS erfolgt das erste Hotfix-Update per BPO-Mechanismus. Der Zielwert steigt von 6 auf 10. Dies ist die erste substanzielle Skalierung während der Fusaka-Periode.

Phase 3: BPO 2 (voraussichtlich 7. Januar 2026 (UTC+8))

Parameteranpassung: Target: 14 / Max: 21

Nach einem Monat intensiver Stresstests folgt das zweite Hotfix-Update. Im Vergleich zum Fusaka-Start hat sich die Kapazität um das 2,3-fache erhöht (6 → 14). Dies markiert die vollständige Umsetzung des aktuellen Skalierungsplans.

Fazit

Die Einführung von BPO ist ein Meilenstein. Sie durchbricht das alte Paradigma, dass jede Blob-Erweiterung einen großen Funktions-Hard Fork erfordert, und zerlegt die Skalierung in eine Reihe von Mini-Hard Forks, die nur Parameter ändern.

Das bedeutet, dass Ethereum künftig wie mit einem „stufenlosen Getriebe“ ausgestattet ist: Die Erweiterung der Blob-Kapazität muss nicht mehr an große Versions-Updates gekoppelt werden. Stattdessen können je nach L2-Bedarf und Client-Performance regelmäßig BPO3, BPO4 usw. geplant und mit häufigeren, kleinen Hard Forks der Durchsatz optimiert werden – statt nur alle paar Jahre eine Änderung vorzunehmen.