Indledning

Den modulære maxis siger, at fremtiden for krypto er en million (eller flere) indbyrdes forbundne domæner, og brugere, der hopper mellem blockchains som Alice, der vandrer gennem Wonderland. Hvorfor holde sig til én kæde, hvis du kan få adgang til avanceret teknologi, nye applikationer, moonshot-afkast på staking/likviditetsforsyning, høj ydeevne og ultralave transaktionsgebyrer på andre blockchains?

Men at flytte mellem blockchains er meget mere kompliceret end Alices tur gennem Wonderland, primært på grund af begrænsninger, der ligger i de nuværende tilgange til blockchain-interoperabilitet (f.eks. cross-chain-broer). Især tværkædede broer i dag er enten usikre ($2.5B+ tabt i bridge hacks), langsomme, dyre eller begrænsede i funktionalitet – eller viser en blanding af egenskaber fra listen.

Andre problemer, der plager brobygningsindustrien, er mere subtile, men stadig nok til at forvandle den modulære maxis drøm om et flerkædet økosystem til et mareridt for brugere og udviklere - et eksempel på dette er, hvordan fungible tokens (som ERC-20'er) bliver ikke-fungible når den er brokoblet til forskellige kæder via forskellige protokoller på tværs af kæder og dermed skader dets funktioner som et overførbart aktiv. I denne artikel vil vi undersøge en løsning, der søger at bevare tokens fungibilitet på tværs af kæder, uanset hvor en tokens oprindelseskontrakt findes: ERC-7281: Sovereign-Bridged Tokens.

ERC-7281 udvider ERC-20 – de facto-standarden for at skabe fungible tokens i Ethereum – for at muliggøre prægning og brænding af kanoniske repræsentationer af ERC-20-tokens på fjerntliggende domæner af flere broer, der er godkendt af token-udstedere. Dette sikrer, at brugere, der brobygger et ERC-20-token, modtager fungible versioner af tokenet på destinationen (dvs. to tokens kan udveksles 1:1), selv når tokens sendes på tværs af kæden via forskellige ruter/broer. Det er vigtigt, at protokoller, der vedtager ERC-7281, opretholder kontrol over brokoblede tokens (i modsætning til status quo, hvor broen kontrollerer et brokoblet token) og kan hastighedsbegrænse udmøntningsoperationer for at reducere eksponeringen i tilfælde af en brofejl.

Lad os bruge USDC som et eksempel på infungibilitet blandt i teorien identiske ERC-20-tokens på tværs af forskellige kæder. I Ethereum Layer 2 (L2) netværk , såsom Arbitrum, Base, Optimism, er det almindeligt at bruge den kanoniske bro til at flytte populære ERC-20 tokens fra Ethereum L1 til disse kæder. Disse versioner af L1-oprindende L2-tokens kaldes almindeligvis bare "brokoblede [indsæt tokennavn]."

I tilfælde af USDC er de almindelige symboler USDC.e, USDC.b og så videre. Over tid udvider Circle sine USDC-udrulninger til andre kæder, inklusive L2s, hvor USDC allerede er live via den kanoniske bro. Selvom disse to tokens er præget af den samme enhed og har samme pris, er de teknisk forskellige, infungible tokens, og er derfor ikke "interoperable" - mens native USDC kan bygges bro via Circles CCTP-bro, kan den brokoblede USDC kun være bro tilbage til L1 via den kanoniske bro.

ERC-7281 løser dette ved at introducere en ERC-20-udvidelse, hvor deployerne af tokenet kan tildele og parametrisere forskellige kilder til brodannelse til det. I eksemplet ovenfor kunne Circle implementere et universelt USDC-token på alle L2'er, hvor de kanoniske broer (f.eks. Circle Mint, Circle CCTP og andre godkendte broer) alle er tildelt som i stand til at præge tokens i henhold til deres logik. For at minimere risikoen for, at myntere bliver hacket, kan deployeren begrænse, hvor mange tokens hver mynter kan præge og brænde i den specifikke tidsperiode – med mere pålidelige broer, såsom den kanoniske L2, der har højere grænser, og broer med centraliseret konsensus lavere.

Selvom ERC-7281 ikke er det første forsøg på at skabe ombyttelige tokens på tværs af kæder, løser den problemer forbundet med tidligere forslag – såsom leverandørlåsning, tab af suverænitet for tokenudstedere, høje omkostninger ved bootstrapping af likviditet til brokoblede tokens, infrastruktur overhead og øget eksponering for brofejl.

Denne todelte rapport vil undersøge begrundelsen for at introducere en suverænt brokoblet token-standard og give et omfattende overblik over ERC-7281-specifikationen (også kendt som xERC-20). Vi vil også diskutere de positive fordele og potentielle ulemper ved at implementere ERC-7281 for brugere, udviklere, infrastrukturudbydere og andre aktører i Ethereum-økosystemet.

En genopfriskning af blockchain-broer

Før du dykker ned i problemet med ikke-fungible broede tokens, hjælper det at forstå, hvorfor broede tokens eksisterer i første omgang. Dette kræver til gengæld forståelse for motivationen for og driften af blockchain-broer - da brooperatører er dem, der er ansvarlige for at skabe brokoblede token-versioner.

En bro er en mekanisme til at overføre information mellem blockchains . Udover rent monetær information kan broer videregive enhver nyttig information såsom token-satser og smart kontrakttilstand på andre kæder. Imidlertid er overførsel af aktiver (tokens) fra en kæde til en anden den mest almindelige brugssag for brugere, der interagerer med en bro i dag.

Tilgange til at lette overførsler af aktiver på tværs af kæder varierer, men token-bro-workflows følger normalt et af tre mønstre på højt niveau:

Låse- og møntbroer

• En bruger ønsker at bygge bro mellem et token fra sin oprindelige eller "hjemme"-kæde (hvor det oprindeligt blev udstedt) til en anden kæde. De to blockchains er ikke interoperable, da hver kæde implementerer forskellige arkitekturer og protokoldesign, som forhindrer brugeren i at overføre tokens direkte fra en tegnebogsadresse i kæde A til en tegnebogsadresse i kæde B.

• Brooperatøren deponerer tokens deponeret af brugeren på oprindelseskæden i en smart kontrakt og skaber en "indpakket" repræsentation af det oprindelige token via en token-kontrakt, der er implementeret i målkæden.

• Når brugeren ønsker at bygge bro i den modsatte retning (destinationskæde → oprindelseskæde), returnerer de de indpakkede tokens til broen på destinationskæden, som verificerer dette i henhold til logikken i broen (f.eks. ZK-beviser eller et eksternt kvorum) og frigiver de originale tokens fra escrow på hjemmekæden.

  
  

Brænd og mint broer

• I stedet for at låse tokens i deponering, brænder (ødelægger) denne tilgang tokens på kildekæden;

• Broen præger derefter en tilsvarende mængde på destinationskæden;

• Til den omvendte tur brændes de broforbundne tokens på destinationskæden, før nye tokens præges på kildekæden;

• Dette fastholder den samlede token-forsyning, mens det muliggør overførsler på tværs af kæder.

  
  

Atombytte

• Denne tilgang udveksler direkte aktiver i kildekæden med aktiver i destinationskæden med en anden part.
• Atomic swaps fungerer via gensidigt låsende fonde med samme hemmelige værdi for at låse dem op, hvilket betyder, at hvis hemmeligheden blev afsløret på nogen side, kan den også afsløres på den anden side. Dette giver swappene atomicitetsegenskaben.
• Atomicitet betyder, at byttet enten fuldføres fuldt ud (på begge sider) eller slet ikke, hvilket forhindrer svindel eller delvise/mislykkede overførsler.

Den første tilgang (lås og mynte) er i øjeblikket den mest almindelige. Ækvivalensen i værdi mellem et indfødt token og dets tilsvarende indpakkede repræsentation præget af en bro er det, der giver brugerne mulighed for at "overføre" aktiver på tværs af kæder og bruge et token på en separat kæde, fra hvor det oprindeligt blev udstedt.

Nye designs – såsom hensigtsbaseret brobygning – er dog blevet ret populære. "Intents" giver brugerne mulighed for at udtrykke ønskede resultater for transaktioner ("swap 100 USDC for 100 DAI") i stedet for at skitsere specifikke trin for at opnå resultater. Hensigter er dukket op som en kraftfuld UX-oplåsning, da de i høj grad forenkler onchain-oplevelsen for folk og gør krypto lettere at bruge, især når de er parret med kædeabstraktionsløsninger .

Hensigter på tværs af kæder giver brugerne mulighed for at overføre tokens mellem kæder uden at bekymre sig om den underliggende kompleksitet af brodannelse. I hensigtsbaserede broer indsætter brugere midler på kildekæden og angiver deres ønskede resultat på destinationskæden (deres "hensigt"). Specialiserede operatører kaldet "fillers" eller "solvers" kan opfylde denne hensigt ved at sende de anmodede tokens til brugeren på destinationskæden på forhånd. Operatørerne beviser derefter, at overførslen fandt sted for at kræve de låste midler på kildekæden som refusion.

Nogle formålsbaserede broer udnytter låse-og-mynte-mekanismer under motorhjelmen. I dette tilfælde præger broen indpakkede tokens, der sendes enten til fylderen, der opfyldte brugerens hensigt – eller direkte til brugeren, hvis ingen fyldstof trådte ind. Mens hensigtsbaserede broer tilføjer et ekstra lag af effektivitet gennem deres solvernetværk, de stadig grundlæggende stole på de samme principper som traditionelle låse-og-mynte broer.

Vi kan tænke på hvert indpakket token, uanset om det er skabt gennem traditionel eller hensigtsbaseret brobygning, som en IOU fra brooperatøren, der lover at frigive et beløb af det underliggende token fra deponeringskontrakten. Værdien af disse indpakkede aktiver korrelerer direkte med brooperatørens (opfattede) kapacitet til at behandle anmodninger fra indehavere om at trække native tokens deponeret på tokenets hjemmekæde.

Broen, der er autoriseret til at låse de underliggende tokens på kildekæden og præge deres indpakkede repræsentationer på destinationskæden, sikrer, at tokenets samlede forsyning forbliver konstant. For én enhed af det underliggende token præges nøjagtig én enhed af det tilsvarende indpakkede token, og omvendt. Hvis en applikation accepterer et indpakket token som et udvekslingsmedium eller bruger indpakkede aktiver som valuta, stoler applikationens udviklere og brugere på, at broudbyderen sikrer de "rigtige" aktiver, der understøtter det indpakkede token.

Hvorfor har vi brug for broer?

Muligheden for at handle med en syntetisk version af et aktiv på en ekstern kæde – aktiveret af broer, der skaber repræsentationer af aktivet – er en kraftfuld funktion og giver både udviklere og brugere mulighed for at udnytte fordelene ved interoperabilitet på tværs af kæder. Nogle af disse fordele inkluderer adgang til mere likviditet, eksponering for nye brugere og fleksibilitet for brugere (som kan interagere med yndlingsapps fra forskellige kæder uden friktion).

For bedre at forstå, hvordan dette fungerer i praksis, og hvorfor det betyder noget for både udviklere og brugere, lad os undersøge et konkret eksempel ved hjælp af en fiktiv decentraliseret udveksling kaldet BobDEX. Dette eksempel vil demonstrere, hvordan indpakkede tokens muliggør udvidelse på tværs af kæder og fremhæver både fordele og potentielle komplikationer, der kan opstå:

BobDEX er en Automated Market Maker (AMM)-børs, som Bob oprettede på Ethereum for at muliggøre tillidsløse swaps mellem forskellige aktiver. BobDEX har et indbygget token, $BOB, der fungerer som et governance-token og et LP-belønningstoken. I sidstnævnte tilfælde udsteder BobDEX BOB-tokens til likviditetsudbydere (LP'er), hvilket giver brugere, der leverer likviditet til en pulje, ret til en procentdel af gebyrer betalt af DEX-brugere, der bytter aktiver indsat i puljen.

BobDEX's markedsandel er vokset betydeligt, men Ethereum L1's begrænsninger hindrer yderligere vækst. For eksempel ønsker nogle brugere ikke at bruge BobDEX på Ethereum på grund af høje gasgebyrer og transaktionsforsinkelser; på samme måde ønsker andre brugere eksponering for prisen på $BOB-tokens uden at skulle have native $BOB-tokens på Ethereum.

For at løse problemet implementerer Bob en version af BobDEX på Arbitrum (en lav-fee, high-throughput Layer 2 (L2) rollup) og implementerer en indpakket version af BOB token (wBOB) på L2 via Arbitrum-Ethereum-broen. BobDEX på Arbitrum er identisk med BobDEX på Ethereum, bortset fra at den bruger wBOB – ikke native BOB-tokens – til LP-belønninger og styring.

Forskellen i applikationstokens (indpakket BOB vs. native BOB) gør ikke en forskel fra perspektivet af brugere (f.eks. likviditetsudbydere), der interagerer med BobDEX på Arbitrum. Da wBOB-tokens understøttes af faktiske BOB-tokens i Arbitrum-Ethereum-broen, kan indehavere af wBOB-tokens nemt bytte til indfødte BOB ERC-20-tokens på Ethereum ved at interagere med brokontrakten.

Situationen er en win-win for Bob og brugere:

1. Bob kan tiltrække flere brugere, især brugere, der ønsker lave gasgebyrer og hurtige transaktionsbekræftelser, når de handler på BobDEX

2. LP'er kan tjene belønninger ved at levere likviditet til BobDEX uden at håndtere Ethereums høje gasomkostninger og lange bekræftelsestider

3. Hodlere kan købe wBOB-tokens på markedet for at drage fordel af ændringer i prisen på BOB-tokens uden at interagere med BOB ERC-20-kontrakten på Ethereum

   
   

Fordelene ved brobygning strækker sig også til at forbedre komponerbar innovation og låse op for nye use cases, der udnytter likviditeten af et brokoblet token. For eksempel kan Alice oprette en udlånsprotokol kaldet AliceLend on Arbitrum, der accepterer wBOB som sikkerhed fra låntagere for at udvide anvendeligheden af wBOB og skabe et nyt marked for udlån og låntagning .

Långivere, der leverer likviditet til AliceLend, er sikre på at modtage indskud: Hvis en bruger misligholder et lån, auktionerer AliceLend automatisk wBOB-tokens indsat som sikkerhed for at tilbagebetale långivere. I dette tilfælde påtager købere af likvideret wBOB-sikkerhed sig rollen som LP'er på BobDEX og har den samme garanti for, at wBOB-tokens kan ombyttes 1:1 til originale BOB-tokens.

Cross-chain brodging i sin nuværende form har givet en brugbar løsning til at sikre interoperabilitet mellem (tidligere siloed) Ethereum L2'er og lette nye applikationer (f.eks. cross-chain udlån og cross-chain DEX'er). Men det brobyggende økosystem kæmper i øjeblikket med begrænsninger, der hindrer yderligere vækst, såsom ikke-fungibiliteten af krydskædede tokens - vi vil udforske dette problem i detaljer efterfølgende.

Hvorfor bliver broede tokens ikke-fungible?

Den tidligere beskrevne bro-workflow med lås og mint ser simpel ud på papiret, men kræver i virkeligheden en masse ingeniør- og mekanismedesignindsats for at fungere korrekt:

Den første udfordring er at sikre, at indpakkede versioner af et brokoblet token altid understøttes af native tokens, der er låst på kildekæden. Hvis en angriber præger repræsentationer af et token i en ekstern kæde uden at deponere native tokens ved kildekæden, kan det gøre broen insolvent ved at bytte (svigagtigt præget) indpakkede tokens med native tokens på hjemmekæden og forhindre legitime brugere - der deponerede i brokontrakten før udmøntning af indpakkede poletter - fra at trække indskud.

Den anden udfordring er mere nuanceret og stammer fra karakteren af brokoblede tokens: to repræsentationer af et token præget af broudbydere i den samme fjernkæde kan ikke udveksles 1:1 med en anden. Vi kan bruge et andet eksempel på to brugere, der forsøger at udveksle tokens, der er brokoblet gennem forskellige ruter, for at illustrere dette aspekt af problemet forbundet med at flytte tokens på tværs af kæder:

• Alice slår bro mellem USDC fra Ethereum til Arbitrum via den kanoniske Arbitrum-bro og modtager 200 USDC.e på Arbitrum, mens Bob slår bro mellem USDC til Arbitrum via Axelar og modtager 200 axlUSDC på Arbitrum. Alice og Bob indgår en aftale om, at Alice sender 200 USDC til Bob (i bytte for 200 USDT), så Bob kan hæve 400 USDC til Ethereum.
• Bob forsøger at hæve 400 USDC via axlUSDC og modtager kun 200 USDC, sammen med en besked, der forklarer, at broen kun har 200 USDC, den kan give Bob. Bob er forvirret, da de indpakkede ERC-20 tokens formodes at være "fungible" og ikke bør udvise uligheder, der forhindrer nogen i at udveksle ERC-20 tokens 1:1 på enhver applikation.
• Bob lærer en hård lektie om brodannelse på tværs af kæder: "fungible ERC-20 token" betyder ikke altid "du kan udveksle denne token 1:1 med andre ERC-20 tokens på tværs af applikationer". Bobs forsøg på at gøre risikable forretninger med Alice – risikabelt, da Alice måske ikke returnerer tokens – går spektakulært galt.

Hvorfor kan Bob ikke trække 400 USDC tilbage, hvis han og Alice modtog indpakkede versioner af det samme underliggende aktiv på destinationskæden? Du kan huske, at vi nævnte, at tokens udstedt på forskellige kæder er inkompatible, så repræsentationen af et indfødt token udstedt på en ikke-indfødt kæde er en IOU fra broen, der lover at tilbagebetale et beløb af de indfødte tokens (afhængigt af hvor meget er tilbage), når brugeren ønsker at bygge bro tilbage til tokenets oprindelige kæde.

Værdien af hvert brokoblet token er således bundet til broudbyderen, der er ansvarlig for at holde indskud på hjemmekæden og præge repræsentationer på destinationskæden; Bobs broudbyder kan kun betale Bob 200 USDC, da det er det beløb, den har midler til at dække fra sit depositum; Alices 200 USDC kan ikke trækkes tilbage gennem Bobs broudbyder, da den aldrig har modtaget depositum eller udstedt en IOU til Alice. Alice skal trække sin låste USDC tilbage fra Arbitrum på Ethereum og gå gennem Bobs broudbyder, før Bob kan få adgang til de resterende tokens.

Bob og Alices dilemma peger på et problem med brodannelse mellem domæner, hvor flere ikke-fungible repræsentationer af et underliggende aktiv præges af konkurrerende broudbydere. Det andet problem med forskellige ERC-20-repræsentationer af det samme aktiv er, at de ikke kan handles i en enkelt likviditetspulje.

Ved at bruge det foregående eksempel, hvis vi har axlUSDC og USDC.e i kæden og ønsker at bytte dem til ETH og omvendt, skal vi implementere to likviditetspuljer - ETH/axlUSDC og ETH/USDC.e. Dette fører til et såkaldt "likviditetsfragmenteringsproblem" - en situation, hvor handelspuljerne har mindre likviditet, end de ellers kunne have, fordi der er flere puljer, der i det væsentlige passer til det samme handelspar.

Løsningen er at have en enkelt "kanonisk" version af et token, der cirkulerer på destinationskæden, så Bob og Alice kan udveksle tokens, uden at hver person trækker sig tilbage fra broen ved kildekæden. At have et kanonisk token pr. kæde gavner også udviklere, da brugere hurtigt kan flytte mellem økosystemer uden at beskæftige sig med problemer omkring token-likviditet.

Så hvordan går vi om at implementere kanoniske versioner af et token på hver kæde, det forventer at blive brugt på og overført mellem? Det næste afsnit forklarer nogle af de populære tilgange til at skabe kanoniske tokens på flere kæder.

Implementering af kanoniske tokens på tværs af forskellige kæder

Det er ikke ligetil at oprette et kanonisk token pr. kæde, og der findes flere muligheder med forskellige afvejninger og fordele. Når vi opretter et kanonisk token pr. kæde, er vi normalt nødt til at tænke på, hvem vi skal stole på med hensyn til eksistensen af IOU'er, der understøtter værdien af et bestemt token.

Antag, at du er skaberen af et token, og du ønsker, at det skal være brugbart og overførbart på tværs af forskellige kæder uden at løbe ind i problemer omkring fungibilitet; du har fire muligheder:

1. Mint kanoniske tokens via kanoniske rollup/sidekædebroer
2. Mint kanoniske tokens via en tredjepartsbroudbyder
3. Mint kanoniske tokens via en token-udsteder-bro
4. Direkte multi-chain udstedelse med atomar swaps

De første tre muligheder er afhængige af forskellige bromekanismer for at lette bevægelse af tokens på tværs af kæder. Som en token-skaber kan du dog også vælge at omgå bridging helt ved at udstede tokenet indbygget på hver understøttet kæde. Under denne tilgang opretholder du separate, men koordinerede token-implementeringer på tværs af kæder, i stedet for at stole på indpakkede tokens eller broinfrastruktur – med atomswaps, der muliggør tillidsfri udveksling mellem kæder.

Denne tilgang kræver imidlertid sofistikeret infrastruktur for at opretholde likviditet på tværs af kæder og lette atomswaps. Kompleksiteten ved at administrere flere indbyggede implementeringer har historisk set begrænset denne tilgang til større protokoller med betydelige tekniske ressourcer.

1. Mint kanoniske tokens via kanoniske rollup/sidekædebroer

Hvis en kæde har en kanonisk (indskrevet) bro, kan du tildele retten til at præge repræsentationer af din protokols token for brugere, der ønsker at bygge bro fra den oprindelige kæde. Transaktioner dirigeret gennem kædens kanoniske bro (indskud og udbetalinger) valideres typisk af kædens validatorsæt, som giver stærkere garantier for, at indskud på hjemmekæden troværdigt bakker alle prægede repræsentationer tilbage.

Selvom den kanoniske bro præger den kanoniske repræsentation af et token, vil andre repræsentationer stadig eksistere. Dette sker simpelthen fordi kanoniske broer ofte har begrænsninger, der forhindrer dem i at tilbyde brugerne den bedste oplevelse. For eksempel medfører brodannelse fra Arbitrum/Optimisme til Ethereum via rollup'ens kanoniske bro en syv-dages forsinkelse, da transaktioner skal valideres af verifikatorer – og muligvis bestrides af et bedrageribevis , hvis ugyldigt – før sammenlægningens afviklingslag (Ethereum--afregner) en transaktionsbatch.

Rollup-brugere, der ønsker hurtigere exits, skal bruge andre broudbydere, som kan påtage sig ejerskab af ventende rollup-exits og give forhåndslikviditet på brugerens ønskede målkæde. Når sådanne broer bruger den traditionelle lock-and-mint-model, ender vi med flere indpakkede repræsentationer af et token udstedt af forskellige protokoller og står over for de samme problemer beskrevet tidligere.

Sidekæder med uafhængige valideringssæt har lavere latenstid, da udbetalinger udføres, når sidekædens konsensusprotokol bekræfter en blok, der indeholder en tilbagetrækningstransaktion. Polygon PoS-broen er et eksempel på en kanonisk bro, der forbinder en sidekæde til forskellige domæner (inklusive Ethereum-oprulninger og Ethereum-mainnet).

Bemærk: Vi henviser til den originale Polygon PoS-kæde, ikke den planlagte validium-kæde , der vil bruge Ethereum til afregning. Polygon bliver en L2, når skiftet fra en sidekæde sikret af eksterne validatorer til et validium sikret af Ethereum-konsensus er gennemført.

Sidekædebroer deler dog også en svaghed med rollup kanoniske broer: Brugere kan kun bygge bro mellem et par forbundne kæder. De kan ikke bygge bro til andre blockchains ved hjælp af den kanoniske bro. For eksempel kan du ikke bygge bro fra Arbitrum til Optimisme i dag ved at bruge Arbitrum Bridge eller bro fra Polygon til Avalanche via Polygon PoS-broen.

1.1. Mint kanoniske tokens ved hjælp af likviditetsbroer

At stole på en rollups oprindelige bro til flytning af kanoniske tokens kommer med flere problemer, såsom dårlig likviditet og forsinkelser på aktivets bevægelse. protokoller løser dette problem ved at arbejde med likviditetsbroer for at lette hurtige udbetalinger og brodannelse med lav latens*.

I henhold til denne ordning vil godkendte likviditetsbroer (a) indpakkede repræsentationer af en protokols token på kildekæden (b) bytte indpakkede tokens til den kanoniske repræsentation på destinationen via en protokolejet likviditetspulje.

Den kanoniske repræsentation af tokenet på destinationskæden er normalt den version, der er præget af den kanoniske sidekæde/rollup-bro, selvom der findes undtagelser (som vi vil se senere). For eksempel er den kanoniske version af USDT om Optimisme opUSDT præget af Optimism Bridge.

Hver likviditetsbro fungerer som en DEX med en Automated Market Maker (AMM) til at udføre swaps mellem par af aktiver deponeret i forskellige likviditetspuljer. For at tilskynde til likviditetsforsyning deler AMM-puljer en del af swapgebyrer til indehavere, der låser kanoniske tokens i puljekontrakterne.

Dette ligner Uniswaps model; den eneste bemærkelsesværdige forskel er, at aktivpar normalt er likviditetsbroens repræsentation af et token i forhold til den kanoniske repræsentation. For eksempel vil en bruger, der bygger bro mellem USDT og Optimisme via Hop, skulle bytte hUSDT på Optimisme via huSDT:opUSDT-puljen.

Arbejdsgangen for brobygning via en likviditetsbro vil se således ud:

• Lås native tokens på kildekæden
• Mint bridge repræsentation af native token på målkæden
• Skift brokoblet repræsentation med kanonisk repræsentation på målkæden via AMM-pulje
• Send kanoniske tokens til brugeren

Denne proces er ens for alle likviditetsbroer (Across, Celer, Hop, Stargate osv.). Det er dog normalt abstraheret væk fra slutbrugeren - især af løsere/fyldere - og vil føles som en enkelt transaktion på trods af, at den involverer mange bevægelige dele.

Når brugeren broderer tilbage til kildekæden, brænder brugeren den kanoniske repræsentation eller udskifter den kanoniske token med brorepræsentationen via AMM, før han brænder denne repræsentation og leverer kvitteringen for proof-of-burn. Når det er bekræftet, kan brugeren trække de oprindelige tokens tilbage, der er låst i begyndelsen. (Ligesom den forrige operation er de beskidte detaljer om at flytte tokens tilbage til den oprindelige kæde skjult for brugeren og administreres af løsere).

Likviditetsbrodannelse er fremragende, hovedsageligt fordi det løser problemet med latens i rollup-brodannelse; for eksempel giver Hop specialiserede parter kendt som "Bonders" mulighed for at attestere gyldigheden af en brugers tilbagetrækningstransaktion på L2 og dække omkostningerne ved at trække sig fra rollup'ens L1-bro. Hver Bonder kører en fuld node for L2-kæden og kan afgøre, om en brugers exit-transaktion i sidste ende vil blive bekræftet på L1, hvilket reducerer risikoen for, at en bruger starter en svigagtig tilbagetrækning og forårsager tab for Bonder.

Likviditetsbroer gør det også muligt for brugere at bevæge sig mellem flere kæder, i modsætning til kanoniske broer; for eksempel giver Hop brugere mulighed for at bygge bro mellem Arbitrum og Optimisme uden først at skulle trække sig tilbage til Ethereum. Ligesom hurtig L2→L1-brodannelse kræver hurtig L2→L2-brodannelse, at Bonders kører en fuld node for kilde-L2-kæden for at bekræfte tilbagetrækninger, før de står for omkostningerne ved at præge tokens for en bruger på destinations-L2-kæden. Dette muliggør mere sammensætning mellem rollups og forbedrer brugeroplevelsen drastisk, da brugere kan flytte tokens på tværs af rollups uden problemer.

Men likviditetsbro har også ulemper, der påvirker anvendeligheden af at bruge en kædes fastlagte bro til at præge den kanoniske repræsentation af et token på en L2/L1-kæde. Vi diskuterer ulemperne ved likviditetsbaseret brobygning i næste afsnit:

Ulemper ved likviditetsbroer

1. Skridning

Slipage er en forskel i mængden af tokens, der forventes og modtages, når du interagerer med en AMM. Slipage opstår på grund af AMMs prissætning af swaps i henhold til den aktuelle likviditet i en pulje — prisfastsættelsen er sådan, at der opretholdes ligevægt mellem puljens saldo af hvert aktiv i et par efter en swap er gennemført, hvilket kan ændre sig mellem det tidspunkt, hvor en bruger starter en handel, og udvekslingen udføres.

Lav likviditet for brokoblede aktiver kan også øge glidning; hvis puljen ikke har nok likviditet til at rebalancere den ene side af puljen, kan en stor handel flytte prisen med en stor margin og resultere i, at brugerne udfører swaps til højere priser. Arbitragører forventes at hjælpe med at korrigere uligheder mellem puljer, der handler med det samme aktiv, men kan blive afskrækket fra arbitrage-handler, der involverer tokens med lav handelsaktivitet/værdi.

Dette påvirker også udviklere, der bygger applikationer på tværs af kæder, da de skal tage højde for kanttilfælde, hvor der opstår glidning. Brugeren kan ikke gennemføre en operation på tværs af kæder på grund af at modtage lavere mængder af et token på en eller flere destinationskæder.

Applikationer som broaggregatorer (der ikke kan vide, om en likviditetsbro vil have nok likviditet til at dække en swap i destinationskæden uden glidning) løser problemet ved at specificere en maksimal glidningstolerance og bruge den til at informere brugerne om tilbud. Selvom dette forhindrer tilbageførsel af transaktioner, mister brugere altid en vis procentdel af det brokoblede token – uanset likviditeten i en bros AMM-puljer.

2. Likviditetsbegrænsninger

En grundlæggende udfordring med likviditetsbroer er det absolutte krav om tilstrækkelig likviditet i destinationskæden. I modsætning til traditionelle lock-and-mint-broer, hvor token-prægning understøttes direkte af låste aktiver, er likviditetsbroer afhængige af tilgængelige tokens i AMM-puljer for at gennemføre krydskædede overførsler. Når likviditeten falder under kritiske tærskler, kan hele brobygningsmekanismen reelt ophøre med at fungere.

• Bridge-operationer kan stoppe helt, hvis likviditeten falder for lavt, hvilket forhindrer brugerne i at gennemføre deres tilsigtede overførsler;
• Brugere kan blive tvunget til at opdele store overførsler i mindre transaktioner for at undgå at udtømme puljelikviditeten;
• I perioder med høj volatilitet eller markedsstress kan likviditetsudbydere trække sig fra puljer, netop når brofunktionalitet er størst behov;
• Bootstrapping af nye token-par bliver særligt udfordrende, da der kræves betydelig initial likviditet for at gøre broen operationel.

Likviditetskravet skaber en cirkulær afhængighed: broer har brug for betydelig likviditet for at fungere pålideligt, men at tiltrække likviditetsudbydere kræver demonstration af ensartet brug af bro og generering af gebyrer. Dette kylling-og-æg-problem er særligt akut for nye eller mindre hyppigt handlede tokens, som kan kæmpe for at opretholde tilstrækkelig likviditet på tværs af flere kæder.

3. Fejljusterede incitamenter

En likviditetsbro er nyttig i det omfang, den kan dække swaps fra den brokoblede repræsentation til den kanoniske token på destinationskæden, uden at brugerne pådrager sig overdreven glidning; gasomkostningerne ved at interagere med broen bestemmer også en likviditetsbros værdi fra en brugers perspektiv. Broaggregatorer og projektteams, der udsteder et token, prioriterer således broer baseret på mængden af likviditet og transaktionsomkostninger.

Selvom dette sikrer, at brugere, der bygger bro mellem et projekts tokens eller bruger en broaggregator til at sende tokens på tværs af kæder, har bedre brugervenlighed, men at vælge broer baseret på likviditet er en ulempe for broer, der ikke er i stand til at bruge på incitamenter til likviditetsudbydere (LP). Ydermere skæmmer valget af broer baseret på rene transaktionsgebyrer konkurrencen til fordel for broer, der anvender en centraliseret tilgang til at reducere driftsomkostningerne og kan opkræve lavere gebyrer på brotransaktioner. I begge tilfælde konkurrerer broer ikke på uden tvivl den vigtigste metrik: sikkerhed.

Likviditetsbaserede broer disfavoriserer også longtail-aktiver med lavere handelsaktivitet (gør dem mindre tilbøjelige til at tiltrække LP'er). Udstedere af long-tail-tokens (eller nye tokens med lave brovolumener) vil enten skulle oprette AMM-puljer og bootstrap-likviditet for at dække swaps af native tokens (brokoblet via en likviditetsbro) mod den kanoniske repræsentation af udstederens token eller arbejde med brooperatører for at øge de økonomiske incitamenter for LP'er til at levere likviditet til det pågældende aktiv.

4. Dårlig bro-UX

Likviditetsbroer er en forbedring af kanoniske broer, men er heller ikke uden UX-problemer. Udover at blive ved med at glide på tværs af kædeswaps, kan brugere muligvis ikke gennemføre en brotransaktion med det samme på destinationskæden, fordi broen ikke har tilstrækkelig puljelikviditet til at dække handel med det kanoniske token på destinationskæden. Bridges kan ikke vide, hvor meget likviditet for et aktivpar vil eksistere, når en brugers besked om at bytte tokens når destinationskæden, så denne kanttilfælde er for det meste uundgåelig.

Brugere har to valg i denne situation (begge suboptimale):

• Vent indtil broen har nok likviditet til at gennemføre byttet og trække kanoniske tokens ud . Dette er suboptimalt på grund af forsinkelsen i bro-transaktioner, og fordi en bruger ikke kan vide, om de vil modtage den samme mængde tokens, som oprindeligt blev citeret, da poollikviditeten kan ændre sig vilkårligt i meget korte perioder.
• Modtag broens proprietære token-repræsentation (f.eks. hUSDT for Hop Bridge) . Dette er suboptimalt, da de fleste applikationer foretrækker at integrere med den kanoniske repræsentation af et indbygget token (f.eks. opUSDT præget af Optimism Bridge) og muligvis ikke accepterer brugerens indpakkede aktiv.

2. Mint kanoniske tokens via en kanonisk tredjepartsbro

En multi-chain dapp kan løse problemet med ikke-fungible broforbundne tokens ved at vælge en enkelt bro for at præge kanoniske repræsentationer af dapp'ens token på hver kæde, hvor dappen er implementeret. Som med kanoniske broer, der præger godkendte repræsentationer af et projekts token, kræver denne tilgang at kortlægge tokens, der er præget på eksterne kæder, til token-kontrakten, der er implementeret på projektets hjemmekæde – hvilket sikrer, at token-forsyningen forbliver den samme globalt. Broudbyderen skal spore prægning og afbrænding af et token og sikre, at prægning og brænding forbliver synkroniseret med token-forsyningen i hjemmekæden.

Brug af en enkelt broudbyder giver mere fleksibilitet for projektteams, især da tredjepartsbroer tilskyndes til at understøtte brobygning mellem en bredere række af økosystemer sammenlignet med kanoniske broer, der kun forbindes til højst én kæde. Hvis der findes en bro på alle kæder, hvor en applikation er implementeret, kan brugere hurtigt flytte krydskæden uden at skulle trække sig tilbage til hjemmekæden; en broudbyder skal kun sikre, at de tokens, der er præget på destinationskæde A, bliver brændt, før en bruger slår tokens på destinationskæde B og kanoniske tokens på kæde B (gen)mappes til tokenet på hjemmekæden.

Problemet med ikke-fungible broede tokens er også elimineret; forudsat at brugerne går gennem den godkendte broudbyder, kan de altid udveksle dem 1:1 med andre brokoblede tokens. Denne tilgang løser yderligere problemerne med likviditetsbaseret brobygning i den kanoniske bromodel:

• Brugere lider ikke af glidning på brotransaktioner, da broudbyderen ikke behøver at konvertere sin repræsentation mod en kanonisk repræsentation via en AMM – broudbyderens token er den kanoniske repræsentation af det brokoblede token på hvert domæne. Værdien af disse repræsentationer er knyttet til værdien af tokens, der er låst af broudbyderen på tokenets oprindelige kæde.

• Brugere lider kun lidt eller ingen forsinkelser ved brobygning, da broudbyderen kan præge indpakkede repræsentationer på destinationskæden umiddelbart efter mint()-meddelelsen ankommer til destinationen.

• Udviklere kan outsource styring af multi-chain token-implementeringer til brooperatører uden at bekymre sig om bootstrapping af AMM-likviditets- eller likviditetstilførselsprogrammer.

  
  

Nogle eksempler på single-bridge-udbyder tokens i naturen inkluderer LayerZero's Omnichain Fungible Token (OFT), Axelar's Interchain Token Service (ITS), Celers xAsset og Multichain's anyAsset. Alle eksempler er i det væsentlige proprietære tokens og er inkompatible med repræsentationer af det samme token sendt via en anden broudbyder. Denne subtile detalje fremhæver nogle problemer med denne tilgang til håndtering af brokoblede tokens. Nemlig følgende:

• Sælger lock-in
• Tab af suverænitet
• Høj eksponering for brofejl
• Tab af tokens brugerdefinerede funktioner på målkæderne
• Er begrænset til leverandørens understøttede kæder
• Manglende evne til at opretholde den samme token-adresse på alle ønskede kæder, hvilket kan skade brugersikkerheden eller gøre dem sårbare over for phishing

Ulemper ved at bruge kanoniske tredjepartsbroer

1. Leverandørlåsning

Valg af en enkelt broudbyder til at præge kanoniske repræsentationer på en eller flere kæder udsætter udviklere for risikoen for leverandørlåsning. Da hver broudbyder fremstiller en proprietær repræsentation, der kun er kompatibel med dens infrastruktur (og integrerede økosystemprojekter), låser single-bridge-udbyder-modellen effektivt en token-udsteder til en specifik broservice uden mulighed for at skifte til en anden bro i fremtiden.

Det er muligt at skifte broudbyder, men skifteomkostningerne er høje nok til at afholde de fleste projekter fra at gå denne vej. For at give en grov idé, antag, at en udvikler (som vi kalder Bob) har udstedt et token (BobToken) på Ethereum og vælger LayerZero OFT til at præge kanoniske versioner af BobToken på Optimisme, Arbitrum og Base. BobToken har en fast forsyning på 1.000.000 tokens, og brokoblede tokens præget via LayerZero tegner sig for 50% af den samlede forsyning af BobTokens i omløb.

Forretningsarrangementet forløber gnidningsløst, indtil Bob beslutter, at brugerne har det bedre med at bygge bro mellem BobTokens via en konkurrerende bridge-tjeneste (f.eks. Axelar). Bob kan dog ikke bare rejse sig og sige: "Jeg skifter til Axelar ITS for at præge kanoniske repræsentationer af BobToken om optimisme, base og arbitrum"; da OFT-tokens og ITS-tokens er inkompatible, risikerer Bob at skabe hovedpine for både gamle brugere og nye brugere, da to BobTokens potentielt ikke er fungible (genintroducerer det problem, vi beskrev tidligere). Desuden kan applikationer integreret med LayerZeros version af BobToken ikke acceptere Axelars version af BobToken som en erstatning – hvilket fragmenterer likviditeten for BobToken på forskellige kæder, hvor konkurrerende repræsentationer af BobToken eksisterer sideløbende.

For at gøre overgangen mulig, skal Bob overbevise brugerne om at pakke indpakkede repræsentationer af BobToken præget gennem LayerZero ved at sende en transaktion, der brænder brokoblede OFT-tokens og låser BobTokens op på Ethereum. Brugere kan nu skifte til den nye kanoniske repræsentation af BobToken ved at låse tokens med Axelar på Ethereum og modtage kanoniske BobTokens (tilknyttet token-kontraktens forsyning på Ethereum) på destinationskæden. Dette er både omkostningstungt og medfører massiv koordinering og driftsomkostninger for DAO-projektledelsesteams, så det er normalt den sikreste mulighed at holde sig til den valgte udbyder.

Dette efterlader imidlertid udviklere som Bob i en problematisk position, da leverandørlåsning gør det umuligt at skifte, hvis en broudbyder ikke overholder aftalevilkårene, har en begrænset funktionspakke, mangler ekspansive økosystemintegrationer, tilbyder dårlig UX osv. . Det giver også broer med næsten uendelig gearing: broudbyderen kan gøre vilkårlige ting som rate-limit-brugere, der bygger bro over BobTokens uden klare årsager, hæve. brogebyrer eller endda censurere brooperationer. Bobs hænder er bundet i dette tilfælde, da det er lige så komplekst at holde et brud fra en defekt kanonisk tredjepartsbro som at blive i forretningsforholdet.

2. Tab af suverænitet for protokoller

Den afsluttende del af det foregående afsnit om leverandørlåsning fremhæver et andet problem med at bruge en kanonisk tredjepartsbro: Tokenudstedere udveksler kontrol med kanoniske brokoblede tokens til gengæld for større bekvemmelighed og UX-forbedringer. For at bruge det foregående eksempel: BobToken på Ethereum er helt inden for Bobs kontrol, da han kontrollerer den underliggende ERC-20 token-kontrakt, men BobToken på Optimism, Arbitrum og Base kontrolleres af LayerZero, som ejer OFT-kontrakten, der udsteder kanoniske repræsentationer af BobToken på de blockchains.

Selvom Bob måske forventer, at LayerZero tilpasser kanoniske repræsentationer med det oprindelige design af det indfødte token, er dette muligvis ikke altid tilfældet. I worst-case scenarier kan adfærden for BobToken på Ethereum afvige væsentligt fra den af BobToken på Optimisme, fordi broudbyderen implementerer en radikalt anderledes version af token-kontrakten - hvilket skaber problemer for protokollens brugere. Dette problem kan også forværres af principal-agent dynamik, hvor målene og interesserne for en protokol og broudbyderen divergerer.

3. Høj eksponering for brofejl

I den første tilgang, hvor tokens brokobles på tværs af kæden gennem hver kædes kanoniske bro, er risikoen for tokenudstederen fra en udnyttelse, der påvirker én bro, indeholdt i den pågældende bro. Antag for eksempel, at en hacker formår at kompromittere en likviditetsbro og præge uendelige mængder af et indpakket token uden at deponere sikkerhed. I så fald kan den kun trække op til den maksimale likviditet, der er tilgængelig for det indpakkede aktiv i likviditetspuljer (f.eks. præge cUSDT på Optimisme → bytte cUSDT til kanonisk opUSDT → trække opUSDT til Ethereum via hurtig bro → bytte til native USDT på Ethereum) .

I tredjeparts kanoniske bromodel svarer risikoen for en token-udsteder fra en udnyttelse, der påvirker partnerbroen, til den samlede mængde tokens, som en angriber sætter på fjernkæder, hvor den berørte bro har en implementering. Dette er muligt, fordi enhver kanonisk repræsentation på alle kæder kan ombyttes 1:1 til kanoniske tokens udstedt på andre kæder:

Antag, at en angriber kompromitterer en tredjepartsbro på kæde B og præger 1000 tokens (hvor tokenet oprindeligt udstedes på kæde A) uden at deponere sikkerhed. Angriberens tokens på kæde B er ikke knyttet til hjemmekædekontrakten, så den kan ikke trække sig tilbage fra kæde A. Alligevel kan den bygge bro til kæde C og bytte 1000 kæde B-tokens til 1000 kæde C-tokens – husk, hver krydskæde token er kompatible og fungible, da de stammer fra den samme brotjeneste. Kæde C-tokens er knyttet til hjemmekædekontrakten, da de lovligt blev præget af brugere, der låste tokens på kæde A (tokens hjemmekæde), hvilket gør det muligt for angriberen at brænde tokens på kæde C og trække native tokens tilbage på kæde A og potentielt fuldføre. rejseplanen ved at udveksle tokens via en CEX eller fiat offramp.

4. Tab af brugerdefinerede token-funktioner

Når du bruger en kanonisk tredjepartsbro, mister tokenudstedere ofte evnen til at implementere tilpassede funktioner eller tokenadfærd, der eksisterer i deres oprindelige implementering. Dette sker, fordi broudbydere har en tendens til at bruge standardiserede ERC-20-implementeringskontrakter, der muligvis ikke understøtter specialiseret funktionalitet, der findes i den originale token-implementering.

Fælles token-funktioner som stemmedelegering (ZK), rebasing-mekanismer (stETH, USDM), gebyr-on-transfer-funktioner (memecoins), blacklisting og whitelisting-funktioner (USDT, USDC), pauselige overførsler og særlige prægningsregler eller -tilladelser fjernes ofte væk, når tokens er brokoblet gennem en tredjepartsudbyder, da den brokoblede version typisk vil bruge en grundlæggende ERC-20 implementering. Dette tab af funktionalitet skaber uoverensstemmelser i, hvordan tokenet fungerer på tværs af forskellige kæder og kan potentielt bryde integrationer, der afhænger af disse brugerdefinerede funktioner.

Standardiseringen af brokoblede tokens, selvom den er enklere fra broudbyderens perspektiv, reducerer effektivt tokenens muligheder og kan hæmme udstederens evne til at opretholde ensartet tokenadfærd på tværs af hele multi-chain-økosystemet i deres applikation. Sådanne problemer kan gøre udvidelser på tværs af kæder til et mareridt for udviklere og repræsentere en hindring for at realisere drømmen om apps, der lever på flere kæder.

5. Begrænsede understøttede kæder

Tokenudstedere bliver afhængige af deres valgte broudbyders netværksdækning og udvidelsesplaner. Hvis broudbyderen ikke understøtter et bestemt blockchain-netværk, som tokenudstederen ønsker at udvide til, står de over for to suboptimale valg:

• Vent på, at broudbyderen tilføjer support til den ønskede kæde, hvilket kan tage lang tid eller aldrig ske på grund af høje integrationsomkostninger (f.eks. ZKsync Eras EVM-uækvivalens, der har fået mange dapps til aldrig at implementere på den)
• Brug en anden broudbyder til den specifikke kæde, hvilket genindfører problemet med ikke-fungible tokens og likviditetsfragmentering

Denne begrænsning kan i væsentlig grad påvirke en protokols vækststrategi og evne til at nå nye brugere på nye kæder. Bridge-udbydere kan prioritere at støtte populære kæder, mens de forsømmer mindre eller nyere netværk, der kan være strategisk vigtige for token-udstederen.

6. Inkonsekvente token-token-adresser på tværs af kæder

Tredjepartsbroudbydere kan implementere brokoblede tokens med forskellige adresser på hver kæde på grund af deres tekniske stack - for eksempel ingen understøttelse af CREATE2 . Mangel på adressekonsistens skaber til gengæld mange UX-problemer:

• Sikkerhedsrisici : Brugere skal verificere forskellige token-adresser på hver kæde, hvilket øger risikoen for at interagere med svigagtige tokens;
• Integrationskompleksitet : Udviklere skal vedligeholde lister over gyldige token-adresser for hvert netværk;
• Øget phishing-risiko : Dårlige skuespillere kan lettere narre brugere med falske tokens, da der ikke er nogen ensartet adresse at tjekke op på.

Disse ulemper, kombineret med de tidligere diskuterede spørgsmål om leverandørlåsning, tab af suverænitet og høj eksponering for brofejl, fremhæver de betydelige begrænsninger ved at stole på kanoniske tredjepartsbroer til implementering af tokens på tværs af kæder. Denne forståelse hjælper med at sætte scenen for, hvorfor alternative løsninger som ERC-7281 er nødvendige for at løse disse udfordringer på en mere omfattende måde.

3. Mint kanoniske tokens via token-udsteder-bro

Hvis en udvikler ønsker at bevare maksimal kontrol over tværkæde-implementeringer af et projekts token, kan den administrere udstedelsen af kanoniske repræsentationer af tokenet på fjernkæder. Dette beskrives som "stol på tokenudstederen", da værdien af hver brokoblet repræsentation af tokenet er bundet til tokens låst på tokenets hjemmekæde af den protokol, der er ansvarlig for at udstede den originale version af tokenet på kildekæden.

For at denne tilgang kan fungere, skal tokenudstederen oprette infrastruktur til at styre prægning og brænding af brokoblede tokens på tværs af kæden (samtidig med at den globale forsyning forbliver synkroniseret via kanonisk kortlægning). Bemærkelsesværdige eksempler på kanoniske repræsentationer af et token udstedt af token-skaberen er MakerDAO's Teleport og Circle's Cross-Chain Transfer Protocol (CCTP) .

Teleport giver brugerne mulighed for at flytte kanonisk DAI mellem Ethereum og forskellige Ethereum-oprulninger via fast-path- og slow-path-operationer. DAI brændes på en kæde og præges på målkæden. CCTP fungerer på samme måde og muliggør overførsler på tværs af kæder af native USDC (udstedt af Circle) via en burn-and-mint-mekanisme. I begge tilfælde kontrollerer tokenudstederen prægning og afbrænding af kanoniske repræsentationer af et token.

Denne tilgang giver fuldstændig kontrol over brokoblede tokens til protokoller. Og det løser problemet med ikke-fungible repræsentationer af det samme token på den mest effektive måde som muligt - der findes kun én kanonisk version af tokenet (præget af udstederen i destinationskæden), hvilket sikrer, at brugerne har den samme oplevelse med at bruge et token. på hvert økosystem, som tokenudstederen understøtter.

Med denne tilgang drager applikationer også fordel af elimineringen af likviditetsfragmentering forårsaget af uofficielle, brokoblede repræsentationer af en protokols token, der flyder i det samme økosystem. Udviklere kan også bygge mere robuste cross-chain-applikationer (f.eks. cross-chain swaps og cross-chain lending), da kanoniske token-udsteder-broer giver mulighed for kapitaleffektiv, problemfri og sikker bevægelse af tokens mellem kæder.

Ulempen ved kanoniske token-udstederbroer er imidlertid, at denne model kun er gennemførlig for projekter med tilstrækkelig kapital til at dække omkostningerne ved at implementere en token-krydskæde og vedligeholde infrastruktur (orakler, keepere osv.), der kræves for at udføre tværgående kædeprægning og afbrænding. Dette har også den noget uønskede effekt, at det er tæt koblet sikkerheden af brokoblede aktiver med protokollens sikkerhedsmodel.

Dette forhold (mellem brokoblede versioner af en protokols tokens og protokollens sikkerhed) er mindelig, da sikkerheden af native tokens, der understøtter kanoniske repræsentationer, allerede afhænger af protokollens sikkerhed, så brugere og eksterne udviklere ikke påtager sig nye tillidsantagelser. Dette gælder især for stablecoin-broer, der drives af udstedere som Circle og Maker (nu Sky) – brugere stoler allerede på, at stablecoin-udstedere har nok aktiver til at dække indløsning af stablecoins til fiat-valutaer, så det er ikke svært at stole på sikkerheden ved en stablecoin-bro.

Men det repræsenterer også et centralt fejlpunkt – hvis tokenudstederens broinfrastruktur kompromitteres, er værdien af alle kanoniske repræsentationer, der cirkulerer i multikædeøkosystemet, i fare. Dette indebærer også, at kun centraliserede depoter (f.eks. Circle i tilfælde af USDC) kan implementere denne model for udstedelse af kanoniske brokoblede tokens.

Sidste tanker

Som vist i denne rapport er fungibilitet på tværs af kæder en vigtig del af sammenlægningsinteroperabilitet med implikationer for oplevelsen af at bevæge sig mellem forskellige kæder. Tokens evne til at forblive fungible, når de kobles til fjernkæder, påvirker også udvikleroplevelsen, da visse use-cases afhænger af denne funktion.

Forskellige løsninger er blevet foreslået for at løse problemet med infungible cross-chain tokens – mange af dem har vi dækket i denne rapport. Dette inkluderer prægning af kanoniske tokens via indfødte (indlejrede) broer, brug af en dedikeret tredjepartsbro til at præge kanoniske tokens på tværs af flere kæder og brug af en protokolejet bro for at lette bevægelse af tokens og bevare fungibiliteten.

Selvom disse tilgange løser specifikke problemer, klarer de ikke alle problemer, og at bruge dem til at muliggøre aktivsfungibilitet på tværs af kæder kræver nogle uønskede afvejninger. Kan vi finde en bedre tilgang? Svaret er ja.

ERC-7281 er en ny tilgang til fungibilitet på tværs af kæder, der mindsker afvejninger forbundet med eksisterende tilgange. Også kendt som xERC-20 , ERC-7281 gør det muligt for protokoller effektivt at implementere kanoniske tokens på flere kæder uden at afveje sikkerhed, suverænitet eller brugeroplevelse.

ERC-7281's unikke design gør det muligt for flere (hvidlistede) broer at præge kanoniske versioner af en protokols tokens på hver understøttet kæde, samtidig med at protokoludviklere dynamisk kan justere prægegrænser pr. bro. Denne funktion løser mange af de problemer, der er forbundet med historiske forslag til kanoniske tokens med flere kæder – inklusiv likviditetsfragmentering, incitamentjustering, UX-bekymringer, brosikkerhedsrisici, tilpasningsmuligheder (af krydskædede tokens) og mere.

Den næste – og sidste – del af vores todelte rapport om aktivsfungibilitet på tværs af kæder vil dække ERC-7281 i detaljer og undersøge, hvordan xERC-20-tokenstandarden kan gavne udviklere og brugere. Vi vil sammenligne ERC-7281 med andre designs til kanoniske tokens med flere kæder, udforske xERC-20's tilgang til kanoniske tokens med flere kæder og fremhæve overvejelser for protokoller og udviklere, der ønsker at bygge videre på standarden.

Følg med!