Am 14. Februar 2026 pausierte das Cross-Chain-Protokoll Hyperbridge im Polkadot-Ökosystem plötzlich. Diese Nachricht sorgte in der Community für erhebliche Diskussionen.

Es muss jedoch betont werden, dass dieses Ereignis kein Hackerangriff war, dass keine Schwachstelle ausgenutzt wurde und dass es keinerlei Verluste von Benutzerfonds gab.

Der Grund ist, dass das Hyperbridge-Team während der Migration vom Parachain- zum Parathread-Modell festgestellt hat: Die aktuelle Implementierung der Polkadot Runtime erzeugt keine Konsens-Endgültigkeitsnachweise, die für die Cross-Chain-Validierung verwendet werden können.

Für ein Protokoll, das auf den Polkadot-Nachweis angewiesen ist, um Cross-Chain-Nachrichten zu validieren, bedeutet dies, dass die gesamte Validierungskette unterbrochen wurde. Daher entschied das Hyperbridge-Team, das System aktiv zu pausieren, um zu verhindern, dass Benutzer möglicherweise niemals zugestellte Cross-Chain-Nachrichten senden.

Das Ergebnis zeigt, dass dies eine typische sicherheitsorientierte Ingenieursentscheidung war. Aber diese Angelegenheit hat auch eine größere Frage in der Branche aufgeworfen: Warum sind Brücken immer ein Hauptziel für Sicherheitsvorfälle?

In der heutigen Diskussion hat Seun von Hyperbridge auch eine sehr offene und sogar etwas scharfe Meinung geteilt.

In seinen Augen liegt die grundlegendste Ursache vieler Sicherheitsprobleme nicht in der Komplexität: Viele Menschen haben nicht wirklich verstanden, was für ein System sie bauen.

Blockchain-Systeme beinhalten Kryptographie, verteilte Systeme und komplexe Mechanikdesigns und sind nach wie vor ein sich ständig entwickelndes Forschungsfeld. Gleichzeitig ist der Anreiz vieler Projekte, in diese Branche einzutreten, tatsächlich, Produkte schnell auf den Markt zu bringen und schnell Gewinne zu erzielen. Wenn das Ziel darin besteht, „schnell online zu gehen“ und nicht „das System vollständig zu verstehen“, werden einige technische Entscheidungen verständlich, legen aber auch oft Sicherheitsrisiken fest.

Wenn du dich entscheidest, ein Protokoll zu bauen, musst du es wirklich verstehen und langfristig dafür verantwortlich sein. Denn einmal, wenn das System online ist, stehen wir nicht nur vor technischen Problemen, sondern auch vor Sicherheitsrisiken, der Sicherheit von Geldern und dem Vertrauen in das gesamte Ökosystem.

In der heutigen Sendung werden wir nicht nur den Hyperbridge-Vorfall Revue passieren lassen, sondern auch einige grundlegendere Fragen diskutieren:

• Warum kommt es in der Branche weiterhin ständig zu Angriffen auf Brücken?

• Auditierung, KI-Audit und Community-Audit, welche ist wirklich effektiver?

• Und wie sollten Entwickler in einer immer noch schnell wachsenden Branche tatsächlich Verantwortung für die Sicherheit übernehmen?

Heute haben wir Seun, ein Kernmitglied von Hyperbridge, eingeladen, um über die technischen Details hinter diesem Vorfall und einige tiefere Überlegungen zum Design der Sicherheit über Brücken zu sprechen.

Kristen: Willkommen zum PolkaWorld-Livestream, in dieser Folge konzentrieren wir uns auf das Thema Sicherheit. Heute haben wir Seun von Hyperbridge eingeladen, um an der Diskussion teilzunehmen.

Am 14. Februar 2026 pausierte Hyperbridge den Betrieb ihrer Brücke, nachdem sie eine technische Einschränkung in Polkadot Runtime entdeckt hatte. Dieses Problem wurde anschließend behoben und am 19. Februar wieder in Betrieb genommen, ohne dass es während des gesamten Prozesses zu einem Verlust von Geldern kam.

Zunächst möchte ich betonen, dass dies kein Angriffsereignis, kein Hackerangriff und kein tatsächliches Versagen des Systems war.

Trotzdem hat diese Pause in der Gemeinschaft einige Bedenken ausgelöst.

