Riktlinjer för revision av insättningsprotokoll

Riktlinjer för revision av insättningsprotokoll

Tidsstämpel: 10 mars 2023 6:57

Lästid: 6 minuter

I den här bloggen har vi beskrivit konceptet med likviditetsinsättningsprotokoll och revisionsriktlinjer för insatsprotokoll. Riktlinjerna täcker en rad sårbara punkter som uttagsmekanismer, avrundningsfel, externa samtal, avgiftslogik, loopar, strukturer, insatsvaraktighet, etc. Det här blogginlägget kommer att vara en användbar referens för granskning av insättningsprotokoll och kan hjälpa dig att identifiera potentiella buggar .

Vad är likviditetsinsats?

Likviditetssatsning tillåter användare att satsa sina kryptovalutainnehav och tjäna belöningar utan att offra likviditet. Istället för att låsa in sina mynt under en bestämd period kan användare få en flytande token som representerar deras insatta tillgångar. Denna token kan handlas eller användas som vilken annan kryptovaluta som helst, vilket gör att användare kan använda sina tillgångar som de vill samtidigt som de tjänar insatsbelöningar.

Riktlinjer för granskning av insättningsprotokoll PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.

Till exempel har du 100 ETH du vill satsa på Ethereum-nätverket. Istället för att låsa din ETH under en bestämd period kan du använda en likviditetsinsatstjänst som Lido för att satsa din ETH och få en flytande token som kallas stETH i gengäld. Med stETH kan du fortfarande handla eller använda din insatsade ETH samtidigt som du tjänar insatsbelöningar.

Låt oss börja med att granska insatskontrakt:

Granska alla tillgängliga revisionsspecifikationer innan du börjar med kontraktskoden. Det kan vara i form av ett vitt papper, README-filer eller något annat. Dessa kommer att ge dig en uppfattning om vad avtalskoden kommer att innehålla.

När du tittar på revisionsspecifikationen för insatskontraktet, leta efter dessa punkter:

  • Typer av avgifter baserade och deras beräkningar.
  • Belöningsmekanism för insatta polletter
  • Ägarens befogenheter
  • Kommer kontraktet att hålla ETH?
  • Vilka symboler kommer kontraktet att innehålla?
  • Ursprungligt kontrakt från vilket det är gaffelt

Kontrollera att specifikationerna matchar koden. Börja med avgifter och tokenomics, följt av validering av ägarens behörighet. Kontrollera att alla belöningar och avgiftsvärden överensstämmer med dokumentationen.

Sårbara platser att leta efter?

1. Belöningsuttagsmekanism:

Kontrollera att belöningsmekanismen för insatsade token är korrekt implementerad och att belöningar fördelas rättvist och proportionellt till alla aktörer. Projekt kan dela ut belöningar på två sätt: antingen automatiskt, på periodisk basis eller på begäran av användarna själva. En uttagsfunktion kan implementeras och anpassas enligt protokollets affärslogik.
Nedan finns några kontrollpunkter:

  • Kontrollera om någon användare kan ta ut mer än sin belöning + insatsbelopp.
  • Kontrollera om det finns bräddavlopp/underflöde i beloppsberäkningen
  • Kontrollera om vissa parametrar kan ha en negativ inverkan på belöningar under beräkningen.
  • Om block.timestamp eller block.number används i denna funktion. Kontrollera om det kan utnyttjas på något sätt.

2. Avgiftslogik:

Om insättningen och uttaget är föremål för någon avgift, kontrollera att ingen enskild användare kan kringgå avgiften. Var dessutom uppmärksam på eventuella problem med spill eller underflöde. Endast administratören eller ägaren ska ha behörighet att ändra avgiftsinställningar. Kontrollera också att en tröskel för maximala avgifter har fastställts, vilket hindrar administratören från att sätta det till ett för högt belopp.

3. LP Tokens präglings-/förbränningsmekanism:

Kontrollera om präglings- och brännmekanismerna har implementerats korrekt. En bränningsfunktion bör vända alla tillståndsändringar som gjorts av en mintfunktion. Dessutom är det viktigt att verifiera att användarna får rätt mängd tokens under den första insatsen, när poolen är tom.

Logiken i minting- och bränningsfunktioner kan matematiskt verifieras för att avslöja eventuella dold sårbarhet. Dessutom bör det totala utbudet av LP-poletter som präglas inte överstiga de insatta tillgångarna.

4. Avrundningsfel:

Även om vissa mindre avrundningsmisstag vanligtvis är oundvikliga och inte ett problem, kan de växa avsevärt när det är möjligt att multiplicera dem. Leta efter kantfall där man kan dra nytta av avrundningsfel genom att upprepade gånger satsa och avsatsa.

