Rapidblocks stellt einen neuartigen Konsensansatz für Ethereum vor, der die herkömmlichen 12-Sekunden-Slots auf nur 2 Sekunden verkürzt. Durch den Einsatz blockweiser Bloom-Filter (BMF), per-Slot-Abstimmungen und einer decoupled-Consensus-Integration ermöglicht das Design schnelle Transaktionsbestätigungen, reduziert MEV-Latenzarbitrage und vermeidet Kaskaden-Reorgs. Die nachfolgende Analyse fasst die wichtigsten Bausteine, Sicherheitsnachweise und praktischen Ergebnisse ausschließlich aus den vorliegenden Daten zusammen.

Warum 2-Sekunden-Slots das Ethereum-Ökosystem verändern

Eine Verkürzung der Slotzeit von 12 Sekunden auf 2 Sekunden beschleunigt die Bestätigung von Transaktionen drastisch und mindert die Möglichkeit, MEV-Arbitrage-Strategien zu nutzen. Gleichzeitig erfordert diese Beschleunigung neuartige Konsensmechanismen, um Kaskaden-Reorgs und Zustandskonflikte bei gleichzeitig produzierten Blöcken mathematisch und netzwerktechnisch zu kontrollieren.

Kernmechanismen von Rapidblocks

Blockweise Bloom-Filter (BMF) und Zustandsentkopplung

• Jeder Block i liefert einen Bloom-Filter, der die von ihm geschriebenen Schlüssel (Balances, Nonces, Code, Storage-Slots) enthält.
• Der nachfolgende Block i+1 baut nicht mehr auf dem unmittelbaren Vorgänger, sondern auf dem Zustand von Block i-1 und respektiert den BMF von Block i.
• Durch diese Entkopplung können verpasste oder ungültige Blöcke ohne Rollback im Kanonischen Set bleiben – Reorg-Kaskaden entfallen.

Per-Slot-Abstimmungen und Window-Voting

• Für jedes Slot j wird exakt ein Wert (Header-Hash oder ⊥) abgestimmt.
• Ein Voting-Fenster L von 4 Slots (bei m = 1) ermöglicht das parallele Verarbeiten von bis zu vier unabhängigen Blöcken.
• Der Fast-Confirmation-Schwellenwert T beträgt 75 % (T = 3/4), was bis zu 50 % byzantinische Anteile bei Doppelabstimmungen toleriert.
• Vote-Expiry (Goldfish) sorgt dafür, dass Stimmen nach einem Slot verfallen, was die Asynchronie-Sensitivität erhöht – daher wird ein Stabilitäts-Gadget (Majorum) auf Horizon-Checkpoints eingesetzt.

Sub-Komitee-Sampling und Fast-Confirmation Schwelle

• Ein zufällig gezogener Sub-Komitee von 512 Validatoren (≈0,05 % des Gesamtnetzes) führt das zeitkritische Window-Voting durch.
• Durch die geringe Größe ist eine Vote-Aggregation innerhalb von 0,5 – 1 Sekunde realisierbar, während das Gesamtkollektiv asynchron finalisiert.
• Der Quorum-Schwellenwert von 0,75 % ermöglicht die Toleranz von bis zu 30 % equivocating Stake bei T = 2/3, wobei T = 3/4 eine stärkere Garantie gegen adaptive Angriffe bietet.

Integration in das Decoupled-Consensus-Paradigma

Francesco D’Amato schlug im März 2026 vor, den kritischen Pfad der Blockerstellung von der Finalisierung zu trennen. Ein Sub-Komitee (256-512 Nodes) arbeitet an einer „Available Chain“, während das restliche Netzwerk die endgültige Finalität asynchron sicherstellt. Diese Trennung löst das Skalierungsdilemma für Rapidblocks: Die P2P-Stimmenaggregation für das gesamte Ethereum-Validator-Set (>1 Million) ist technisch unmöglich, aber für ein Sub-Komitee von 512 ist sie innerhalb der Sub-Sekunden-Grenze erreichbar.

Die Window-Voting-Logik lässt sich nahtlos mit dem Decoupled-Consensus-Modell kombinieren: Das Sub-Komitee verwendet das Goldfish-ähnliche View-Merge-Verfahren (Vote-Expiry = 1 Slot) und RLMD-GHOST (2023) für zusätzliche Asynchronie-Resilienz. Der „Majorum-Stabilisierungs-Gadget“ auf den Horizon-Checkpoints schützt die wenigen fragilen Goldfish-Entscheidungen.

Sicherheit und formale Verifikation

• Formale Modellprüfungen (Quint/Apalache) belegen, dass die Regeln „Own Values“ und „Closure“ notwendig sind, um Split- und Lock-Undoing-Angriffe zu verhindern.
• Goldfish-Design ist bei temporärer Asynchronie besonders brüchig; RLMD-GHOST liefert ein robusteres Grundgerüst.
• Simulationen mit 30 % adversarialem Stake zeigen:
• Mit „Own Values“ und „Closure“ beträgt die Rate fehlerhafter Bestätigungen < 1 % (m = 1) bzw. < 0,5 % (m = 2).
• Ohne diese Regeln steigt die Fehlerrate auf 4,8 % bzw. 28 %.
• Ein kleiner Quint-Model-Check bestätigt die fünf Sicherheits-Lemmas für m = 1 (Agreement, Lock Persistence, etc.).

