📝 Salutare tuturor, eu sunt 𝟏𝟎, să fiu sincer, îmi este frică, nu din cauza tehnologiei în sine, ci pentru că încă folosim o mentalitate veche de apărare pentru a face față unui adversar nou, înarmat cu AI.
Datele deja spun totul: în Q1 2026, atacurile DeFi au atins un nou maxim; în Q2 abia a început și deja ne apropiem de vârf. În trecut, credeam că atacurile de nivel național sunt un pic exagerate, dar de la KelpDAO, Step Finance până la WazirX, acest risc devine din ce în ce mai concret.
KelpDAO este un exemplu foarte tipic. Problema nu este în vulnerabilitățile codului, ci în moștenire. Au folosit configurația implicită a LayerZero, care permite unui singur validator să confirme mesajele între lanțuri, fără a fi inclusă în audit. Rezultatul este că 292 milioane de dolari au dispărut într-un timp extrem de scurt.
Riscurile actuale nu mai sunt doar dacă codul este scris greșit, ci că s-ar putea să nu știi nici măcar ce riscuri ai moștenit.
👇👇👇
Unu, odată cu venirea AI-ului, atacurile și apărarea nu mai sunt echitabile.
În trecut, credeam că, atâta timp cât auditul este suficient de detaliat, setările multi-semnătură sunt suficient de sigure, plus măsurile de timp de blocare, totul este deja stabil și mă simt mai în siguranță.
Dar acum situația este un pic diferită, oamenii ar putea necesita câteva săptămâni pentru a verifica cu atenție configurațiile a sute de protocoale; dar AI-ul poate face acest lucru în câteva ore. Și AI-ul Mythos de la Anthropic poate transforma chiar și o vulnerabilitate cunoscută într-un instrument de atac direct exploatabil în 24 de ore, cu un cost de sub 50 de dolari.
Aceasta a adus două schimbări foarte reale:
În primul rând, acele vulnerabilități pe care credeai că puțini le pot descoperi, acum AI-ul le poate găsi în masă.
În al doilea rând, în timp ce te străduiești să previi toate vulnerabilitățile, atacatorii folosesc deja AI pentru scanări la scară largă.
De aceea, acum mă îndrept spre o gândire mai practică: în loc să presupun că sistemul este în siguranță, mai bine să presupun că va fi atacat la un moment dat. Este mai important să planifici cum să oprești rapid pierderile și să controlezi daunele, în loc să aștepți.
Pe scurt: în loc să încerci să blochezi toate porțile, mai bine să te gândești cum să minimizezi daunele dacă o poartă este deschisă.
Doi, cel mai temut nu este bug-ul din contract, ci bug-ul uman.
Această afirmație nu este a mea, ci datele ne spun asta. Până în Q1 2026, pierderile din întreaga industrie cauzate de phishing și atacuri de inginerie socială vor reprezenta peste 65%, suma fiind de aproximativ 306 milioane de dolari.
De exemplu, incidentul WazirX de 230 de milioane de dolari, problema nu a fost în contractul inteligent, ci în cheile private ale administratorului portofelului multi-semnătură care au fost furate. Atacatorul a obținut accesul și a modificat direct logica portofelului.
Adică: contractul este sigur, procesul este bine gândit, dar persoanele cu permisiuni au fost păcălite sau compromise, iar totul s-a dus de râpă.
Nu te baza doar pe un portofel multi-semnătură; poți să îți gestionezi banii pentru diferite scopuri separat, folosind structuri multi-semnătură diferite pentru a controla riscurile. De asemenea, un alt aspect crucial: nu amesteca cheile cu dispozitivele de zi cu zi.
Dacă computerul sau telefonul tău accesează internetul, primește e-mailuri, folosește Slack sau a dat click pe linkuri necunoscute, atunci aceste dispozitive nu pot fi considerate un mediu sigur.
Pe scurt: atâta timp cât este conectat la internet, se consideră că are riscuri. Poate părea puțin exagerat, chiar și prea precaut. Dar în această etapă, siguranța este o chestiune de normalitate.
Trei, kill switch-ul nu este un accesoriu, este frâna ta de urgență.
Mulți cred că kill switch-ul este folosit doar în cazuri extreme, dar de fapt ar trebui să fie proiectat de la început.
Să fiu direct: cu cât calea ta de ieșire este mai largă, cu atât limita pierderilor este mai mare. O funcție de minare fără limită pe bloc este ca și cum ai oferi un cec în alb pentru o vulnerabilitate de minare infinită.
În plus, kill switch-ul nu trebuie să fie prezent doar pe UI. Trebuie să ai un script care să înghețe toate mișcările de valoare cu o singură apăsare, executat atomic. Și înainte de a apăsa, ar fi bine să ai un sistem de avertizare care funcționează, un monitor de linie care urmărește constant variabilele tale, iar dacă acestea sunt încălcate, să escaladeze imediat către oameni.
De ce subliniez importanța oamenilor? Pentru că AI-ul poate detecta, dar deciziile finale tot oamenii trebuie să le ia. Nimeni nu vrea să lase un algoritm să decidă dacă să înghețe milioane de dolari.
Patru, un concept tehnic pe care îl prefer: variabilele constante.
Variabilele sunt regulile pe care le-ai stabilit în designul sistemului, care trebuie să rămână întotdeauna valabile indiferent de ce se întâmplă. De exemplu: depozitul total ≤ datoriile totale.
Poți să scrii aceste reguli în cod, astfel încât sistemul să verifice automat după fiecare funcție critică. Dacă se descoperă că regula a fost încălcată, sistemul se oprește direct sau dă o eroare, fără a continua să execute tranzacții.
Multe atacuri DeFi (cum ar fi împrumuturile flash sau manipularea oracle-urilor) au la bază faptul că atacatorul a intervenit în procesul de execuție al funcției, aducând sistemul într-o stare greșită pe termen scurt.
Dar dacă în starea finală forțezi verificarea variabilelor, chiar dacă au fost schimbate între timp, trebuie să revină la o stare legală, altfel eșuezi direct. Poate să te lase să intri, dar nu te va lăsa să ieși cu rezultate greșite.
Desigur, variabilele constante nu trebuie să fie cât mai multe. Dacă restricționezi totul, sistemul devine rigid, și chiar operațiunile normale nu pot fi efectuate.
O abordare mai bună este să alegi doar două sau trei reguli esențiale, cum ar fi siguranța fondurilor și echilibrul activelor, ca obiecte de protecție prioritară.
Apoi, combină verificarea formală sau testarea fuzzing de stare pentru a le valida, care în general poate acoperi majoritatea riscurilor.
Cinci, esența siguranței este de a lăsa spațiu pentru pierderi.
Acum sunt din ce în ce mai convins că siguranța nu este ceva ce poți rezolva cu un audit sau un raport. Este mai degrabă un proces care trebuie să funcționeze zilnic, cu vigilență constantă.
Există o zicală care spune bine: lipsa dovezilor de a fi fost hack-uit nu înseamnă că nu vei fi hack-uit. Cel mai mare pericol nu este de obicei vulnerabilitatea în sine, ci momentul în care crezi că totul este în regulă.
De aceea, acum am o mentalitate de a accepta că voi fi hack-uit, dar nu voi permite să fiu distrus într-o singură lovitură. Planific din timp, fac simulări, configurez portofelul de protecție, și listez procesele de negociere și urmărire înainte. Nu este vorba despre perfecțiune, ci despre a fi pregătit atunci când ziua aceea vine.
Nu urmărești să nu ai niciodată probleme, ci să te menții stabil atunci când apar probleme.