Retningslinjer for revisjon av innsatsprotokoller

Lesetid: 6 minutter

I denne bloggen har vi skissert konseptet med likviditetsinnsatsprotokoller og revisjonsretningslinjer for innsatsprotokoller. Retningslinjene dekker en rekke sårbare punkter som uttaksmekanismer, avrundingsfeil, eksterne samtaler, gebyrlogikk, løkker, strukturer, innsatsvarighet osv. Dette blogginnlegget vil være en nyttig referanse for revisjon av innsatsprotokoller og kan hjelpe deg med å identifisere potensielle feil .

Hva er likviditetsinnsats?

Likviditetssatsing lar brukere satse sine beholdninger av kryptovaluta og tjene belønninger uten å ofre likviditet. I stedet for å låse myntene sine for en fast periode, kan brukere motta et flytende token som representerer deres eiendeler. Dette tokenet kan omsettes eller brukes som enhver annen kryptovaluta, slik at brukerne kan bruke sine eiendeler som de vil mens de fortsatt tjener innsatsbelønninger.

For eksempel har du 100 ETH du vil satse på Ethereum-nettverket. I stedet for å låse ETH-en din for en fast periode, kan du bruke en likviditetsinnsatstjeneste som Lido for å satse ETH-en din og motta en flytende token kalt stETH i retur. Med stETH kan du fortsatt handle eller bruke din innsats ETH mens du tjener innsatsbelønninger.

La oss komme i gang med revisjon av innsatskontrakter:

Undersøk alle tilgjengelige revisjonsspesifikasjoner før du begynner med kontraktskoden. Det kan være i form av en hvitbok, README-filer eller noe annet. Disse vil gi deg en idé om hva kontraktskoden vil inneholde.

Når du ser på revisjonsspesifikasjonsdokumentet for innsatskontrakten, se etter disse punktene:

• Typer avgifter basert og deres beregninger.
• Belønningsmekanisme for satsede tokens
• Maktene til eieren
• Vil kontrakten inneholde ETH?
• Hvilke symboler vil kontrakten inneholde?
• Opprinnelig kontrakt som det er gaffel fra

Sjekk at spesifikasjonene samsvarer med koden. Begynn med avgifter og tokenomics, etterfulgt av validering av eierens autoritet. Sjekk at alle belønninger og gebyrverdier er i samsvar med dokumentasjonen.

Sårbare steder å se etter?

1. Belønningsuttaksmekanisme:

Sjekk at belønningsmekanismen for innsatssymboler er korrekt implementert og at belønningene fordeles rettferdig og proporsjonalt til alle deltakere. Prosjekter kan distribuere belønninger på to måter: enten automatisk, på periodisk basis, eller på forespørsel fra brukerne selv. En uttaksfunksjon kan implementeres og tilpasses i henhold til protokollens forretningslogikk.
Nedenfor er noen sjekkpunkter:

• Sjekk om noen bruker kan ta ut mer enn belønningen + innsatsbeløpet.
• Sjekk for Over-/underløp i mengdeberegningen
• Sjekk om visse parametere kan ha en negativ innvirkning på belønninger under beregningen.
• Hvis blokk.tidsstempel eller blokk.nummer brukes i denne funksjonen. Sjekk om det kan utnyttes på noen måte.

2. Gebyrlogikk:

Hvis innskuddet og uttaket er underlagt et gebyr, må du kontrollere at ingen enkelt bruker kan omgå gebyret. Vær i tillegg på vakt for potensielle problemer med overløp eller underflyt. Bare administratoren eller eieren skal ha tillatelse til å endre gebyrinnstillingene. Kontroller også at det er etablert en terskel for maksimale gebyrer, som hindrer administratoren i å sette den til et for høyt beløp.

3. LP Tokens prege-/forbrenningsmekanisme:

Kontroller om prege- og brenningsmekanismene er riktig implementert. En brennfunksjon skal reversere alle tilstandsendringer som er gjort av en mint-funksjon. I tillegg er det avgjørende å verifisere at brukere mottar riktig mengde tokens under den første innsatsen, når bassenget er tomt.

Logikken til prege- og brenningsfunksjoner kan matematisk verifiseres for å avdekke eventuelle skjulte sårbarheter. Den totale tilførselen av LP-tokens som er preget bør ikke overstige innsatsen.

4. Avrundingsfeil:

Selv om visse mindre avrundingsfeil vanligvis er uunngåelige og ikke et problem, kan de vokse betydelig når det er mulig å multiplisere dem. Se etter kanttilfeller hvor man kan tjene på avrundingsfeil ved gjentatte staking og unstaking.