Um für die kommenden Diskussionen etwas Kontext zu schaffen, möchte ich Sean bitten, uns detailliert zu erklären, was tatsächlich passiert ist und wie das Team dieses Problem gelöst hat.

Seun: Okay, danke für die Einladung. Ich freue mich, einige Details zu diesem Vorfall zu teilen, insbesondere da er während unseres Übergangs vom Parachain-Modell zum Parathread-Modell stattfand.

Kurz gesagt, Polkadot ist eine Blockchain, die anderen Blockchains Validierung bereitstellt. Ich werde nicht im Detail darauf eingehen, wie es genau umgesetzt wird, aber insgesamt gibt es eine „Protokollbeziehung“ zwischen Polkadot und den von ihm validierten Blockchains.

Das heißt, der Konsensmechanismus von Polkadot und die von ihm erzeugten Finalitätsnachweise (Finality Proofs) können ebenfalls als Finalitätsnachweise für diese validierten Ketten dienen. Egal, ob diese Ketten Parachains oder Parathreads sind, theoretisch sollte das so sein. Ich habe zuvor an der Entwicklung des Polkadot-Protokolls teilgenommen, daher bin ich mit seinen internen Mechanismen ziemlich vertraut.

Als wir vom Parachain-Modell zum Parathread-Modell wechselten, erwähnte unser CTO David im Team-Chat, dass unser Prover (Beweisgenerator) nicht mehr funktionierte. Übrigens ist unser Prover Open Source und kann in unserem Code-Repository gefunden werden.

Der Grund für den Systemfehler damals war, dass unser Para ID auf Polkadot nicht gefunden werden konnte.

Meine erste Reaktion damals war: „Das ist normal, denn wir sind nicht mehr Parachain, sondern Parathread.“

Ursprünglich hielt ich das für kein ernsthaftes Problem, es bedeutete nur, dass wir unsere Methode zur Erlangung des Polkadot-Nachweises an das neue Parathread-Modell anpassen mussten. Aber nach weiteren Untersuchungen entdeckten wir ein schwerwiegenderes Problem; unsere vorherige Kernannahme wurde gebrochen.

Diese Annahme ist, dass Polkadot für die von ihm validierten Ketten (zum Beispiel Parachains) Finalitätsnachweise bereitstellt.

Aber im Parathread-Modell wurde dieser Mechanismus tatsächlich beeinträchtigt.

Um ehrlich zu sein, verfolge ich normalerweise nicht regelmäßig die Updates des Polkadot-Codebases. Da unser Team derzeit hauptsächlich auf den Aufbau unserer Infrastruktur, die Anwendungsentwicklung, Integrationsarbeiten und Geschäftsvergrößerung konzentriert ist, ist die vorhandene Infrastruktur aus unserer Sicht funktional. Normalerweise müssen wir nur regelmäßig die Polkadot SDKs und ähnliche Tools aktualisieren. Theoretisch sollten wir keine kontinuierliche Verfolgung der Entwicklung des Polkadot-Protokolls selbst benötigen.

Aber nach weiteren Untersuchungen fanden wir heraus, dass das Polkadot-Protokoll in der aktuellen Implementierung tatsächlich Parathreads ausdrücklich von den Konsensbeweisen ausschließt.

In dem Moment, in dem wir nicht mehr Parachain sind, kann Hyperbridge keine Nachweise mehr von Polkadot erhalten. Man muss sich daran erinnern, dass Hyperbridge im Wesentlichen ein Co-Prozessor ist, der eine große Menge an Validierungsarbeiten im Namen des verbundenen Netzwerks ausführt. Um zu ermöglichen, dass externe Netzwerke sehen, was auf Hyperbridge passiert, oder Nachrichten von Hyperbridge empfangen, müssen sie zuerst den Beweis von Polkadot validieren, und dieser Beweis wiederum beweist, dass der Zustand von Hyperbridge gültig ist.

Daher war Hyperbridge tatsächlich blockiert, als diese Kette von Beweisen unterbrochen wurde.

Das heißt, wir haben das System nicht aktiv „pausiert“.

Natürlich haben wir auch die Fähigkeit, Verträge auf allen verschiedenen Netzwerken zu pausieren, um zu verhindern, dass Anwendungen weiterhin Nachrichten senden, was eine Sicherheitsvorkehrung ist.

