Ghid pentru auditarea protocoalelor de staking

Timp de citit: 6 minute

În acest blog, am subliniat conceptul de protocoale de miza de lichiditate și liniile directoare de audit pentru protocoalele de mizație. Orientările acoperă o serie de puncte vulnerabile, cum ar fi mecanismele de retragere, erorile de rotunjire, apelurile externe, logica taxelor, buclele, structurile, durata de miză etc. Această postare de blog va fi o referință utilă pentru auditarea protocoalelor de miză și vă poate ajuta să identificați erori potențiale .

Ce este miza de lichiditate?

Miza de lichiditate permite utilizatorilor să-și mizeze deținerile de criptomonede și să câștige recompense fără a sacrifica lichiditatea. În loc să-și blocheze monedele pentru o perioadă fixă, utilizatorii pot primi un jeton lichid care reprezintă activele lor mizate. Acest token poate fi tranzacționat sau folosit ca orice altă criptomonedă, permițând utilizatorilor să-și folosească activele după bunul plac, în timp ce câștigă recompense de miză.

De exemplu, aveți 100 ETH pe care doriți să mizați în rețeaua Ethereum. În loc să vă blocați ETH pentru o perioadă fixă, puteți utiliza un serviciu de miza de lichiditate precum Lido pentru a vă miza ETH și pentru a primi un token lichid numit stETH în schimb. Cu stETH, puteți în continuare să tranzacționați sau să utilizați ETH-ul mizat în timp ce câștigați recompense de miză.

Să începem cu auditarea contractelor de staking:

Examinați toate specificațiile de audit disponibile înainte de a începe cu codul contractului. Ar putea fi sub formă de hârtie albă, fișiere README sau altceva. Acestea vă vor oferi o idee despre ce va conține codul contractului.

Când vă uitați la documentul cu specificațiile de audit pentru contractul de staking, căutați următoarele puncte:

• Tipuri de taxe bazate și calculele acestora.
• Mecanism de recompense pentru jetoanele mizate
• Puterile proprietarului
• Contractul va păstra ETH?
• Ce simboluri va deține contractul?
• Contractul original din care este bifurcat

Verificați dacă specificațiile corespund codului. Începeți cu taxe și tokenomics, urmate de validarea autorității proprietarului. Verificați dacă toate recompensele și valorile taxelor sunt în conformitate cu documentația.

Locuri vulnerabile de căutat?

1. Mecanismul de retragere a recompensei:

Verificați dacă mecanismul de recompense cu token mizat este implementat corect și că recompensele sunt distribuite corect și proporțional tuturor participanților. Proiectele pot distribui recompense în două moduri: fie automat, periodic, fie la cererea utilizatorilor înșiși. O funcție de retragere poate fi implementată și personalizată conform logicii de afaceri a protocolului.
Mai jos sunt câteva puncte de control:

• Verificați dacă vreun utilizator poate retrage mai mult decât recompensa + suma mizată.
• Verificați pentru depășire/depășire în calculul sumei
• Verificați dacă anumiți parametri pot avea un impact negativ asupra recompenselor în timpul calculului.
• Dacă în această funcție se utilizează block.timestamp sau block.number. Verificați dacă poate fi exploatat în vreun fel.

2. Logica taxei:

Dacă depunerea și retragerea sunt supuse unor taxe, atunci verificați că niciun utilizator nu poate ocoli taxa. În plus, fiți vigilenți pentru orice posibile probleme de depășire sau de depășire. Numai administratorul sau proprietarul ar trebui să fie autorizat să modifice setările de taxe. De asemenea, verificați dacă a fost stabilit un prag pentru taxele maxime, împiedicând administratorul să îl stabilească la o sumă excesiv de mare.

3. Mecanismul de batere/ardere al Jetonului LP:

Verificați dacă mecanismele de batere și ardere au fost corect implementate. O funcție de ardere ar trebui să inverseze toate modificările de stare făcute de o funcție de mentă. În plus, este crucial să se verifice dacă utilizatorii primesc cantitatea adecvată de jetoane în timpul primei mize, când pool-ul este gol.

Logica funcțiilor de batere și ardere poate fi verificată matematic pentru a descoperi orice vulnerabilitate ascunsă. De asemenea, oferta totală de jetoane LP bătute nu trebuie să depășească activele mizate.

4. Erori de rotunjire:

Chiar dacă anumite greșeli minore de rotunjire sunt de obicei inevitabile și nu reprezintă o preocupare, ele pot crește semnificativ atunci când este posibil să le înmulțim. Căutați cazuri limită în care se poate profita de pe urma erorilor de rotunjire prin mizarea și anularea în mod repetat.

Pentru a determina dacă erorile de rotunjire se pot acumula într-o sumă substanțială pe o perioadă lungă de timp, putem calcula matematic intervalul posibilelor erori de rotunjire.

