Smart Contract Audit Report for Dusa

Ledelsesoversigt

Dusa kontaktede Sayfer for at udføre en sikkerhedsrevision af deres smarte kontrakter. 

Denne rapport dokumenterer forskningen udført af Sayfer rettet mod de udvalgte ressourcer, der er defineret under forskningsomfanget. Denne rapport viser især gennemgangen af ​​sikkerhedsstilling for Dusas smarte kontrakter.

I løbet af undersøgelsesperioden på 4 uger opdagede vi 17 sårbarheder i kontrakten.

Alt i alt er Dusa en velbygget protokol. Det faktum, at det er afledt og oversat fra TraderJoe, gør det til en meget solid protokol med en ret almindelig arkitektur, men som anses for optimal. Vi har dog nogle få anbefalinger, som vi mener kan forbedre kvaliteten og sikkerheden af ​​protokollen. Disse anbefalinger er beskrevet i afsnittet "Arkitekturgennemgang".

Som konklusion bør flere rettelser implementeres efter rapporten, men systemets sikkerhedsposition er kompetent.

Efter en gennemgang fra Sayfer-teamet bekræfter vi, at alle sikkerhedsproblemerne nævnt i denne rapport er blevet behandlet eller anerkendt af Dusa-teamet.

Risikometodologi

Hos Sayfer er vi forpligtet til at levere smart kontraktrevision af højeste kvalitet til vores kunder. Det er derfor, vi har implementeret en omfattende risikovurderingsmodel for at evaluere alvoren af ​​vores resultater og give vores kunder de bedst mulige anbefalinger til afbødning.

Vores risikovurderingsmodel er baseret på to nøglefaktorer: IMPACT og SANDSYNLIGHED. Påvirkning refererer til den potentielle skade, der kan følge af et problem, såsom økonomisk tab, skade på omdømme eller et ikke-operativt system. Sandsynlighed refererer til sandsynligheden for, at et problem vil opstå under hensyntagen til faktorer som kontraktens kompleksitet og antallet af potentielle angribere.

Ved at kombinere disse to faktorer kan vi skabe en omfattende forståelse af den risiko, et bestemt problem udgør, og give vores kunder en klar og handlekraftig vurdering af problemets alvor. Denne tilgang giver os mulighed for at prioritere vores anbefalinger og sikre, at vores kunder får den bedst mulige rådgivning om, hvordan de beskytter deres smarte kontrakter.

Risiko er defineret som følger:

Protokoloversigt

Protokol introduktion

Dusa er en banebrydende decentraliseret finansprotokol (DeFi), der introducerer en fuldt decentraliseret og avanceret automatiseret market maker (AMM) oplevelse. Bygget på Massa blockchain, lægger Dusa vægt på nøgleprincipper såsom fuld decentralisering, tilgængelighed for alle brugerprofiler, interoperabilitet med fremtidige decentraliserede applikationer (DApps) og et stærkt engagement i sikkerhed og censurmodstand. Dens køreplan skitserer en trinvis tilgang, herunder forskning og udvikling, testning, incitamentbaserede quests og implementering af en decentraliseret udveksling (DEX). Dusas unikke funktioner inkluderer koncentreret likviditet, variable gebyrer, autonom likviditet og komplekse handelsordrer, alt sammen designet til at forbedre brugeroplevelsen og maksimere afkastet. Med et dedikeret team, strategiske investorer og rådgivere sigter Dusa efter at være pioner inden for vedtagelse af autonome smarte kontrakter og udvide sine decentraliserede løsninger til andre økosystemer.

Arkitektur gennemgang

Idet vi anerkender, at Dusa er et afledt af en veletableret løsning, TraderJoe, og stemmer overens med et anerkendt arkitektonisk mønster, bemærker vi begrænsede yderligere anbefalinger til den nuværende arkitektur. Vores evaluering af Dusa-protokolarkitekturen har imidlertid ført til et omfattende overblik, der kombinerer værdifuld indsigt med gennemtænkte anbefalinger til forbedringer:

