Op-ed: Reimagining cross-chain bridges: La oss slutte å prøve å være likviditetsprotokoller PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Op-ed: Reimagining cross-chain bridges: La oss slutte å prøve å være likviditetsprotokoller

Etter en rekke store utnyttelser av broer, blir det gitt mye oksygen til fortellingen om at tverrkjedeteknologi er iboende feil - at interoperabilitet på tvers av kjeder betyr risiko. Med anslagsvis 2 milliarder dollar tapt over 13 brohakk i år, blir det stadig vanskeligere å ignorere dette argumentet.

At deBridge, tror vi at det ikke bare er avgjørende, men uunngåelig at alle krysskjedebroer fullstendig revurderer sin tilnærming til likviditetsaggregering.

Begrensningene til låst likviditet

Ved å låse likviditet for å gi krysskjederuting (som nesten alle broer gjør akkurat nå), har broer plassert seg i en konkurranse de er nødt til å tape. Vi ser broer møte opp mot etablerte, spesialbygde likviditetsprotokoller som AAVE, Compoundog frax, prosjekter som utvilsomt vil tjene penger på likviditet mer effektivt og sikkert. Eksempler florerer av broer med hundrevis av millioner dollar i TVL, med ekstremt lav utnyttelse av låst likviditet.

Med dette designet blir broprosjekter tvunget til å kjøre uholdbare likviditetsutvinningskampanjer som ikke klarer å tilby langsiktige kapitaleffektive løsninger. Med mindre symbolske insentiver opprettholdes på ubestemt tid – en uforsvarlig ambisjon for ethvert prosjekt – vil likviditetsleverandører uunngåelig fjerne kapital for å forfølge muligheter med høyere avkastning.

For å samle likviditet på en sikker måte, må broer anskaffe forsikringer for å la likviditetstilbydere ha muligheten til å sikre risiko. Dette er en annen utgift som gjør inntektsgenerering av likviditet enda vanskeligere. Det er derfor de fleste eksisterende broer ikke er lønnsomme, ettersom kostnader og betalte likviditetsutvinningsbelønninger ofte overstiger protokollens nettofortjeneste.

Det er også arkitektoniske hensyn i spill her, gitt at en verdioverføring på tvers av kjeder er en forespørsel som kan avgjøres på ulike måter. Alle eksisterende broer avvikler disse ordrene fra sine egne likviditetspooler hvor likviditet er kontinuerlig låst når det er nødvendig kun i det nøyaktige øyeblikket verdioverføringen skal oppfylles.

Størrelsen på bestillingen kan også variere — hvis den overstiger størrelsen på broens likviditetspool, vil avsenderen ende opp med innpakkede tokens eller en transaksjon som er suspendert på ubestemt tid. På den annen side, hvis ordren er for liten for likviditetspoolens størrelse, er likviditetsutnyttelsen svært lav og ineffektiv. Denne onde sirkelen fremhever videre at denne likviditetsprotokolltilnærmingen til brodesign er ineffektiv og fundamentalt feil.

Løser sikkerhetsproblemet

Så viktig av en sak som dette er, er ikke økonomisk ubærekraft den eneste hovedutfordringen her. Selv om vi antar at broer har funnet ut en måte å bruke den låste likviditetstilnærmingen på og holde seg kapitaleffektiv, er det nå tydelig at det er en altoppslukende oppgave å bygge en sikker likviditetsprotokoll. Faktisk, ved å bevisst eller ubevisst bli likviditetsprotokoller, gir broprosjekter seg selv den enorme oppgaven å sikre en mangefasettert angrepsoverflate.

For å starte på et høyt nivå, er et av de åpenbare problemene med en låst bro i likviditetsstil at den skaper en risikomultiplikatoreffekt, der sårbarhetene til én støttet kjede kan smitte over på å kompromittere kapital som holdes i andre økosystemer.

Her er det spørsmålet om sikkerhet ved fullmakt. En bro kan få hele sin likviditetsbase kompromittert hvis det er en potensiell sårbarhet i kodebasen til en støttet blokkjede/L2. Vi så denne muligheten tidligere i år med en sårbarhet oppdaget i Optimism, som ville ha gjort det mulig for angripere å prege en vilkårlig mengde eiendeler og forutsigbart bytte disse mot tokens i andre økosystemer.

Igjen, eventuelle problemer med konsensusmekanismen til en kjede kan også føre til systemisk smitte, og sette enhver likviditet som er låst i andre støttede kjeder i fare. I dette tilfellet sender broen ganske enkelt utnyttelsen til andre kjeder. Dette kan inkludere 51 % angrep eller andre feil på protokollnivå.

Bortsett fra denne typen arvelige risikoer, ser vi i økende grad situasjoner der feil fra selve broprosjektene på en eller annen måte har forårsaket tap av låst likviditet. Fra feilaktige protokolloppgraderinger, dårlig smart kontraktsdesign eller kompromittert infrastruktur for validatorer, er det mange scenarier der dårlige aktører kan utnytte sårbarheter i selve broen.

Alle disse risikoene forsterkes raskt og – som vi har sett ved for mange anledninger – blir til slutt født av likviditetstilbydere når de mister innløseligheten til sine innpakkede eiendeler. En slik mulighet burde være uakseptabel.

Få benekter det enorme løftet om interoperabilitet på tvers av kjeder for å presse Web3-adopsjon til nye høyder. Men med den store størrelsen og hyppigheten av broutnyttelser, har det blitt smertelig klart at den grunnleggende utformingen av broteknologi må omformes fra første prinsipper. Den bro-slåtte likviditetsprotokolldesignen fungerer bare ikke.

Er det noen måte vi kan utvikle en fundamentalt ny og unik tilnærming til brodesign, en som fullstendig fjerner risiko for likviditetstilbydere, eliminerer angrepsvektorer, og samtidig bevarer det høyeste nivået av kapitaleffektivitet?

Det kan være akkurat det i nær fremtid. Hos deBridge jobber vi med en ny likviditetsruting på tvers av kjeder som løser alle disse problemene. Følg med.

Gjesteinnlegg av Alex Smirnov fra deBridge Finance

Alex Smirnov er en matematiker, forsker, utvikler og blockchain-entusiast. Han er administrerende direktør og medgründer av deBridge, en generisk meldings- og interoperabilitetsprotokoll på tvers av kjeder, hvor han fokuserer på protokolldesign, produktadministrasjon, partnerskap og drift. Alex var med å grunnlegge Phenom, et blockchain-forsknings- og utviklingsselskap, og han har også ledet et team som har vunnet en rekke hackathons og utviklet ulike blockchain-løsninger og dApps.

→ Les mer

Tidstempel:

Mer fra CryptoSlate