Kommentar: Cross-Chain-Bridges neu denken: Hören wir auf, Liquiditätsprotokolle zu sein

Nach einer Reihe groß angelegter Exploits von Bridges wird der Erzählung, dass Cross-Chain-Technologie von Natur aus fehlerhaft ist, viel Sauerstoff gegeben – dass Cross-Chain-Interoperabilität Risiken bedeutet. Mit einem geschätzten Verlust von 2 Milliarden US-Dollar durch 13 Bridge-Hacks in diesem Jahr wird es immer schwieriger, dieses Argument zu ignorieren.

At deBridge, denken wir, dass es nicht nur zwingend, sondern unvermeidlich ist, dass alle Cross-Chain-Bridges ihren Ansatz zur Liquiditätsaggregation komplett überdenken.

Die Grenzen der gesperrten Liquidität

Indem sie Liquidität sperren, um Cross-Chain-Routing bereitzustellen (wie es derzeit fast jede Bridge tut), haben sich Bridges einem Wettbewerb gestellt, den sie zwangsläufig verlieren werden. Wir sehen, dass Bridges gegen etablierte, speziell entwickelte Liquiditätsprotokolle wie z AAVE, Compounds und Frax, Projekte, die Liquidität zweifellos effektiver und sicherer monetarisieren werden. Es gibt viele Beispiele für Brücken mit Hunderten von Millionen Dollar an TVL, mit extrem geringer Nutzung der gesperrten Liquidität.

Mit diesem Design werden Bridge-Projekte dazu gezwungen, nicht nachhaltige Liquidity-Mining-Kampagnen durchzuführen, die keine langfristigen Lösungen für die Kapitaleffizienz bieten. Sofern Token-Anreize nicht auf unbestimmte Zeit aufrechterhalten werden – ein unsolides Ziel für jedes Projekt – werden Liquiditätsanbieter unweigerlich Kapital abziehen, um höhere Renditechancen zu verfolgen.

Um Liquidität sicher zu aggregieren, müssten Bridges Versicherungspolicen erwerben, damit Liquiditätsanbieter Risiken absichern können. Dies ist ein weiterer Aufwand, der die Monetarisierung von Liquidität noch schwieriger macht. Aus diesem Grund sind die meisten bestehenden Brücken nicht rentabel, da die Kosten und bezahlten Belohnungen für das Liquiditätsabbau oft den Nettogewinn des Protokolls übersteigen.

Hier spielen auch architektonische Überlegungen eine Rolle, da eine kettenübergreifende Wertübertragung eine Anforderung ist, die auf unterschiedliche Weise abgewickelt werden kann. Alle bestehenden Bridges wickeln diese Aufträge aus ihren eigenen Liquiditätspools ab, in denen Liquidität kontinuierlich gesperrt wird, wenn sie nur genau in dem Moment benötigt wird, in dem die Wertübertragung ausgeführt werden soll.

Die Größe der Order kann ebenfalls unterschiedlich sein – wenn sie die Größe des Liquiditätspools der Bridge überschreitet, erhält der Absender am Ende verpackte Token oder eine auf unbestimmte Zeit ausgesetzte/festgefahrene Transaktion. Ist der Auftrag dagegen zu klein für die Größe des Liquiditätspools, ist die Liquiditätsauslastung sehr gering und ineffizient. Dieser Teufelskreis unterstreicht weiter, dass dieser Ansatz des Liquiditätsprotokolls für das Bridge-Design ineffektiv und grundlegend falsch ist.

Lösung des Sicherheitsproblems

So wichtig das Thema auch ist, die wirtschaftliche Unhaltbarkeit ist hier nicht die einzige große Herausforderung. Selbst wenn Bridges einen Weg gefunden haben, den Locked-Liquidity-Ansatz zu nutzen und kapitaleffizient zu bleiben, ist es offensichtlich, dass der Aufbau eines sicheren Liquiditätsprotokolls eine alles verzehrende Aufgabe ist. Indem Bridge-Projekte wissentlich oder unwissentlich zu Liquiditätsprotokollen werden, geben sie sich selbst die immense Aufgabe, eine vielschichtige Angriffsfläche zu schützen.

