Op-ed: Reimagining cross-chain broar: Låt oss sluta försöka vara likviditetsprotokoll PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.

Op-ed: Reimagining cross-chain broar: Låt oss sluta försöka vara likviditetsprotokoll

Efter ett antal storskaliga exploateringar av broar ges mycket syre till berättelsen om att tvärkedjeteknologi är i sig bristfällig - att interoperabilitet mellan kedjor innebär risk. Med uppskattningsvis 2 miljarder dollar förlorade över 13 bridge hacks i år, blir det allt svårare att ignorera detta argument.

At deBridge, tror vi att det inte bara är absolut nödvändigt utan också oundvikligt att alla tvärkedjebryggor helt omprövar sin strategi för likviditetsaggregation.

Begränsningarna för låst likviditet

Genom att låsa likviditet för att tillhandahålla cross-chain routing (som nästan alla broar gör just nu), har broar placerat sig i en tävling som de kommer att förlora. Vi ser broar möta etablerade, specialbyggda likviditetsprotokoll som AAVE, Luktämneoch FRAX, projekt som utan tvekan kommer att tjäna pengar på likviditet mer effektivt och säkert. Det finns gott om exempel på broar med hundratals miljoner dollar i TVL, med extremt lågt utnyttjande av låst likviditet.

Med denna design tvingas broprojekt att driva ohållbara likviditetsutvinningskampanjer som misslyckas med att erbjuda långsiktiga lösningar för kapitaleffektivitet. Om inte symboliska incitament upprätthålls på obestämd tid – en osund ambition för alla projekt – kommer likviditetsleverantörer oundvikligen att ta bort kapital för att eftersträva möjligheter med högre avkastning.

För att samla likviditet på ett säkert sätt skulle bryggor behöva skaffa försäkringar för att låta likviditetsleverantörer ha möjlighet att säkra risker. Detta är en annan utgift som gör likviditetsgenerering ännu svårare. Det är därför de flesta befintliga broar inte är lönsamma, eftersom kostnader och betalda likviditetsutvinningsbelöningar ofta överstiger protokollets nettovinst.

Det finns också arkitektoniska överväganden i spel här, med tanke på att en värdeöverföring över kedjan är en begäran som kan lösas på olika sätt. Alla befintliga bryggor reglerar dessa order från sina egna likviditetspooler där likviditeten kontinuerligt låses när den behövs först i det exakta ögonblicket värdeöverföringen ska genomföras.

Storleken på beställningen kan också skilja sig åt — om den överstiger storleken på bryggans likviditetspool, kommer avsändaren att sluta med inslagna tokens eller en på obestämd tid avbruten/fast transaktion. Å andra sidan, om ordern är för liten för likviditetspoolens storlek är likviditetsutnyttjandet mycket lågt och ineffektivt. Denna onda cirkel understryker ytterligare att denna metod för likviditetsprotokoll för brodesign är ineffektiv och fundamentalt felaktig.

Löser säkerhetsproblemet

Lika viktig av en fråga som detta är, är ekonomisk ohållbarhet inte den enda stora utmaningen här. Även om man antar att broar har kommit på ett sätt att använda den låsta likviditetsmetoden och förbli kapitaleffektiva, är det vid det här laget uppenbart att att bygga ett säkert likviditetsprotokoll är en alltförbrukande uppgift. Genom att medvetet eller omedvetet bli likviditetsprotokoll ger broprojekt sig själva den enorma uppgiften att skydda en mångfacetterad attackyta.

För att börja på hög nivå är en av de uppenbara problemen med en låst likviditetsliknande bro att den skapar en riskmultiplikatoreffekt, där sårbarheterna i en stödd kedja kan spilla över och äventyra kapital som finns i andra ekosystem.

Här är det frågan om säkerhet genom proxy. En brygga kan få hela sin likviditetsbas äventyrad om det finns en potentiell sårbarhet i kodbasen för en blockchain/L2 som stöds. Vi såg den här möjligheten tidigare i år med en sårbarhet som upptäcktes i Optimism, vilket skulle ha gjort det möjligt för angripare att skapa en godtycklig mängd tillgångar och förutsägbart byta ut dessa mot tokens i andra ekosystem.

Återigen, alla problem med konsensusmekanismen för en kedja kan också leda till systemisk smitta, vilket äventyrar all likviditet som är låst i andra stödda kedjor. I det här fallet sänder bron helt enkelt exploateringen till andra kedjor. Detta kan inkludera 51 % attacker eller andra fel på protokollnivå.

Bortsett från dessa typer av ärvda risker, ser vi allt oftare situationer där misstag från själva broprojekten på ett eller annat sätt har orsakat en förlust av låst likviditet. Från felaktiga protokolluppgraderingar, dålig smart kontraktsdesign eller komprometterad infrastruktur för validerare, det finns många scenarier där dåliga aktörer kan utnyttja sårbarheter i själva bron.

Alla dessa risker förvärras snabbt och – som vi har sett vid alltför många tillfällen – föds så småningom av likviditetsleverantörer när de förlorar möjligheten att lösa in sina inslagna tillgångar. En sådan möjlighet borde vara oacceptabel.

Få förnekar det stora löftet om interoperabilitet över kedjan för att driva introduktionen av Web3 till nya höjder. Men med den stora storleken och frekvensen av broexploater har det blivit plågsamt tydligt att den grundläggande utformningen av överbryggningsteknik måste omformas från första principer. Den bro-förvandlade likviditetsprotokolldesignen fungerar helt enkelt inte.

Finns det något sätt vi kan ta fram ett fundamentalt nytt och unikt tillvägagångssätt för brodesign, ett som helt tar bort risker för likviditetsleverantörer, eliminerar attackvektorer och samtidigt bevarar den högsta nivån av kapitaleffektivitet?

Det kan bli just det inom en snar framtid. På deBridge arbetar vi med en ny likviditetsrutt för flera kedjor som löser alla dessa problem. Håll ögonen öppna.

Gästinlägg av Alex Smirnov från deBridge Finance

Alex Smirnov är en matematiker, forskare, utvecklare och blockchain-entusiast. Han är VD och medgrundare av deBridge, ett generiskt meddelande- och interoperabilitetsprotokoll över kedjan, där han fokuserar på protokolldesign, produkthantering, partnerskap och drift. Alex var med och grundade Phenom, ett forsknings- och utvecklingsföretag för blockkedjor, och han har också lett ett team som har vunnit många hackathons och utvecklat olika blockkedjelösningar och dApps.

→ Läs mer

Tidsstämpel:

Mer från CryptoSlate