Топ 5 ИИ сказали, что мой смарт-контракт идеален. Я заставил их работать вместе и они нашли 4 бага

Тринадцать ручных аудитов

Объектом был модульный набор контрактов: родительский SovereignBankPro.sol и дочерние - SovereignAutoPay.sol, SovereignCashback.sol, SovereignMath.sol, SovereignTimelock.sol, SovereignVaults.sol - плюс вся папка с тестами и чистая компиляция со 100% прохождением всех 83 тестов.

Поскольку не каждая модель принимает архив, я собрал всё в один текстовый документ: вверху структура папок и файлов, технический стек, затем исходники всех контрактов, затем тесты. Перед каждым аудитом я сначала спрашивал модель об одном - «понятна ли тебе информация об этом контракте?» - и начинал только после подтверждения.

Для каждого одиночного аудита я использовал ровно один промпт, один и тот же для всех пяти моделей: примерно «это смарт-контракт банка SovereignBankWeb3, вот структура папок/файлов и тех-стек - проведи аудит, найди ошибки и уязвимости, напиши инструкции по исправлению и предложи улучшения». Один промпт. Пятью моделями были Gemini Pro, DeepSeek, ChatGPT, Grok и Claude Opus.

Дальше консолидацию я делал руками. Я собирал все пять аудитов в другой текстовый документ, строго структурированный - какая модель что сказала, - и получалось много, порядка 4000–6000 строк. Я отдавал этот документ Gemini Pro и Claude по отдельности, и каждый выдавал консолидированный отчёт. Теперь у меня было два резюме. Тогда я отправлял отчёт Claude в Gemini, а отчёт Gemini - в Claude для перекрёстной проверки, пока не оставался один общий вердикт: единый консолидированный аудит с ошибками, уязвимостями и рекомендациями по исправлению.

После этого я уходил в код, вносил правки - и начинал заново. Пять новых аудитов, ручная консолидация, перекрёстная проверка, один вердикт. Тринадцать раз.

Бесило меня то, что модели никогда не находили всё за один проход. Каждый раунд всплывало что-то новое. Счёт уменьшался с каждым разом, и примерно к десятому аудиту три модели из пяти говорили мне, что контракт чист.

«Критических уязвимостей нет»
«Хорошая структура»
«Готов к продакшену»

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

Почему это был неправильный инструмент, хотя он и работал

Посмотрите, чем на самом деле был этот процесс: я вручную играл роль модератора, дирижирующего консилиумом. Копипаст, структурирование, перекрёстная проверка между Gemini и Claude - я был конвейером, руками, тринадцать раз. Один промпт умножить на пять моделей умножить на тринадцать раундов. На бумаге это почти смешно. Вот тот зуд, который инструмент и должен был унять.

Что структурированный прогон делает иначе

После того как я собрал Egregor - локальное десктоп-приложение, которое заставляет несколько моделей работать вместе как структурированный консилиум, а не отвечать поодиночке, - я прогнал тот же контракт через него ещё раз. Один аудит смарт-контракта в режиме «Код-ревью» уже использует минимум десять промптов, и это в экономном режиме.

Вот механика. Режим «Код-ревью» загружает пресет из пяти моделей, каждая в своей роли - пять промптов для старта. «Роль» здесь - это песочница со своим промптом; модель, помещённая в роль, работает по нему, и промпт может измениться, если включить какую-то функцию вроде сжатия, экономии или режима «по очереди». Роли могут назначаться пресетом автоматически, либо вы перетаскиваете модель под нужную роль.

Включаешь Anti-Groupthink - добавляются ещё два промпта, и модели меняются ролями: настоящая коллаборация, а не склеенные параллельные запросы. Включаешь Red Team - добавляется ещё один круг консенсуса с очередной сменой ролей. И вот ты уже за десятью промптами, при пяти моделях в пяти ролях. А можно пойти дальше: до двенадцати ролей, у каждой свой промпт, и больше одной модели на роль. Для аудита пяти-шести моделей достаточно - потом можно поменять им роли и провести второй проход.

Содержание этих ролевых промптов я публиковать не буду - это интеллектуальная собственность инструмента. Но опишу то, что потребовало больше всего труда: заставить модели реально быть критичными. Каждая крупная модель обучена вежливо соглашаться и хвалить; только Grok мог позволить себе нахамить. Поэтому в ролевые промпты были вшиты два правила:

1. Не соглашаться с другим участником, пока тот не представит факты и доказательства.
2. Пойти и проверить эти факты самому.

Второе правило важно потому, что - реальный пример из этих прогонов - Gemini иногда предоставлял факты, которых попросту не существовало.

Сам прогон вы наблюдаете в реальном времени. Вы добавляете папку или архив с контрактом в Egregor (он делает всё содержимое понятным для моделей), настраиваете аудит и нажимаете старт - как в обычном окне чата. Сразу появляется список участвующих моделей, и он пульсирует, пока они думают и готовят ответы. Когда раунд завершается, ответ каждой модели группируется в карточку, которую можно открыть, прочитать целиком, скопировать и сохранить. Потом следующий раунд, и ещё - их число зависит от настроек и включённых режимов. В конце модератор формирует финальный вердикт.

Что он нашёл, включая то, что сломалось

Буду честным насчёт того, что именно произошло в этом прогоне, потому что честность здесь и есть суть. Этот консилиум был намеренно скромным, и три из пяти моделей были БЕСПЛАТНЫМИ - не дорогая конфигурация. В конвейере пять шагов. Шаг 1, глубокий архитектурный анализ, не завершился: он упал с ошибкой fetch. Этот сбой был на стороне OpenRouter, а не инструмента; Egregor просто зафиксировал пробел и сообщил о нём в финальном вердикте, вместо того чтобы скрыть. Прогон продолжился на шагах 2–5.

