Fundația Ethereum a folosit agenți AI pentru a depista un bug ce putea scoate validatorii din funcțiune

Dezvoltatorii de la Ethereum Foundation au rulat recent agenți AI pe software-ul pe care funcționează rețeaua Ethereum, în căutare de vulnerabilități, ca parte a eforturilor de întărire a celui mai mare blockchain după valoarea blocată. Au apărut semnalări, dar echipa Protocol Security subliniază că verdictul final a rămas, în multe cazuri, la judecata umană: diferențierea între probleme reale și alarme false. Fundația a publicat și note de teren cu recomandări pentru ca restul ecosistemului să-și calibreze propriile fluxuri de lucru cu AI. Ethereum rulează pe mii de noduri — calculatoare obișnuite care execută software-ul rețelei, păstrează câte o copie a lanțului și transmit mesaje către vecini. Deasupra acestui strat stau validatorii, nodurile care depun ether în staking și votează validitatea blocurilor. Funcționarea lor depinde de livrarea mesajelor. Vulnerabilitatea identificată era în gossipsub. Defectul permitea unui sistem la distanță să provoace un crash: software-ul nodului ajungea la un calcul imposibil, se oprea și se închidea, lăsând validatorul offline până când un operator îl repornea. Problema a fost remediată rapid și publicată sub identificatorul "CVE202634219", cu credit acordat echipei. Îngrijorarea mai mare a fost filtrarea semnalărilor agenților. Nikos Baxevanis, autorul postării, a scris că surpriza a fost cât de puțin efort a fost necesar pentru a "găsi" buguri și cât de mult pentru a stabili care sunt reale și care doar par reale. Diferența pornește de la natura ieșirii. Un fuzzer — instrumentul standard care bombardează software-ul cu date malformate până când ceva cedează — întoarce un crash și un log cu locul producerii, pe care un inginer îl poate valida în câteva minute. Un agent AI produce o narațiune: descrie cum poate fi atinsă vulnerabilitatea, argumentează impactul, propune un nivel de severitate și livrează cod funcțional care ar demonstra atacul. Totul vine în proză fluentă, cu un aspect similar indiferent dacă bugul este real sau inventat. Potrivit Fundației, au recurent trei tipuri de alarme false. Primul: un crash care apare doar într-un build de test, unde compilatorul activează verificări de siguranță absente din versiunea livrată utilizatorilor, astfel că în producție nu se rupe nimic. Al doilea: un "atac" care funcționează doar dacă valoarea periculoasă este introdusă manual în program, fiindcă toate căile prin care un actor extern ar încerca să o injecteze o resping înainte. Al treilea: rezultate din verificare formală (formal verification), unde o demonstrație trece arătând ceva trivial adevărat, fără să spună nimic relevant despre software. În toate cazurile, "testul" nu testează de fapt nimic, iar agentul poate redacta varianta goală la fel de rapid și convingător ca pe cea autentică. O altă limitare observată: agenții sunt buni la raționamente pe un singur moment, dar mai slabi la buguri care se întind pe o secvență de pași, fiecare valid în sine, unde problema este doar ordinea. Acesta este tiparul multor exploatări care au golit protocoale cripto în acest an: instrumente tehnice perfect legitime luate individual, dar o succesiune care maschează furtul. Atacuri recente urmează modelul. Exploitul Edel Finance de la începutul lunii a ocolit un feed de preț Chainlink corect prin stratul de wrapping de deasupra. În atacul de guvernanță BONK, cumpărarea de tokenuri, votul și executarea unei propuneri aprobate au fost fiecare tranzacții obișnuite. Răspunsul propus de Fundație: agenții pot sugera ce secvențe merită testate, iar testele trebuie rulate oricum, cu validare umană.