Överbrygga anpassade EVM-kedjor till Tron-likviditet | Intervju med Andrew Nalichaev

29 april 2026

Sammanfatta med AI

I det här samtalet tittar Andrew närmare på vad det innebär att ansluta en anpassad EVM-kedja till Tron-likviditet. Han går igenom bryggsäkerhet, sårbarheter i gränsfall, gränserna för revisioner och avvägningarna bakom LP-, lock-and-mint-, avsiktsbaserade och hybridmodeller med fokus på vad som faktiskt går sönder i produktionen och varför.

Om du arbetar med anpassade kedjor, interoperabilitet eller likviditetsdirigering är det här en genomgång på praktikernivå av besluten bakom infrastruktur mellan kedjor.

Text från intervjun

Fördjupa CrossCurve-exploateringen i februari 2026. Vad exakt misslyckades där, och hur ska incidenter som detta förändra hur vi tänker på broar mellan kedjor?

Jag tycker att det är en riktigt bra fråga eftersom vi har ett partnerskap med CrossCurve och vi använde deras lösning för några av våra kunder. När olyckan inträffade försökte vi verkligen utvärdera hur det påverkade våra kunder och våra partnerskap. Och efter en intern kontroll insåg vi att den goda nyheten är att det inte har någon inverkan på våra specifika kunder.

Vad hände egentligen? Så CrossCurve använde några externa budbärare som skulle skicka ett meddelande från källkedjan till destinationskedjan. Vad det faktiskt betyder är att CrossCurve sa att de har, och de har faktiskt, lösningen som kallas en konsensusbrygga. Det betyder faktiskt att de använder olika budbärare samtidigt för att skydda den specifika transaktionen, processen med lock-and-mint eller processen med att överföra likviditet mellan kedjorna. Men i det här specifika fallet, de var tvungna att packa dessa två olika kedjor, så de använde bara Axelar-lösningen.

Och problemet ligger inte i CrossCurve utan i Axelars meddelandemekanism. Vad innebär det i praktiken? När någon skickar en transaktion från destinationskedjan till källkedjan kontrollerar källkedjan bara transaktions-ID:t på destinationskedjan och jämför siffrorna, utan att faktiskt verifiera meddelandet från källkedjan. Tyvärr nämnde många revisorer och forskare inte detta som en sårbarhet. På grund av detta använde CrossCurve bara samma lösning och de metoder som godkänts av externa revisorer.

I grund och botten visar det oss att vi ibland inte ens kan lita fullt ut på revisorer och måste dubbelkolla varje gång. Kanske tillämpa några ytterligare AI-kontroller eller vad som helst. Men den goda nyheten är att CrossCurve fortfarande är med i spelet. Och definitivt finns det dåliga nyheter om det, men det betyder inte att det har problem ur arkitekturens synvinkel. Vi kan tänka på det som en påminnelse om hur någon kan missbruka och attackera broarna. Men det betyder ändå bara att vi måste göra vissa dubbelkontroller, komma ihåg att sådana attacker kan inträffa och bygga nästa lösningar och broar mellan olika kedjor på ett säkrare sätt.

Du vet, det beror på fallet. Jag kan säga att de vanligaste arkitektoniska problemen löstes under den tidigare tjurmarknaden, någon gång mellan mitten av 2020 och 2021. Så de vanligaste fallen har redan lösts vid det här laget. Men vissa fall är verkligen gränsfall. Till exempel fallet med CrossCurve. Jag tycker att det är ett riktigt marginalfall, för även efter alla kontroller, även med en bra arkitektur och en helt lysande idé, finns det fortfarande sådana svaga punkter.

Och jag tror definitivt att vi just nu redan har den vanligaste arkitektoniska lösningen som finns. Vi kallar det en guldstandard för branschen, och i allmänhet är det en gemensam standard, tror jag. Så vi kan inte säga att det finns helt arkitektoniska problem med den. Vi kan säga att vissa små buggar eller små ovanliga fall, och vad vi faktiskt kallar ett edge case, kan inträffa.

Jag tror att vårt huvudmål just nu är att förhindra och skydda mot sådana marginalfall på arkitekturnivå. Det är till exempel möjligt att använda en hybridlösning, en dubbelkontroll, en extra revision eller kanske en nedkylning i vissa fall. I vårt företag försöker vi verkligen att implementera fler och fler säkerhetskontroller och skydd, och ibland föredrar vi till och med att återanvända befintliga lösningar snarare än att skapa broar från noll.

Och i det här fallet är det definitivt bättre att tillämpa huvudstandarden än att försöka uppfinna hjulet på nytt.

Jag tror att det är den fråga som alla våra kunder, eller till och med alla som bestämmer sig för att skapa sin egen anpassade kedja, ställer till oss. I de flesta fall kommer det att vara EVM-kompatibla kedjor, ibland Layer 2 ZK-rollup eller Optimistic rollup. Och alla vill ha en del av likviditeten från Tron-kedjan eftersom den fortfarande spelar en stor roll i överföringar av stablecoins: någon får betalt, får lön eller betalar räkningar med stablecoins på Tron.