И всё равно - даже со сломанным первым шагом и преимущественно бесплатными моделями - он вскрыл четыре критические проблемы, которые одиночные модели к тринадцатой ручной итерации уже перестали замечать:

1. Риск реентранси в executeAutoPay - присутствующий даже с модификатором nonReentrant, потому что внешние трансферы токенов соседствовали с изменениями состояния. Фикс: все изменения состояния до внешнего вызова, после - проверка балансового инварианта.
2. Отсутствие валидации входа в createStandingOrder - никаких проверок суммы, интервала и получателя, что открывало вектор отказа в обслуживании (DoS) и позволяло создавать нерабочие ордера.
3. Слабая проверка стейблкоина в initialize - try/catch, который молча проглатывал ошибки совместимости токена вместо того, чтобы отклонить нестандартный токен.
4. Вечные права деплоера - админ-роли так и не делегировались таймлоку, оставляя у деплоера постоянный контроль. Архитектурный риск, а не опечатка. Ровно то, что одиночная модель проскакивает.

Вот пример фикса с валидацией - для наглядности конкретики находок:

// Пример фикса: валидация в createStandingOrder
function createStandingOrder(
    address recipient,
    uint256 amount,
    uint256 interval
) external {
    require(recipient != address(0), "Invalid recipient");
    require(amount > 0, "Amount must be > 0");
    require(interval >= 1 days, "Interval too short");
    // ... остальная логика
}

То, что по-настоящему завоевало моё доверие

Консилиум не просто выдал список находок. Он ещё и сам объявил, что не проверял - пометив несколько функций (emergencyWithdrawFull, claimInheritance, finalizeRecovery) как «не проверено глубоко, требует отдельного прохода». Вот эта честность и есть суть, и её было видно в разногласии между шагами. Один шаг выдал широкий список из десяти пунктов, но часть из них была неподтверждёнными гипотезами, написанными без чтения реальных функций. Последующий шаг сравнения отбросил их как шум и оставил только подтверждённое в коде. Одиночная модель либо завалит вас недоказанными догадками, либо выдаст пару находок без перекрёстной проверки. Консилиум отделил подтверждённые баги от шума - и нарисовал карту собственной неуверенности.

Почему это работает (скучная, но настоящая причина)

Это не магия и не «одна дорогая модель такая умная». У современных ИИ есть систематические слепые зоны, которые лишь частично пересекаются. Каждая модель проваливает заметную долю сложных задач - но проваливает не одно и то же. Когда несколько моделей анализируют один код, а потом читают и атакуют выводы друг друга, пробелы перестают совпадать. Что пропустила одна - ловит другая. Что выдумала одна - отвергает другая, особенно когда их обязали проверять факты до того, как соглашаться.

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

Сколько это стоило

Весь аудит обошёлся примерно в сорок центов токенов API, потому что три модели из пяти бесплатные, а платишь только за то, что потребляют платные, - списывается напрямую с твоего API-ключа, без посредников. Профильная фирма берёт за сопоставимую проверку тысячи долларов. Egregor не заменяет полный человеческий аудит для протокола на $50M - но для инди-разработчиков, хакатонов, обучения и предварительных проверок он полностью меняет расклад.

Друзья, не стоит рассматривать EGREGOR только как аудитора, его применение НАМНОГО шире. Вот только несколько примеров:

• Политическое прогнозирование
• Разработка драйверов
• Разработка 3D моделей для печати и литья
• Разработка формул для БАДов (потом сертификация)
• Написание книг и статей
• Точные переводы текстов и технической документации
• Юридические консультации и обсуждения
• Трейдинг
• Бизнес аналитика
• Психология

Всё это пропускается через несколько ИИ моделей, которые вы сами выбираете перед запуском дебатов. Одна голова хорошо, а одна голова + совет из нескольких передовых моделей намного лучше.

Кто за этим стоит

Я - Владислав Штер, соло-фаундер, строю небольшую экосистему инструментов вокруг одной идеи - суверенитета: вы, а не корпорация, должны контролировать свои данные, деньги и ИИ.

• Egregor - это тот самый мульти-ИИ консилиум из статьи; помимо код-ревью у него ещё 28 экспертных пресетов.
• SovereignBank Web3 - некастодиальный банкинг, чей контракт вы только что разобрали.
• SovereignWeb3 Browser - браузер без DNS, разрешающий домены через блокчейн.
• Sovereign - изоляция данных на уровне ОС для смартфонов.

Egregor работает на вашей машине, поддерживает бесплатные и платные модели через OpenRouter и построен на одном убеждении: следующий скачок в ИИ - это не модель побольше, а архитектура поумнее. Заставьте модели, которые у вас уже есть, работать вместе - и они поймают то, что любая из них поодиночке поклялась бы, что этого нет.

Прочитать полный аудит можно на моём github в репо EGREGOR. Одиночный ИИ говорит вам, что контракт чист. Консилиум говорит, где он на самом деле не чист - и куда он не заглянул.

В следующей статье я наберусь наглости и заявлю, что по моему ошибочному мнению, EGREGOR сильнее Mythos и Gemini Ultra, а так же объясню почему.

More details here: https://gitverse.ru/wadyas/Egregor/content/master
GitHub: https://github.com/VladislavShter/Egregor
Demo Video:

Tags: AI Collective Intelligence, AI Council, AI Orchestrator, Multimodality, Code Audit, Smart Contract Audit, Коллективный разум ИИ, Консилиум ИИ, Egregor ИИ, аудит смарт контрактов