För att avgöra om avrundningsfel kan uppstå till en betydande mängd under en längre tidsperiod, kan vi matematiskt beräkna intervallet av möjliga avrundningsfel.

5. Insatslängd:

Se till att beräkningarna av insatsvaraktigheten i kontraktet överensstämmer med den angivna affärslogiken. Verifiera att användare inte kan lösa in belöningar innan insatstiden har avslutats genom att kringgå varaktighetskontrollerna. Kontrollera också om insatsens varaktighet kan utnyttjas av en angripare för att få fler belöningar.

6. Externa samtal och tokenhantering:

De flesta av de externa samtalen kommer att gå till tokenkontrakten. Så vi måste bestämma vilka typer av tokens som insatskontraktet kommer att hantera. Det är viktigt att kontrollera externa samtal för eventuella fel och återinträdesattacker. Deflatoriska tokens eller tokens med överföringsavgifter, såsom Safemoon, kan utgöra ett problem om deras logik inte är korrekt implementerad.

7. Prismanipulationskontroller:

Prismanipulation via ett flashlån är ett av de vanligaste hackarna på DeFi-projekt. Det kan finnas situationer där illvilliga aktörer kan använda flashlån för att manipulera priserna under utsättning eller avstängning av stora mängder tokens. Granska insättnings- och avsättningsfunktionerna noggrant för att undvika scenarier som kan leda till snabblånebaserade prismanipulationsattacker och förlust av andra användares pengar.

8. Några ytterligare kontroller:

  • Öglor: Om kontraktslogiken innebär looping över matriser är det viktigt att se till att blockgasgränsen inte överskrids. Detta kan inträffa när arraystorleken är mycket stor, så du bör undersöka vilka funktioner som kan öka storleken på arrayen och om någon användare kan utnyttja den för att orsaka en DoS-attack. Kolla in det här rapport.
  • Strukturer: Insatskontrakt använder struct-typen för att lagra användar- eller pooldata. När du deklarerar eller får åtkomst till en struktur inom en funktion är det viktigt att ange om du ska använda "minne" eller "lagring". Det kan hjälpa oss att spara lite gas. För mer information, se till den här artikeln.
  • Framkörning: Leta efter alla scenarier där illvilliga aktörer kan köra alla transaktioner till sin fördel.
  • Funktionssynlighet/ åtkomstkontrollkontroller: Alla funktioner som är deklarerade som externa eller offentliga kan nås av vem som helst. Därför är det viktigt att säkerställa att ingen offentlig funktion kan utföra några känsliga handlingar. Det är avgörande att verifiera att insättningsprotokollet har implementerat lämpliga kontroller för att förhindra obehörig åtkomst till både de utsatta mynten och systemets infrastruktur.
  • Centraliseringsrisker: Det är viktigt att inte ge ägaren överdrivna befogenheter. Om administratörsadressen äventyras kan det orsaka betydande skada på protokollet. Verifiera att ägaren eller administratörsbehörigheterna är lämpliga och se till att protokollet har en plan för hantering av situationer där en administratörs privata nycklar läcker.
  • ETH/WETH-hantering: Kontrakt innehåller ofta specifik logik för hantering av ETH. Till exempel, när msg.value > 0, kan ett kontrakt konvertera ETH till WETH samtidigt som det tillåter att WETH tas emot direkt. När en användare anger WETH som valuta men skickar ETH med anropet kan detta bryta vissa invarianter och leda till felaktigt beteende.

Hittills har vi diskuterat protokoll för likviditetsinsättning och revisionsriktlinjerna för sådana protokoll. I ett nötskal, likviditetsinsatser tillåter användare att tjäna insatsbelöningar utan att offra likviditet. Vi har beskrivit de sårbara ställena i insatskontrakt som revisorer måste vara uppmärksamma på, såsom uttagsmekanismer, avgiftslogik, mekanism för myntning/förbränning av LP-token, avrundningsfel, insatsvaraktighet, externa samtal och kontroller av prismanipulation. 

Vi rekommenderar revisorer att granska revisionsspecifikationsdokument, matcha specifikationer med kod och kontrollera avgifter och tokenomics-validering. Vi rekommenderar också ytterligare kontroller såsom looping över arrayer, specificering av minne eller lagring för strukturtypdata och front-running scenarier. Dessa riktlinjer kommer att vara användbara för att granska insättningsprotokoll och hjälpa till att identifiera potentiella buggar.

11 Visningar

Tidsstämpel:

Mer från Pilbåt