Retningslinjer for revision af indsatsprotokoller

Genudgivet af Platon

Abonnenter: 0

Læsetid: 6 minutter

I denne blog har vi skitseret konceptet med likviditetsindsatsprotokoller og revisionsretningslinjer for indsatsprotokoller. Retningslinjerne dækker en række sårbare steder såsom tilbagetrækningsmekanismer, afrundingsfejl, eksterne opkald, gebyrlogik, loops, strukturer, indsatsvarighed osv. Dette blogindlæg vil være en nyttig reference til revision af indsatsprotokoller og kan hjælpe dig med at identificere potentielle fejl .

Hvad er likviditetsindsats?

Likviditetsindsats giver brugerne mulighed for at satse deres cryptocurrency-beholdning og tjene belønninger uden at ofre likviditet. I stedet for at låse deres mønter inde i en fast periode, kan brugere modtage et flydende token, der repræsenterer deres satsede aktiver. Dette token kan handles eller bruges som enhver anden kryptovaluta, hvilket giver brugerne mulighed for at bruge deres aktiver, som de vil, mens de stadig tjener indsatsbelønninger.

Guidelines for Auditing Staking Protocols PlatoBlockchain Data Intelligence. Vertical Search. Ai.

For eksempel har du 100 ETH, du vil satse på Ethereum-netværket. I stedet for at låse din ETH i en fast periode, kan du bruge en likviditetsindsatstjeneste som Lido til at satse din ETH og modtage et flydende token kaldet stETH til gengæld. Med stETH kan du stadig handle eller bruge din satsede ETH, mens du optjener indsatsbelønninger.

Lad os komme i gang med revision af indsatskontrakter:

Undersøg alle tilgængelige revisionsspecifikationer, før du begynder med kontraktkoden. Det kan være i form af en hvidbog, README-filer eller noget andet. Disse vil give dig en idé om, hvad kontraktkoden vil indeholde.

Når du ser på revisionsspecifikationsdokumentet for indsatskontrakten, skal du kigge efter disse punkter:

Typer af gebyrer baseret og deres beregninger.
Belønningsmekanisme for indsatte tokens
Ejerens beføjelser
Vil kontrakten holde ETH?
Hvilke tokens vil kontrakten indeholde?
Original kontrakt, hvorfra den er gaflet

Tjek at specifikationerne stemmer overens med koden. Begynd med gebyrer og tokenomics, efterfulgt af validering af ejerens autoritet. Tjek, at alle belønninger og gebyrværdier er i overensstemmelse med dokumentationen.

Sårbare steder at kigge efter?

1. Mekanisme for tilbagetrækning af belønning:

Tjek, at belønningsmekanismen for satsede tokener er korrekt implementeret, og at belønninger fordeles retfærdigt og proportionalt til alle aktører. Projekter kan fordele belønninger på to måder: enten automatisk, på periodisk basis eller efter anmodning fra brugerne selv. En tilbagetrækningsfunktion kan implementeres og tilpasses i henhold til protokollens forretningslogik.
Nedenfor er et par kontrolpunkter:

Tjek om en bruger er i stand til at hæve mere end sin belønning + indsatsbeløb.
Tjek for Overløb/underløb i mængdeberegningen
Tjek, om visse parametre kan have en negativ indvirkning på belønninger under beregningen.
Hvis blok.tidsstempel eller blok.nummer bruges i denne funktion. Tjek om det kan udnyttes på nogen måde.

2. Gebyrlogik:

Hvis indbetalingen og udbetalingen er underlagt et gebyr, skal du kontrollere, at ingen enkelt bruger kan omgå gebyret. Derudover skal du være opmærksom på eventuelle problemer med overløb eller underløb. Kun administratoren eller ejeren bør have tilladelse til at ændre gebyrindstillinger. Kontroller også, at der er etableret en tærskel for maksimale gebyrer, hvilket forhindrer administratoren i at sætte det til et for højt beløb.

3. LP Tokens prægning/brændingsmekanisme:

Kontroller, om prægnings- og brændingsmekanismerne er blevet korrekt implementeret. En brændefunktion skal vende alle tilstandsændringer foretaget af en mint-funktion. Derudover er det afgørende at verificere, at brugerne modtager den passende mængde tokens under den første indsats, når puljen er tom.

Logikken i præge- og brændefunktioner kan matematisk verificeres for at afdække enhver skjult sårbarhed. Desuden bør det samlede udbud af prægede LP-poletter ikke overstige de indsatte aktiver.

4. Afrundingsfejl:

Selvom visse mindre afrundingsfejl typisk er uundgåelige og ikke et problem, kan de vokse betydeligt, når det er muligt at gange dem. Se efter kanttilfælde, hvor man kan drage fordel af afrundingsfejl ved gentagne gange at udsætte og udsætte.

