În crypto, cele mai costisitoare greșeli nu arată întotdeauna ca niște atacuri spectaculoase. Uneori nu e vorba de oracole răsturnate, de împrumuturi fulger sau de cine știe ce combinații imposibil de urmărit. E doar o piesă mică, lăsată pe valoarea implicită, într-un contract care trebuia să facă un lucru simplu și vital: să respingă dovezile false.
Textul de mai jos este o rescriere bazată pe analiza publicată de Cryptology.ro, site românesc de știri și comentarii despre crypto, care a urmărit în detaliu primul val de exploituri confirmate pe protocoale zero-knowledge aflate în producție.
De ce povestea asta a fost un șoc pentru industrie?
Dovezile zero-knowledge, prescurtate ZK, au crescut cu o promisiune care a prins rădăcini în cultura Web3: nu mai e nevoie să ai încredere în echipă, în brand sau în reputație, fiindcă poți verifica matematica. Dacă dovada trece, afirmația e adevărată. Dacă nu trece, e respinsă.
Numai că matematica ajunge pe blockchain prin cod, iar codul ajunge pe blockchain printr-o succesiune de pași care nu se văd în prezentări. Cineva compilează, cineva generează parametri, cineva publică contractele, cineva atașează chei de verificare. Dacă un singur pas rămâne neterminat, întregul mecanism poate deveni, fără intenție, o ușă larg deschisă.
Ce s-a întâmplat, de fapt, la final de februarie și început de martie 2026?
În ultimele zile din februarie și în primele din martie 2026, două protocoale de confidențialitate construite pe Groth16, o variantă populară de dovezi ZK, au fost exploatate pe contracte active, cu fonduri reale blocate. Mai mult decât pierderile în sine, momentul a atras atenția fiindcă a confirmat ceva ce, multă vreme, a părut doar o ipoteză: poți avea criptografie solidă și, totuși, un verificator care acceptă orice.
Primul incident a vizat Veil Cash, un protocol lansat pe rețeaua Base. Câteva zile mai târziu a urmat FoomCash, cu un impact financiar mult mai mare. Legătura dintre ele nu a fost doar tehnologică. A fost aceeași omisiune de configurare.
Veil Cash: retrageri repetate, fără să fi existat depuneri
Veil Cash era descris ca un fork al Tornado Cash, adică un protocol care permite depuneri și retrageri anonime folosind dovezi zero-knowledge. În jurul datei de 20 februarie 2026, un atacator a trimis o singură tranzacție în care a apelat funcția de retragere de 29 de ori consecutiv, scoțând câte 0,1 ETH la fiecare apel. Rezultatul a fost sec: pool-ul a fost golit.
Ceea ce a sărit în ochi, chiar și pentru cei obișnuiți cu atacuri meticuloase, a fost lipsa de grijă cu care au fost alese anumite valori tehnice, precum nullifier-urile. Au apărut într-o serie care pornea de la 0xdead0000 și continua incremental, aproape ostentativ. Contractul nu a protestat, pentru că verificarea, în practică, nu mai avea dinți.
DefimonAlerts, echipa de monitorizare a firmei Decurity, a intervenit rapid și a reușit să salveze 2,025 ETH din fondurile rămase, returnându-le echipei Veil Cash. Mai târziu, în aceeași seară, atacatorul a trimis înapoi fondurile extrase inițial. Pe blockchain vezi mișcările, nu și motivele, așa că rămâne deschis dacă a fost un gest whitehat sau o retragere strategică după ce semnalul public devenise prea puternic.
În zilele următoare, un cercetător cunoscut sub pseudonimul DK27ss a publicat pe GitHub un proof-of-concept complet, cu pașii necesari pentru a reproduce exploitul. Din momentul acela, nu mai era vorba despre un incident izolat, ci despre o tehnică accesibilă oricui avea interesul să o folosească.
FoomCash: aceeași vulnerabilitate, la altă scară
FoomCash a confirmat partea care sperie cel mai tare în securitate: greșeala nu avea nevoie de condiții speciale. Era repetabilă. Protocolul a pierdut echivalentul a 2,26 milioane de dolari, iar explicația a fost, în esență, aceeași ca la Veil Cash: ceremonia de configurare nu fusese dusă până la capăt.
Incidentul a fost urmărit atent și de Rekt News, într-un material intitulat The Unfinished Proof, care a surprins atât componenta tehnică, cât și tensiunile tipice post-incident, de la discuțiile despre recompense de tip bug bounty până la modul în care echipa a încadrat ulterior operațiunea. Indiferent de nuanțele din comunicare, concluzia practică a rămas aceeași: verificatorul de pe lanț ajunsese să accepte demonstrații fabricate.
Unde s-a rupt lanțul, pe înțelesul tuturor?
Groth16 este apreciat pentru dovezile compacte și verificarea rapidă. Partea sensibilă este dependența de un set inițial de parametri generați într-o ceremonie numită trusted setup. În interiorul acestui set există elemente care trebuie să fie distincte și independente.
În scenariul exploatat aici, doi parametri, numiți frecvent gamma și delta, au rămas identici. Când se întâmplă asta, ecuația de verificare se degradează, iar contractul nu mai poate distinge o dovadă reală de una inventată. În loc să fie un filtru, devine o ștampilă.
În ecosistemul open-source, snarkjs este un instrument foarte răspândit pentru Groth16. El pornește intenționat cu o valoare temporară, un placeholder, în care gamma și delta sunt setate la fel, urmând să fie înlocuite în faza a doua a ceremoniei printr-o comandă clară. În aceste două cazuri, comanda nu a fost rulată. Criptografia nu a cedat. Procesul a rămas neterminat.
Istoria avertismentelor care nu au schimbat reflexele
Faptul că asemenea vulnerabilități ajung în producție e greu de privit fără un pic de context. În 2019, Tornado Cash a descoperit o eroare în circuitele sale, suficientă cât să permită falsificarea unei rădăcini Merkle și golirea contractului. Echipa a exploatat intern problema înainte ca altcineva să o facă și a documentat public incidentul.
Mai târziu, Zcash a recunoscut că a reparat discret o vulnerabilitate care ar fi permis emiterea nelimitată de monede, legată de parametrii trusted setup. Mult timp, industria a pariat pe faptul că asemenea atacuri sunt rare pentru că sunt grele. Doar că dificultatea nu e o barieră stabilă. E o întârziere.
Frozen Heart și lecția despre Fiat, Shamir și detalii care contează
În 2022, Trail of Bits a descris o clasă de probleme numită Frozen Heart, legată de implementări defectuoase ale transformării Fiat-Shamir, adică mecanismul prin care protocoalele interactive devin non-interactive și pot rula pe blockchain. Ideea de bază e simplă: dacă anumite valori publice nu sunt legate corect de transcript-ul hash înainte să fie generată provocarea criptografică, un doveditor adversarial poate obține un avantaj pe care nu ar trebui să îl aibă.
În contextul acestei discuții au apărut nume cunoscute, precum snarkjs, Dusk Network și gnark. Problema a fost tratată, corecțiile au fost aplicate, dar episoadele din 2026 arată cât de ușor se poate instala o falsă liniște. Vulnerabilitățile se mută, se rescriu și reapar acolo unde procesul nu e verificat până la capăt.
Șase zkVM-uri și aceeași categorie de eroare
Tot la început de martie 2026, OtterSec a publicat un raport despre o vulnerabilitate de tip Fiat-Shamir întâlnită în șase implementări diferite de mașini virtuale zero-knowledge. Deși mecanismul nu este identic cu greșeala de configurare din Groth16, efectul seamănă: anumite valori controlate de doveditor ajungeau să influențeze verificarea fără să fie incluse la timp în transcript, ceea ce poate transforma verificarea într-un joc cu regulile schimbate.
Conform documentării din ecosistem, corecțiile pentru o parte dintre aceste implementări au fost introduse între octombrie 2025 și ianuarie 2026, după divulgare privată. Separat, Solana a remediat de două ori aceeași clasă de vulnerabilitate în 2025, în aprilie și în iunie, înainte să existe exploatări confirmate.
Cine verifică verificatorul?
Aici apare o nuanță pe care mulți o ignoră până când e prea târziu: granița dintre ce acoperă un audit și ce rămâne în afara lui. Circuitele criptografice ajung frecvent la auditori. Procesul de publicare pe lanț și cheile de verificare ajung mult mai rar, deși tocmai ele decid dacă o demonstrație e respinsă sau acceptată.
În cazul Veil Cash, auditul a fost realizat de Pashov Audit Group, iar contractul verificator configurat greșit a fost menționat ca fiind în afara ariei auditate. După incidentul FoomCash, zkSecurity, firma care a publicat analiza tehnică a exploitului Groth16, a spus direct că aceeași omisiune ar fi putut apărea și la proiecte auditate de ei, tocmai fiindcă faza de publicare pe lanț nu intră aproape niciodată în perimetrul standard.
Dedaub a derulat apoi o scanare la nivelul EVM, căutând contracte care stochează același element criptografic de două ori, un indiciu relevant pentru vulnerabilitatea observată. Nu au fost găsite alte contracte active cu fonduri importante blocate și aceeași problemă, ceea ce a sugerat un impact imediat limitat.
În schimb, o simplă căutare pe GitHub a scos la suprafață repo-uri care păstrează valorile implicite vulnerabile. Genul de cod pe care îl clonezi, îl adaptezi în grabă și îl trimiți în producție, cu impresia că e sigur doar fiindcă are vizibilitate.
În lectura propusă de Mihai Popa, analist și editorialist la Cryptology.ro, miezul acestor episoade nu este că zero-knowledge ar fi o tehnologie fragilă, ci că promisiunea ei se sprijină pe pași de implementare și publicare pe lanț pe care mulți încă nu îi tratează ca pe elemente de securitate.
Ce rămâne după zgomot?
După Veil Cash și FoomCash, e greu să mai confunzi siguranța unui sistem criptografic cu disciplina unui proces de implementare. Dacă proof-of-concept-ul e public și dacă setările implicite încă trăiesc în repo-uri copiate la nesfârșit, riscul nu mai ține de cât de elegantă e teoria. Ține de cât de bine îți verifici propria execuție.
Zero-knowledge rămâne o piesă centrală pentru confidențialitate și scalare, iar industria nu se va întoarce din drum. Dar episodul acesta schimbă tonul. Când o singură comandă omisă poate transforma un verificator într-un simplu spectator, întrebarea importantă nu mai este cât de solidă e matematica, ci cât de atent e întregul lanț de pași care o aduce în producție.