Im Allgemeinen haben viele Smart Contracts eine Pausierungsmöglichkeit, um das System bei einem Angriff oder unvorhergesehenen Umständen zu schützen.

Wir hatten diesen Mechanismus zuvor nie verwendet, aber um auf Nummer sicher zu gehen, hatten wir ihn bereits im Voraus entworfen. Um ehrlich zu sein, habe ich damals nicht wirklich gedacht, dass wir ihn brauchen würden, aber während unserer Sicherheitsprüfung hat das Prüfungsteam tatsächlich empfohlen, einen solchen Mechanismus zu haben, also haben wir ihn implementiert.

Das Ergebnis zu diesem Zeitpunkt war: Die Brücke konnte keine Nachrichten mehr zwischen verschiedenen Netzwerken übermitteln.

Natürlich kannst du weiterhin Nachrichten an Hyperbridge senden, aber Hyperbridge kann diese Nachrichten nicht an die Zielkette weiterleiten, da es nicht mehr in der Lage ist, die Gültigkeit dieser Nachrichten gegenüber dem Zielnetzwerk nachzuweisen.

Daher wurde die gesamte Brücke tatsächlich eingefroren. Wir begannen, unsere Verträge in allen relevanten Netzwerken zu pausieren, um zu verhindern, dass Benutzer weiterhin Transaktionen initiieren.

Anders ausgedrückt, wenn jemand versucht, Token über die Kette zu senden oder eine Drittanwendung versucht, über Hyperbridge Nachrichten über die Kette zu senden, wird unser Vertrag diese Transaktionen direkt zurückrollen und so das Senden der Nachrichten verhindern.

Der Zweck dieser Vorgehensweise besteht darin, zu verhindern, dass Benutzer Nachrichten senden, die möglicherweise niemals zugestellt werden können, zumindest bis wir dieses Problem gelöst haben.

Im Wesentlichen war der Kern dieses Vorfalls, dass der „Protokollvertrag“ zwischen Polkadot und seinen oberen Ketten (Parachains) gebrochen wurde.

Warum die Fellows und das Entwicklungsteam von Polkadot beschlossen haben, Parathreads von den Konsensmechanismen auszuschließen, kann ich nicht kommentieren. Ich denke, diese Frage sollte besser direkt an das Polkadot-Team gerichtet werden.

Kristin: Aus dem gesamten Prozess gesehen hat das Team von Hyperbridge sehr schnell reagiert, ihr habt die Brücke schnell gestoppt und so potenzielle Verluste verhindert.

Ich möchte also weiter fragen, ob dieses Pausierungssystem eine integrierte Funktion von Hyperbridge ist, um die Sicherheit von Hyperbridge zu gewährleisten? Unter welchen Umständen würde dieser Mechanismus ausgelöst werden?

Seun: Im Hyperbridge-Netzwerk selbst (also auf der Hyperbridge-Parachain) gibt es tatsächlich keinen Mechanismus, um die gesamte Brücke direkt zu pausieren. Anders gesagt, wir haben kein runtime-niveau pallet, das alle Transaktionen zwangsweise pausieren kann. Aber auf der Ebene der Smart Contracts, die in verschiedenen Netzwerken bereitgestellt werden, haben wir die Kontrolle.

Diese Verträge erlauben es uns, zu pausieren:

• Nachrichten senden

• Nachrichten empfangen

• Oder beide gleichzeitig pausieren

Wie ich zuvor gesagt habe, haben wir diesen Mechanismus zuvor nie verwendet. Der Grund, warum dieser Mechanismus existiert, ist tatsächlich der Vorschlag des Prüfungsteams.

Als das Hyperbridge-Protokoll eine Sicherheitsprüfung durchführte, war SR Labs dafür verantwortlich. SR Labs ist auch die Prüfungsstelle für Polkadot und verantwortlich für die Prüfung des Polkadot-Protokolls selbst. Während des Prüfungsprozesses empfahlen sie uns, ein System zu schaffen, das die Brücke im Falle von Problemen pausieren kann, um die Gelder der Benutzer schnell zu schützen.

Das war tatsächlich auch der Vorschlag des Prüfungsteams. Sie glauben, dass dies eine Standardpraxis für Systeme wie Brückenprotokolle und DeFi-Protokolle ist.