Definitivt, alla vill få tillgång till denna likviditet och använda den på sin egen anpassade kedja. Tron- och EVM-kompatibla kedjor har olika typer av adresser, olika typer av smarta kontrakt och olika språk för de smarta kontrakten. Och det är därför det är så svårt. Om vi ansluter EVM-kedjan till EVM-kedjan kommer adressen på destinationskedjan och källkedjan att vara densamma, och vi kan använda samma smarta kontrakt för lock-and-mint, även ur synvinkeln för betalningarna för transaktionsavgifterna.

I en EVM-kedja har vi alltså samma mekanism för att beräkna gasavgifter och transaktionskostnader. I Tron är det helt annorlunda, med ett energikoncept, med betalning i några TRX, etc. Det är en anledning till att det är så annorlunda och varför det är mer komplext, snarare än att bara ansluta två olika EVM-kompatibla kedjor.

Ärligt talat tror jag att LP-bryggor är det mest klassiska tillvägagångssättet för många kedjor. Det betyder att du, som någon som vill para ihop din kedja med en extern, eller som ägare av bron, inte behöver tillhandahålla din egen likviditet. Du kan be samhället att tillhandahålla denna likviditet, och i de flesta fall kommer de att gå med på att dela sin likviditet med dig.

Men du måste ge dem lite vinst. Och du kommer att konkurrera med befintliga DeFi-protokoll eller andra användningsfall för likviditet. Det innebär att din bro bör ha många TVL låsta och många transaktioner som passerar den. Om transaktionsvolymen är riktigt hög och du tar ut många avgifter kommer du att kunna dela dessa avgifter med likviditetsleverantörerna.

Annars, i ett fall där du kommer att ha färre transaktioner, betyder det att LP-leverantören har mindre anledning att tillhandahålla likviditet eftersom de kommer att samla in mindre av avgifterna. Det är därför de kan bestämma sig för att bara ta bort likviditet från din bro och använda den på ett externt DeFi-protokoll. I det här fallet kommer glidningen i den här LP-transaktionen, med den här bryggningen med LP, att vara högre.

Det är därför någon kan bestämma sig för att “Okej, jag vill inte göra transaktionen i den här kedjan med den här bron, och jag föredrar ett annat alternativ”.” Så du måste spela med likviditeten och du måste ge fler och fler skäl att stödja din bridgelösning med likviditeten.

Definitivt inte ur social synvinkel. Du vet, det bästa med lås-och-mint-strategin är att du inte har likviditet alls. När det gäller LP-bryggor måste du be någon att tillhandahålla likviditeten för LP. I det här fallet behöver du inte ens ha din egen likviditet.

Om någon vill använda vissa stablecoins eller använda din kedja kan de låsa ett visst antal stablecoins, eller vilket mynt det nu är, på källkedjan och sedan prägla ett lika stort antal på din anpassade kedja eller, i allmänhet, på destinationskedjan.

Men vad är problemet? Det största problemet med detta tillvägagångssätt är att det kan skapa en annan typ av token på destinationskedjan. Så det handlar om fragmenteringen av likviditeten. Till exempel kommer du att ha en version av token från Ethereum och en annan från Arbitrum, eller olika typer av tokens utfärdade av olika broar med en lock-and-mint-strategi. Så det handlar om fragmentering.

Men det finns också vissa tekniska problem, för om någon angriper budbäraren och skickar fel meddelande om att man måste låsa upp ett visst antal tokens på källkedjan eller utfärda ytterligare ett antal tokens på destinationskedjan, så kommer de att kunna få den extra likviditet som inte är säkerställd av de faktiska tokens på källkedjan.

Så det är en stor fråga, och i de flesta fall, om någon försöker attackera sådana broar, kombinerar de en ekonomisk attack med en teknisk, men inte en social.

Jag håller verkligen med om att en avsiktsbaserad metod kan vara den bästa metoden ur användarupplevelsesynpunkt. Men om man skapar sin egen kedja innebär det att man måste ge ytterligare motivation till vissa robotar, algoritmer eller till och med personer att vara lösare, eftersom lösare är en nyckelkomponent i den avsiktsbaserade metoden.

För många av våra kunder använder vi 1inch Fusion+. Det är precis en avsiktsbaserad strategi. Men om du vill använda samma sak för dina egna anpassade kedjor måste du motivera någon att vara den här lösaren. Om de till exempel ser mindre och mindre transaktionsvolym på din kedja och färre och färre människor som vill göra den här broöverföringen, kan de bara försöka diktera sina förväntningar på dig ur intäktssynpunkt, och då blir användarupplevelsen sämre och sämre.