• Fra et synspunkt om bedste praksis anbefaler vi at overveje implementeringen af ​​en multisig-tegnebog til styring af privilegerede roller i fremtiden. Mens vi anerkender den nylige udgivelse af Massa multisig-koden (https://github.com/massalabs/massa-standards/tree/feature/multisig-sc/smart-contracts/assembly/contracts/multisig), råder vi til forsigtighed og betragter brugen af ​​en standard privat nøgle også som en levedygtig mulighed for nuværende.
• En anden indsigtsfuld anbefaling foreslår at vedtage en samlet likviditetsmodel, der forestiller sig en global Vault/PoolManager i stedet for individuelle kontrakter pr. pulje. Dette strategiske skift, inspireret af de seneste fremskridt inden for AMM'er som Uniswap V4 og Balancer, lover betydelige fordele. Disse omfatter omkostningseffektive multihop-swaps og forbedret flashlånskapacitet, som tilskrives strømlinet adgang til hele likviditetspuljen.

Revisionsresultater

[H] Frontløbsrisiko ved oprettelse af et nyt par

Beskrivelse

For at oprette et nyt par, skal brugeren ringe Router::createLBPair(StaticArray ). Under motorhjelmen kalder denne funktion Factory::createLBPair(StaticArray ), som igen kalder Massa's transferCoins (adresse, nummer).

• Factory.ts:264; createLBPair(StaticArray )

transferCoins(_pair._origin, 200 * ONE_COIN);

Ifølge dokumentation, overfører denne funktion simpelthen mønter fra den aktuelle adresse til en given adresse. Det betyder, at disse midler på forhånd skal sendes til Fabrik. På den anden side har brugerne mulighed for at ringe oprette Par fra router, som er standardindgangspunktet for andre operationer. Men hvis de indsættes i en separat transaktion, er der mulighed for, at nogen, forsætligt eller på anden måde, også ringer createLBPair(StaticArray ).

Når en blok med transaktioner er afsluttet, vil de blive lagt ud i en ukendt rækkefølge. Derefter vil den første transaktion inkluderet, få disse midler overført fra fabrikken til et nyt par, mens den anden bruger (sidstnævnte transaktion) vil få deres transaktion tilbageført på grund af mangel på tilgængelige midler.

Mitigation

Finansieringen af ​​paroprettelse skal faktisk finde sted i den samme transaktion for at undgå problemer med genbestilling af transaktioner. 

For eksempel kunne en af ​​måderne at opnå det på være en mekanisme, der kontrollerer fabrikssaldoen og puljesaldoen ved slutningen af ​​en funktion og sender overskuddet tilbage, svarende til dette https://github.com/massalabs/coin-vester/blob/master/smart-contract/assembly/contracts/main.ts#L34

Mekanismen vil være på plads i oprette LBPair funktion (af Fabrik), i konstruktør, mynte, brænde, indsamle Gebyrer, øge OracleLængde, sikker Overførsel Fra & sikkerBatchTransferFrom (parret). Dette er de funktioner, der kan bruge Massa til opbevaring, da de kan oprette nye poster i lageret (det koster ikke noget at ændre lageret). Funktioner, der interagerer med disse funktioner, skal også have denne mekanisme. 

De kan opdeles i to forskellige slags:

• Funktioner, der interagerer med disse, og som ikke interagerer med WMAS (oprette LBPair fra router og fabrik + tilføje likviditet, fjerne likviditet) vil overføre alle overførte Mønter, gem saldoen på SC i en konstant, og efter SC-opkaldet overføres forskellen mellem den nye saldo og den gemte saldo tilbage til den, der ringer.
• Funktioner, der interagerer med disse, og som interagerer med WMAS (addLiquidityMAS, fjerne LiquidityMAS) skal bruge en parameter mere for at kende antallet af mønter, der skal pakkes ind, vil du sende forskellen mellem overførte Mønter og dette nummer i opkaldet. Resten af ​​mekanismen i disse funktioner vil være den samme som den lige før.

[H] Midler, der er indbetalt til oprettelse af par, kan gå tabt

Beskrivelse

Dette problem er et resultat af, hvordan paroprettelse er designet. En bruger kan ringe Router::createLBPair(StaticArray ) og da en oprettelse af et par kræver en indbetaling, kan han vedhæfte penge til funktionsopkaldet, hvilket lyder som en intuitiv løsning.

Men hvis brugeren gør det, vil pengene aldrig nå parret og vil gå tabt i kontrakten (selv om det kan reddes af ejeren). Dette skyldes, at de vil sidde fast i Router-kontrakten, mens pardannelsen foregår i Fabrikskontrakten, hvor transferCoins(), som trækker penge fra den nuværende (fabrikkens) adresse, bruges i stedet.

• Factory.ts:264; createLBPair(StaticArray )

transferCoins(_pair._origin, 200 * ONE_COIN);

Da det er implementeret på fabrikken, vil midler, der sendes til routeren, ikke nå frem til fabrikken, som heller ikke har midlerne til at oprette et par og vende tilbage.

Mitigation

En mulighed er at implementere løsningen foreslået i SIG-01.
Omvendt Fabriks.ts kan kaldes direkte for at oprette par og kræve, at brugerne sender enten det nøjagtige påkrævede beløb sammen med funktionsopkaldet, ELLER i det mindste det nødvendige beløb med tilbagebetaling af eventuelle overskydende midler, der er sendt.

[M] Flere par af samme type kan fortynde likviditeten

Beskrivelse

Når du opretter et nyt par, er der ingen kontrol, om præcis det samme par allerede eksisterer. Dette kan sprede brugernes likviditet på tværs af flere tilsvarende puljer. Puljer med lav likviditet er mere tilbøjelige til prismanipulationer og tilbyder mindre gunstige handler og bør derfor undgås.


Mitigation

Tjek, om et par af bestemte parametre allerede eksisterer ved oprettelse af par, hvis det er tilfældet, skal du vende tilbage.

[L] Præcis saldokontrol efter et flashlån kan blive misbrugt

Beskrivelse

Efter et flashlån kræver systemet, at saldoen præcis er balancen før flashlånet plus gebyrer.

• flashLoan(StaticArray )

assert(

  _balanceAfter == SafeMath256.add(_balanceBefore, _fees.total),

  LBPair__FlashLoanInvalidBalance(),

);

Typisk kræves det, at saldoen er større, da det er restriktivt at kræve et nøjagtigt match.

Mitigation

Tjek kun, om saldoen er større end saldoen før flashlånet plus gebyrer. Dette er også den logik, som TraderJoe bruger i deres flashlånsfunktion.

[L] Ignorering af et LB-par udsender ikke en hændelse

Beskrivelse

funktionen setLBPairIgnored(StaticArray ) kan bruges til at kontrollere, om et par skal ignoreres til routing eller ej. Enhver ændring i flaget via denne funktion udsender begivenheden SET_LBPAIR_IGNORED. Det er dog også muligt at ændre flaget via setLBPairInformation(StaticArray ), som ikke udsender en begivenhed.

Mitigation