Wie man Cross-Chain-Token wieder fungibel macht: Teil I

Einführung Die modularen Maxis sagen, die Zukunft der Kryptowährungen liege in einer Million (oder mehr) miteinander verbundener Domänen und Benutzern, die zwischen Blockchains hin- und herspringen wie Alice im Wunderland. Warum sollte man bei einer Kette bleiben, wenn man auf anderen Blockchains auf Spitzentechnologie, neuartige Anwendungen, Mondschussrenditen bei Staking/Liquiditätsbereitstellung, hohe Leistung und extrem niedrige Transaktionsgebühren zugreifen kann? Doch das Wechseln zwischen Blockchains ist viel komplizierter als Alices Reise durchs Wunderland, was hauptsächlich auf die Einschränkungen zurückzuführen ist, die den aktuellen Ansätzen zur Blockchain-Interoperabilität (z. B. Cross-Chain-Brücken) innewohnen. Insbesondere sind Cross-Chain-Brücken heute entweder unsicher (mehr als 2,5 Milliarden Dollar Verlust durch Bridge-Hacks), langsam, teuer oder in ihrer Funktionalität eingeschränkt – oder sie zeigen eine Mischung aus Eigenschaften aus der Liste an. Andere Probleme, die die Überbrückungsbranche plagen, sind subtiler, aber immer noch genug, um den Traum des modularen Maxi von einem Multi-Chain-Ökosystem in einen Albtraum für Benutzer und Entwickler zu verwandeln – ein Beispiel dafür ist, wie fungible Token (wie ERC-20s) nicht fungibel werden, wenn sie über verschiedene Cross-Chain-Protokolle mit verschiedenen Chains verbunden werden, was ihre Funktionen als übertragbares Asset beeinträchtigt. In diesem Artikel werden wir eine Lösung untersuchen, die die Token-Fungibilität über Chains hinweg bewahren soll, unabhängig davon, wo der Ursprungsvertrag eines Tokens besteht: ERC-7281: Sovereign-Bridged Tokens. ERC-7281 erweitert ERC-20 – den De-facto-Standard für die Erstellung fungibler Token in Ethereum – um das Prägen und Brennen kanonischer Darstellungen von ERC-20-Token auf Remote-Domänen durch mehrere von Token-Emittenten genehmigte Brücken zu ermöglichen. Dies stellt sicher, dass Benutzer, die einen ERC-20-Token überbrücken, fungible Versionen des Tokens am Ziel erhalten (d. h. zwei Token können 1:1 ausgetauscht werden), selbst wenn Token über verschiedene Routen/Brücken kettenübergreifend gesendet werden. Wichtig ist, dass Protokolle, die ERC-7281 übernehmen, die Kontrolle über überbrückte Token behalten (im Gegensatz zum Status quo, bei dem die Brücke einen überbrückten Token kontrolliert) und die Prägevorgänge geschwindigkeitsbegrenzen können, um das Risiko im Falle eines Brückenausfalls zu verringern. Nehmen wir USDC als Beispiel für die Infungibilität zwischen theoretisch identischen ERC-20-Tokens in verschiedenen Ketten. In wie Arbitrum, Base und Optimism ist es üblich, die kanonische Brücke zu verwenden, um beliebte ERC-20-Token von Ethereum L1 auf diese Ketten zu verschieben. Diese Versionen von L1-ursprünglichen L2-Tokens werden üblicherweise einfach „überbrückt [Token-Name einfügen]“ genannt. Ethereum Layer 2 (L2)-Netzwerken Im Fall von USDC sind die gängigen Symbole USDC.e, USDC.b usw. Mit der Zeit erweitert Circle seine USDC-Bereitstellungen auf andere Ketten, einschließlich L2s, wo USDC bereits über die kanonische Brücke aktiv ist. Obwohl diese beiden Token von derselben Stelle geprägt werden und denselben Preis haben, handelt es sich technisch gesehen um unterschiedliche, nicht fungible Token, die daher nicht „interoperabel“ sind – während natives USDC über die CCTP-Brücke von Circle überbrückt werden kann, kann das überbrückte USDC nur über die kanonische Brücke zurück zum L1 überbrückt werden. ERC-7281 behebt dies durch die Einführung einer ERC-20-Erweiterung, bei der die Bereitsteller des Tokens verschiedene Brückenquellen dafür zuweisen und parametrisieren können. Im obigen Beispiel könnte Circle einen universellen USDC-Token auf allen L2s bereitstellen, wobei die kanonischen Brücken (z. B. Circle Mint, Circle CCTP und andere zugelassene Brücken) alle gemäß ihrer Logik als fähig zum Prägen der Token zugewiesen werden. Um das Risiko eines Hackerangriffs auf die Minter zu minimieren, kann der Bereitsteller begrenzen, wie viele Token jeder Minter in einem bestimmten Zeitraum prägen und vernichten kann – wobei zuverlässigere Brücken, wie die kanonische L2-Brücke, höhere Grenzen haben und Brücken mit zentralisiertem Konsens niedrigere. Obwohl ERC-7281 nicht der erste Versuch ist, fungible Cross-Chain-Token zu erstellen, behebt es Probleme, die mit früheren Vorschlägen verbunden waren – wie z. B. Anbieterabhängigkeit, Verlust der Souveränität für Token-Emittenten, hohe Kosten für die Bereitstellung von Liquidität für überbrückte Token, Infrastrukturaufwand und erhöhte Anfälligkeit für Brückenausfälle. Dieser zweiteilige Bericht untersucht die Gründe für die Einführung eines Sovereign-Bridged-Token-Standards und bietet einen umfassenden Überblick über die ERC-7281-Spezifikation (auch bekannt als xERC-20). Wir diskutieren auch die positiven Vorteile und potenziellen Nachteile der Implementierung von ERC-7281 für Benutzer, Entwickler, Infrastrukturanbieter und andere Akteure im Ethereum-Ökosystem. Eine Auffrischung zum Thema Blockchain-Brücken Bevor wir uns mit dem Problem der nicht fungiblen Bridged Tokens befassen, ist es hilfreich zu verstehen, warum Bridged Tokens überhaupt existieren. Dies wiederum erfordert ein Verständnis der Motivation und Funktionsweise von Blockchain-Brücken – da die Brückenbetreiber für die Erstellung von Bridged Token-Versionen verantwortlich sind. . Neben rein monetären Informationen können Brücken auch alle nützlichen Informationen wie Token-Kurse und den Status von Smart Contracts an andere Ketten weitergeben. Der häufigste Anwendungsfall für Benutzer, die heute mit einer Brücke interagieren, ist jedoch die Übertragung von Vermögenswerten (Token) von einer Kette auf eine andere. Eine Brücke ist ein Mechanismus zum Übertragen von Informationen zwischen Blockchains Die Ansätze zur Erleichterung der kettenübergreifenden Übertragung von Vermögenswerten sind unterschiedlich, aber Token-Bridging-Workflows folgen normalerweise einem von drei Mustern auf hoher Ebene: Schloss- und Münzbrücken Ein Benutzer möchte einen Token von seiner nativen oder „Heimat“-Kette (wo er ursprünglich ausgegeben wurde) zu einer anderen Kette übertragen. Die beiden Blockchains sind nicht interoperabel, da jede Kette unterschiedliche Architekturen und Protokolldesigns implementiert, was den Benutzer daran hindert, Token direkt von einer Wallet-Adresse in Kette A zu einer Wallet-Adresse in Kette B zu übertragen. Der Brückenbetreiber verwahrt die vom Benutzer in der Ursprungskette hinterlegten Token in einem Smart Contract und erstellt über einen in der Zielkette eingesetzten Token-Vertrag eine „verpackte“ Darstellung des nativen Tokens. Wenn der Benutzer eine Brücke in umgekehrter Richtung (Zielkette → Ursprungskette) bauen möchte, gibt er die verpackten Token an die Brücke in der Zielkette zurück, die diese entsprechend der Logik in der Brücke überprüft (z. B. ZK-Beweise oder ein externes Quorum) und die ursprünglichen Token aus der Hinterlegung in der Heimatkette freigibt. Brücken brennen und prägen Anstatt die Token in einem Treuhandkonto zu sperren, werden bei diesem Ansatz die Token in der Quellkette verbrannt (zerstört). Die Brücke prägt dann einen entsprechenden Betrag auf der Zielkette; Für die Rückreise werden die überbrückten Token in der Zielkette verbrannt, bevor neue Token in der Quellkette geprägt werden. Dadurch bleibt die gesamte Token-Versorgung erhalten und gleichzeitig werden kettenübergreifende Übertragungen ermöglicht. Atomare Swaps Bei diesem Ansatz werden Vermögenswerte in der Quellkette direkt gegen Vermögenswerte in der Zielkette mit einer anderen Partei ausgetauscht. Atomare Swaps funktionieren, indem man Gelder mit demselben geheimen Wert gegenseitig sperrt, um sie wieder freizugeben. Das bedeutet, dass, wenn das Geheimnis auf einer Seite enthüllt wurde, es auch auf der anderen Seite enthüllt werden kann. Dies verleiht den Swaps die Atomizitätseigenschaft. Atomarität bedeutet, dass der Austausch entweder vollständig (auf beiden Seiten) oder überhaupt nicht abgeschlossen wird, wodurch Betrug oder teilweise/fehlgeschlagene Übertragungen verhindert werden. Der erste Ansatz (Lock and Mint) ist derzeit der gebräuchlichste. Die Wertgleichheit zwischen einem nativen Token und seiner entsprechenden, von einer Bridge geprägten, gepackten Darstellung ermöglicht es Benutzern, Vermögenswerte kettenübergreifend zu „übertragen“ und einen Token in einer anderen Kette zu verwenden als dort, wo er ursprünglich ausgegeben wurde. Neue Designs – wie beispielsweise Intent-basiertes Bridging – erfreuen sich jedoch zunehmender Beliebtheit. „Intents“ ermöglichen es Benutzern, gewünschte Ergebnisse für Transaktionen auszudrücken („100 USDC gegen 100 DAI tauschen“), anstatt bestimmte Schritte zur Erreichung der Ergebnisse zu skizzieren. Intents haben sich als leistungsstarkes UX-Tool erwiesen, da sie das Onchain-Erlebnis für Benutzer erheblich vereinfachen und die Verwendung von Kryptowährungen einfacher machen, insbesondere in Verbindung mit . Chain-Abstraktionslösungen ermöglichen es Benutzern, Token zwischen Ketten zu übertragen, ohne sich um die zugrunde liegende Komplexität des Bridgings kümmern zu müssen. Bei Intent-basierten Bridges zahlen Benutzer Geldmittel in die Quellkette ein und geben ihr gewünschtes Ergebnis in der Zielkette an (ihre „Intent“). Spezialisierte Operatoren, sogenannte „Filler“ oder „Solver“, können diesen Intent erfüllen, indem sie die angeforderten Token im Voraus an den Benutzer in der Zielkette senden. Die Operatoren weisen dann nach, dass die Übertragung stattgefunden hat, um die gesperrten Geldmittel in der Quellkette als Rückerstattung zu beanspruchen. Cross-Chain-Intents Einige absichtsbasierte Brücken nutzen im Hintergrund Lock-and-Mint-Mechanismen. In diesem Fall prägt die Brücke verpackte Token, die entweder an den Füller gesendet werden, der die Absicht des Benutzers erfüllt hat – oder direkt an den Benutzer, wenn kein Füller eingegriffen hat. Obwohl absichtsbasierte Brücken durch ihr Solver-Netzwerk eine zusätzliche Effizienzebene hinzufügen, basieren sie grundsätzlich immer noch auf denselben Prinzipien wie herkömmliche Lock-and-Mint-Brücken. Wir können uns jeden Wrapped Token, egal ob er durch traditionelles oder absichtsbasiertes Bridging erstellt wurde, als Schuldschein des Bridge-Betreibers vorstellen, der verspricht, einen bestimmten Betrag des zugrunde liegenden Tokens aus dem Treuhandvertrag freizugeben. Der Wert dieser Wrapped Assets korreliert direkt mit der (wahrgenommenen) Kapazität des Bridge-Betreibers, Anfragen von Inhabern zum Abheben nativer Token zu verarbeiten, die in der Home-Chain des Tokens hinterlegt sind. Die Brücke, die berechtigt ist, die zugrunde liegenden Token in der Quellkette zu sperren und ihre verpackten Darstellungen in der Zielkette zu prägen, stellt sicher, dass die Gesamtmenge des Tokens konstant bleibt. Für eine Einheit des zugrunde liegenden Tokens wird genau eine Einheit des entsprechenden verpackten Tokens geprägt und umgekehrt. Wenn eine Anwendung einen verpackten Token als Tauschmittel akzeptiert oder verpackte Vermögenswerte als Währung verwendet, vertrauen die Entwickler und Benutzer der Anwendung darauf, dass der Brückenanbieter die „echten“ Vermögenswerte sichert, die den verpackten Token stützen. Warum brauchen wir Brücken? Die Möglichkeit, mit einer synthetischen Version eines Vermögenswerts auf einer Remote-Kette zu handeln – ermöglicht durch Brücken, die Darstellungen des Vermögenswerts erstellen – ist eine leistungsstarke Funktion und ermöglicht es Entwicklern und Benutzern gleichermaßen, die Vorteile der kettenübergreifenden Interoperabilität zu nutzen. Zu diesen Vorteilen gehören der Zugang zu mehr Liquidität, die Bekanntheit neuer Benutzer und Flexibilität für Benutzer (die problemlos mit Lieblings-Apps aus verschiedenen Ketten interagieren können). Um besser zu verstehen, wie dies in der Praxis funktioniert und warum es sowohl für Entwickler als auch für Benutzer wichtig ist, untersuchen wir ein konkretes Beispiel anhand einer fiktiven dezentralen Börse namens BobDEX. Dieses Beispiel zeigt, wie Wrapped Tokens eine kettenübergreifende Erweiterung ermöglichen, und hebt sowohl die Vorteile als auch die potenziellen Komplikationen hervor, die auftreten können: BobDEX ist eine Automated Market Maker (AMM)-Börse, die Bob auf Ethereum erstellt hat, um vertrauenslosen Tausch zwischen verschiedenen Vermögenswerten zu ermöglichen. BobDEX hat einen nativen Token, $BOB, der gleichzeitig als Governance-Token und LP-Belohnungstoken fungiert. Im letzteren Fall gibt BobDEX BOB-Token an Liquiditätsanbieter (LPs) aus und berechtigt Benutzer, die einem Pool Liquidität bereitstellen, zu einem Prozentsatz der Gebühren, die von DEX-Benutzern gezahlt werden, die im Pool hinterlegte Vermögenswerte tauschen. Der Marktanteil von BobDEX ist deutlich gestiegen, aber die Einschränkungen von Ethereum L1 verhindern weiteres Wachstum. Einige Benutzer möchten BobDEX beispielsweise aufgrund hoher Gasgebühren und Transaktionsverzögerungen nicht auf Ethereum verwenden. Andere Benutzer möchten den Preis von $BOB-Tokens nutzen, ohne native $BOB-Tokens auf Ethereum halten zu müssen. Um das Problem zu lösen, setzt Bob eine Version von BobDEX auf Arbitrum ein (ein Layer 2 (L2)-Rollup mit niedrigen Gebühren und hohem Durchsatz) und setzt eine verpackte Version des BOB-Tokens (wBOB) auf L2 über die Arbitrum-Ethereum-Brücke ein. BobDEX auf Arbitrum ist identisch mit BobDEX auf Ethereum, außer dass es wBOB – keine nativen BOB-Token – für LP-Belohnungen und -Verwaltung verwendet. Der Unterschied bei den Anwendungstoken (verpacktes BOB vs. natives BOB) macht aus Sicht der Benutzer (z. B. Liquiditätsanbieter), die mit BobDEX auf Arbitrum interagieren, keinen Unterschied. Da wBOB-Token durch tatsächliche BOB-Token gedeckt sind, die in der Arbitrum-Ethereum-Brücke gehalten werden, können wBOB-Token-Inhaber diese durch Interaktion mit dem Brückenvertrag problemlos gegen native BOB ERC-20-Token auf Ethereum tauschen. Die Situation ist eine Win-Win-Situation für Bob und die Benutzer: Bob kann mehr Benutzer anziehen, insbesondere Benutzer, die niedrige Gasgebühren und schnelle Transaktionsbestätigungen beim Handel auf BobDEX wünschen. LPs können durch die Bereitstellung von Liquidität für BobDEX Prämien verdienen, ohne sich mit den hohen Gaskosten und langen Bestätigungszeiten von Ethereum herumschlagen zu müssen. Hodler können wBOB-Token auf dem Markt kaufen, um von Preisänderungen der BOB-Token zu profitieren, ohne mit dem BOB ERC-20-Vertrag auf Ethereum zu interagieren. Die Vorteile der Überbrückung erstrecken sich auch auf die Verbesserung der zusammensetzbaren Innovation und die Erschließung neuer Anwendungsfälle, die die Liquidität eines überbrückten Tokens nutzen. Beispielsweise kann Alice auf Arbitrum ein Kreditprotokoll namens AliceLend erstellen, das wBOB als Sicherheit von Kreditnehmern akzeptiert, um den Nutzen von wBOB zu erweitern und einen neuen Markt für zu schaffen. Kreditvergabe und -aufnahme Kreditgeber, die AliceLend Liquidität zur Verfügung stellen, können sich sicher sein, Einlagen zu erhalten: Wenn ein Benutzer mit der Rückzahlung eines Kredits in Verzug gerät, versteigert AliceLend automatisch als Sicherheit hinterlegte wBOB-Token, um die Kreditgeber zu entschädigen. In diesem Fall übernehmen Käufer liquidierter wBOB-Sicherheiten die Rolle von LPs auf BobDEX und haben die gleiche Garantie, dass wBOB-Token 1:1 gegen ursprüngliche BOB-Token eingetauscht werden können. Cross-Chain-Bridging in seiner aktuellen Form hat eine praktikable Lösung geboten, um sicherzustellen und neuartige Anwendungen (z. B. Cross-Chain-Lending und Cross-Chain-DEXes) zu ermöglichen. Das Bridging-Ökosystem hat derzeit jedoch mit Einschränkungen zu kämpfen, die weiteres Wachstum behindern, wie z. B. die Nichtfungibilität von Cross-Chain-Tokens – wir werden dieses Problem später ausführlich untersuchen. die Interoperabilität zwischen (bisher isolierten) Ethereum L2s Warum werden überbrückte Token nicht fungibel? Der zuvor beschriebene Lock-and-Mint-Bridging-Workflow sieht auf dem Papier einfach aus, erfordert in der Realität jedoch einen hohen technischen und mechanismusbezogenen Aufwand, um ordnungsgemäß zu funktionieren: besteht darin, sicherzustellen, dass die gewrappten Versionen eines überbrückten Tokens immer durch native Token gedeckt sind, die in der Quellkette gesperrt sind. Wenn ein Angreifer Darstellungen eines Tokens in einer Remotekette prägt, ohne native Token in der Quellkette zu hinterlegen, kann er die Brücke zahlungsunfähig machen, indem er (betrügerisch geprägte) gewrappte Token mit nativen Token in der Heimatkette austauscht und legitime Benutzer – die vor dem Prägen gewrappter Token im Brückenvertrag eingezahlt haben – daran hindert, Einlagen abzuheben. Die erste Herausforderung ist differenzierter und ergibt sich aus der Natur der überbrückten Token: Zwei Darstellungen eines Tokens, die von Bridge-Anbietern in derselben Remote-Kette geprägt wurden, können nicht 1:1 gegeneinander ausgetauscht werden. Wir können ein weiteres Beispiel von zwei Benutzern verwenden, die versuchen, über unterschiedliche Routen überbrückte Token auszutauschen, um diesen Aspekt des Problems zu veranschaulichen, das mit der Übertragung von Token über Ketten hinweg verbunden ist: Die zweite Herausforderung Alice überträgt USDC von Ethereum zu Arbitrum über die kanonische Arbitrum-Brücke und erhält 200 USDC.e auf Arbitrum, während Bob USDC über Axelar zu Arbitrum überträgt und 200 axlUSDC auf Arbitrum erhält. Alice und Bob schließen eine Vereinbarung, wonach Alice 200 USDC an Bob sendet (im Austausch für 200 USDT), damit Bob 400 USDC auf Ethereum abheben kann. Bob versucht, 400 USDC über axlUSDC abzuheben und erhält nur 200 USDC sowie eine Nachricht, in der erklärt wird, dass die Brücke nur 200 USDC hat, die sie Bob geben kann. Bob ist verwirrt, da die verpackten ERC-20-Token „fungibel“ sein sollen und keine Unterschiede aufweisen sollten, die jeden daran hindern, ERC-20-Token bei jeder Anwendung 1:1 auszutauschen. Bob lernt eine harte Lektion über Cross-Chain-Bridging: „fungibler ERC-20-Token“ bedeutet nicht immer „Sie können diesen Token 1:1 mit anderen ERC-20-Token anwendungsübergreifend austauschen“. Bobs Versuch, riskante Geschäfte mit Alice zu machen – riskant, da Alice die Token möglicherweise nicht zurückgibt – geht spektakulär schief. Warum kann Bob nicht 400 USDC abheben, wenn er und Alice verpackte Versionen desselben Basiswerts auf der Zielkette erhalten haben? Sie erinnern sich, dass wir erwähnt haben, dass auf verschiedenen Ketten ausgegebene Token inkompatibel sind. Die Darstellung eines auf einer nicht-nativen Kette ausgegebenen nativen Tokens ist also ein Schuldschein der Brücke, der verspricht, einen bestimmten Betrag der nativen Token zurückzuzahlen (je nachdem, wie viel übrig ist), wenn der Benutzer zur nativen Kette des Tokens zurückkehren möchte. Der Wert jedes überbrückten Tokens ist somit an den Bridge-Provider gebunden, der für die Verwaltung der Einlagen auf der Heimatkette und die Prägung von Darstellungen auf der Zielkette verantwortlich ist. Bobs Bridge-Provider kann Bob nur 200 USDC zahlen, da dies der Betrag ist, den er aus seiner Einlage decken kann. Alice‘ 200 USDC können nicht über Bobs Bridge-Provider abgehoben werden, da dieser weder die Einlage erhalten noch Alice einen Schuldschein ausgestellt hat. Alice muss ihre gesperrten USDC aus dem Arbitrum auf Ethereum abheben und über Bobs Bridge-Provider überbrücken, bevor Bob auf die verbleibenden Token zugreifen kann. Das Dilemma von Bob und Alice weist auf ein Problem bei der Überbrückung zwischen Domänen hin, bei denen mehrere nicht fungible Darstellungen eines zugrunde liegenden Vermögenswerts von konkurrierenden Brückenanbietern geprägt werden. Das andere Problem mit verschiedenen ERC-20-Darstellungen desselben Vermögenswerts besteht darin, dass sie nicht in einem einzigen Liquiditätspool gehandelt werden können. Wenn wir im vorherigen Beispiel axlUSDC und USDC.e in der Kette haben und sie in ETH und umgekehrt tauschen möchten, müssen wir zwei Liquiditätspools bereitstellen – ETH/axlUSDC und ETH/USDC.e. Dies führt zu einem sogenannten „Liquiditätsfragmentierungs“-Problem – einer Situation, in der die Handelspools über eine geringere Liquidität verfügen, als sie andernfalls hätten, weil es mehrere Pools gibt, die im Wesentlichen zum gleichen Handelspaar passen. Die Lösung besteht darin, eine einzige „kanonische“ Version eines Tokens in der Zielkette zirkulieren zu lassen, sodass Bob und Alice Token austauschen können, ohne dass sich jeder von der Brücke in der Quellkette zurückzieht. Ein kanonischer Token pro Kette kommt auch Entwicklern zugute, da Benutzer schnell zwischen Ökosystemen wechseln können, ohne sich mit Problemen rund um die Token-Liquidität auseinandersetzen zu müssen. Wie können wir also kanonische Versionen eines Tokens auf jeder Kette implementieren, auf der es verwendet und zwischen der es übertragen werden soll? Im nächsten Abschnitt werden einige der gängigen Ansätze zum Erstellen kanonischer Token auf mehreren Ketten erläutert. Implementierung kanonischer Token über verschiedene Ketten hinweg Das Erstellen eines kanonischen Tokens pro Kette ist nicht einfach, und es gibt mehrere Optionen mit unterschiedlichen Vor- und Nachteilen. Beim Erstellen eines kanonischen Tokens pro Kette müssen wir normalerweise darüber nachdenken, wem wir hinsichtlich der Existenz von Schuldscheinen vertrauen können, die den Wert eines bestimmten Tokens stützen. Angenommen, Sie sind der Ersteller eines Tokens und möchten, dass dieser über verschiedene Ketten hinweg verwendet und übertragen werden kann, ohne dass es zu Problemen hinsichtlich der Fungibilität kommt. Dann haben Sie vier Möglichkeiten: Prägen Sie kanonische Token über kanonische Rollup-/Sidechain-Brücken Prägen Sie kanonische Token über einen Drittanbieter-Bridge-Anbieter Prägen Sie kanonische Token über eine Token-Emittenten-Brücke Direkte Multi-Chain-Emission mit Atomic Swaps Die ersten drei Optionen basieren auf verschiedenen Überbrückungsmechanismen, um die kettenübergreifende Bewegung von Token zu erleichtern. Als Token-Ersteller können Sie das Überbrücken jedoch auch vollständig umgehen, indem Sie den Token nativ auf jeder unterstützten Kette ausgeben. Bei diesem Ansatz verlassen Sie sich nicht auf verpackte Token oder eine Brückeninfrastruktur, sondern verwalten separate, aber koordinierte Tokenbereitstellungen über alle Ketten hinweg – mit Atomic Swaps, die einen vertrauenslosen Austausch zwischen den Ketten ermöglichen. Dieser Ansatz erfordert jedoch eine ausgefeilte Infrastruktur, um die Liquidität über alle Ketten hinweg aufrechtzuerhalten und Atomic Swaps zu ermöglichen. Die Komplexität der Verwaltung mehrerer nativer Bereitstellungen hat diesen Ansatz in der Vergangenheit auf größere Protokolle mit erheblichen technischen Ressourcen beschränkt. 1. Prägen Sie kanonische Token über kanonische Rollup-/Sidechain-Brücken Wenn eine Kette eine kanonische (verankerte) Brücke hat, können Sie das Recht zuweisen, Darstellungen des Tokens Ihres Protokolls für Benutzer zu prägen, die von der nativen Kette aus eine Brücke bauen möchten. Transaktionen, die über die kanonische Brücke der Kette geleitet werden (Einzahlungen und Abhebungen), werden normalerweise durch den Validatorsatz der Kette validiert, der stärkere Garantien dafür bietet, dass Einzahlungen auf der Heimatkette alle geprägten Darstellungen glaubwürdig unterstützen. Obwohl die kanonische Brücke die kanonische Darstellung eines Tokens prägt, werden dennoch andere Darstellungen existieren. Dies liegt einfach daran, dass kanonische Brücken oft Einschränkungen haben, die sie daran hindern, den Benutzern das beste Erlebnis zu bieten. Beispielsweise kommt es bei der Überbrückung von Arbitrum/Optimism zu Ethereum über die kanonische Brücke des Rollups zu einer Verzögerung von sieben Tagen, da Transaktionen von Prüfern validiert und, falls ungültig, möglicherweise durch einen angefochten werden müssen, bevor die Abwicklungsebene des Rollups (Ethereum) einen Transaktionsstapel abwickelt. Betrugsnachweis Rollup-Benutzer, die schnellere Exits wünschen, müssen andere Bridge-Anbieter verwenden, die das Eigentum an ausstehenden Rollup-Exits übernehmen und im Voraus Liquidität auf der gewünschten Zielkette des Benutzers bereitstellen können. Wenn solche Bridges das traditionelle Lock-and-Mint-Modell verwenden, erhalten wir mehrere verpackte Darstellungen eines Tokens, die von verschiedenen Protokollen ausgegeben werden, und stehen vor denselben Problemen, die zuvor beschrieben wurden. Sidechains mit unabhängigen Validator-Sets haben eine geringere Latenz, da Auszahlungen ausgeführt werden, sobald das Konsensprotokoll der Sidechain einen Block bestätigt, der eine Auszahlungstransaktion enthält. Die Polygon PoS-Brücke ist ein Beispiel für eine kanonische Brücke, die eine Sidechain mit verschiedenen Domänen verbindet (einschließlich Ethereum-Rollups und Ethereum-Mainnet). Hinweis: Wir beziehen uns auf die ursprüngliche Polygon PoS-Kette, nicht auf die , die Ethereum zur Abwicklung verwenden wird. Polygon wird zu einem L2, sobald der Wechsel von einer durch externe Validierer gesicherten Sidechain zu einem durch Ethereum-Konsens gesicherten Validium abgeschlossen ist. geplante Validium-Kette Sidechain-Brücken haben jedoch auch eine Schwäche mit Rollup-Canonical-Brücken gemeinsam: Benutzer können nur zwischen einem Paar verbundener Ketten eine Brücke bauen. Sie können mit der Canonical-Brücke keine Brücke zu anderen Blockchains bauen. Beispielsweise können Sie heute nicht mit der Arbitrum-Brücke eine Brücke von Arbitrum zu Optimism bauen oder mit der Polygon-PoS-Brücke eine Brücke von Polygon zu Avalanche bauen. 1.1. Prägen Sie kanonische Token mithilfe von Liquiditätsbrücken Das Verlassen auf die native Brücke eines Rollups zum Verschieben kanonischer Token bringt verschiedene Probleme mit sich, beispielsweise mangelnde Liquidität und Verzögerungen bei der Vermögensbewegung. Protokolle umgehen dieses Problem, indem sie mit Liquiditätsbrücken arbeiten, um schnelle Abhebungen und Überbrückungen mit geringer Latenz* zu ermöglichen. Im Rahmen dieser Vereinbarung prägen genehmigte Liquiditätsbrücken (a) verpackte Darstellungen des Tokens eines Protokolls in der Quellkette (b) und tauschen verpackte Token über einen protokolleigenen Liquiditätspool gegen die kanonische Darstellung am Ziel aus. Die kanonische Darstellung des Tokens in der Zielkette ist normalerweise die von der kanonischen Sidechain/Rollup-Brücke geprägte Version, obwohl es Ausnahmen gibt (wie wir später sehen werden). Beispielsweise ist die kanonische Version von USDT auf Optimism opUSDT, geprägt von der Optimism Bridge. Jede Liquiditätsbrücke funktioniert wie ein DEX mit einem Automated Market Maker (AMM), um Swaps zwischen Paaren von Vermögenswerten auszuführen, die in verschiedenen Liquiditätspools hinterlegt sind. Um die Bereitstellung von Liquidität zu fördern, teilen AMM-Pools einen Teil der Swap-Gebühren mit Inhabern, die kanonische Token in den Poolverträgen sperren. Dies ähnelt dem Modell von Uniswap. Der einzige erkennbare Unterschied besteht darin, dass Asset-Paare normalerweise die Darstellung eines Tokens durch die Liquiditätsbrücke gegenüber der kanonischen Darstellung sind. Beispielsweise muss ein Benutzer, der USDT über Hop mit Optimism verbindet, hUSDT über den Pool huSDT:opUSDT auf Optimism tauschen. Der Workflow zur Überbrückung über eine Liquiditätsbrücke sieht folgendermaßen aus: Sperren Sie native Token in der Quellkette Mint Bridge-Darstellung des nativen Tokens in der Zielkette Tauschen Sie die überbrückte Darstellung mit der kanonischen Darstellung in der Zielkette über den AMM-Pool aus Senden Sie kanonische Token an den Benutzer Dieser Prozess ist für alle Liquiditätsbrücken (Across, Celer, Hop, Stargate usw.) ähnlich. Allerdings wird er normalerweise vom Endbenutzer abstrahiert – insbesondere durch Solver/Filler – und fühlt sich trotz der vielen beweglichen Teile wie eine einzelne Transaktion an. Beim Zurücküberbrücken zur Quellkette verbrennt der Benutzer die kanonische Darstellung oder tauscht das kanonische Token über das AMM mit der Brückendarstellung aus, bevor er diese Darstellung verbrennt und den Burn-Proof-Beleg bereitstellt. Nach der Bestätigung kann der Benutzer die zu Beginn gesperrten nativen Token abheben. (Genau wie beim vorherigen Vorgang sind die schmutzigen Details des Zurückverschiebens von Token in die ursprüngliche Kette vor dem Benutzer verborgen und werden von Lösern verwaltet.) Liquidity Bridging ist hervorragend, vor allem weil es das Problem der Latenz beim Rollup Bridging behebt. Hop ermöglicht es beispielsweise spezialisierten Parteien, sogenannten „Bondern“, die Gültigkeit der Auszahlungstransaktion eines Benutzers auf L2 zu bestätigen und die Kosten für die Auszahlung von der L1-Brücke des Rollups vorzustrecken. Jeder Bonder betreibt einen vollständigen Knoten für die L2-Kette und kann bestimmen, ob die Exit-Transaktion eines Benutzers schließlich auf L1 bestätigt wird. Dadurch wird das Risiko verringert, dass ein Benutzer eine betrügerische Auszahlung initiiert und dem Bonder Verluste verursacht. Liquiditätsbrücken ermöglichen es Benutzern im Gegensatz zu kanonischen Brücken auch, zwischen mehreren Ketten zu wechseln. Hop ermöglicht es Benutzern beispielsweise, zwischen Arbitrum und Optimism zu wechseln, ohne zuerst auf Ethereum abheben zu müssen. Genau wie beim schnellen L2→L1-Bridging erfordert das schnelle L2→L2-Bridging, dass Bonders einen vollständigen Knoten für die Quell-L2-Kette ausführen, um Abhebungen zu bestätigen, bevor die Kosten für die Prägung von Token für einen Benutzer auf der Ziel-L2-Kette vorgezogen werden. Dies ermöglicht eine bessere Zusammensetzbarkeit zwischen Rollups und verbessert die Benutzererfahrung erheblich, da Benutzer Token problemlos zwischen Rollups verschieben können. Liquiditätsbrücken haben jedoch auch Nachteile, die den Nutzen der Verwendung der in einer Kette verankerten Brücke zum Prägen der kanonischen Darstellung eines Tokens auf einer L2/L1-Kette beeinträchtigen. Wir diskutieren die Nachteile der liquiditätsbasierten Brücken im nächsten Abschnitt: Nachteile von Liquiditätsbrücken 1. Schlupf Slippage ist eine Differenz zwischen der Anzahl der erwarteten und der erhaltenen Token bei der Interaktion mit einem AMM. Slippage entsteht, weil AMMs Swaps entsprechend der aktuellen Liquidität in einem Pool bewerten – die Preisgestaltung ist so, dass nach Abschluss eines Swaps das Gleichgewicht zwischen dem Pool-Saldo jedes Vermögenswerts in einem Paar aufrechterhalten wird, was sich zwischen dem Zeitpunkt, an dem ein Benutzer einen Handel initiiert, und der Ausführung des Austauschs ändern kann. Eine geringe Liquidität für überbrückte Vermögenswerte kann auch zu einem höheren Slippage führen. Wenn der Pool nicht über genügend Liquidität verfügt, um eine Seite des Pools auszugleichen, kann ein großer Handel den Preis stark verschieben und dazu führen, dass Benutzer Swaps zu höheren Preisen durchführen. Arbitrageure sollen dabei helfen, Unterschiede zwischen Pools auszugleichen, die mit demselben Vermögenswert handeln. Sie werden jedoch möglicherweise von Arbitragegeschäften mit Token mit geringer Handelsaktivität/niedrigem Wert abgehalten. Dies wirkt sich auch auf Entwickler aus, die kettenübergreifende Anwendungen erstellen, da sie Randfälle berücksichtigen müssen, in denen Slippage auftritt. Der Benutzer kann einen kettenübergreifenden Vorgang nicht abschließen, da er auf einer oder mehreren Zielketten geringere Mengen eines Tokens erhält. Anwendungen wie Bridge-Aggregatoren (die nicht wissen können, ob eine Liquiditätsbrücke über genügend Liquidität verfügt, um einen Swap in der Zielkette ohne Slippage abzudecken) umgehen das Problem, indem sie eine maximale Slippage-Toleranz angeben und diese verwenden, um den Benutzern bereitgestellte Kurse zu informieren. Dies verhindert zwar die Rückgängigmachung von Transaktionen, Benutzer verlieren jedoch immer einen gewissen Prozentsatz des überbrückten Tokens – unabhängig von der Liquidität in den AMM-Pools einer Brücke. 2. Liquiditätsbeschränkungen Eine grundlegende Herausforderung bei Liquiditätsbrücken ist die absolute Notwendigkeit ausreichender Liquidität in der Zielkette. Im Gegensatz zu herkömmlichen Lock-and-Mint-Brücken, bei denen die Token-Prägung direkt durch gesperrte Vermögenswerte abgesichert ist, sind Liquiditätsbrücken auf verfügbare Token in AMM-Pools angewiesen, um kettenübergreifende Übertragungen abzuschließen. Wenn die Liquidität unter kritische Schwellenwerte fällt, kann der gesamte Brückenmechanismus effektiv aufhören zu funktionieren. Wenn die Liquidität zu niedrig wird, kann der Brückenbetrieb ganz zum Erliegen kommen, sodass Benutzer ihre geplanten Überweisungen nicht mehr durchführen können. Um eine Erschöpfung der Poolliquidität zu vermeiden, sind Benutzer möglicherweise gezwungen, große Überweisungen in kleinere Transaktionen aufzuteilen. In Zeiten hoher Volatilität oder Marktstress ziehen sich Liquiditätsanbieter möglicherweise aus den Pools zurück, und zwar genau dann, wenn die Brückenfunktionalität am dringendsten benötigt wird. Das Bootstrapping neuer Token-Paare wird zu einer besonderen Herausforderung, da eine erhebliche anfängliche Liquidität erforderlich ist, um die Brücke betriebsbereit zu machen. Der Liquiditätsbedarf schafft eine zirkuläre Abhängigkeit: Brücken benötigen erhebliche Liquidität, um zuverlässig zu funktionieren, aber um Liquiditätsanbieter anzuziehen, muss eine konsistente Nutzung der Brücke und Gebührengenerierung nachgewiesen werden. Dieses Henne-Ei-Problem ist besonders akut bei neuen oder weniger häufig gehandelten Token, die möglicherweise Schwierigkeiten haben, über mehrere Ketten hinweg ausreichend Liquidität aufrechtzuerhalten. 3. Falsch ausgerichtete Anreize Eine Liquiditätsbrücke ist insofern hilfreich, als sie Swaps von der überbrückten Darstellung zum kanonischen Token in der Zielkette abdecken kann, ohne dass den Benutzern übermäßige Slippage entsteht; die Gaskosten für die Interaktion mit der Brücke bestimmen auch den Wert einer Liquiditätsbrücke aus Sicht eines Benutzers. Daher priorisieren Brückenaggregatoren und Projektteams, die einen Token ausgeben, Brücken basierend auf der Höhe der Liquidität und den Transaktionskosten. Dies stellt zwar sicher, dass Benutzer, die die Token eines Projekts überbrücken oder einen Bridge-Aggregator verwenden, um Token kettenübergreifend zu senden, eine bessere UX haben, aber die Auswahl von Bridges auf der Grundlage der Liquidität benachteiligt Bridges, die nicht für Anreize von Liquiditätsanbietern (LP) ausgeben können. Darüber hinaus verzerrt die Auswahl von Bridges auf der Grundlage reiner Transaktionsgebühren den Wettbewerb zugunsten von Bridges, die einen zentralisierten Ansatz zur Reduzierung der Betriebskosten verfolgen und niedrigere Gebühren für Überbrückungstransaktionen erheben können. In beiden Fällen konkurrieren Bridges nicht in Bezug auf die wohl wichtigste Kennzahl: Sicherheit. Liquiditätsbasierte Brücken benachteiligen auch Long-Tail-Assets mit geringerer Handelsaktivität (wodurch sie weniger wahrscheinlich LPs anziehen). Emittenten von Long-Tail-Token (oder neuen Token mit geringen Überbrückungsvolumina) müssen entweder AMM-Pools einrichten und Liquidität bereitstellen, um Swaps nativer Token (überbrückt über eine Liquiditätsbrücke) gegen die kanonische Darstellung des Tokens des Emittenten abzudecken, oder mit Brückenbetreibern zusammenarbeiten, um die finanziellen Anreize für LPs zu erhöhen, Liquidität für diesen Vermögenswert bereitzustellen. 4. Schlechte Überbrückungs-UX Liquiditätsbrücken sind eine Verbesserung gegenüber kanonischen Brücken, sind aber auch nicht ohne UX-Probleme. Neben anhaltendem Slippage bei Cross-Chain-Swaps können Benutzer möglicherweise eine Überbrückungstransaktion nicht sofort auf der Zielkette abschließen, da die Brücke nicht über genügend Poolliquidität verfügt, um den Handel mit dem kanonischen Token auf der Zielkette abzudecken. Brücken können nicht wissen, wie viel Liquidität für ein Asset-Paar vorhanden sein wird, wenn die Nachricht eines Benutzers zum Tauschen von Token die Zielkette erreicht, sodass dieser Grenzfall größtenteils unvermeidbar ist. Benutzer haben in dieser Situation zwei Möglichkeiten (beide nicht optimal): . Dies ist aufgrund der Verzögerung bei Überbrückungstransaktionen nicht optimal und weil ein Benutzer nicht wissen kann, ob er die gleiche Anzahl an Token erhält, die ursprünglich angegeben wurde, da sich die Poolliquidität in sehr kurzen Zeiträumen beliebig ändern kann. Warten Sie, bis die Brücke über genügend Liquidität verfügt, um den Tausch abzuschließen und kanonische Token abzuheben . Dies ist nicht optimal, da die meisten Anwendungen die Integration mit der kanonischen Darstellung eines nativen Tokens (z. B. opUSDT, geprägt von der Optimism Bridge) bevorzugen und das gepackte Asset des Benutzers möglicherweise nicht akzeptieren. Erhalten Sie die proprietäre Token-Darstellung der Brücke (z. B. hUSDT für Hop Bridge) 2. Prägen Sie kanonische Token über eine kanonische Drittanbieterbrücke Eine Multi-Chain-Dapp kann das Problem nicht fungibler Bridge-Token umgehen, indem sie eine Bridge auswählt, um kanonische Darstellungen des Tokens der Dapp auf jeder Chain zu prägen, auf der die Dapp eingesetzt wird. Wie bei kanonischen Bridges, die genehmigte Darstellungen des Tokens eines Projekts prägen, erfordert dieser Ansatz die Zuordnung von auf Remote-Chains geprägten Token zum Token-Vertrag, der auf der Home-Chain des Projekts eingesetzt wird – um sicherzustellen, dass die Token-Versorgung weltweit gleich bleibt. Der Bridge-Anbieter muss das Prägen und Brennen eines Tokens verfolgen und sicherstellen, dass die Präge- und Brennvorgänge mit der Token-Versorgung auf der Home-Chain synchronisiert bleiben. einzelne Die Verwendung eines einzigen Bridge-Anbieters bietet Projektteams mehr Flexibilität, insbesondere da Drittanbieter-Bridges dazu motiviert werden, die Überbrückung zwischen einer größeren Bandbreite von Ökosystemen zu unterstützen, im Vergleich zu kanonischen Bridges, die nur eine Verbindung zu höchstens einer Kette herstellen. Wenn auf allen Ketten, auf denen eine Anwendung bereitgestellt wird, eine Bridge vorhanden ist, können Benutzer schnell zwischen Ketten wechseln, ohne sich zur Heimatkette zurückziehen zu müssen. Ein Bridge-Anbieter muss lediglich sicherstellen, dass die auf Zielkette A geprägten Token verbrannt werden, bevor ein Benutzer Token auf Zielkette B prägt, und kanonische Token auf Kette B dem Token auf der Heimatkette (neu) zugeordnet werden. Das Problem nicht fungibler Bridged-Token wird ebenfalls eliminiert; vorausgesetzt, Benutzer nutzen den Bridge über den zugelassenen Bridge-Anbieter, können sie diese immer 1:1 gegen andere Bridged-Token austauschen. Dieser Ansatz behebt außerdem die Probleme des liquiditätsbasierten Bridgings im kanonischen Bridge-Modell: Benutzer leiden bei Bridge-Transaktionen nicht unter Slippage, da der Bridge-Anbieter seine Darstellung nicht über ein AMM in eine kanonische Darstellung umwandeln muss – das Token des Bridge-Anbieters ist die kanonische Darstellung des überbrückten Tokens in jeder Domäne. Der Wert dieser Darstellungen ist an den Wert der Token gekoppelt, die vom Bridge-Anbieter in der nativen Kette des Tokens gesperrt wurden. Für Benutzer treten beim Überbrücken kaum oder gar keine Verzögerungen auf, da der Brückenanbieter verpackte Darstellungen in der Zielkette prägen kann, unmittelbar nachdem die mint()-Nachricht am Ziel eintrifft. Entwickler können die Verwaltung von Multi-Chain-Token-Bereitstellungen an Brückenbetreiber auslagern, ohne sich um das Bootstrapping von AMM-Liquidität oder Anreizprogramme zur Liquiditätsbereitstellung kümmern zu müssen. Einige Beispiele für Token von einem einzigen Bridge-Provider sind LayerZeros Omnichain Fungible Token (OFT), Axelars Interchain Token Service (ITS), Celers xAsset und Multichains anyAsset. Bei allen Beispielen handelt es sich im Wesentlichen um proprietäre Token, die nicht mit den Darstellungen desselben Tokens kompatibel sind, die über einen anderen Bridge-Provider gesendet werden. Dieses subtile Detail verdeutlicht einige Probleme bei diesem Ansatz zur Handhabung von Bridge-Token. Und zwar die folgenden: Lieferantenbindung Verlust der Souveränität Hohes Risiko von Brückeneinstürzen Verlust der benutzerdefinierten Funktionen des Tokens auf den Zielketten Beschränkung auf vom Anbieter unterstützte Ketten Unfähigkeit, die gleiche Token-Adresse auf allen gewünschten Ketten beizubehalten, was die Benutzersicherheit gefährden oder sie anfällig für Phishing machen kann Nachteile der Verwendung kanonischer Drittanbieter-Brücken 1. Anbieterabhängigkeit Die Auswahl eines einzigen Bridge-Anbieters zur Prägung kanonischer Darstellungen auf einer oder mehreren Ketten setzt Entwickler dem Risiko einer Anbieterbindung aus. Da jeder Bridge-Anbieter eine proprietäre Darstellung prägt, die nur mit seiner Infrastruktur (und integrierten Ökosystemprojekten) kompatibel ist, bindet das Modell mit einem einzigen Bridge-Anbieter einen Token-Emittenten effektiv an einen bestimmten Bridging-Dienst, ohne die Möglichkeit, in Zukunft zu einer anderen Bridge zu wechseln. Es ist möglich, den Bridge-Anbieter zu wechseln, aber die Wechselkosten sind so hoch, dass die meisten Projekte davon abgehalten werden, diesen Weg zu gehen. Um eine grobe Vorstellung zu geben, nehmen wir an, ein Entwickler (den wir Bob nennen) hat einen Token (BobToken) auf Ethereum herausgegeben und wählt LayerZero OFT, um kanonische Versionen von BobToken auf Optimism, Arbitrum und Base zu prägen. BobToken hat einen festen Vorrat von 1.000.000 Token, und über LayerZero geprägte Bridge-Token machen 50 % des gesamten Vorrats an im Umlauf befindlichen BobTokens aus. Die Geschäftsvereinbarung läuft reibungslos, bis Bob entscheidet, dass Benutzer besser dran sind, BobTokens über einen konkurrierenden Brückendienst (z. B. Axelar) zu überbrücken. Bob kann jedoch nicht einfach sagen: „Ich wechsle zu Axelar ITS, um kanonische Darstellungen von BobToken auf Optimism, Base und Arbitrum zu prägen“; da OFT-Token und ITS-Token inkompatibel sind, riskiert Bob, sowohl alten als auch neuen Benutzern Kopfschmerzen zu bereiten, da zwei BobTokens möglicherweise nicht fungibel sind (was das zuvor beschriebene Problem erneut aufwirft). Darüber hinaus können Anwendungen, die in die BobToken-Version von LayerZero integriert sind, die BobToken-Version von Axelar nicht als Ersatz akzeptieren – was die Liquidität für BobToken auf verschiedenen Ketten fragmentiert, auf denen konkurrierende Darstellungen von BobToken koexistieren. Um den Übergang zu ermöglichen, muss Bob die Benutzer davon überzeugen, die über LayerZero geprägten BobToken-Darstellungen zu entpacken, indem er eine Transaktion sendet, die überbrückte OFT-Token verbrennt und BobTokens auf Ethereum freischaltet. Benutzer können nun zur neuen kanonischen Darstellung von BobToken wechseln, indem sie Token mit Axelar auf Ethereum sperren und kanonische BobTokens (die dem Angebot des Token-Vertrags auf Ethereum zugeordnet sind) auf der Zielkette empfangen. Dies ist sowohl kostenintensiv als auch mit einem enormen Koordinations- und Betriebsaufwand für die Projektmanagementteams von DAOs verbunden, sodass es normalerweise die sicherste Option ist, beim gewählten Anbieter zu bleiben. Dies bringt Entwickler wie Bob jedoch in eine problematische Lage, da die Abhängigkeit vom Anbieter einen Wechsel unmöglich macht, wenn ein Bridge-Anbieter die Vertragsbedingungen nicht einhält, nur über eine begrenzte Funktionspalette verfügt, keine umfassenden Ökosystemintegrationen bietet, eine schlechte UX bietet usw. Außerdem bietet es Bridges nahezu unbegrenzte Einflussmöglichkeiten: Der Bridge-Anbieter kann beliebige Dinge tun, wie beispielsweise die Rate der Benutzer, die BobTokens überbrücken, ohne ersichtlichen Grund begrenzen, die Bridge-Gebühren erhöhen oder sogar Bridge-Operationen zensieren. In diesem Fall sind Bob die Hände gebunden, da ein sauberer Bruch mit einer fehlerhaften kanonischen Drittanbieter-Bridge genauso komplex ist wie die Aufrechterhaltung der Geschäftsbeziehung. 2. Verlust der Protokollsouveränität Der abschließende Teil des vorherigen Abschnitts zur Anbieterbindung hebt ein weiteres Problem bei der Verwendung einer kanonischen Drittanbieterbrücke hervor: Token-Emittenten tauschen die Kontrolle über kanonische überbrückte Token gegen mehr Komfort und UX-Verbesserungen ein. Um das vorherige Beispiel zu verwenden: BobToken auf Ethereum liegt vollständig unter Bobs Kontrolle, da er den zugrunde liegenden ERC-20-Token-Vertrag kontrolliert, aber BobToken auf Optimism, Arbitrum und Base werden von LayerZero kontrolliert, dem der OFT-Vertrag gehört, der kanonische Darstellungen von BobToken auf diesen Blockchains ausgibt. Bob erwartet zwar, dass LayerZero kanonische Darstellungen mit dem ursprünglichen Design des nativen Tokens in Einklang bringt, dies ist jedoch möglicherweise nicht immer der Fall. Im schlimmsten Fall kann das Verhalten von BobToken auf Ethereum erheblich von dem von BobToken auf Optimism abweichen, da der Bridge-Anbieter eine radikal andere Version des Token-Vertrags implementiert, was zu Problemen für die Benutzer des Protokolls führt. Dieses Problem kann auch durch Prinzipal-Agent-Dynamik verschärft werden, bei der die Ziele und Interessen eines Protokolls und des Bridge-Anbieters auseinander gehen. 3. Hohes Risiko von Brückeneinstürzen Beim ersten Ansatz, bei dem Token über die kanonische Brücke jeder Kette kettenübergreifend übertragen werden, ist das Risiko für den Token-Emittenten durch einen Exploit, der eine Brücke betrifft, auf diese Brücke beschränkt. Nehmen wir beispielsweise an, ein Hacker schafft es, eine Liquiditätsbrücke zu kompromittieren und unendlich viele verpackte Token zu prägen, ohne Sicherheiten zu hinterlegen. In diesem Fall kann er nur bis zur maximalen Liquidität abheben, die für den verpackten Vermögenswert in Liquiditätspools verfügbar ist (z. B. Prägen von cUSDT auf Optimism → Tausch von cUSDT gegen kanonisches opUSDT → Abheben von opUSDT auf Ethereum über eine schnelle Brücke → Tausch gegen natives USDT auf Ethereum). Im Modell der kanonischen Brücke eines Drittanbieters entspricht das Risiko für einen Token-Herausgeber durch einen Exploit, der die Partnerbrücke betrifft, der Gesamtmenge an Token, die ein Angreifer auf Remote-Ketten prägt, auf denen die betroffene Brücke eine Bereitstellung hat. Dies ist möglich, weil jede kanonische Darstellung auf allen Ketten 1:1 gegen kanonische Token ausgetauscht werden kann, die auf anderen Ketten ausgegeben wurden: Angenommen, ein Angreifer kompromittiert eine Drittanbieterbrücke in Kette B und prägt 1000 Token (wobei der Token zunächst in Kette A ausgegeben wird), ohne Sicherheiten zu hinterlegen. Die Token des Angreifers in Kette B sind nicht dem Home-Chain-Vertrag zugeordnet, sodass er nicht von Kette A abheben kann. Er kann jedoch eine Brücke zu Kette C bauen und 1000 Token der Kette B gegen 1000 Token der Kette C tauschen – denken Sie daran, dass jeder Cross-Chain-Token kompatibel und fungibel ist, da sie vom selben Brückendienst stammen. Die Token der Kette C sind dem Home-Chain-Vertrag zugeordnet, da sie rechtmäßig von Benutzern geprägt wurden, die Token in Kette A (der Home-Chain des Tokens) gesperrt haben, wodurch der Angreifer Token in Kette C vernichten und native Token in Kette A abheben und den Vorgang möglicherweise abschließen kann, indem er die Token über eine CEX- oder Fiat-Offramp austauscht. 4. Verlust benutzerdefinierter Token-Funktionen Bei Verwendung einer kanonischen Drittanbieterbrücke verlieren Token-Emittenten häufig die Möglichkeit, benutzerdefinierte Funktionen oder Token-Verhaltensweisen zu implementieren, die in ihrer ursprünglichen Bereitstellung vorhanden sind. Dies liegt daran, dass Bridge-Anbieter dazu neigen, standardisierte ERC-20-Implementierungsverträge zu verwenden, die möglicherweise keine speziellen Funktionen unterstützen, die in der ursprünglichen Token-Implementierung vorhanden sind. Gängige Token-Funktionen wie Stimmrechtsdelegation (ZK), Rebasing-Mechanismen (stETH, USDM), Gebühren-bei-Übertragungs-Funktionen (Memecoins), Blacklisting- und Whitelisting-Funktionen (USDT, USDC), pausierbare Übertragungen und spezielle Prägeregeln oder -berechtigungen werden häufig entfernt, wenn Token über einen Drittanbieter überbrückt werden, da die überbrückte Version normalerweise eine grundlegende ERC-20-Implementierung verwendet. Dieser Funktionsverlust führt zu Inkonsistenzen in der Funktionsweise des Tokens über verschiedene Ketten hinweg und kann möglicherweise Integrationen beschädigen, die von diesen benutzerdefinierten Funktionen abhängen. Die Standardisierung von Bridged Tokens ist zwar aus Sicht des Bridge-Anbieters einfacher, reduziert aber effektiv die Fähigkeiten des Tokens und kann die Fähigkeit des Herausgebers beeinträchtigen, ein konsistentes Token-Verhalten über das gesamte Multi-Chain-Ökosystem seiner Anwendung hinweg aufrechtzuerhalten. Solche Probleme können Cross-Chain-Erweiterungen zu einem Albtraum für Entwickler machen und ein Hindernis für die Verwirklichung des Traums von Apps darstellen, die auf mehreren Chains leben. 5. Begrenzte unterstützte Ketten Token-Emittenten werden abhängig von der Netzwerkabdeckung und den Expansionsplänen ihres gewählten Bridge-Anbieters. Wenn der Bridge-Anbieter ein bestimmtes Blockchain-Netzwerk, in das der Token-Emittent expandieren möchte, nicht unterstützt, stehen sie vor zwei suboptimalen Entscheidungen: Warten Sie, bis der Bridge-Anbieter Unterstützung für die gewünschte Kette hinzufügt. Dies kann lange dauern oder aufgrund der hohen Integrationskosten nie passieren (z. B. die EVM-Inäquivalenz von ZKsync Era, die dazu geführt hat, dass viele Dapps nie darauf bereitgestellt wurden). Verwenden Sie für diese spezifische Kette einen anderen Bridge-Provider, was das Problem der nicht fungiblen Token und der Liquiditätsfragmentierung erneut aufwirft Diese Einschränkung kann die Wachstumsstrategie eines Protokolls und die Fähigkeit, neue Benutzer auf neu entstehenden Ketten zu erreichen, erheblich beeinträchtigen. Bridge-Anbieter können die Unterstützung beliebter Ketten priorisieren und dabei kleinere oder neuere Netzwerke vernachlässigen, die für den Token-Emittenten strategisch wichtig sein könnten. 6. Inkonsistente Cross-Chain-Token-Token-Adressen Drittanbieter von Bridges können Bridge-Token mit unterschiedlichen Adressen auf jeder Kette einsetzen, da ihr Technologie-Stack Besonderheiten aufweist – z. B. keine Unterstützung für . Die fehlende Adresskonsistenz führt wiederum zu vielen UX-Problemen: CREATE2 : Benutzer müssen in jeder Kette unterschiedliche Token-Adressen verifizieren, was das Risiko der Interaktion mit betrügerischen Token erhöht; Sicherheitsrisiken : Entwickler müssen für jedes Netzwerk Listen mit gültigen Token-Adressen pflegen; Integrationskomplexität : Böswillige Akteure können Benutzer leichter mit gefälschten Token täuschen, da keine konsistente Adresse zum Abgleich vorhanden ist. Erhöhtes Phishing-Risiko Diese Nachteile, kombiniert mit den zuvor diskutierten Problemen der Anbieterabhängigkeit, des Souveränitätsverlusts und der hohen Anfälligkeit für Brückenausfälle, unterstreichen die erheblichen Einschränkungen, die sich aus der Nutzung kanonischer Drittanbieterbrücken für die Bereitstellung von Cross-Chain-Token ergeben. Dieses Verständnis hilft dabei, die Grundlage dafür zu schaffen, warum alternative Lösungen wie ERC-7281 erforderlich sind, um diese Herausforderungen umfassender anzugehen. 3. Prägen Sie kanonische Token über die Token-Emittentenbrücke Wenn ein Entwickler die maximale Kontrolle über die kettenübergreifende Bereitstellung des Tokens eines Projekts behalten möchte, kann er die Ausgabe kanonischer Darstellungen des Tokens auf Remote-Ketten verwalten. Dies wird als „Vertrauen dem Token-Herausgeber“ bezeichnet, da der Wert jeder überbrückten Darstellung des Tokens an Token gebunden ist, die durch das Protokoll, das für die Ausgabe der Originalversion des Tokens auf der Quellkette verantwortlich ist, auf der Heimatkette des Tokens gesperrt sind. Damit dieser Ansatz funktioniert, muss der Token-Emittent eine Infrastruktur einrichten, um das Prägen und Verbrennen von überbrückten Token kettenübergreifend zu verwalten (und gleichzeitig sicherzustellen, dass das globale Angebot über kanonische Zuordnung synchron bleibt). Bemerkenswerte Beispiele für kanonische Darstellungen eines vom Token-Ersteller ausgegebenen Tokens sind und von Circle. Teleport von MakerDAO das Cross-Chain Transfer Protocol (CCTP) Teleport ermöglicht es Benutzern, kanonische DAI zwischen Ethereum und verschiedenen Ethereum-Rollups über Fast-Path- und Slow-Path-Operationen zu verschieben. DAI wird auf einer Kette verbrannt und auf der Zielkette geprägt. CCTP funktioniert ähnlich und ermöglicht kettenübergreifende Übertragungen von nativem USDC (herausgegeben von Circle) über einen Burn-and-Mint-Mechanismus. In beiden Fällen kontrolliert der Token-Emittent das Prägen und Brennen kanonischer Darstellungen eines Tokens. Dieser Ansatz bietet vollständige Kontrolle über überbrückte Token für Protokolle. Und er behebt das Problem nicht fungibler Darstellungen desselben Tokens auf die effektivste Art und Weise – es gibt nur eine kanonische Version des Tokens (vom Emittenten in der Zielkette geprägt), was sicherstellt, dass Benutzer bei der Verwendung eines Tokens in jedem vom Token-Emittenten unterstützten Ökosystem die gleiche Erfahrung machen. Mit diesem Ansatz profitieren Anwendungen auch von der Beseitigung der Liquiditätsfragmentierung, die durch inoffizielle, überbrückte Darstellungen des Tokens eines Protokolls verursacht wird, das im selben Ökosystem schwebt. Entwickler können auch robustere Cross-Chain-Anwendungen erstellen (z. B. Cross-Chain-Swaps und Cross-Chain-Lending), da kanonische Token-Emittentenbrücken eine kapitaleffiziente, nahtlose und sichere Bewegung von Token zwischen Ketten ermöglichen. Der Nachteil kanonischer Token-Emittentenbrücken besteht jedoch darin, dass dieses Modell nur für Projekte mit genügend Kapital machbar ist, um den Aufwand für die Bereitstellung eines Tokens über mehrere Ketten hinweg und die Wartung der Infrastruktur (Orakel, Keeper usw.) abzudecken, die für die Durchführung der kettenübergreifenden Prägung und Verbrennung erforderlich ist. Dies hat auch den etwas unerwünschten Effekt, dass die Sicherheit der überbrückten Vermögenswerte eng mit dem Sicherheitsmodell des Protokolls verknüpft ist. Diese Beziehung (zwischen überbrückten Versionen der Token eines Protokolls und der Sicherheit des Protokolls) ist einvernehmlich, da die Sicherheit nativer Token, die kanonische Darstellungen unterstützen, bereits von der Sicherheit des Protokolls abhängt, sodass Benutzer und externe Entwickler keine neuen Vertrauensannahmen treffen müssen. Dies gilt insbesondere für die von Emittenten wie Circle und Maker (jetzt Sky) betrieben werden – Benutzer vertrauen bereits darauf, dass Stablecoin-Emittenten über genügend Vermögenswerte verfügen, um die Einlösung von Stablecoins gegen Fiat-Währungen abzudecken, sodass es nicht schwierig ist, der Sicherheit einer Stablecoin-Brücke zu vertrauen. Stablecoin-Brücken, Es stellt aber auch einen zentralen Fehlerpunkt dar – wenn die Brückeninfrastruktur des Token-Emittenten kompromittiert wird, ist der Wert aller kanonischen Darstellungen, die im Multi-Chain-Ökosystem zirkulieren, in Gefahr. Dies bedeutet auch, dass nur zentralisierte Verwahrer (z. B. Circle im Fall von USDC) dieses Modell der Ausgabe kanonischer Bridged-Token implementieren können. Abschließende Gedanken Wie in diesem Bericht gezeigt, ist die kettenübergreifende Fungibilität von Vermögenswerten ein wichtiger Teil der Rollup-Interoperabilität mit Auswirkungen auf die Erfahrung beim Wechsel zwischen verschiedenen Ketten. Die Fähigkeit von Token, fungibel zu bleiben, wenn sie mit Remote-Ketten verbunden werden, wirkt sich auch auf die Entwicklererfahrung aus, da bestimmte Anwendungsfälle von dieser Funktion abhängen. Es wurden verschiedene Lösungen vorgeschlagen, um das Problem der nicht fungiblen Cross-Chain-Token zu lösen – viele davon haben wir in diesem Bericht behandelt. Dazu gehört das Prägen kanonischer Token über native (verankerte) Brücken, die Verwendung einer dedizierten Drittanbieterbrücke zum Prägen kanonischer Token über mehrere Ketten hinweg und die Verwendung einer protokolleigenen Brücke, um die Bewegung von Token zu erleichtern und die Fungibilität zu wahren. Diese Ansätze lösen zwar bestimmte Probleme, gehen aber nicht auf alle Probleme ein. Ihre Verwendung zur Ermöglichung der kettenübergreifenden Fungibilität von Vermögenswerten erfordert einige unerwünschte Kompromisse. Können wir einen besseren Ansatz finden? Die Antwort lautet ja. ERC-7281 ist ein neuer Ansatz für die kettenübergreifende Fungibilität von Vermögenswerten, der die mit bestehenden Ansätzen verbundenen Kompromisse abmildert. ERC-7281, auch als bekannt, ermöglicht Protokollen die effiziente Bereitstellung kanonischer Token auf mehreren Ketten, ohne Kompromisse bei Sicherheit, Souveränität oder Benutzererfahrung einzugehen. xERC-20 Das einzigartige Design von ERC-7281 ermöglicht es mehreren (auf der Whitelist aufgeführten) Brücken, kanonische Versionen der Token eines Protokolls auf jeder unterstützten Kette zu prägen, während Protokollentwickler die Prägegrenzen dynamisch auf Brückenbasis anpassen können. Diese Funktion löst viele der Probleme, die mit früheren Vorschlägen für kanonische Multichain-Token verbunden sind – darunter Liquiditätsfragmentierung, Anreizausrichtung, UX-Bedenken, Brückensicherheitsrisiken, Anpassbarkeit (von Cross-Chain-Token) und mehr. Der nächste – und letzte – Teil unseres zweiteiligen Berichts zur kettenübergreifenden Fungibilität von Vermögenswerten wird sich ausführlich mit ERC-7281 befassen und untersuchen, wie Entwickler und Benutzer vom xERC-20-Token-Standard profitieren können. Wir werden ERC-7281 mit anderen Designs für kanonische Multichain-Token vergleichen, den Ansatz von xERC-20 für kanonische Multichain-Token untersuchen und Überlegungen für Protokolle und Entwickler hervorheben, die auf dem Standard aufbauen möchten. Bleiben Sie dran! Anmerkung des Autors: Eine Version dieses Artikels wurde ursprünglich veröffentlicht. hier