Kompromisse bei Konsensmodellen für Interoperabilität: PoW, PoS, DPoS und BFT in der Sicherheit von Cross-Chain-Bridges

Allein im ersten Halbjahr 2025 wurden über 2,3 Milliarden US-Dollar aus Cross-Chain-Bridges abgezogen – was bereits die Gesamtsumme des gesamten Jahres 2024 übersteigt. Während sich ein Großteil der Branchendiskussion auf Smart-Contract-Audits und das Management von Multisig-Schlüsseln konzentriert, bleibt eine leisere, aber ebenso kritische Schwachstelle oft ungeprüft: die Diskrepanz zwischen der Art und Weise, wie verschiedene Blockchains einen Konsens erzielen, und der Art und Weise, wie Bridges annehmen, dass sie dies tun.

Jede Cross-Chain-Bridge trifft implizite Annahmen über die Finalität. Wenn diese Annahmen mit dem tatsächlichen Konsensmodell einer Quell- oder Ziel-Chain kollidieren, finden Angreifer Fenster für Exploits. Zu verstehen, wie sich PoW-, PoS-, DPoS- und BFT-Konsensmechanismen unterscheiden – und wie sich diese Unterschiede auf Designentscheidungen bei Bridges und die Auswahl von Messaging-Protokollen auswirken – ist heute eines der wichtigsten Themen in der Web3-Infrastruktur.

Was Finalität eigentlich für Bridges bedeutet

Bevor wir Konsenstypen vergleichen, hilft es, festzulegen, was Bridges eigentlich von der Konsensschicht einer Chain benötigen: Finalität – die Garantie, dass eine bestätigte Transaktion nicht rückgängig gemacht werden kann.

Finalität gibt es in zwei Varianten:

• Probabilistische Finalität: Eine Transaktion wird im Laufe der Zeit sicherer, wenn mehr Blöcke darauf aufgebaut werden, aber die Unumkehrbarkeit ist mathematisch nie absolut. Bitcoin ist das klassische Beispiel.
• Deterministische (sofortige) Finalität: Sobald ein Block von einer qualifizierten Mehrheit der Validatoren bestätigt wurde, kann er nicht mehr rückgängig gemacht werden. Die meisten BFT-basierten Chains bieten diese Garantie.

Für Bridges ist dieser Unterschied enorm. Eine Bridge, die eine Bitcoin-Einzahlung nach sechs Blöcken als bestätigt ansieht, geht eine probabilistische Wette ein. Eine Bridge, die einen Cosmos-IBC-Transfer nach einem einzigen Block-Commit bestätigt, verlässt sich auf deterministische Garantien, die in der CometBFT-Konsens-Engine verankert sind.

Wenn sich die Finalitätsmodelle der verbundenen Chains unterscheiden, müssen Bridges entweder lange genug warten, um statistisch sicher zu sein, oder ein erhöhtes Reversal-Risiko akzeptieren. Dieses Missverständnis hat die Branche bereits Milliarden gekostet.

PoW: Hohe Sicherheit, langsame Finalität, unfreundlich für Bridges

Proof-of-Work-Chains wie Bitcoin bieten eine außergewöhnliche Sybil-Resistenz und praxiserprobte Sicherheit auf der Basisschicht. Die Kosten für einen 51 %-Angriff auf Bitcoin sind enorm – bei den aktuellen Hash-Raten werden sie auf Milliarden von US-Dollar pro Stunde geschätzt –, was tiefe Block-Reorganisationen wirtschaftlich unerschwinglich macht.

Doch diese Sicherheit hat für Bridge-Designer ihren Preis:

• Nur probabilistische Finalität: Es gibt keinen harten Cut-off, an dem ein Bitcoin-Block „final“ ist. Sechs Bestätigungen (~ 60 Minuten) sind Konvention, kein Protokoll.
• Langsame Blockzeiten: Bitcoins durchschnittliche Blockzeit von 10 Minuten bedeutet, dass Bridges entweder eine Stunde warten oder das Reversal-Risiko akzeptieren müssen.
• Reorg-Fenster: Jede Bridge, die Einzahlungen vor einer tiefen Bestätigung verarbeitet, ist anfällig für Double-Spend-Angriffe durch Blockchain-Reorganisationen.

