⚡ electrical engineering

BigDipper: Sharded Censorship Resistant Data Availability for Leader-Based BFT

BigDipper ist ein geschichtetes Data-Availability-Framework für Leader-basierte BFT-Protokolle, das die Zensurresistenz durch die Einführung eines DA-CR-Mechanismus von der Konsensebene entkoppelt, wodurch Validatoren die Verfügbarkeit von Mini-Blöcken ohne vollständige Rekonstruktion verifizieren können, während es Anwendungen auf höherer Ebene ermöglicht, ihre eigenen Schutzstrategien zu individualisieren.

Ursprüngliche Autoren: Bowen Xue, Samuel Laferriere, Soubhik Deb, Sreeram Kannan

Veröffentlicht 2026-06-03

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Bowen Xue, Samuel Laferriere, Soubhik Deb, Sreeram Kannan

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das Problem: Der „Chef“, der Ihren Brief verstecken kann

Stellen Sie sich ein Blockchain-Netzwerk wie einen riesigen, Hochgeschwindigkeits-Postdienst vor. In vielen dieser Systeme gibt es einen Leader (wie einen Postmeister), der dafür verantwortlich ist, die Post zu sortieren und sie auf die Lieferwagen (Blöcke) zu laden, die in die Welt hinausfahren.

Dieses System ist schnell und effizient. Es hat jedoch einen Makel: Der Postmeister hat die totale Kontrolle darüber, was genau jetzt auf den Wagen kommt. Wenn der Postmeister bösartig ist, kann er die Wagen zwar planmäßig fahren lassen, aber heimlich Ihren speziellen Brief auf dem Wagen zurückhalten. Er muss nicht das gesamte System stoppen; er muss nur Ihren spezifischen Brief für ein paar Minuten verzögern.

In der realen Welt ist das ein Desaster für Dinge wie:

Auktionsgebote: Wenn Ihr Gebot um einen Wagen verzögert wird, verlieren Sie die Auktion.
Liquidationen: Wenn eine Bank einen schlechten Kredit nicht schnell genug liquidieren kann, verliert sie Geld.
Bridge-Nachrichten: Wenn Sie Krypto zwischen Chains bewegen, kann eine Verzögerung bedeuten, dass Gelder verloren gehen.

Bestehende Lösungen versuchen dies zu beheben, indem sie den Postmeister zwingen, strikte Regeln für alle einzuhalten. Aber das ist so, als müsste jeder für einen VIP-gepanzerten LKW bezahlen, nur weil eine einzige Person einen zeitkritischen Brief verschickt. Das ist teuer und verlangsamt alles.

Die Lösung: BigDipper

BigDipper ist ein neues System, das darauf ausgelegt ist, dieses Problem zu lösen, ohne das gesamte Netzwerk zu verlangsamen. Es folgt einer einfachen Regel: „Programmiere nicht die Regeln fest; gib die Werkzeuge vor und lass den Nutzer entscheiden.“

Stellen Sie sich BigDipper als einen intelligenten Sortierraum vor, der zwischen den Leuten, die Briefe versenden, und dem Postmeister sitzt.

1. Die „Mini-Blöcke“ (Die Shards)

Anstatt dass der Postmeister die gesamte Post selbst einsammelt, erlaubt BigDipper den Replicas (den lokalen Postämtern), die Post zuerst zu sammeln.

Jedes lokale Postamt sammelt die Briefe, die es erhält, und legt sie in einen kleinen, versiegelten Umschlag namens Mini-Block.
Diese Umschläge werden dann an den Postmeister gesendet.

2. Das „Magische Puzzle“ (Erasure Coding)

Hier kommt der clevere Teil. Der Postmeister nimmt all diese Mini-Blöcke und zerlegt sie mithilfe eines speziellen mathematischen Tricks namens Erasure Coding in Puzzleteile.

Stellen Sie sich vor, Sie nehmen 100 Briefe, schreddern sie und erstellen daraus 300 Puzzleteile.
Sie können die ursprünglichen 100 Briefe aus beliebigen 100 dieser 300 Teile rekonstruieren.
Der Postmeister sendet diese Puzzleteile an die Validator (die Prüfer, die kontrollieren, ob das System ehrlich arbeitet).

Warum ist das cool?
Die Prüfer müssen nicht die gesamte Ladung Post sehen, um zu wissen, dass sie da ist. Sie müssen nur ein paar Puzzleteile und einen „magischen Beleg“ (eine kryptografische Verpflichtung/Commitment) prüfen, um zu beweisen, dass der gesamte Wagen gültig ist. Dies hält das System schnell und skalierbar.