Och denna låga kostnad kan bli högre och högre, och transaktionshastigheten kan bli långsammare. Kanske kommer du att vara den enda solvern eller resolvern som arbetar med ett sådant tillvägagångssätt. Så jag tycker att det är det värsta med det avsiktsbaserade tillvägagångssättet.

När man talar om broar i allmänhet, om du skapar din egen anpassade kedja, vill du ansluta den till det externa ekosystemet. I de flesta fall är jag ganska säker på att du egentligen inte vill ansluta en enda kedja till en enda extern kedja. 

Men om vi använder LP-metoden eller lock-and-mint-metoden innebär det att du måste ansluta din enda kedja till många kedjor, vilket är mycket kostsamt och kräver mycket likviditet. I de flesta fall är det normalt att välja en kedja som källkedja och ansluta den till din kedja. Och i det här fallet, med din destinationskedja, kan det vara en strategi som innebär att man låser in sig.

Men den här externa kedjan kan kopplas till många, många, många andra externa kedjor på olika sätt. Till exempel med LP-metoden eller med en avsiktsbaserad metod. Om du skapar din egen L2 ZK-rollup och vill få tillgång till likviditet från det externa ekosystemet kan du använda Arbitrum som en källkedja.

Arbitrum kan anslutas till Tron via ett avsiktsbaserat tillvägagångssätt och till Ethereum via ett LP-tillvägagångssätt. Och sedan kommer den sista milen bara att vara en lås-och-mint-strategi för din kedja. Med hybridlösningen får du alltså tillgång till all extern likviditet i externa kedjor, men med en mellanliggande kedja som du kan använda som källa för din egen anpassade kedja.

Jag tror att den mest obekväma frågan är: hur mycket är du beredd att spendera på den här bridgelösningen? Och hur mycket pengar är du beredd att avsätta för en viss lösning? Om vi talar om en avsiktsbaserad strategi innebär det att du redan från början måste tillhandahålla sponsring eller andra skäl för att lösningsleverantörerna ska fortsätta att vara lösningsleverantörer i din kedja. Om trafiken i din kedja inte är den största från dag ett, måste du verkligen sponsra deras lösning. Om du slutar göra detta kan de i de flesta fall välja att stänga av sin lösning.

Annars, om vi pratar om en lock-and-mint-strategi, måste du betala lite pengar till de befintliga välkända budbärarna för att ansluta din kedja till deras nätverk av budbärare. Och det är mycket. Jag menar, du kommer att betala hundratusentals US-dollar bara för att vara ansluten, och det är en engångsbetalning.

Om vi talar om LP-metoden kan du i princip tillhandahålla din egen likviditet. Och det betyder fortfarande att du kan vara den enda LP-leverantören för den här metoden, men den här likviditeten kommer att vara låst. Eller så betalar du någon för att låsa likviditeten, och det innebär också att du måste spendera en del av dina egna tokens eller, i bästa fall, ytterligare sponsring för den låsta likviditeten.

Så för mig är den första och viktigaste frågan hur mycket du verkligen är villig att spendera på det, och hur mycket pengar och tokens du är villig att avsätta till sådana lösningar.

Möt intervjupersonen

Blockchain-expert och DeFi-analytiker

Andrew översätter decentraliserade koncept till säkra, funktionella finansiella verktyg. Han navigerar i det flyktiga DeFi-landskapet för att bygga skalbara blockchain-infrastrukturer som adresserar verklig nytta, och går förbi buzzwords för att leverera tekniskt värde.

Andrews expertis i arbete

Mer om detta ämne

    Kontakta oss

    Boka ett samtal eller fyll i formuläret nedan så återkommer vi till dig när vi har behandlat din förfrågan.

    Skicka ett röstmeddelande till oss
    Bifoga dokument
    Ladda upp filen

    Du kan bifoga 1 fil på upp till 2 MB. Giltiga filformat: pdf, jpg, jpeg, png.

    Genom att klicka på Skicka samtycker du till att Innowise behandlar dina personuppgifter enligt våra Integritetspolicy för att förse dig med relevant information. Genom att lämna ditt telefonnummer samtycker du till att vi kan kontakta dig via röstsamtal, SMS och meddelandeappar. Samtals-, meddelande- och datataxor kan gälla.

    Du kan också skicka oss din förfrågan

    till contact@innowise.com
    Vad händer härnäst?
    1

    När vi har tagit emot och behandlat din förfrågan återkommer vi till dig för att beskriva dina projektbehov och undertecknar en NDA för att säkerställa sekretess.

    2

    Efter att ha undersökt dina önskemål, behov och förväntningar kommer vårt team att ta fram ett projektförslag förslag med arbetsomfattning, teamstorlek, tids- och kostnadsberäkningar.

    3

    Vi ordnar ett möte med dig för att diskutera erbjudandet och fastställa detaljerna.

    4

    Slutligen undertecknar vi ett kontrakt och börjar arbeta med ditt projekt direkt.

        arrow