Erfaringer fra Curve Finance og Web3, der er udsat for angreb

Erfaringer fra Curve Finance og Web3, der er udsat for angreb

Tidsstempel: 26. september 2023 kl. 11
Erfaringer fra Curve Finance og Web3 er tilbøjelige til at angribe PlatoBlockchain Data Intelligence. Lodret søgning. Ai.

Curve Finance's seneste nærdødsoplevelse (og dens afværgede udbredelse) kan virke som en sløring i Web3s bakspejl, men det er faktisk noget, der bliver ved med at ske i branchen. Det er ikke første gang, at en decentral finansiering protokol - eller en hvilken som helst decentral app for den sags skyld - er blevet påvirket af et angreb, der er helt lovligt inden for sin egen kode. Mere så, krisen kunne have været forhindret, hvis on-chain risikostyring eksisterede.

Alt dette peger på et bredere problem i Web3. Det er problemet begrænset udtryksevne og ressourcer der findes i dets udviklingsmiljøer, og hvordan det påvirker sikkerheden generelt.

Hacke eller udnytte?

Da Curve Finance-angriberen var i stand til at hente US$61.7 millioner i aktiver fra Curve Finances smarte kontrakter, mange medier og kommentatorer kaldte begivenheden for en "hack." Men dette var ikke et hack - det var en udnyttelse. Forskellen her er nøglen. 

I denne sammenhæng ville et hack have fundet sted, hvis angriberen på en eller anden måde havde omgået eller brudt en eksisterende sikkerhedsforanstaltning. Men angrebet på Curve var en udnyttelse. Der skete ikke noget, der var ud over det sædvanlige i forhold til, hvad protokollens Vyper-kode tillod. Plyndren udnyttede simpelthen, hvordan protokollens design fungerede.

Hvem er skyld i dette? Ingen. Curves Vyper-kode er, ligesom det meste af (Solidity)-koden, der bruges i Web3-applikationer, stærkt begrænset i sin evne til at udtrykke kompleksitet ud over relativt simpel transaktionslogik. 

Dette gør det svært for nogen at designe sikkerhedsforanstaltninger, der forhindrer dette eller andre angreb. Mere bekymrende er det, at det også gør det svært for nogen at designe værktøjer korrekt for at forhindre, at de spredes over DeFis enorme og sammensatte likviditetslandskab.

On-chain risikoanalyse

Men det betyder ikke, at der ikke var noget, som Curve kunne gøre for at forhindre dette angreb og dets spredning over DeFi. Et simpelt eksempel på en løsning ville være on-chain risikoanalyse. 

Den generaliserede version af et problematisk mønster, der kunne løses, kan opsummeres i en hypotetisk situation som denne:

  • Den dårlige skuespiller Bob køber $5 millioner af det meget flygtige $RISKY-token via en flashlån.
  • Værdien af ​​$RISKY token pumpes effektivt af Bob efter købet. 
  • Bob optager et lån på $100 millioner på Naive Finance støttet af $RISKY.
  • Naive Finance tjekker prisen på $RISKY og bekræfter, at Bob er "god" for pengene.
  • Bob løber.
  • Når Naive Finance likviderer $RISKY, er det kun $5 millioner værd.

(Et andet eksempel på dette generelle mønster kan findes i Euler hack fra marts.)

Traditionelt løses dette problem ved risikoanalyseløsninger, der bestemmer, hvor god en garanti et aktiv kan være. Hvis de fandtes i kæden, kunne Naive Finance kontrollere statistiske estimater baseret på tokens historiske pris, før lånet blev godkendt. Protokollen ville have gennemskuet pumpen og nægtet Bob de 100 millioner dollars.

DeFi mangler denne form for on-chain risikoanalyse og styring.

Går vi tilbage til Curve Finance, kunne et spænd have været forhindret, hvis Aave og Frax havde en automatiseret, on-chain grænse på lånegodkendelser, når de passerer en procentdel af sikkerhedstokens cirkulerende forsyning. Dette ville have været en sikrere og mindre stress-inducerende situation for alle.

Begrænset udtryksevne og ressourcer

Det virkelige problem her er, at nuværende Web3-økosystemer ikke kan understøtte noget som denne risikoanalyseløsning i kæden. De er begrænset af den slags biblioteker og rammer, der er tilgængelige i virtuelle maskiner som Ethereum Virtual Machine. De er også begrænsede med hensyn til de ressourcer, de har til rådighed.

For at udvikle noget som denne risikoanalyse- og styringsløsning, skal en decentral app regne med kodningsbiblioteker, der har funktioner til i det mindste grundlæggende matematiske begreber som logaritmer og andre. 

Dette er ikke tilfældet i Web3, fordi dApps ikke har adgang til nusset, matematikmodulet i Python, for eksempel. Den typiske værktøjskasse er der ikke, og udviklere er nødt til at genopfinde hjulet i stedet for.

Så har vi et andet problem. Selv hvis de havde disse biblioteker, ville de være for dyre at kode. Bogstaveligt talt dyrt. Ethereum Virtual Machine er designet, så der er en pris for hver beregning. 

Selvom der er gyldige grunde til dette, såsom at forhindre uendelige loops og sådan, skaber det også en ressourcebegrænsning for dApps, der muligvis skal skaleres beregningsmæssigt uden at pådrage sig urimelige omkostninger. Man kunne nemt se, hvordan en risikostyringsløsning ville koste mere at køre, end hvad den er i stand til at spare i fonde.

Fokus på de rigtige problemer

På et lokalt niveau kunne spredningen af ​​Curve Finance dødvandet have været forhindret med on-chain risikostyring. På et generelt niveau kunne hele denne klasse af angreb forhindres med mere udtryksevne og ressourcer i Web3.

Dette er to aspekter af blockchain-skalerbarhed, der længe er blevet overset, fordi de går ud over at give mere delt blokplads til dApps. De involverer faktisk oprettelsen af ​​udviklingsmiljøer i Web3, der efterligner Web2's. De handler om beregningsmæssig skalerbarhed , programmerbarhed, ikke kun skalering af mængden af ​​data, der er tilgængelig på kæden.

Måske hvis protokoludviklere hos Curve, Aave eller Frax havde evnen til at regne med en bedre værktøjskasse og flere ressourcer, kunne disse og fremtidige udnyttelser helt undgås. Måske kunne vi starte med on-chain risikostyring.

Tidsstempel:

Mere fra Forkast