For at afgøre, om afrundingsfejl kan opstå til et væsentligt beløb over en længere periode, kan vi matematisk beregne rækken af mulige afrundingsfejl.

5. Indsatsvarighed:

Sørg for, at beregningerne af indsatsvarigheden i kontrakten stemmer overens med den angivne forretningslogik. Bekræft, at brugere ikke kan indløse belønninger, før indsatsvarigheden er afsluttet, ved at omgå varighedscheckene. Tjek også, om varigheden af indsatsen kan udnyttes af en angriber til at få flere belønninger.

6. Eksterne opkald og tokenhåndtering:

De fleste af de eksterne opkald vil være til token-kontrakterne. Så vi skal afgøre, hvilke typer tokens, som indsatskontrakten skal håndtere. Det er vigtigt at kontrollere eksterne opkald for eventuelle fejl og genindgangsangreb. Deflationære tokens eller tokens med overførselsgebyrer, såsom Safemoon, kan udgøre et problem, hvis deres logik ikke er korrekt implementeret.

7. Kontrol af prismanipulationer:

Prismanipulation via et flashlån er et af de hyppigste hacks på DeFi-projekter. Der kan være situationer, hvor ondsindede aktører kan bruge flash-lån til at manipulere priserne under satsning eller unstaking af store mængder tokens. Gennemgå omhyggeligt indsats- og unstaking-funktioner for at undgå edge-case scenarier, der kan resultere i flash-lån-baserede prismanipulationsangreb og tab af andre brugeres midler.

8. Nogle yderligere kontroller:

sløjfer: Hvis kontraktlogikken involverer looping over arrays, er det vigtigt at sikre, at blokgasgrænsen ikke overskrides. Dette kan forekomme, når array-størrelsen er meget stor, så du bør undersøge, hvilke funktioner der kan øge størrelsen af arrayet, og om en bruger kan udnytte det til at forårsage et DoS-angreb. Tjek dette ud indberette.
Strukturer: Indsatskontrakter bruger struct-typen til at gemme bruger- eller pooldata. Når du erklærer eller får adgang til en struktur i en funktion, er det vigtigt at angive, om du vil bruge "hukommelse" eller "lager". Det kan måske hjælpe os med at spare lidt gas. For mere information, se venligst til denne artikel.
Front-Løb: Se efter scenarier, hvor ondsindede aktører kunne frontløbe enhver transaktion til deres fordel.
Funktionssynlighed/adgangskontroltjek: Enhver funktion, der er erklæret som ekstern eller offentlig, kan tilgås af alle. Derfor er det vigtigt at sikre, at ingen offentlig funktion kan udføre følsomme handlinger. Det er afgørende at verificere, at indsatsprotokollen har implementeret passende kontroller for at forhindre uautoriseret adgang til både de udsatte mønter og systemets infrastruktur.
Centraliseringsrisici: Det er vigtigt ikke at give ejeren overdrevne beføjelser. Hvis administratoradressen er kompromitteret, kan det forårsage betydelig skade på protokollen. Bekræft, at ejer- eller administratorrettighederne er passende, og sørg for, at protokollen har en plan på plads for håndtering af situationer, hvor en administrators private nøgler er lækket.
ETH / WETH håndtering: Kontrakter indeholder ofte specifik logik for håndtering af ETH. For eksempel, når msg.value > 0, kan en kontrakt konvertere ETH til WETH, mens den stadig tillader, at WETH modtages direkte. Når en bruger angiver WETH som valuta, men sender ETH med opkaldet, kan dette bryde visse invarianter og føre til forkert adfærd.

Indtil videre har vi diskuteret likviditetsindsatsprotokoller og revisionsretningslinjerne for sådanne protokoller. I en nøddeskal giver likviditetsindsats brugere mulighed for at optjene indsatsbelønninger uden at ofre likviditet. Vi har skitseret de sårbare steder i indsatskontrakter, som revisorer skal være opmærksomme på, såsom tilbagetrækningsmekanismer, gebyrlogik, LP-tokens prægning/brændingsmekanisme, afrundingsfejl, indsatsvarighed, eksterne opkald og prismanipulationstjek.

Vi anbefaler revisorer at undersøge revisionsspecifikationsdokumenter, matche specifikationer med kode og kontrollere gebyrer og tokenomics-validering. Vi anbefaler også yderligere kontroller, såsom looping over arrays, specificering af hukommelse eller lager til strukturtypedata og frontløbende scenarier. Disse retningslinjer vil være nyttige til revision af indsatsprotokoller og hjælpe med at identificere potentielle fejl.

11 Views