Das Grundprinzip ist einfach: Jedes Mal, wenn ein Protokoll Gelder oder Vermögenswerte beinhaltet, sollte es in der Lage sein, Verträge im Falle eines Problems zu pausieren.

Wie ich zuvor gesagt habe, haben wir in über einem Jahr seit dem Start von Hyperbridge diesen Mechanismus nie verwendet – bis zu diesem Vorfall am 14. Februar.

Kristin: Ich möchte eine etwas sensible Frage stellen.

Wir wissen, dass Hyperbridge bereits eine Prüfung durch Dritte durchlaufen hat und dass die Prüfungsstelle im Voraus auf einige potenzielle Risiken hingewiesen hat. Aber in der Branche durchläuft viele große Protokolle mehrere Sicherheitsprüfungen, und einige der größten Hackerereignisse in der Geschichte der Kryptoindustrie fanden tatsächlich auch bei Projekten statt, die bereits wiederholt geprüft wurden.

Wie effektiv ist aus deiner Sicht eine Sicherheitsprüfung wirklich?

Seun: Um ehrlich zu sein, sind wir gegenüber den Prüfungsstellen selbst recht vorsichtig und sogar ein wenig skeptisch. Aus diesem Grund haben wir uns damals sehr klar für SR Labs als Prüfungsstelle entschieden. SR Labs ist auch das Prüfungsteam für das Polkadot-Protokoll. Wir glauben, dass sie über umfangreiche Erfahrung in der Prüfung von Multi-Chain-Protokollen verfügen.

Tatsächlich kennt unser eigenes Team dieses System sehr gut.

Persönlich habe ich früher bei Polkadot gearbeitet und dann zu Composable Finance gewechselt, wo wir das erste IBC-Protokoll außerhalb des Cosmos-Ökosystems gebaut haben. Daher haben wir in Bezug auf Multi-Chain-Protokolle viele Erfahrungen gesammelt.

In gewissem Maße könnten wir sogar besser geeignet sein, die Multi-Chain-Protokolle anderer zu prüfen.

Nach den tatsächlichen Betriebsdaten hat Hyperbridge in über einem Jahr über 500 Millionen Dollar an Transaktionsvolumen bearbeitet und fast 100.000 Transaktionen abgeschlossen. Während dieser Zeit gab es keine Sicherheitsvorfälle.

Darüber hinaus ist unser System in seiner Gestaltung vollständig dezentralisiert. Das heißt, jeder kann Nachrichten an Hyperbridge senden.

Viele Menschen verstehen tatsächlich nicht, dass die Sicherheit unseres Systems in der Architektur sehr stark ist.

Viele externe Brücken benötigen:

• Whitelist erstellen

• Nur bestimmten vertrauenswürdigen Knoten erlauben, Nachrichten zu senden

• Von diesen Knoten erklären, welche Nachrichten weitergeleitet werden sollen

Aber Hyperbridge ist völlig anders. Unser System ist vollständig Open Source, du kannst es im Block-Explorer sehen, es gibt jetzt über 130 Relayer.

Die Rolle dieser Relayer besteht darin, Hyperbridge mitzuteilen, wie die Nachrichten weitergeleitet werden sollten, und der gesamte Prozess erfolgt durch kryptographische Beweise.

Also, aus unserer Erfahrung sind die besten Prüfer tatsächlich die, die den Code selbst schreiben. Wenn du nicht wirklich verstehst, welches System du baust, solltest du es vielleicht nicht bauen. Besonders in der heutigen Zeit der „KI, die Code schreibt“ und „Vibe Coding“.

Das ist auch die Ingenieursphilosophie unseres Teams, man muss genau verstehen, wie das eigene Protokoll funktioniert.

Kristin: Apropos Prüfungen, jetzt gibt es neben traditionellen Prüfungen auch KI-Prüfungswerkzeuge. Du hast gerade erwähnt, dass Entwickler ihr Protokoll selbst verstehen müssen. Glaubst du, dass KI-Audits helfen könnten, die Sicherheit des Protokolls zu erhöhen?

Wenn in Zukunft ausgereifte KI-Audit-Tools verfügbar werden, würdet ihr in Betracht ziehen, sie zu verwenden?