Um auf hohem Niveau zu beginnen, eines der offensichtlichen Probleme mit einer gesperrten Liquiditätsbrücke ist, dass sie einen Risikomultiplikatoreffekt erzeugt, bei dem die Schwachstellen einer unterstützten Kette auf das in anderen Ökosystemen gehaltene Kapital übergreifen können.

Hier gibt es das Problem der Sicherheit durch Proxy. Eine Brücke kann ihre gesamte Liquiditätsbasis kompromittieren, wenn es eine potenzielle Schwachstelle in der Codebasis einer unterstützten Blockchain/L2 gibt. Wir haben diese Möglichkeit Anfang dieses Jahres bei einer in Optimism entdeckten Schwachstelle gesehen, die es Angreifern ermöglicht hätte, eine beliebige Menge an Assets zu prägen und diese voraussichtlich gegen Token in anderen Ökosystemen einzutauschen.

Letzte Woche habe ich einen kritischen Fehler (der vollständig gepatcht wurde) in entdeckt (und gemeldet). @optimismPBC (eine „Layer-2-Skalierungslösung“ für Ethereum), die es einem Angreifer erlaubt hätte, eine beliebige Menge an Token zu drucken, wofür ich ein Kopfgeld von 2,000,042 $ gewonnen habe. https://t.co/J6KOlU8aSW

- Jay Freeman (saurik) (@saurik) 10. Februar 2022

Auch hier können alle Probleme mit dem Konsensmechanismus einer Kette auch zu einer systemischen Ansteckung führen und die in anderen unterstützten Ketten eingeschlossene Liquidität gefährden. In diesem Fall sendet die Bridge den Exploit einfach an andere Chains. Dies könnte 51 %-Angriffe oder andere Fehler auf Protokollebene umfassen.

Abgesehen von diesen Arten von vererbten Risiken sehen wir zunehmend Situationen, in denen Fehler bei den Brückenprojekten selbst auf die eine oder andere Weise zu einem Verlust an gebundener Liquidität geführt haben. Von verpfuschten Protokoll-Upgrades, schlechtem Smart-Contract-Design oder kompromittierter Infrastruktur von Validatoren gibt es viele Szenarien, in denen schlechte Akteure Schwachstellen in der Bridge selbst ausnutzen können.

All diese Risiken verschärfen sich schnell und werden – wie wir bei zu vielen Gelegenheiten gesehen haben – schließlich von Liquiditätsanbietern getragen, wenn sie die Einlösbarkeit ihrer verpackten Vermögenswerte verlieren. Eine solche Möglichkeit sollte inakzeptabel sein.

Nur wenige leugnen das große Versprechen der Cross-Chain-Interoperabilität, um die Einführung von Web3 zu neuen Höhen zu führen. Aber angesichts der schieren Größe und Häufigkeit von Bridge-Exploits ist schmerzlich klar geworden, dass das grundlegende Design der Bridging-Technologie von Grund auf neu gedacht werden muss. Das Design des Bridge-Turn-Liquidity-Protokolls funktioniert einfach nicht.

Gibt es eine Möglichkeit, einen grundlegend neuen und einzigartigen Ansatz für das Bridge-Design zu entwickeln, einen Ansatz, der Risiken für Liquiditätsanbieter vollständig beseitigt, Angriffsvektoren eliminiert und gleichzeitig ein Höchstmaß an Kapitaleffizienz bewahrt?

Genau das könnte es in naher Zukunft geben. Bei deBridge arbeiten wir an einem neuen Cross-Chain-Liquidity-Routing, das all diese Probleme löst. Bleib dran.