3. Die „Zensurresistente“ Regel (DA-CR)

Dies ist die Kerninnovation. BigDipper führt eine Regel namens DA-CR (Data Availability mit Censorship Resistance / Datenverfügbarkeit mit Zensurresistenz) ein.

Die Regel: Der Postmeister muss Puzzleteile von mindestens einer bestimmten Anzahl lokaler Postämter enthalten. Er kann nicht einfach auswählen, wer auf den Wagen darf und wer nicht.
Der Haken: Der Postmeister kann immer noch versuchen, einen spezifischen Brief zu verstecken, aber er kann dies nur tun, wenn es ihm gelingt, das gesamte lokale Postamt auszuschließen, das diesen Brief erhalten hat.

4. Die „Fanout“-Strategie (Navigator)

Hier kommt der Nutzer (der Client) ins Spiel. BigDipper gibt Ihnen eine Wahlmöglichkeit: Wie viel Schutz wollen Sie?

Die kostengünstige Option: Sie senden Ihren Brief an nur ein einziges lokales Postamt. Es ist günstig und schnell, aber wenn genau dieses Postamt vom Postmeister ignoriert wird, wird Ihr Brief zensiert.
Die hochsichere Option: Sie senden Ihren Brief an viele lokale Postämter (hoher „Fanout“). Selbst wenn der Postmeister 50 % der Ämter ignoriert, befindet sich Ihr Brief immer noch in den Händen der anderen. Es kostet etwas mehr, ihn an mehr Orte zu senden, aber Ihre Chance auf Zensur sinkt gegen Null.

Die Analogie:
Wenn Sie eine gewöhnliche Geburtstagskarte verschicken, werfen Sie sie vielleicht einfach in einen Briefkasten. Wenn Sie jedoch einen Gewinnlos der Lotterie verschicken, senden Sie vielleicht Kopien an 10 verschiedene Briefkästen. BigDipper lässt Sie entscheiden, wie viele Briefkästen Sie nutzen möchten, basierend darauf, wie viel Ihnen der Brief wert ist.

Das Ergebnis: Ein modulares System

BigDipper trennt das Consensus (die Einigung über die Reihenfolge von Ereignissen) von der Execution (der eigentlichen Verarbeitung der Daten).

Die Validator (Prüfer) prüfen nur die „magischen Belege“ und ein paar Puzzleteile. Sie müssen nicht den gesamten LKW herunterladen. Das macht das System unglaublich schnell.
Die Execution-Ebene (die Leute, die tatsächlich die Apps betreiben) kann entscheiden, wie sie die vollständigen Daten später abrufen. Sie können leistungsstarke Computer, spezialisierte Teams oder andere Methoden nutzen, um das Gesamtbild zu erhalten.

Zusammenfassung der Ansprüche

Das Paper behauptet, dass durch diesen „gesharten“ (aufgeteilten) Ansatz mit Erasure Coding und linearen Commitments:

Zensur ist abstimmbar: Nutzer können ihren eigenen Schutzgrad wählen. Wenn Sie unzensierbar sein müssen, zahlen Sie den Preis, die Daten an mehr Knoten zu senden. Wenn nicht, sparen Sie Geld.
Skalierbarkeit: Das System wird nicht langsamer, wenn es wächst, da die Validatoren nicht den gesamten Block herunterladen müssen; sie prüfen nur ihre spezifischen „Shards“ (Puzzleteile).
Sicherheit: Selbst bei einem bösartigen Postmeister garantiert das System, dass – sofern genügend ehrliche Knoten Ihre Daten besitzen – das System nicht getäuscht werden kann, dass die Daten fehlen oder verändert wurden.
Integration: Es wurde erfolgreich in HotStuff-2 (ein populäres Blockchain-Protokoll) integriert, ohne dessen Sicherheitsregeln zu verletzen, was beweist, dass es in einem realen Umfeld funktioniert.

Kurz gesagt: BigDipper verhindert, dass der „Postmeister“ ein Single Point of Failure ist, indem es die Post auf viele Hände verteilt, Mathematik nutzt, um zu beweisen, dass die Post da ist, und dem Absender überlässt, wie vielen Händen er vertrauen möchte.

Technisches Resümee: BigDipper

Problemstellung