Seun: Aus unserer Sicht ist die beste Prüfungsweise tatsächlich: ein Prüfungswettbewerb oder ein Bug-Bounty-Mechanismus. Das heißt, wir richten einen Belohnungspool ein, und jeder, der in der Lage ist, Schwächen im Protokoll zu finden, kann eine Belohnung erhalten. Ich denke, das ist eine der effektivsten Prüfungsweisen.

Viele Protokolle führen vor dem Start im Hauptnetz umfassende „Praktikertests“ auf diese Weise durch.

Ein Beispiel ist Uniswap, eines der DeFi-Protokolle mit dem höchsten TVL. Sie haben vor der Veröffentlichung von Uniswap V4 monatelang an einem Prüfungswettbewerb gearbeitet, ich erinnere mich, dass der gesamte Prüfungsprozess etwa sechs Monate dauerte. In dieser Zeit entdeckten viele Forscher eine große Anzahl von Bugs, darunter sogar einige sehr schwerwiegende Schwachstellen. Diese Probleme wurden alle vor dem Start im Hauptnetz behoben.

Daher war die Sicherheit, als das Protokoll das Hauptnetz startete, bereits sehr gründlich getestet.

Daher ist aus unserer Sicht die beste Prüfungsweise, die gesamte Gemeinschaft in die Prüfung einzubeziehen, anstatt sich nur auf einige wenige Prüfungsstellen zu verlassen.

Viele traditionelle Prüfungsstellen wenden lediglich die häufigen Schwachmustern, die sie in anderen Protokollen gefunden haben, auf dein Protokoll an, ohne wirklich in dein System einzutauchen und darüber nachzudenken, wie dein Protokoll strukturell am wahrscheinlichsten ausgenutzt oder angegriffen werden könnte.

Kristin: Ich stimme deiner Meinung zu. Die Mitglieder der Gemeinschaft haben oft mehr Leidenschaft für das Protokoll selbst, und in gewissem Maße könnte ihr Verständnis des Protokolls auch tiefer sein als das von Drittanbieter-Prüfungsstellen. In der Branche gibt es sowohl Drittanbieter-Audits als auch KI-Audits, und es gibt sogar Community-Audit-Wettbewerbe. Gleichzeitig kommt es jedoch im Web3-Bereich weiterhin häufig zu Angriffen auf Brücken. Es scheint, als ob keine der Lektionen aus der Vergangenheit wirklich gelernt wurde.

In diesem Jahr haben wir mehrere bedeutende Ereignisse gesehen. Was denkst du also, warum kommt es weiterhin zu Angriffen auf Brücken? Warum scheint die Branche nicht wirklich aus vergangenen Vorfällen gelernt zu haben? Was macht Brücken strukturell zu einem so bevorzugten Ziel für Angreifer?

Seun: Ich denke, die Realität ist: Viele Menschen verstehen nicht wirklich, was sie da bauen. Ich weiß, dass das arrogant klingen kann, aber die Tatsache ist, dass Blockchain-Systeme in vielerlei Hinsicht nach wie vor neue Forschungsfelder sind, wie Kryptographie, verteilte Systeme, Mechanikdesign, die selbst sehr komplex sind. Viele Menschen, die Produkte auf Blockchain entwickeln, haben in der Tat nicht wirklich verstanden, mit welchem Maß, welcher Komplexität und Tiefe sie es zu tun haben.

Viele Menschen kommen in diese Branche, um schnell Geld zu verdienen. Wenn man die gesamte Branche aus dieser Perspektive betrachtet, das heißt, wenn man erkennt, dass viele Menschen nur schnell arbitrage machen wollen, wird klar, dass die technischen Entscheidungen vieler Projekte „verständlich“ werden.

Für Entwickler gilt: Wenn du dich entscheidest, ein Protokoll zu bauen, musst du Verantwortung für dieses Protokoll übernehmen, da in der Folge viele Sicherheits- und Betriebsprobleme auftreten werden.

Dieser Artikel ist der erste Teil des Livestreams, der zweite Teil wird morgen veröffentlicht!

Ursprüngliches Video: https://x.com/i/broadcasts/1OGwblnyglvKB

• PolkaWorld Telegram-Gruppe: https://t.me/polkaworld_org

• PolkaWorld Youtube-Kanal:

  https://www.youtube.com/c/PolkaWorld

• PolkaWorld Twitter:

  @polkaworld_org

\u003ct-306/\u003e\u003ct-307/\u003e