Модель ИИ - паникер на смарт контракты

Сейчас работаю над одним интересным проектом, который является логическим продолжением HornetMCP (базой данных с уязвимостями) и позволяет запускать агентов ИИ для аудита смарт контрактов. Агентов это, конечно, сильно сказано, скорее просто итеративные запросы к llm, но сейчас это модно говорить про агентов, поэтому оставлю так.

Сам проект будет 100% опенсорс и о нем расскажу позже. А сейчас о другом.

В процессе работы я пришел к выводу, что в популярных ИИ системах для аудита используется всего несколько паттернов:

1. Простая инструкция для ИИ о том, как смотреть код и что искать, в простонародье - skill;
2. Статический анализатор Slither (в 99% случаев);
3. Разбор AST и построение графов;
4. Прогон по паттернам, в основном по yaml инструкциям;
5. Ну, и у самых продвинутых, обученные LLM на собранных данных по отчетам и уязвимостям;

Однако продвинутыми они являются только в одном случае: если в этих отчетах есть примеры полного кода смарт контракта с уязвимостью и его исправленная версия. Просто одних отчетов, как у меня, не достаточно для тренировки модели. И собрать эти данные работа неимоверно кропотливая и трудозатратна.

К примеру, на платформе code4rena все отчеты выложены в удобном формате markdown. Собрать парсер можно за 10 минут с Claude. Далее фильтр по языкам и вот все отчеты готовы. А дальше самое нудное - берешь отчет, ищешь конкурсный репо на GitHub, ищешь контракты, в которых находили эти баги. Сохраняешь контракты в markdown файле. Затем ищешь актуальный репо протокола с исправленным кодом, проверяешь, что баг был действительно исправлен и добавляешь этот код в markdown. Как вы понимаете, это работа не на одного человека, и не на пару месяцев. К тому же, что делать, если ни код протокола, ни его официальный репо не являются открытыми для общественности?

Вероятно, только одна-две компании в мире готовы выделять на это время и деньги.

Всем остальным, довольствоваться только имеющимися открытыми отчетами.

С обучением модели тоже не все гладко. Каждая модель предполагает свой метод обучения: напортачишь с этим и результат будет ужасным.

Вот поэтому и нет достойных открытых моделей для аудита.

Для проекта я решил пойти другим путем: вместо того, чтобы обучать на полных данных, я хочу попробовать обучить модель только на открытых отчетах (на данный момент их 23 265), и сделать модель-паникер.

Вместо того, чтобы анализировать код, она будет просто смотреть на схожие моменты и выдавать пометки для аудита. Да, будет огромное количество false positives, т.е. ошибочных правок. Но могут быть и валидные. Тут вопрос в том, сколько пометок сделает модель.

Другой вопрос, как валидировать такие находки? С одной стороны, многие агенты делают кросс-чек, т.е. проверяют друг друга, с другой - можно отсеять самые "плохие" и провести тесты на остальных.

Сейчас аудиторы и компании делают оркестрацию моделей, когда есть модели подготовки, аудита, проверки, скептического судьи, финального валидатора, тестировщика и т.д. Пройдя через весь этот пайплайн, могут остаться вполне валидные уязвимости. Или же, на крайний случай, в память аудита запишутся некоторые данные, которые могут помочь другим моделям в поиске багов.

Так или иначе, модель-паникер для локального прогона контрактов, может дать хорошую почву для последующей работы остальных моделей и самих аудиторов.

В общем, эту модель я тоже планирую дать в общий доступ на huggingface с описанием процесса обучения, примеров данных и процессом аудита, который будет заложен в нее.

Что думаете по такой модели-паникер?

#ai #audit