Проект на виду. Часть 8. Какой контекст у смарт контракта?

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

На данный момент я собрал около 28К уязвимостей из таких отчетов. Было бы больше 35К-40К, если бы я не удалял большинство Low и 99,5% Ingo/Gas описаний багов (честно говоря, во многих компаниях эти разделы откровенный мусор!).

Сейчас я в стадии ранжирования этих уязвимостей и определения "веса" каждой из них, для более аккуратных рекомендаций ассистента. Но сейчас не об этом.

На днях я столкнулся с проблемой, а что такое "контекст контракта"?

С одной стороны, "контекст контракта" - это его описание и основное назначение. Но насколько хорошим будет такой контекст для ответов на вопросы по нему?

С другой стороны, контракт - это набор определенных функций. И может стоит рассматривать контекст через призму его функций?

Или описание контекста функций недостаточно без детализации их внешних и внутренних действий? Кроме того, большую роль в контексте функций являются изменения состояний переменных хранилища и использование storage/memory пространств...

Кроме того, глупо рассматривать контекст отдельного контракта, когда он работает сообща с другими контрактами в протоколе и вне его.

А документация? Своя и протоколов, с которыми он работает... Это же тоже все должно быть частью контекста...

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

На данном этапе анализаторов и аудиторов кода, все рассматривают контракты с позиции "разбить через solc и распознать" или "самому составить контекст", чтобы понять весь протокол и сгенерировать потенциальные атаки.

Этот подход отличный и рабочий (не зря есть столько мощных аудиторов).

А в своем проекте я хочу помочь аудиторам быстрее "понимать проект", а значит быстрее переходить к стадии поиска потенциальных уязвимостей.

P.S. Напомню, что я делаю не очередного ИИ-аудитора, а ассистента, который помогает разобраться в коде, а не ищет проблемы за самого аудитора.

С этим постом я просто хотел поделиться с вами, чем сейчас занимаюсь и куда стремлюсь. И если у вас появятся идеи или что-то по поводу контекста смарт контрактов, буду рад, если поделитесь в комментариях. Это очень поможет моей текущей работе.

#ai #tool