Die wirkliche Gefahr entsteht, wenn eine PoW-Chain mit schwacher Hash-Power (nicht Bitcoin, sondern kleinere PoW-Chains) mit einem hochwertigen DeFi-Ökosystem verbunden wird. Ethereum Classic erlitt im Jahr 2020 einen 51 %-Angriff, und jede Bridge, die ETC-Einzahlungen zu schnell als final behandelte, wäre in diesem Moment ausnutzbar gewesen.

Bestpassendes Messaging-Protokoll: Da PoW-Chains keine Light-Client-Unterstützung für eine effiziente Proof-Verifizierung bieten, verlassen sich Bridges, die mit ihnen verbunden sind, in der Regel auf externe Validatoren oder Oracle-Committees statt auf kryptografische Finalitätsbeweise. Protokolle wie Axelar (DPoS-gesichertes Validatoren-Netzwerk) und das Oracle+Relayer-Modell von LayerZero sind hier besser geeignet als IBC-artige Light-Client-Bridges, da letztere für einen effizienten Betrieb eine sofortige Finalität der Quell-Chain erfordern.

PoS: Verbesserte Finalität, aber Komplexität bei Checkpoints

Ethereums Übergang zu Proof-of-Stake brachte erhebliche Verbesserungen für das Design von Cross-Chain-Bridges. Die Konsensschicht von Ethereum (früher Ethereum 2.0) verwendet eine Kombination aus LMD-GHOST Fork Choice und Casper FFG Finalisierung, was alle zwei Epochen (~ 12,8 Minuten) für ökonomische Finalität sorgt.

Für Bridges ist dies ein bedeutendes Upgrade gegenüber Bitcoin:

• Finalisierte Checkpoints werden kryptografisch von einer qualifizierten Mehrheit des gestakten ETH bestätigt.
• Eine Reorganisation über einen finalisierten Checkpoint hinaus würde das Slashing von mehr als einem Drittel des gesamten gestakten ETH erfordern – derzeit zig Milliarden US-Dollar.
• Light Clients können die Signaturen des Sync-Committees von Ethereum verifizieren, was vertrauensminimiertere Bridge-Designs ermöglicht.

PoS bringt jedoch eigene Komplikationen mit sich:

• Rotation des Validatoren-Sets: Bridge-Light-Clients müssen Änderungen am Validatoren-Set verfolgen. Ein veralteter Light-Client könnte Proofs akzeptieren, die von einem nicht mehr existierenden Validatoren-Set signiert wurden.
• Slashing ist keine sofortige Bestrafung: Wirtschaftliche Sanktionen schrecken Angriffe ab, verhindern sie aber nicht unmittelbar im kurzen Fenster vor der Finalisierung.
• Finalitäts-Checkpoints erzeugen Latenz: Bridges, die auf die Casper FFG-Finalität warten, verlängern die Cross-Chain-Transaktionszeiten um 12–13 Minuten – akzeptabel für große Überweisungen, frustrierend für DeFi-Nutzer.

Bestpassendes Messaging-Protokoll: Das PoS-Modell von Ethereum ist zunehmend kompatibel mit ZK-Proof-basierten Bridge-Designs. Aufstrebende Protokolle wie Telepathy von Succinct nutzen ZK-SNARKs, um die Signaturen des Sync-Committees von Ethereum on-chain zu verifizieren, was vertrauensminimierte Bridges mit angemessener Latenz ermöglicht. Die Unterstützung von LayerZero v2 für ZK-Proof DVNs (Decentralized Verifier Networks) passt ebenfalls gut zu PoS-Chains, die verifizierbare kryptografische Zustandsbeweise liefern.

DPoS: Schneller Konsens, Risiko beim Validator-Set