Leader-basierte Byzantine Fault Tolerant (BFT) Protokolle dominieren in produktiven Blockchain-Systemen aufgrund ihrer geringen Latenz und einfachen Kommunikationsstrukturen. Sie räumen dem Leader jedoch eine kurzfristige Kontrolle über die Inklusion von Transaktionen ein. Ein bösartiger Leader kann das Protokoll am Laufen halten (Liveness sicherstellen), während er zeitkritische Transaktionen – wie etwa Auktionsgebote, Oracle-Updates, Liquidationen und Bridge-Nachrichten – selektiv verzögert oder ausschließt. Dieses Phänomen, bezeichnet als kurzfristige Zensur (short-term censorship), wird durch standardmäßige BFT-Liveness-Garantien nicht erfasst.

Bestehende Lösungen implementieren oft starke Anti-Zensur-, Versteckungs- oder Ordering-Mechanismen fest im Konsenspfad. Während diese Ansätze für spezifische Anwendungsfälle effektiv sind, zwingen sie alle Transaktionen dazu, denselben hohen Preis für den Schutz zu zahlen, unabhängig davon, ob eine spezifische Transaktion eine solche Robustheit benötigt. Dieses Paper argumentiert für ein modulareres Design, das dem End-to-End-Prinzip folgt: Die Konsensebene sollte minimale Primitiven für sicheres Ordering und Datenverfügbarkeit bereitstellen und die Wahl der Strategien zur Zensurresistenz und der damit verbundenen Kosten der Anwendung auf der höheren Ebene überlassen.

Methodik

BigDipper führt eine Censorship-Resistant Data Availability (DA-CR) Schicht ein, die zwischen der Transaktionsübermittlung und dem Leader-basierten BFT-Konsens positioniert ist. Das System basiert auf drei Kernkomponenten:

DA-CR Abstraktion: Eine Schicht, in der Replikate Mini-Blöcke beisteuern, sowie ein Mechanismus, der zertifiziert, welche Daten verfügbar sind und vom Leader erfasst werden müssen. Diese Schicht ist durch Parameter $(t, \eta)$ charakterisiert, wobei $t$ die garantierte Inklusion ehrlicher Mini-Blöcke darstellt und $\eta$ die verbleibende Fähigkeit des Leaders beschreibt, Platz zu beanspruchen (Daten auszuschließen).
Sharded Consensus Critical Path: Im Gegensatz zu traditionellen Designs, bei denen Validatoren die gesamte Block-Payload herunterladen und ausführen müssen, hält BigDipper die Daten auf dem kritischen Pfad shard-basiert (fragmentiert). Validatoren stimmen basierend auf kompakten Commitments, Verfügbarkeitsnachweisen und DA-CR-Inklusionsregeln ab, anstatt die vollständige Payload zu rekonstruieren.
Client-Tunable Submission (Navigator): Ein Protokoll zur Transaktionsverbreitung, bei dem Clients einen „Fanout“-Parameter $x$ wählen, indem sie Transaktionen an $x$ verschiedene Replikate senden. Dies ermöglicht es Clients, die Kommunikation zu Kosten gegen die Wahrscheinlichkeit einer prompten Inklusion abzuwägen.

Kernkonstruktionen

Das Paper präsentiert konkrete DA-CR-Konstruktionen basierend auf Reed-Solomon (RS) Erasure Coding und linearen Polynomial-Commitments (KZG):

Card-7: Ein rechenschaftspflichtiges (accountable) Protokoll, bei dem der Leader Attestierungen für inkludierte Mini-Blöcke bereitstellen muss. Es garantiert, dass $t = n - 2f$ ehrliche Mini-Blöcke inkludiert werden und $\eta = 0$ gilt (kein Platzbeanspruchung durch den Leader). Es erfordert $n \ge 3f + 1$ .
Card-1/4: Eine Variante ohne Rechenschaftspflicht mit geringerem Overhead. Es entfernt die Anforderung öffentlicher Attestierungen, wodurch der Leader verbergen kann, welche Replikate inkludiert wurden. Es erreicht $t = n - 3f$ und $\eta = n - f - 1$ , was eine stärkere Annahme von $n \ge 4f + 1$ erfordert.
Card-Lite: Eine Optimierung von Card-7 unter Verwendung eines doppelt homomorphen Commitment-Schemas. Es reduziert den pro-Replika-Overhead auf $O(\log n)$ durch das Sampling von Commitments anstatt der Übertragung der vollständigen Liste, während es $t \approx n - 2f$ beibehält.

Integration in HotStuff-2

