Un singur pas ratat într-o procedură de configurare. Nicio breșă sofisticată, nicio manipulare de oracol, nicio schemă de tip flash loan. Doar o valoare implicită lăsată pe loc, într-un contract verificator, în spatele căruia stăteau milioane de dolari în fonduri ale utilizatorilor.
Două protocoale au picat în aceeași săptămână, iar ecosistemul zero-knowledge a primit o lecție pe care o tot amâna de un deceniu.
Dovezile zero-knowledge, cunoscute în industrie sub acronimul ZK, au fost promovate cu un mesaj central, repetat obsesiv în whitepaper-uri, prezentări și thread-uri pe Twitter: nu trebuie să ai încredere în echipa din spatele proiectului, e suficient să verifici matematica.
Pe acest fundament s-au ridicat protocoale, rollup-uri, sisteme de confidențialitate și infrastructuri de identitate digitală. Iar ideea că, prin criptografie, încrederea devine opțională a ajuns un fel de axiomă a industriei.
Doar că axioma avea o fisură. Una care nu ținea de teorie, ci de practică.
Ce s-a întâmplat, pe scurt?
Undeva între ultima săptămână a lunii februarie și prima din martie 2026, două protocoale de confidențialitate construite pe tehnologia Groth16, o variantă populară de demonstrație ZK, au fost exploatate pe contracte active, cu fonduri reale. E prima dată când un atac de acest tip se confirmă în producție, pe întreaga istorie a tehnologiei zero-knowledge.
Veil Cash, un protocol de confidențialitate pe rețeaua Base, a fost golit de 2,9 ETH printr-o singură tranzacție. Câteva zile mai târziu, FoomCash a pierdut echivalentul a 2,26 milioane de dolari. Nu din cauza unei vulnerabilități asemănătoare, ci din cauza exact aceleiași.
Un parametru de configurare, care ar fi trebuit personalizat în timpul ceremoniei de trusted setup, rămăsese pe valoarea implicită. Toolchain-ul snarkjs generează acea valoare ca un placeholder temporar, cu așteptarea clară că dezvoltatorul o va înlocui înainte de lansare.
La Veil Cash, nimeni nu a rulat comanda. La FoomCash, la fel. Rezultatul a fost identic de ambele părți: verificatorul de pe blockchain accepta orice demonstrație, fie ea autentică sau complet fabricată din nimic.
Cum a funcționat, tehnic vorbind?
Pentru cine vrea să înțeleagă mecanismul, Groth16 este unul dintre cele mai răspândite sisteme de dovezi zero-knowledge. E apreciat pentru că generează dovezi mici și rapide la verificare.
Funcționarea lui depinde însă de un set de parametri criptografici generați într-o ceremonie inițială, numită trusted setup. Printre acești parametri se numără și două elemente, notate gamma și delta, care trebuie neapărat să fie distincte și independente unul de celălalt.
Când cei doi parametri rămân identici, ecuația de verificare degenerează. Practic, verificatorul nu mai poate distinge o dovadă autentică de una inventată. Orice valoare trimisă contractului trece testul.
Instrumentul snarkjs, cel mai popular din ecosistemul open-source pentru generarea și verificarea dovezilor Groth16, pornește cu gamma și delta setate pe aceeași valoare, și anume generatorul standard al curbei BN254. E un comportament documentat, o valoare de pornire menită să fie suprascrisă prin rularea fazei a doua a ceremoniei. Procesul apare în documentație. Comanda există. N-a executat-o nimeni.
Veil Cash – prima lovitură
Veil Cash era, la bază, un fork al Tornado Cash. Permitea depuneri prin intermediul unui contract validator și retrageri anonime prin dovezi zero-knowledge. Funcționa pe rețeaua Base, discret, fără prea multă vizibilitate într-un ecosistem dominat de proiecte mai zgomotoase.
Undeva în jurul datei de 20 februarie 2026, un atacator a lansat o singură tranzacție care a apelat funcția de retragere de 29 de ori consecutiv, extrăgând câte 0,1 ETH la fiecare pas. Pool-ul s-a golit complet, deși atacatorul nu depusese niciodată vreun fond în protocol.
Ceea ce a atras atenția cercetătorilor de securitate a fost modul aproape ironic în care atacatorul și-a ales hash-urile nullifier: de la 0xdead0000 până la 0xdead001c. Valori fabricate manual, trimise cu nonșalanță, pe care contractul verificator le-a acceptat fără nicio obiecție.
Echipa de securitate DefimonAlerts, brațul de monitorizare al firmei Decurity, a intervenit rapid și a reușit să salveze 2,025 ETH din pool-urile rămase, returnându-i echipei Veil Cash. Mai târziu în aceeași seară, atacatorul original a trimis înapoi fondurile extrase. De ce a făcut-o, nu știm cu certitudine. Poate a fost un test whitehat, poate conștiință, poate cu totul altceva. Blockchain-ul nu oferă motivații, doar tranzacții.
Dar tehnica funcționase perfect. Iar în zilele următoare, un cercetător care folosea pseudonimul DK27ss a publicat pe GitHub un proof-of-concept complet, cu tot codul necesar pentru replicarea atacului. Din acel moment, exploitul nu mai era un incident izolat. Era documentație deschisă, la un click distanță de oricine avea curiozitatea sau interesul s-o folosească.
FoomCash – dovada că problema se amplifică
Dacă Veil Cash a reprezentat demonstrația de concept, FoomCash a confirmat că aceeași problemă funcționează și la altă scară. Aceeași vulnerabilitate, aceeași comandă omisă din fluxul de configurare, dar cu o miză financiară de câteva sute de ori mai mare: 2,26 milioane de dolari.
FoomCash era tot un protocol de confidențialitate, cu o arhitectură similară, care parcursese aceeași cale de implementare Groth16 fără a finaliza ceremonia de configurare. Atacul a fost mai amplu ca dimensiune, iar consecințele au fost documentate în detaliu de publicația Rekt News într-un material intitulat „The Unfinished Proof”.
Articolul a acoperit inclusiv disputele legate de recompensa bug bounty, schimburile tensionate pe grupul EthSecurity de pe Telegram și post-mortem-ul oficial al echipei FoomCash, în care operațiunea era descrisă drept „un răspuns whitehat de elită”, pe când datele de pe blockchain sugerau o poveste oarecum diferită.
Dincolo de dramă, miza reală era confirmarea unui tipar. Vulnerabilitatea nu aparținea unei singure echipe neglijente. Era un defect al modului în care protocoalele ZK ajungeau în producție.
O eroare cu rădăcini adânci
Probabil cel mai deranjant aspect al întregului episod este că vulnerabilitatea exploatată nu era o necunoscută. Avea, dimpotrivă, o istorie lungă și bine documentată, pe care ecosistemul alesese, sistematic, s-o trateze ca pe o curiozitate teoretică și nu ca pe o amenințare practică.
Încă din 2019, echipa Tornado Cash descoperise o eroare în propria implementare a circuitelor circomlib. Un singur caracter greșit, semnul „=” în loc de „<==”, care ar fi permis oricui să falsifice o rădăcină Merkle și să golească contractul. Echipa a exploatat-o singură, înainte ca altcineva s-o găsească, a publicat un raport post-mortem și a trecut mai departe.
Doi ani mai târziu, echipa Zcash a recunoscut că remediase discret o vulnerabilitate care permitea emiterea nelimitată de monede, ascunsă în parametrii trusted setup-ului. Eroarea exista de ani buni. Fusese considerată neexploatată pentru că, în cuvintele echipei, ar fi necesitat „un nivel ridicat de sofisticare tehnică și criptografică pe care foarte puțini oameni îl posedă”.
Complexitatea drept fortificație, sofisticarea drept factor de descurajare. Cam ăsta a fost consensul nescris al industriei vreme de ani: codul ZK este prea obscur pentru a fi exploatat la scară largă, atacatorii nu vor citi lucrările academice, nu vor face calculele. Nimeni nu și-a pus serios întrebarea ce se întâmplă în ziua în care cineva chiar le face.
Frozen Heart și familia de vulnerabilități ignorată
În 2022, firma de securitate Trail of Bits a publicat o cercetare care identifica o întreagă familie de erori de implementare, căreia i-a dat numele „Frozen Heart”. Esența problemei era simplă în formulare, dar devastatoare în consecințe: valori publice care nu erau legate de transcript-ul hash înainte ca provocarea criptografică să fie generată. O deficiență în implementarea transformării Fiat-Shamir, adică tocmai mecanismul prin care un protocol interactiv devine non-interactiv.
Printre implementările afectate se numărau snarkjs (dezvoltat de Iden3), Dusk Network și gnark (dezvoltat de ConsenSys). Cercetarea a fost publicată, clasa de bug-uri a fost documentată formal, iar grupul 0xPARC a construit un tracker public care să catalogheze tiparele.
Echipele au aplicat corecțiile necesare. Cercetătorii și-au bifat descoperirile. Ecosistemul a dat aprobator din cap și a mers mai departe, fără să privească prea atent în spate.
Șase mașini virtuale, aceeași eroare
La doar două zile după analiza post-exploit a FoomCash din 1 martie 2026, firma de securitate OtterSec a publicat un raport cu un titlu greu de ignorat: „Unfaithful Claims: Breaking 6 zkVMs”.
Doi cercetători, Himanshu Sheoran și Valter Wik, documentaseră aceeași clasă de vulnerabilitate Fiat-Shamir în șase implementări independente de mașini virtuale zero-knowledge, și anume Jolt (dezvoltat de a16z), Nexus, Cairo-M (Kakarot Labs), Ceno (Scroll), Expander (Polyhedra) și Binius64. Șase echipe diferite, șase baze de cod separate, sisteme de demonstrație diferite, dar aceeași greșeală de fond.
Mecanismul tehnic diferă de cel al erorilor Groth16 de la Veil Cash și FoomCash, dar urmează același tipar de eșec al solidității criptografice. Dacă o valoare care influențează o ecuație de verificare nu este inclusă în transcript înainte ca provocarea să fie derivată, cel care generează demonstrația poate, practic, să vadă provocarea înainte de a-și alege răspunsul. Alege exact valoarea care face ecuația să treacă, demonstrația este validată, iar afirmația pe care o susține poate fi complet falsă.
În fiecare din cele șase sisteme, valori controlate de cel care genera demonstrația, cum ar fi revendicările de deschidere, sumele de lookup sau intrările publice, alimentau ecuațiile de verificare fără a fi fost integrate mai întâi în transcript.
Corecția, în fiecare caz, a însemnat una sau două linii de cod. Dar descoperirea problemei presupunea înțelegerea completă a fluxului de verificare de la un capăt la altul și formularea unei singure întrebări pe care majoritatea echipelor nu și-o puseseră: ce s-ar întâmpla dacă cel care generează demonstrația ar fi ales această valoare după ce a văzut provocarea?
Ca să ilustreze gravitatea, OtterSec a publicat o provocare deschisă: trimiteți o demonstrație validă că ați descoperit un contraexemplu la Ultima Teoremă a lui Fermat, adică numere întregi a, b și c, fiecare cel puțin 1, pentru care a³ + b³ = c³. Într-un sistem ZK funcțional, o astfel de demonstrație ar fi imposibilă. Într-unul vulnerabil, era doar o formalitate.
Cinci dintre cele șase implementări fuseseră corectate între octombrie 2025 și ianuarie 2026, ca urmare a divulgării private. Ceno, mașina virtuală ZK a proiectului Scroll, avea un issue deschis din 10 noiembrie, iar la data publicării raportului OtterSec acesta rămânea nerezolvat. Recompensa de 500.000 de dolari oferită de Polyhedra pentru vulnerabilitatea descoperită în Expander se afla încă în așteptarea confirmării.
Separat, Solana remediase o instanță a aceleiași clase de vulnerabilitate în aprilie 2025 și o a doua în iunie 2025, în ambele cazuri înainte ca vreo tentativă de exploatare să se materializeze. O abordare discretă, dar eficientă, pe care nu toate echipele au reușit s-o replice.
Cine verifică verificatorul?
Unul dintre aspectele cu adevărat tulburătoare ale acestor incidente privește granițele a ceea ce un audit de securitate acoperă și ce lasă descoperit.
Circuitele criptografice trec prin audit. Procesul de deploy, de obicei, nu. Cheile de verificare, adică exact suprafața criptografică de care depinde dacă o demonstrație este acceptată sau nu, ajung rareori pe masa auditorilor.
Nu e vorba de o neglijență clasică. E o graniță pe care ambele părți o acceptă tacit, adesea fără să cântărească prea mult ce se află de cealaltă parte a liniei.
Firma Pashov Audit Group a auditat Veil Cash. Contractul verificator configurat greșit era explicit în afara sferei lor de lucru. Au precizat acest lucru după incident, fără să fie criticați pentru asta, fiindcă scopul se negociază, iar parametrii de deploy pur și simplu nu le fuseseră puși la dispoziție.
Rezultatul, însă, a fost un protocol care trecuse auditul cu bine și care, în momentul lansării, funcționa cu un verificator incapabil să respingă vreo demonstrație, indiferent cât de falsă ar fi fost.
Firma zkSecurity, cea care a publicat analiza tehnică a exploitului Groth16 după golirea FoomCash, a recunoscut fără ocolișuri propria expunere. Primul lor gând la examinarea vulnerabilității a fost că exact același lucru s-ar fi putut întâmpla unui proiect auditat de ei. Faza de deploy nu intră aproape niciodată în perimetrul unui audit, iar asta era o practică pe care au declarat că vor s-o schimbe.
După exploitul FoomCash, firma Dedaub a derulat un scan la nivelul întregului EVM, căutând contracte care stochează același element criptografic de două ori. Nu au apărut alte contracte active cu fonduri semnificative blocate și aceeași vulnerabilitate. Pe lanțurile EVM, cel puțin, raza de impact părea circumscrisă.
Dar o căutare pe GitHub a dezvăluit o altă față a problemei. Mai multe repository-uri purtau aceeași amprentă vulnerabilă, cu gamma și delta identice. Un exemplu pe care zkSecurity l-a evidențiat: o implementare Tornado Cash concepută în scop educativ, acumulând 248 de stele pe GitHub. Exact genul de repository pe care un dezvoltator îl clonează ca punct de plecare, îl publică pe un blockchain fără a parcurge documentația de configurare și îl consideră pregătit pentru producție doar fiindcă altcineva i-a dat o steluță.
De ce aceeași eroare refuză să dispară?
Diagnosticul oferit de OtterSec în legătură cu persistența acestei clase de vulnerabilități atinge un nerv sensibil al întregului ecosistem.
Lucrările academice descriu protocoale interactive, în care un verificator real transmite provocări aleatorii în timp real. În acel context, legarea valorilor este implicită. Ceea ce lucrările nu detaliază este ce anume trebuie inclus în transcript atunci când protocolul este convertit în versiune non-interactivă, adică tocmai forma în care ajunge pe blockchain.
Responsabilitatea cade pe cel care implementează. Iar în arhitecturile modulare ale mașinilor virtuale ZK, fiecare strat pornește de la presupunerea că stratul vecin se ocupă de legare. Fiecare operație de hash are un cost computațional, iar presiunea constantă spre optimizare împinge treptat valori în afara transcript-ului, pe logica „probabil nu contează”.
Testele automate rulează cu proveri onești. Testele de integrare, la fel. Niciun instrument automatizat nu simulează comportamentul unui prover adversarial. Pentru a depista aceste vulnerabilități, ai nevoie de un om care înțelege fluxul complet de verificare de la un capăt la altul și care pune întrebarea pe care nimeni altcineva nu și-a pus-o.
Ce urmează?
Ecosistemul a început să reacționeze. Firma zkSecurity integrează detecția fazei a doua în scannerul lor de monitorizare continuă, zkao. Cinci din cele șase mașini virtuale afectate au primit corecții. Au pornit și discuții despre includerea parametrilor de deploy în perimetrul standard al auditurilor de securitate.
Dar a reacționa la ceea ce s-a descoperit deja nu e totuna cu a ști ce anume n-a fost încă găsit.
Proof-of-concept-ul pentru exploitul Groth16 este disponibil public pe GitHub. La fel și varianta care l-a escaladat la milioane de dolari. Repository-urile care încă poartă valorile implicite vulnerabile sunt și ele acolo, deschise. Distanța dintre aceste două realități se măsoară, practic, în cine nu le-a descoperit încă.
Orice divulgare de securitate este, simultan, și un plan de atac. Iar în acest spațiu, planurile de atac au un termen de valabilitate care se numără în zile, nu în luni.
Recalibrarea unei promisiuni
Promisiunea fundamentală a tehnologiei zero-knowledge n-a fost niciodată despre cod, ci despre matematica din spatele lui. Sistemele de demonstrație ZK au fost prezentate drept capătul nevoii de încredere: nu trebuie să crezi că echipa a construit corect, verifici demonstrația și atât.
Garanția aceasta, însă, ține doar atât cât țin ceremonia care a generat parametrii, transcript-ul care leagă valorile celui ce generează demonstrația și perimetrul pe care cineva, undeva, a fost de acord să-l verifice.
Într-o singură săptămână, două protocoale au fost exploatate public, împotriva unor fonduri reale, pentru prima dată în întreaga istorie a acestei tehnologii. Nu fiindcă criptografia s-a stricat, ci fiindcă munca de care depinde criptografia ca să funcționeze n-a fost făcută. Sau n-a fost asumată de nimeni.
Veil Cash a arătat că exploitul e posibil. FoomCash a arătat că se scalează. Cele șase mașini virtuale ZK au arătat că nu e treaba unei singure echipe neglijente.
Ecosistemul ZK a petrecut un deceniu spunându-le utilizatorilor că matematica e garanția supremă. Se dovedește, acum, că matematica avea nevoie de o ceremonie. Ceremonia avea nevoie de o comandă. Iar comanda avea nevoie de cineva care s-o execute.
Nimeni nu se asigurase că acel cineva există.
Când singurul lucru care separă fondurile unui utilizator de un contract gol este un singur pas dintr-un ghid de configurare, cine răspunde dacă acel pas nu s-a executat niciodată?