Delegated-Proof-of-Stake-Systeme – eingesetzt von EOS, BNB Chain und vor allem durch das Validator-Netzwerk von Axelar selbst – führen ein kleineres, gewähltes Validator-Set ein, um einen schnelleren Konsens zu erzielen.

DPoS-Vorteile für Bridges:

• Schnelle Blockzeiten und nahezu sofortige Finalität: Mit 21 bis 101 aktiven Validatoren bestätigt die BNB Chain Blöcke in ~ 3 Sekunden mit praktischer Finalität in ~ 15 Sekunden.
• Vorhersehbare Validator-Sets: Bridges können leichtgewichtigere Proofs beibehalten, da sich das Validator-Set in einem langsameren Wahlzyklus ändert.
• Geringerer Rechenaufwand: Weniger Validatoren bedeuten weniger zu verifizierende Signaturen.

Aber DPoS komprimiert die Angriffsfläche:

• Kollusionsrisiko: Eine Supermehrheit gewählter Delegierter – auf einigen Chains potenziell nur 11 von 21 – kann theoretisch kolludieren, um einen Konsens zu fälschen. Angriffe durch Stimmenkauf bei Delegiertenwahlen wurden auf EOS dokumentiert.
• Kartelldynamik: In der Praxis kontrollieren oft wenige Einheiten mehrere Delegiertenplätze, was die Dezentralisierung verringert.
• Kaskade bei Schlüsselkompromittierung: Wenn eine Bridge auf das DPoS-Validator-Set vertraut und mehrere Validatoren gleichzeitig kompromittiert werden, bricht die Sicherheit der Bridge zusammen mit der zugrunde liegenden Chain zusammen.

Das Axelar-Netzwerk ist eine interessante Fallstudie: Es ist selbst eine DPoS-Chain (aufgebaut auf dem Cosmos SDK mit CometBFT-Konsens und über 75 aktiven Validatoren), die als Hub für das Cross-Chain Messaging dient. Die Sicherheit jeder Nachricht, die Axelar weiterleitet, wird letztlich durch die ökonomische Sicherheit des AXL-Stakings gestützt – ein bewusstes Design, das das Sicherheitsmodell der Bridge explizit und quantifizierbar macht.

Am besten geeignetes Messaging-Protokoll: DPoS-Chains passen natürlich zu Hub-and-Spoke-Interoperabilitätsarchitekturen wie Axelar, bei denen eine zweckgebundene DPoS-Konsensschicht Cross-Chain-Nachrichten absichert. Point-to-Point-Protokolle wie IBC können ebenfalls funktionieren, wenn die DPoS-Chain kompatible Light-Client-Schnittstellen bereitstellt, obwohl das kleinere Validator-Set bedeutet, dass die kryptografische Sicherheitsschwelle niedriger ist als bei stärker dezentralisierten PoS-Netzwerken.

BFT: Sofortige Finalität, die native Umgebung von IBC

Byzantinische Fehlertoleranz (BFT) – insbesondere CometBFT (ehemals Tendermint), das im gesamten Cosmos-Ökosystem verwendet wird – ist das bridge-freundlichste Konsensmodell, das derzeit im Einsatz ist.

BFT-Garantien:

• Deterministische, sofortige Finalität: Ein Block ist in dem Moment unwiderruflich festgeschrieben, in dem eine Supermehrheit (2/3+) der Validatoren ihn unterzeichnet. Es gibt keine probabilistische Wartezeit.
• Keine Forks per Design: Unter normalen Netzwerkbedingungen forken BFT-Chains nicht. Ein einzelner bestätigter Block ist die kanonische Chain.
• Erkennung von Fehlverhalten: Das Light-Client-Protokoll von IBC beinhaltet die Meldung von Fehlverhalten – wenn ein Validator-Set zweideutig handelt (zwei widersprüchliche Blöcke unterzeichnet), kann ein Proof on-chain eingereicht werden, der den Light Client einfriert, um weiteren Schaden zu verhindern.