Zustandszugriffslisten (BALs) als deterministischer Ersatz für Bloom-Filter

EIP-7928 definiert Block-Level Access Lists (BALs) als deterministische Alternative zu probabilistischen Bloom-Filtern. Empirische Messungen aus 2025/2026 zeigen:

• Durchschnittliche BAL-Größe für Kontensaldi: 9,6 KiB (SSZ-kodierter Balance-Diff über 1.000 Mainnet-Blöcke, ca. 182 Tx/Block).
• Worst-Case-Zustandsliste (vollständige Read/Write-Slots): 1,51 MiB pro Block.
• Während Bloom-Filter bei stark fragmentierten Konten zu bis zu 18 % falschen Positiven führen können, eliminieren BALs diese Fehlklassifikationen vollständig und sichern deterministische Parallel-Ausführung.

Praxismessungen und Durchsatzpotential

Eine Analyse von 501 aufeinanderfolgenden Mainnet-Blöcken (12 Oktober 2026) wurde in sechs gleich große 2-Sekunden-Slices unterteilt. Ergebnisse:

• 87 % der Transaktionen und 69 % des Gas-Volumens folgten dem Fast-Path (keine Schlüsselkonflikte mit dem Vorgängerslice).
• Abhängig von der Anzahl gleichzeitiger Slots (c) liegt der Fast-Path-Anteil zwischen 78 % und 90 % für Transaktionen und 59 % bis 74 % für Gas.
• Durchschnittliche Wartezeit für blockierte Transaktionen: 0,19 – 0,34 Slots (0,4 – 0,7 s).
• Ein 1 KB-Filter reicht für das betrachtete Sample aus; bei einer Slice-Größe von 1.000 Keys würde ein gleichgroßer Filter bis zu 18 % fälschlicherweise blockieren.

Die Messungen belegen, dass unter realen Mainnet-Bedingungen mindestens 80-87 % der Transaktionen ohne Zustandskonflikt parallel bzw. im Fast-Path verarbeitet werden können.

Risiken und Gegenmaßnahmen

• Asynchrone Netzwerk-Jitter: Bei m = 1 erfordert die Vote-Aggregation eine P2P-Latenz < 0,5 s. Überschreitungen führen zu 42 % Lock-Undoing-Verlusten.
• Kumulative False-Positive-Raten von BMF: Bei Transaktionsspitzen (z. B. DEX-Arbitrage) kann ein 1-KB-Filter bis zu 18 % unbeteiligte Transaktionen fälschlich blockieren, wodurch die theoretische Durchsatzsteigerung gedämpft wird.
• Zersplitterung durch Sub-Komitees: Zufällig gezogene Komitees (256-512 Nodes) reduzieren die byzantinische Fehlertoleranz gegenüber adaptiven Bestechungs- oder DoS-Angriffen im Vergleich zum gesamten Validator-Set.
• Gegenmaßnahmen: Nutzung von BALs zur Eliminierung von False Positives, Majorum-Stabilisierungs-Gadget für Horizon-Checkpoints, und ein hoher Quorum-Schwellenwert (T = 0,75) zur Begrenzung von Äquivokations-Schäden.

Häufig gestellte Fragen

• Warum führen verpasste oder ungültige Blöcke bei Rapidblocks nicht zu Chain-Reorganisationen? Weil nachfolgende Blöcke nicht auf dem unmittelbaren Zustand des Vorgängers, sondern auf dem konsolidierten Zustand zwei Slots zuvor ($i-1$) aufbauen und nur die Schreibzugriffe via Filter berücksichtigen.
• Wie realistisch ist eine P2P-Stimmenaggregation innerhalb von 0,5 s auf Ethereum? Für das gesamte Validator-Set (>1 Million Nodes) ist dies technisch unrealistisch. Machbar wird es erst durch Decoupled Consensus, bei dem nur ein Sub-Komitee von ca. 512 Validatoren im zeitkritischen Pfad votiert.
• Welche Rolle spielen ‚Own Values‘ und ‚Closure‘ im Sicherheitsnachweis? Sie verhindern, dass laufende Stimmauszählungen von byzantinischen Proposern manipuliert werden: ‚Own Values‘ friert die lokale Sicht des Knotens ein, während ‚Closure‘ verlangt, dass Referenzzustände bereits $m$ Runden zuvor unumstößlich bestätigt wurden.

Fazit

Rapidblocks kombiniert blockweise Bloom-Filter, per-Slot-Window-Voting und ein decoupled-Consensus-Framework, um Ethereum-Slots auf 2 Sekunden zu reduzieren, ohne Reorg-Kaskaden zu erzeugen. Formale Verifikationen (Quint/Apalache), Simulationen und Mainnet-Messungen belegen, dass das Design unter realen Bedingungen 80-87 % der Transaktionen im Fast-Path verarbeiten kann, während Sicherheitsmechanismen wie ‚Own Values‘, ‚Closure‘ und Majorum-Stabilisierung Angriffe effektiv abwehren. Die Integration von BALs bietet zudem eine deterministische Alternative zu Bloom-Filtern und reduziert False-Positive-Risiken. Trotz offener Herausforderungen – insbesondere Netzwerk-Jitter, False-Positive-Raten und die Robustheit kleiner Sub-Komitees – stellt Rapidblocks einen vielversprechenden Schritt hin zu einer schnellen, skalierbaren und sicheren Ethereum-L1-Architektur dar.