Indem sie Liquidität sperren, um ein kettenübergreifendes Routing zu ermöglichen (wie es derzeit fast jede Bridge tut), haben sich Bridges in einen Wettbewerb begeben, den sie zwangsläufig verlieren werden
Nach einer Reihe groß angelegter Angriffe auf Bridges wird der Behauptung, dass die Cross-Chain-Technologie von Natur aus fehlerhaft ist – dass Cross-Chain-Interoperabilität ein Risiko bedeutet – viel Luft gemacht. Angesichts des geschätzten Verlustes von 2 Milliarden Dollar bei 13 Bridge-Hacks in diesem Jahr wird es immer schwieriger, dieses Argument zu ignorieren.
Wir bei deBridge sind der Meinung, dass es nicht nur zwingend notwendig, sondern unvermeidlich ist, dass alle Cross-Chain-Bridges ihren Ansatz zur Liquiditätsaggregation komplett überdenken müssen.
Die Grenzen der gesperrten Liquidität
Durch das Sperren von Liquidität, um ein kettenübergreifendes Routing zu ermöglichen (wie es derzeit fast alle Brücken tun), haben sich die Brücken in einen Wettbewerb begeben, den sie zwangsläufig verlieren werden. Wir sehen, wie Bridges gegen etablierte, speziell entwickelte Liquiditätsprotokolle wie AAVE, Compound und Frax antreten, Projekte, die Liquidität zweifellos effektiver und sicherer monetarisieren werden. Es gibt zahlreiche Beispiele für Brücken mit Hunderten von Millionen Dollar an TVL und einer extrem geringen Nutzung der gesperrten Liquidität.
Mit diesem Design sind Bridge-Projekte gezwungen, unhaltbare Liquiditätsabbaukampagnen durchzuführen, die keine langfristigen Lösungen zur Kapitaleffizienz bieten. Wenn die Token-Anreize nicht unbegrenzt aufrechterhalten werden – ein unvernünftiges Ziel für jedes Projekt -, werden die Liquiditätsanbieter unweigerlich Kapital abziehen, um höher rentierliche Möglichkeiten zu verfolgen.
Um Liquidität sicher zu aggregieren, müssten Brücken Versicherungspolicen abschließen, damit die Liquiditätsanbieter die Möglichkeit haben, Risiken abzusichern. Dies ist ein weiterer Kostenfaktor, der die Monetarisierung von Liquidität noch schwieriger macht. Aus diesem Grund sind die meisten bestehenden Brücken nicht rentabel, da die Kosten und die gezahlten Belohnungen für den Abbau von Liquidität oft den Nettogewinn des Protokolls übersteigen.
Hier spielen auch architektonische Überlegungen eine Rolle, da ein kettenübergreifender Werttransfer eine Anfrage ist, die auf verschiedene Weise abgewickelt werden kann. Alle bestehenden Brücken wickeln diese Aufträge aus ihren eigenen Liquiditätspools ab, in denen kontinuierlich Liquidität gesperrt wird, wenn sie nur genau in dem Moment benötigt wird, in dem der Werttransfer erfüllt werden soll.
Auch die Größe des Auftrags kann unterschiedlich sein – übersteigt er die Größe des Liquiditätspools der Bridge, so erhält der Absender entweder eingepackte Token oder eine auf unbestimmte Zeit ausgesetzte/gestaute Transaktion. Ist der Auftrag hingegen zu klein für die Größe des Liquiditätspools, ist die Liquiditätsnutzung sehr gering und ineffizient. Dieser Teufelskreis macht deutlich, dass der Ansatz des Liquiditätsprotokolls für das Brückendesign ineffektiv und grundlegend falsch ist.
Lösung des Sicherheitsproblems
So wichtig dieses Thema auch ist, die wirtschaftliche Unhaltbarkeit ist nicht die einzige große Herausforderung. Selbst wenn Brücken einen Weg finden würden, den Ansatz der gesperrten Liquidität zu nutzen und dabei kapitaleffizient zu bleiben, ist es inzwischen offensichtlich, dass der Aufbau eines sicheren Liquiditätsprotokolls eine alles verschlingende Aufgabe ist. Indem sie wissentlich oder unwissentlich zu Liquiditätsprotokollen werden, stellen sich Brückenprojekte der immensen Aufgabe, eine vielschichtige Angriffsfläche zu sichern.
Eines der offensichtlichen Probleme einer gesperrten Liquiditätsbrücke besteht darin, dass sie einen Risiko-Multiplikator-Effekt erzeugt, bei dem die Schwachstellen einer unterstützten Kette auf das in anderen Ökosystemen gehaltene Kapital übergreifen können.
Hier stellt sich das Problem der Sicherheit durch Stellvertreter. Eine Brücke kann ihre gesamte Liquiditätsbasis gefährden, wenn es eine potenzielle Schwachstelle in der Codebasis einer unterstützten Blockchain/L2 gibt. Wir haben diese Möglichkeit Anfang dieses Jahres mit einer in Optimism entdeckten Schwachstelle gesehen, die es Angreifern ermöglicht hätte, eine beliebige Menge an Vermögenswerten zu prägen und diese vorhersehbar gegen Token in anderen Ökosystemen einzutauschen.
Letzte Woche habe ich einen kritischen Fehler in @optimismPBC (eine „Layer-2-Skalierungslösung“ für Ethereum) entdeckt (und gemeldet), der es einem Angreifer ermöglicht hätte, eine beliebige Menge von Token zu drucken, wofür ich ein Kopfgeld in Höhe von 2.000.042 $ gewonnen habe. https://t.co/J6KOlU8aSW
– Jay Freeman (saurik) (@saurik) February 10, 2022
Auch können Probleme mit dem Konsensmechanismus einer Kette zu einer systemischen Ansteckung führen und die in anderen unterstützten Ketten gebundene Liquidität gefährden. In diesem Fall sendet die Bridge die Schwachstelle einfach an andere Chains weiter. Dazu könnten 51%-Angriffe oder andere Fehler auf Protokollebene gehören.
Abgesehen von diesen Arten von vererbten Risiken sehen wir zunehmend Situationen, in denen Fehler der Bridge-Projekte selbst auf die eine oder andere Weise zu einem Verlust von gesperrter Liquidität geführt haben. Von verpfuschten Protokoll-Upgrades über ein schlechtes Smart-Contract-Design bis hin zu einer kompromittierten Infrastruktur von Validierern gibt es viele Szenarien, in denen schlechte Akteure Schwachstellen in der Bridge selbst ausnutzen können.
All diese Risiken summieren sich schnell und werden – wie wir bei vielen Gelegenheiten gesehen haben – letztendlich von den Liquiditätsanbietern getragen, wenn sie die Einlösbarkeit ihrer verpackten Vermögenswerte verlieren. Eine solche Möglichkeit sollte inakzeptabel sein.
Nur wenige bestreiten, dass die kettenübergreifende Interoperabilität die Akzeptanz des Web3 auf ein neues Niveau heben wird. Doch angesichts des Ausmaßes und der Häufigkeit von Bridge-Exploits ist schmerzlich deutlich geworden, dass das grundlegende Design der Bridging-Technologie von Grund auf neu überdacht werden muss. Das Design der Brücke, die zum Liquiditätsprotokoll wird, funktioniert einfach nicht.
Gibt es eine Möglichkeit, einen grundlegend neuen und einzigartigen Ansatz für das Brückenkonzept zu entwickeln, der die Risiken für Liquiditätsanbieter vollständig beseitigt, Angriffsvektoren ausschaltet und gleichzeitig ein Höchstmaß an Kapitaleffizienz bewahrt?
Genau das könnte es in naher Zukunft geben. Bei deBridge arbeiten wir an einem neuen kettenübergreifenden Liquiditäts-Routing, das all diese Probleme löst. Bleiben Sie dran.