Diese Eigenschaften sind genau das, worauf das Inter-Blockchain Communication (IBC) Protokoll ausgelegt wurde. IBC ist vertrauensminimiert, weil:

1. Es auf der Light-Client-Verifizierung von Header-Daten der Gegenpartei-Chain basiert, nicht auf externen Validatoren.
2. Deterministische BFT-Finalität bedeutet, dass der Light Client sich nie gegen Reorgs absichern muss.
3. Es keine Custodians und keine Multisigs gibt – nur kryptografische Proofs der State Inclusion.

IBC v2, das im März 2025 gestartet wurde, erweitert dieses Modell auf Ethereum – unter Verwendung von ZK-Proofs, um die PoS-Finalitäts-Checkpoints von Ethereum innerhalb eines IBC-Light-Client-Kontexts verifizierbar zu machen. Dies ist eine bahnbrechende Entwicklung: Das native BFT-Vertrauensmodell wird angepasst, um PoS-Chains zu umschließen, wodurch die Sicherheitsfläche von IBC drastisch vergrößert wird.

Der Kompromiss: BFT-Konsens skaliert schlecht. Wenn Validator-Sets über ein paar hundert Knoten hinauswachsen, steigt der Kommunikationsaufwand für das Sammeln von Signaturen quadratisch an. Deshalb neigen BFT-Chains zu kleineren, kuratierten Validator-Sets – was wiederum die Zentralisierungsbedenken von DPoS aufwirft.

Am besten geeignetes Messaging-Protokoll: IBC ist die kanonische Wahl für BFT-Chains und der Goldstandard für vertrauensminimierte Cross-Chain-Kommunikation. Hyperlane ist hier ebenfalls gut geeignet: Seine Interchain Security Modules (ISMs) können so konfiguriert werden, dass sie den Status von BFT-Chains direkt verifizieren, und sein permissionless Relayer-Modell bedeutet, dass jeder Infrastruktur für das BFT-zu-BFT-Messaging betreiben kann.

Messaging-Protokolle auf Konsens-Typen abstimmen

Hier ist ein praktischer Leitfaden für die Auswahl eines Messaging-Protokolls basierend auf den Konsens-Typen der verbundenen Chains:

LayerZero v2 funktioniert mit praktisch jeder Chain, erfordert jedoch eine sorgfältige DVN-Konfiguration. Sein modularer Security-Stack – bei dem Anwendungsentwickler auswählen, welche Decentralized Verifier Networks ihre Nachrichten validieren – macht es chain-agnostisch auf Kosten der Verlagerung von Sicherheitsentscheidungen auf die Entwickler. Bestens geeignet für heterogene Umgebungen, in denen kein einzelnes Finalitätsmodell dominiert.

Axelar ist speziell für Chains konzipiert, bei denen externe ökonomische Sicherheit akzeptabel ist. Sein DPoS-Validator-Netzwerk verarbeitet explizit Konsens-Fehlanpassungen: Axelar-Validatoren beobachten die Finalität der Quell-Chain (unabhängig davon, wie die Quell-Chain diese definiert), bevor sie Nachrichten weiterleiten. Dies macht es vielseitig, führt jedoch Axelars eigenes Validator-Set als Vertrauensannahme ein. Bestens geeignet für die Verbindung von PoW- oder PoS-Chains mit dem breiteren Ökosystem.

IBC ist die vertrauensminimierteste Option, erfordert jedoch, dass Quell-Chains über eine schnelle, deterministische Finalität und kompatible Light-Client-Implementierungen verfügen. Da IBC v2 die Unterstützung auf Ethereum ausweitet, wächst seine Reichweite. Bestens geeignet für BFT-zu-BFT-Verbindungen und zunehmend für BFT-zu-PoS-Verbindungen via ZK-Bridges.