For å finne ut om avrundingsfeil kan påløpe et betydelig beløp over en lengre periode, kan vi matematisk beregne rekkevidden av mulige avrundingsfeil.

5. Innsatsvarighet:

Sørg for at beregningene av innsatsvarighet i kontrakten stemmer overens med den angitte forretningslogikken. Bekreft at brukere ikke kan løse inn belønninger før innsatsvarigheten er over, ved å omgå varighetssjekkene. Sjekk også om varigheten av innsatsen kan utnyttes av en angriper for å få flere belønninger.

6. Eksterne samtaler og tokenhåndtering:

De fleste eksterne samtalene vil gå til token-kontraktene. Så vi må bestemme hvilke typer tokens innsatskontrakten skal håndtere. Det er viktig å sjekke eksterne anrop for eventuelle feil og reentrancy-angrep. Deflatoriske tokens eller tokens med overføringsgebyrer, for eksempel Safemoon, kan utgjøre et problem hvis logikken deres ikke er riktig implementert.

7. Prismanipulasjonssjekker:

Prismanipulering via et flashlån er et av de hyppigste hackene på DeFi-prosjekter. Det kan være situasjoner der ondsinnede aktører kan bruke flashlån for å manipulere priser under innsats eller unstaking av store mengder tokens. Gjennomgå innsats- og unstaking-funksjoner nøye for å unngå edge-case-scenarier som kan resultere i flash-lånbaserte prismanipulasjonsangrep og tap av andre brukeres midler.

8. Noen tilleggssjekker:

• Looper: Hvis kontraktslogikken involverer looping over arrays, er det viktig å sikre at blokkgassgrensen ikke overskrides. Dette kan oppstå når matrisestørrelsen er veldig stor, så du bør undersøke hvilke funksjoner som kan øke størrelsen på matrisen og om en bruker kan utnytte den til å forårsake et DoS-angrep. Sjekk ut dette rapporterer.
• Strukturer: Innsatskontrakter bruker strukturtypen for å lagre bruker- eller pooldata. Når du deklarerer eller får tilgang til en struktur i en funksjon, er det viktig å spesifisere om du skal bruke "minne" eller "lagring". Det kan hjelpe oss å spare litt gass. For mer informasjon, se til denne artikkelen.
• Frontløp: Se etter scenarier der ondsinnede aktører kan frontkjøre enhver transaksjon til deres fordel.
• Funksjonssynlighet/tilgangskontrollkontroller: Enhver funksjon som er erklært som ekstern eller offentlig kan nås av alle. Derfor er det viktig å sikre at ingen offentlig funksjon kan utføre noen sensitive handlinger. Det er avgjørende å verifisere at innsatsprotokollen har implementert passende kontroller for å hindre uautorisert tilgang til både de utsatte myntene og systemets infrastruktur.
• Sentraliseringsrisikoer: Det er viktig å ikke gi eieren overdrevne fullmakter. Hvis admin-adressen er kompromittert, kan det forårsake betydelig skade på protokollen. Bekreft at eier- eller administratorrettighetene er riktige, og sørg for at protokollen har en plan for håndtering av situasjoner der en administrators private nøkler lekkes.
• ETH / WETH håndtering: Kontrakter inkluderer ofte spesifikk logikk for håndtering av ETH. For eksempel, når msg.value > 0, kan en kontrakt konvertere ETH til WETH mens den fortsatt lar WETH mottas direkte. Når en bruker spesifiserer WETH som valuta, men sender ETH med anropet, kan dette bryte visse invarianter og føre til feil oppførsel.

Så langt har vi diskutert likviditetssatsingsprotokoller og revisjonsretningslinjene for slike protokoller. I et nøtteskall lar likviditetssatsing brukere tjene innsatsbelønninger uten å ofre likviditet. Vi har skissert de sårbare punktene i innsatskontrakter som revisorer må være oppmerksomme på, for eksempel uttaksmekanismer, gebyrlogikk, LP-token prege-/brenningsmekanisme, avrundingsfeil, innsatsvarighet, eksterne samtaler og prismanipulasjonssjekker. 

Vi anbefaler revisorer å undersøke dokumenter med revisjonsspesifikasjoner, matche spesifikasjoner med kode og sjekke honorarer og tokenomikkvalidering. Vi anbefaler også tilleggskontroller som looping over arrays, spesifisering av minne eller lagring for strukturtypedata og scenarier som kjører i forkant. Disse retningslinjene vil være nyttige for å revidere stakingprotokoller og hjelpe med å identifisere potensielle feil.

---

11 Visninger

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://blog.quillhash.com/2023/03/10/guidelines-for-auditing-staking-protocols/