Un audit al contractelor inteligente este o încercare structurată de a descoperi cum un contract poate eșua, poate fi utilizat greșit sau poate fi controlat într-un mod neașteptat de utilizatori. Nu este același lucru cu rularea unui scaner, citirea unei insignă de audit sau confirmarea faptului că codul sursă este verificat. Utilizați fluxul de lucru de mai jos pentru a revizui un contract EVM implementat sau o bază de cod înainte de a-i încredința fonduri semnificative.
Important: Acesta este un cadru practic de evaluare, nu o garanție că un proiect este sigur și nu oferă sfaturi de investiții. Un protocol de producție cu o valoare substanțială ar trebui să fie evaluat independent de către profesioniști cu experiență în domeniul securității. Imaginile în stil interfață din acest ghid sunt ilustrative și nu ar trebui tratate ca dovezi despre un anumit proiect sau o implementare.
| Pas | Întrebare principală | Dovezi utile |
|---|---|---|
| 1. Domeniu de aplicare | Revizuiesc exact contractul pe care îl solicită utilizatorii? | Adresă, lanț, bytecode, proxy și implementare |
| 2. Puncte de intrare | Ce poate face fiecare apelant? | Funcții publice/externe, schimbări de stare, graf de apeluri |
| 3. Automatizare | Ce modele evidente merită atenție? | Rezultatul compilatorului, constatările Slither, triajul detectorului |
| 4. Securitate manuală | Poate o secvență de apeluri să încalce presupunerile? | Apeluri externe, reintrare, apeluri inverse, gestionarea defecțiunilor |
| 5. Logică | Contabilitatea rămâne corectă în cazurile limită? | Aritmetică, rotunjire, taxe, limite, tranziții de stare |
| 6. Privilegii | Cine poate schimba sau opri sistemul? | Roluri, proprietar, chei de administrator, proxy, inițializator |
| 7. Testarea | Se menține comportamentul în cazul unor intrări și secvențe neașteptate? | Teste unitare, fuzz, invariante și fork |
| 8. Raportare | Poate o altă persoană reproduce și retesta rezultatul? | Starea constatărilor, impactului, dovezilor, remedierilor și retestării |
Începeți cu lanțul și adresa exacte. Înregistrați adresa de implementare, hash-ul tranzacției, numărul blocului, versiunea compilatorului, setările optimizatorului, argumentele constructorului și commit-ul sau versiunea despre care echipa spune că este implementată. Un proiect poate avea mai multe adrese pentru un token, un router, un seif, un proxy, o implementare, un oracol sau o implementare de test. O verificare a adresei greșite nu are nicio valoare practică.
Verificați dacă sursa verificată a explorerului reproduce bytecode-ul implementat. Verificarea este utilă deoarece vă permite să inspectați sursa și ABI-ul, dar este doar o verificare a identității: nu dovedește că logica de business este sigură. Dacă contractul este actualizabil, identificați atât proxy-ul, cât și implementarea sa curentă. Citiți adresa de implementare din mecanismul documentat al proxy-ului sau din informațiile explorerului, apoi confirmați că implementarea este cea pe care intenționați să o revizuiți. Ghidul oficial de verificare Foundry al Etherscan documentează verificarea pentru contractele noi și existente.
De asemenea, definiți limita. Includeți bibliotecile importate, contractele moștenite, bibliotecile legate, contractele helper implementate, adaptoarele Oracle, token-urile primite de la utilizatori și componentele privilegiate off-chain. Notați ce este în afara domeniului de aplicare și de ce. Acest lucru previne ca o revizuire restrânsă să fie confundată cu o revizuire a întregului sistem.
Enumerați fiecare funcție publică și externă, inclusiv funcțiile moștenite și rutinele de gestionare a primirilor sau de rezervă. Pentru fiecare dintre ele, înregistrați dacă aceasta poate:
Apoi, mapați activele și limitele de încredere. Urmăriți un depozit de la utilizator în spațiul de stocare, prin calcularea prețurilor și a cotelor, până la retragere. Identificați fiecare adresă furnizată de un apelant și fiecare adresă încărcată din spațiul de stocare. Întrebați care valori sunt considerate corecte: un oracol, un token, un mesaj bridge, un keeper, un receptor de apel invers sau un administrator. Țintele de revizuire cu cea mai mare valoare sunt funcțiile care combină inputul controlat de utilizator, starea privilegiată, aritmetica și un apel extern.
Reproduceți versiunea proiectului cu versiunea Solidity, versiunile de dependențe, configurația optimizatorului și ipotezele lanțului țintă menționate. Tratați avertismentele compilatorului ca elemente de revizuire, mai degrabă decât ca zgomot inofensiv. Considerațiile de securitate ale Solidity recomandă în mod specific luarea în serios a avertismentelor, menținerea unor contracte ușor de înțeles și verificarea problemelor cunoscute ale compilatorului. Consultați lista oficială a erorilor cunoscute ale compilatorului Solidity atunci când versiunea compilatorului sau modelele de cod afectate o fac relevantă.
Pentru un proiect Hardhat, Foundry sau similar, rulați Slither din rădăcina proiectului. Documentația oficială descrie instrumentul ca un analizor static Solidity și Vyper și oferă comanda comună:
slither .Salvați rezultatul și evaluați fiecare rezultat în funcție de impact și încredere. Examinați cu atenție descoperirile care implică trimiteri arbitrare de token-uri, upgrade-uri neprotejate, reintrare, valori returnate neverificate, apeluri delegate periculoase, tx.origin, aleatorietate slabă și interfețe incorecte. Un detector poate raporta un fals pozitiv, poate rata o eroare economică specifică proiectului sau poate semnala cod care este intenționat constrâns în altă parte. Analiza statică restrânge căutarea; nu înlocuiește raționamentul manual. Depozitul și documentația Slither listează, de asemenea, imprimante pentru puncte de intrare, autorizare, grafice de apeluri și rezumate de contracte care ajută la organizarea unei revizuiri.
Pentru fiecare apel extern, opriți și urmăriți starea înainte, în timpul și după apel. Apelatul poate fi un contract malițios, un token cu hook-uri, un receptor de apel invers sau un alt protocol care modifică o dependență partajată. Documentația Solidity explică faptul că o interacțiune cu un alt contract poate transfera controlul către acel contract și recomandă modelul Checks-Effects-Interactions: validați mai întâi, actualizați starea acestui contract a doua oară și interacționați extern la urmă.
Nu limitați căutarea la transferuri Ether evidente. Verificați hook-urile în stil ERC-777, apelurile inverse ERC-1155, apelurile inverse flash-loan, ruterele arbitrare, apelurile oracle și apelurile efectuate prin bibliotecile moștenite. Verificați reintrarea între funcții și contracte: un apel invers poate intra într-o funcție diferită care citește o stare intermediară. Confirmați că fiecare apel de nivel scăzut își verifică rezultatul succesului și gestionează corect o valoare returnată. Întrebați dacă un destinatar eșuat poate bloca permanent retragerile sau o buclă.
Înregistrați o secvență de atac concretă pentru fiecare problemă plauzibilă. De exemplu: atacatorul depune bani, începe o retragere, primește un apel invers, reintroduce o a doua retragere și abia apoi permite finalizarea primului apel. Dacă secvența nu poate fi făcută să funcționeze din cauza unui invariant sau a unei gărzi specifice, notați motivul respectiv. Acest lucru face ca concluzia să fie auditabilă, mai degrabă decât speculativă.
Verificați semnificația fiecărei unități și conversii: wei versus ether, zecimale token, puncte de bază, acțiuni versus active, valori cu semn și unități de timp. Urmați direcția de rotunjire. O împărțire care rotunjește în favoarea unui deponent, împrumutat, lichidator sau beneficiar de comisioane poate pierde valoare atunci când este repetată. Verificați înmulțirea înainte de împărțire, sumele minime și maxime, plafoanele comisioanelor, prețurile neactualizate, oferta zero, soldul zero și primul deponent sau ultimul retrăgător.
Solidity 0.8 și versiunile ulterioare detectează în mod normal depășirea și depășirea valorilor aritmetice, dar codul din interiorul unui uncheckedbloc modifică în mod deliberat acest comportament. Aritmetica verificată poate, de asemenea, face ca un protocol să revină la normal sau să devină inutilizabil dacă limitele nu sunt proiectate corect. Testați ambele rezultate: furt sau contabilizare incorectă și denial of service cauzat de o valoare care nu poate fi niciodată procesată.
Scrieți invarianții în limbaj simplu înainte de a-i transforma în teste. Exemplele includ „acțiunile totale corespund activelor conform regulii de rotunjire menționate”, „un utilizator nu poate retrage mai mult decât creanța sa înregistrată”, „oferta totală de tokenuri este egală cu suma soldurilor acolo unde se aplică modelul respectiv” și „o taxă nu poate depăși plafonul configurat”. Comparați soldurile de stocare cu soldurile reale ale tokenurilor, deoarece tokenurile pot fi trimise direct către un contract sau se pot comporta diferit față de implementarea ERC-20 presupusă.
Construiți o matrice de privilegii. Pentru fiecare funcție administrativă, identificați rolul necesar, deținătorul actual, mecanismul de transfer, întârzierea, controlul cu semnături multiple sau guvernanță și comportamentul în situații de urgență. Acordați o atenție deosebită creării de funcții, pauzei, modificării taxelor, modificării surselor Oracle, recuperării fondurilor, actualizării codului și modificării adreselor de token sau router de încredere. Documentația OpenZeppelin privind controlul accesului distinge proprietatea simplă de permisiunile bazate pe roluri și descrie privilegiile minime ca o practică de securitate utilă.
Separați „codul permite unui administrator să facă asta” de „un utilizator arbitrar poate face asta”. Prima poate fi un risc explicit de guvernanță sau custodie; a doua este o vulnerabilitate de autorizare. Verificați dacă verificările de rol acoperă fiecare cale sensibilă, inclusiv asistenții interni accesibili din funcțiile publice. Verificați dacă un administrator implicit își poate acorda lui însuși sau altora puteri suplimentare și dacă transferul de proprietate poate fi trimis accidental către o adresă inutilizabilă.
Pentru proxy-uri, examinați inițializatorul, autorizația de implementare, întârzierea de actualizare, structura de stocare și planul de revenire la normal sau de urgență. Ghidul OpenZeppelin privind contractele actualizabile explică de ce constructorii nu inițializează stocarea proxy, de ce inițializatorii trebuie protejați, de ce o implementare nu ar trebui să rămână neinițializată și de ce schimbarea ordinii sau a tipurilor de stocare poate corupe o actualizare. Tratați o cheie de administrator proxy ca parte a limitei de securitate a protocolului, nu ca un detaliu de implementare.
Executați teste unitare pentru comportamentul așteptat, apoi adăugați teste negative pentru apelanți neautorizați, valori zero, valori maxime, semnături expirate, date Oracle învechite, transferuri eșuate și operații repetate. Analizați intrările în loc să testați doar câteva numere selectate manual. Includeți actori multipli și contracte de receptori rău intenționați acolo unde designul permite apeluri inverse.
Folosește testarea invariabilă pentru proprietățile care trebuie să rămână adevărate după mai multe apeluri randomizate. Documentația de testare invariabilă Foundry descrie secvențe randomizate, intrări fuzzed, rulări, adâncime, contracte țintă și expeditori țintă. Configura handlere-uri astfel încât apelurile să fie semnificative; dacă fiecare depunere fuzzed este anulată deoarece actorul de testare nu are token-uri, un invariant care trece poate însemna pur și simplu că nicio stare utilă nu s-a schimbat.
Când este posibil, utilizați o bifurcație a rețelei țintă pentru a exersa adresele implementate, configurația curentă, comportamentul token-urilor și rutarea proxy. Păstrați testele fork în siguranță și doar pentru citire, cu excepția cazului în care utilizați o bifurcație locală izolată. Minimizați fiecare secvență eșuată și păstrați contraexemplu, adresele apelantului, contextul blocului, soldurile și valorile de stocare relevante. Un test care trece este o dovadă despre căile testate, nu o dovadă a tuturor căilor posibile.
Folosiți o singură înregistrare per problemă. O constatare practică ar trebui să conțină:
Severitatea ar trebui să reflecte impactul realist și exploatabilitatea, nu cât de alarmant arată un model de cod. Explicați presupunerile. Un apel de nivel scăzut poate fi în siguranță în spatele unui invariant puternic; o modificare aparent obișnuită a parametrilor poate fi critică dacă controlează un oracol sau o actualizare. După o corecție, revizuiți diferența, rulați din nou testul relevant, rulați din nou suita completă și verificați dacă există regresii. Dacă adresa implementată a fost deja actualizată sau modificată, retestați implementarea și configurația on-chain.
Ar trebui să poți răspunde cu da la aceste întrebări:
Dacă vreun răspuns este nu, etichetați auditul ca fiind incomplet și menționați dovezile lipsă. O limitare transparentă este mai utilă decât o concluzie vagă „sigură”. Securitatea contractelor inteligente este un proces continuu: fiecare actualizare, modificare a dependenței, integrare nouă și modificare a privilegiilor poate crea o nouă limită de revizuire.
Learn how to allocate crypto by risk tolerance, time horizon, diversification, custody, liquidity, and rebalancing—without relying on a one-size-fits-all formula.
Învață cum să auditezi pas cu pas contractul inteligent al unui proiect cripto, de la verificarea permisiunilor de implementare și mapare până la testarea logicii, actualizărilor și remedierilor.
Construiește un portofoliu pe termen lung de criptomonede cu un cadru axat pe risc pentru alocare, selecție de active, custodie, disciplină de cumpărare, reechilibrare, evidențe și evitarea înșelăciunilor.
Learn how to read on-chain data, track whale wallets, evaluate smart-money labels, and separate verifiable blockchain facts from inference before acting on wallet activity.
Află de ce platformele futures pentru criptomonede afișează o eroare „Marjă insuficientă”, cum să diagnostichezi cauza, să o remediezi în siguranță și să eviți problemele legate de marjă înainte de a plasa următoarea tranzacție.
Află cum funcționează Binance Launchpad și Launchpool, cum să verifici eligibilitatea, să te alături în siguranță, să urmărești recompensele și să înțelegi limitele și riscurile.
Află ce înseamnă „toleranță de alunecare depășită” pe CEX-uri și DEX-uri, cum să verifici dacă o tranzacție a eșuat și când să actualizezi, să reduci dimensiunea, să utilizezi un ordin limită sau să ajustezi toleranța.
Learn how Bybit Copy Trading works, how to evaluate Master Traders, set copy parameters, manage risk, and monitor copied USDT perpetual trades.
Află cum oferta, cererea, deblocările, emisiile, consumurile și utilitatea de tokenuri pot afecta prețul unei criptomonede - și ce nu poate prezice tokenomica.
Învață cum să compari volumul criptomonedelor cu valoarea sa de referință, să confirmi depășirile de preț, să identifici momentumul care scade și să eviți să confundi o creștere manipulată cu o creștere puternică.