Hyperlane bietet durch konfigurierbare ISMs die größte Flexibilität für Entwickler. Teams können ein Multisig-ISM (komiteebasiert, ähnlich dem Modell von Axelar) oder ein ZK-Light-Client-ISM (ähnlich wie IBC) wählen, abhängig vom Konsens-Typ der Quell-Chain. Bestens geeignet für Teams, die souveräne Rollups oder Appchains erstellen, die ihre eigenen Sicherheitsparameter definieren müssen.

Chainlink CCIP stützt sich auf das dezentrale Oracle-Netzwerk (DON) von Chainlink für die Cross-Chain-Nachrichtenverifizierung, was es relativ konsens-agnostisch macht. Bestens geeignet für Enterprise-Anwendungen und DeFi-Protokolle, die bereits Chainlink-Preis-Feeds nutzen, wo es auf einfache Integration und Markenvertrauen ankommt.

Die verborgenen Kosten nicht übereinstimmender Finalität

Die Bridge-Hacks, die die Ära 2022–2024 prägten – Ronin ( 625 Mio. $), Wormhole ( 320 Mio.$ ), Nomad ( 190 Mio. $ ) – hatten einen gemeinsamen Nenner: Sie alle trafen gefährliche Annahmen über die Transaktionsfinalität auf den verbundenen Chains.

Die Validatoren von Ronin bestätigten Einzahlungen, bevor eine angemessene On-Chain-Finalität erreicht war. Das Fraud-Proof-Zeitfenster von Nomad versäumte es, das Reorganisationsrisiko ( Reorg-Risiko ) auf verbundenen Chains zu berücksichtigen. Dies waren nicht nur Fehler im Smart Contract – es waren architektonische Unstimmigkeiten zwischen den Finalitätsmodellen.

Während die Branche Verluste von über 2,3 Milliarden $ aus der ersten Jahreshälfte 2025 verarbeitet, ist die Lektion klar: Bei der Sicherheit von Bridges geht es nicht nur darum, wie viele Auditoren den Vertrag geprüft haben. Es geht darum, ob die Finalitätsannahmen der Bridge mit den tatsächlichen Garantien jeder verbundenen Chain übereinstimmen – einschließlich des schwächsten Glieds im Netzwerk.

Ausblick: ZK-Proofs als universeller Adapter

Die spannendste Entwicklung im Bereich der Bridge-Sicherheit ist die Entstehung von ZK-Proof-basierten Light Clients als konsens-agnostische Verifizierungsschicht für Finalität. Projekte wie Succinct Labs, Polyhedra und die IBC v2-Initiative entwickeln ZK-Circuits, die PoS-Checkpoint-Signaturen, BFT-Validatoren-Sets und sogar PoW-Blockheader verifizieren können – und das alles innerhalb von On-Chain Smart Contracts.

Wenn die ZK-basierte Verifizierung wie erwartet bis 2025 und 2026 ausreift, könnte sie das Kernproblem lösen, das dieser Artikel untersucht: Bridges müssten sich nicht mehr zwischen der Sicherheit kryptografischer Beweise ( die eine deterministische Finalität erfordern ) und der Flexibilität externer Validatoren ( die jedes Finalitätsmodell handhaben, aber Vertrauensannahmen hinzufügen ) entscheiden.

Bis diese Zukunft eintritt, ist die praktische Empfehlung klar: Kennen Sie die Konsensmodelle Ihrer Chains, wählen Sie Messaging-Protokolle, die deren Finalitätsgarantien entsprechen, und bauen Sie niemals eine Bridge, die eine deterministische Finalität voraussetzt, wo nur eine probabilistische Finalität existiert.

---

BlockEden.xyz bietet Node-Infrastruktur der Enterprise-Klasse und API-Dienste für über 27 Blockchain-Netzwerke, darunter Sui, Aptos, Ethereum und Cosmos-Chains. Egal, ob Sie eine Cross-Chain-Anwendung entwickeln oder einen zuverlässigen RPC-Zugang für eine Bridge-Infrastruktur benötigen – erkunden Sie unseren API-Marktplatz, um auf Fundamenten zu bauen, die auf Produktionszuverlässigkeit ausgelegt sind.