5. Durata mizarii:

Asigurați-vă că calculele duratei de mizare din contract sunt aliniate cu logica de afaceri specificată. Verificați dacă utilizatorii nu pot răscumpăra recompense înainte ca durata de miză să se încheie, ocolind verificările duratei. De asemenea, verificați dacă durata mizarii poate fi exploatată de un atacator pentru a obține mai multe recompense.

6. Apeluri externe și gestionarea jetoanelor:

Majoritatea apelurilor externe vor fi către contractele cu simboluri. Deci, trebuie să stabilim ce tipuri de jetoane va gestiona contractul de miza. Este esențial să verificați apelurile externe pentru eventuale erori și atacuri de reintrare. Jetoanele deflaționiste sau jetoanele cu taxe de transfer, cum ar fi Safemoon, pot reprezenta o problemă dacă logica lor nu este implementată corect.

7. Verificări de manipulare a prețurilor:

Manipularea prețului printr-un împrumut flash este unul dintre cele mai frecvente hack-uri pe proiecte DeFi. Pot exista situații în care actorii rău intenționați pot folosi împrumuturi flash pentru a manipula prețurile în timpul mizarii sau a dezafectării unor cantități mari de jetoane. Examinați cu atenție funcțiile de staking și unstaking pentru a evita scenariile marginale care ar putea duce la atacuri flash de manipulare a prețurilor bazate pe împrumuturi și pierderea fondurilor altor utilizatori.

8. Câteva verificări suplimentare:

• buclele: Dacă logica contractului implică bucla peste matrice, este important să vă asigurați că limita de gaz bloc nu este depășită. Acest lucru poate apărea atunci când dimensiunea matricei este foarte mare, așa că ar trebui să investigați ce funcții ar putea crește dimensiunea matricei și dacă orice utilizator l-ar putea exploata pentru a provoca un atac DoS. Verifica asta raportează.
• Structuri: Contractele de staking folosesc tipul de structura pentru a stoca date despre utilizatori sau pool. Când declarați sau accesați o structură într-o funcție, este important să specificați dacă să folosiți „memorie” sau „stocare”. Ne poate ajuta să economisim niște gaz. Pentru mai multe informații, vă rugăm să consultați la acest articol.
• Având în frunte: Căutați orice scenarii în care actorii rău intenționați ar putea conduce orice tranzacție în avantajul lor.
• Verificări ale vizibilității/controlului accesului: Orice funcție care este declarată externă sau publică poate fi accesată de oricine. Prin urmare, este important să ne asigurăm că nicio funcție publică nu poate efectua acțiuni sensibile. Este esențial să se verifice dacă protocolul de miză a implementat controale adecvate pentru a preveni accesul neautorizat atât la monedele mizate, cât și la infrastructura sistemului.
• Riscuri de centralizare: Este important să nu se acorde proprietarului puteri excesive. Dacă adresa de administrator este compromisă, ar putea cauza daune semnificative protocolului. Verificați dacă privilegiile de proprietar sau de administrator sunt adecvate și asigurați-vă că protocolul are un plan în vigoare pentru gestionarea situațiilor în care cheile private ale unui administrator sunt scurse.
• Manipulare ETH / WETH: Contractele includ adesea o logică specifică pentru gestionarea ETH. De exemplu, când msg.value > 0, un contract poate converti ETH în WETH, permițând în același timp să fie primit direct WETH. Când un utilizator specifică WETH ca monedă, dar trimite ETH împreună cu apelul, acest lucru poate rupe anumite invariante și poate duce la un comportament incorect.

Până acum, am discutat despre protocoalele de participare a lichidității și liniile directoare de audit pentru astfel de protocoale. Pe scurt, miza de lichiditate permite utilizatorilor să câștige recompense de miză fără a sacrifica lichiditatea. Am evidențiat punctele vulnerabile din contractele de miză cărora auditorii trebuie să le acorde atenție, cum ar fi mecanismele de retragere, logica taxelor, mecanismul de batere/ardere a jetoanelor LP, erori de rotunjire, durata de mizare, apeluri externe și verificări de manipulare a prețurilor. 

Recomandăm auditorilor să examineze documentele cu specificațiile de audit, să potrivească specificațiile cu codul și să verifice taxele și validarea tokenomics. De asemenea, recomandăm verificări suplimentare, cum ar fi bucla peste matrice, specificarea memoriei sau stocării pentru date de tip struct și scenarii de avansare. Aceste instrucțiuni vor fi utile pentru auditarea protocoalelor de miză și vor ajuta la identificarea erorilor potențiale.

---

11 Vizualizări

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
• Sursa: https://blog.quillhash.com/2023/03/10/guidelines-for-auditing-staking-protocols/