BigDipper wird innerhalb von HotStuff-2 instanziiert. Die Integration erfolgt chirurgisch durch die Einführung einer Scooping-Regel als Gültigkeitsprädikat. Ein Leader-Proposal ist nur gültig, wenn es einen abgeschlossenen DA-CR-Output (ein Zertifikat, das Datenverfügbarkeit und die Inklusion der erforderlichen Replica-beigesteuerten Daten beweist) enthält. Dies verändert den Sicherheitskern von HotStuff-2 nicht, verhindert aber, dass Leader Fortschritte machen, ohne die erforderlichen, von den Replikas beigesteuerten Daten zu erfassen.

Zentrale Beiträge

Modulare Abstraktion für kurzfristige Zensurresistenz: Die Einführung von DA-CR, welche den Mechanismus der Datenverfügbarkeit von den spezifischen Zensurresistenz-Policies entkoppelt. Es formalisiert die Trade-offs zwischen garantierter Inklusion ( $t$ ) und dem Einfluss des Leaders ( $\eta$ ).
Sharded, skalierbarer Datenpfad: Ein Design, bei dem gewöhnliche Validatoren nicht die gesamte Block-Payload herunterladen müssen, um abzustimmen. Sie verifizieren Commitments und Metadaten, wodurch die Bandbreite der Aggregate Proposal mit dem Beitrag der Replica-Seite skaliert, statt durch die Bandbreite eines einzelnen Leaders begrenzt zu werden.
Client-Tunable Censorship Resistance: Das Navigator-Protokoll erlaubt es Clients, die Inklusionswahrscheinlichkeit durch Erhöhung ihres Fanouts zu verstärken. Das Paper analysiert den Kosten-/Sicherheits-Tradeoff und beweist mittels eines Union-Bound-Arguments, dass eine großflächige Zensur exponentiell unwahrscheinlicher wird, wenn die Anzahl der eingereichten Transaktionen und Replikate steigt.
Konkrete Integration und Analyse: Eine vollständige Instanziierung von BigDipper innerhalb von HotStuff-2, die zeigt, dass DA-CR präzise mit bestehenden Leader-basierten BFT-Protokollen verbunden werden kann, ohne Sicherheit oder Liveness zu gefährden.

Ergebnisse und Analyse

Zensurresistenz: Die Analyse zeigt, dass ein bösartiger Leader zwar Transaktionen zensieren kann, die an eine kleine Anzahl von Replikas gesendet werden, das Zensieren eines großen Teils der Transaktionen jedoch exponentiell schwieriger wird, wenn das System skaliert. Speziell: Wenn $T$ Clients jeweils $x$ Kopien senden, sinkt die Wahrscheinlichkeit, dass ein Adversary einen Anteil $\alpha$ der Transaktionen zensiert, exponentiell mit $T$ .
Skalierbarkeit: Durch die Trennung von Konsens und vollständiger Datenausführung ermöglicht BigDipper, dass die Konsensebene linear mit der aggregierten Bandbreite der Replikas skaliert. Die Systemkapazität wird nicht dadurch limitiert, dass jeder Validator die gesamte Payload verarbeiten muss.
Performance: Das Card-7-Protokoll fügt sich in den bestehenden Nachrichtenplan von HotStuff-2 (Propose, Vote, Prepare, Vote2) ein, indem es DA-CR-Nachrichten (Collection, Dispersal, Approval, Agreement) auf die Standard-BFT-Nachrichten aufpinscht (piggybacking).

Bedeutung

Das Paper behauptet, dass BigDipper einen modularen Rahmen für kurzfristige Zensurresistenz bietet, der den „Einheitsmodell“-Aufschlag (one-size-fits-all tax) bestehender Protokolle vermeidet. Durch das Befolgen des End-to-End-Arguments ermöglicht es Anwendungen, ihre eigenen Submission-Strategien (z. B. wie viele Replikas kontaktiert werden, ob Erasure Coding verwendet wird) basierend auf ihren spezifischen wirtschaftlichen Anforderungen an Latenz und Inklusionsgarantien zu wählen.

Die Bedeutung liegt in der Verlagerung der Last der Zensurresistenz von einem festen Protokollpreis hin zu einem abstimmbaren Client-seitigen Parameter, während gleichzeitig sichergestellt wird, dass die Konsensebene effizient und shard-basiert bleibt. Es demonstriert, dass Leader-basierte BFTs zensurresistent gemacht werden können, ohne die Vorteile der geringen Latenz des Leader-basierten Modells zu opfern, sofern die Datenverfügbarkeit durch einen shard-basierten, commitment-basierten Mechanismus zertifiziert wird, anstatt durch vollständige Replikation.