Команда Protocol Security зі складу Ethereum Foundation (EF) провела масштабний експеримент: вони розгорнули скоординованих ШІ-агентів проти критичних компонентів блокчейн-інфраструктури. Під приціл потрапили системне ПЗ, криптографічний код та смарт-контракти. Результати виявилися несподіваними навіть для самих розробників.
Головний висновок, який зробили в EF, стосується не стільки кількості знайдених помилок, скільки процесу їх обробки. Як зазначили в команді, ШІ дійсно знаходить баги — це не стало сюрпризом. Здивувало інше: наскільки мало зусиль знадобилося для їх виявлення і наскільки багато — для відокремлення реальних вразливостей від хибних спрацьовувань.
Важливо підкреслити: штучний інтелект не замінив людину в процесі аудиту безпеки. Він лише змістив вузьке місце. Раніше дослідники витрачали основний час на пошук гіпотез, тепер же — на перевірку величезного масиву згенерованих кандидатів. Тріаж, а не генерація, став новим вузьким горлечком.
Архітектура системи: роєвий інтелект замість моноліту
Protocol Security відмовилася від класичної схеми з одним великим ШІ-агентом, який керує всім процесом. Натомість було розгорнуто мережу спеціалізованих систем, що працюють паралельно проти одного репозиторію. Одні агенти відповідали за первинну розвідку коду, інші — за пошук потенційних вразливостей, заповнення прогалин та валідацію. Координація здійснювалася через спільний репозиторій та систему контролю версій.
Як пояснили в EF, час, який раніше йшов на формування та перевірку гіпотез, тепер перерозподілено на їх масову оцінку: побудову оракула, тріаж, ведення списку відомих проблем та розкриття. Агенти чудово справляються зі швидким скануванням великих ділянок коду, трасуванням шляхів виконання та підготовкою матеріалів для proof-of-concept. Але кожен кандидат все одно вимагає незалежного відтворення на реальному коді, перш ніж його можна кваліфікувати як вразливість.
Конкретні знахідки та обмеження методу
Публічно розкритий приклад — вразливість CVE-2026-34219 у Rust-реалізації libp2p gossipsub. Вона пов'язана з обробкою backoff expiry — періоду, протягом якого вузол тимчасово обмежує взаємодію з піром. Помилка дозволяла віддалено викликати аварійне завершення процесу під час обробки спеціально сформованого PRUNE-повідомлення з майже максимальним значенням backoff. Причина — неперевірена арифметика при додаванні Instant + Duration, що призводило до переповнення.
Однак загальну кількість реальних багів, виявлених агентами, в EF не розкрили. У блозі згадується про кілька знахідок, але публічно названо лише один приклад. Більшість згенерованих кандидатів виявилися хибнопозитивними, дублями або проблемами поза межами перевірки. В EF назвали це нормальною частиною методу, а не провалом системи. Мета — швидко відкидати невірні кандидати та підкріплювати реальні доказом, з яким важко сперечатися.
Примітно, що ШІ-агенти гірше справляються з вразливостями, які проявляються лише через довгий ланцюжок коректних дій. Така логіка вимагає не лише знайти підозрілий фрагмент коду, але й довести, що вся послідовність станів дійсно досяжна. Це класична проблема комбінаторного вибуху, з якою стикаються всі автоматизовані аналізатори.
Моя професійна думка: Експеримент EF — важливий крок в еволюції безпеки блокчейнів, але він наочно демонструє, що ШІ сьогодні — це потужний інструмент для генерації гіпотез, а не для їх верифікації. Поки людський фактор залишається критичною ланкою в тріажі, повна автоматизація аудиту безпеки — справа віддаленого майбутнього. Інвестиції в інструменти для швидкої валідації кандидатів стануть наступним логічним етапом розвитку цієї технології.