ББ-216: ИИ-аудиты в Web3
This episode is in Russian. Transcript lightly edited for readability; timestamps link to the video. Published with attribution to the Базовый Блок podcast — thank you for having us!
[00:00] Вступление и представление гостей
[00:00] Ведущий: Привет, с вами подкаст «Базовый Блок» — подкаст про блокчейн и в последнее время немного про AI. Сегодня будет как раз такой выпуск — про применение искусственного интеллекта в блокчейн-делах. Это выпуск номер 216, и сегодня у нас в гостях Игорь Гуламов и Александра Гуламова, основатели проекта Savant Chat.
В интернете не так много публичных материалов с ними — они не самые публичные личности. Однако в среде русскоязычной ветеранской блокчейн-тусовки авторитет команды Игоря и Александры очень высок благодаря вкладу в развитие Layer 2 на его зародышевом этапе, вкладу в развитие zk-технологий, а также многочисленным аудитам. Поэтому, когда стало известно, что Игорь и Александра создали AI-аудитора кода, это вызвало в OG-тусовке большой интерес. Все знают: ребята не делают буллщит, ребята делиерят сложные продукты и технологии.
[00:55] — Привет, большое спасибо за приглашение!
[00:58] Ведущий: Сегодня мы будем говорить про применение искусственного интеллекта в аудитах безопасности смарт-контрактов. И для того, чтобы выпуск получился более глубоким, я воспользовался тем, что являюсь кофаундером аудиторской компании Pessimistic Security, и позвал в качестве соведущего своего технического кофаундера Женю Марченко.
[01:14] Женя Марченко: Всем привет. Приятно быть на «Базовом Блоке» после долгого перерыва.
[01:19] Ведущий: Женя Марченко — практикующий аудитор смарт-контрактов уже больше восьми лет, а также CTO компании Pessimistic Security, где мы применяем и Savant Chat, и другие AI-тулы безопасности в реальных аудитах. Перед тем как мы начнём, я хочу поблагодарить наших патронов — тех, кто поддерживает нас на сайтах Patreon и Boosty. Огромное спасибо всем, кто нас поддерживает.
Также я хочу сказать спасибо нашим спонсорам. Это компания 1inch — проект с 23 млн пользователей и оборотом около 1 млрд долларов в сутки. По данным The Block, 1inch контролирует около 60% рынка свапов. Через 1inch можно выгодно обменивать токены между Ethereum, Polygon, Arbitrum и другими сетями, получая лучший курс и защиту от MEV-ботов. Обмены внутри Solana, кстати, тоже уже работают.
Также нас поддерживает Zerion. Zerion API — это мощный инструмент для web3-разработчиков. С его помощью можно в реальном времени получать данные о кошельках, токенах, DeFi-позициях и так далее в нескольких десятках блокчейнов, включая Ethereum, Solana и другие. Всё, что вам может понадобиться, в Zerion API есть. API предоставляет детальные человекочитаемые транзакции, аптайм 99,9%, масштабируемость свыше 1000 запросов в секунду. API Zerion используют такие компании, как Uniswap, OpenSea, WalletConnect, Rainbow Wallet и другие.
Также нас поддерживает Fluence — облачная платформа на базе децентрализованной инфраструктуры, которая предоставляет более дешёвую отказоустойчивую альтернативу традиционным облачным решениям, таким как AWS, DigitalOcean и Hetzner. С помощью Fluence вы получаете доступ к глобальной сети независимых провайдеров, можете быстро запускать виртуальные серверы и разворачивать рабочие нагрузки по всему миру, при этом значительно снижаете расходы и не зависите от одного провайдера. Спасибо, Fluence. И наш последний спонсор — это Gosh, кор-разработчик блокчейна Acki Nacki, основанного на новом протоколе, достигающем консенсуса за две итерации — самым быстрым из теоретически возможных. Рекомендую послушать наш недавний выпуск с основателем Gosh Митей Горошевским — получился достаточно хайповым и дискуссионным. Огромное спасибо, Gosh.
[03:26] Как Игорь и Александра попали в блокчейн
[03:26] Ведущий: Ну что же, перейдём к сути нашего подкаста — к обсуждению того, что делают Игорь и Александра. Обычно мы начинаем наш подкаст с вопроса: «Как ты попал в блокчейн?» Думаю, его можно по очереди адресовать Игорю и Александре. Ребята, вам слово.
[03:43] Игорь: Я в блокчейн попал раньше. В целом я следил за биткоином, может быть, через год-два после релиза. Но что-то крипто-нейтивное я стал делать в семнадцатом году, когда Пётр Королёв собрал BANKEX Foundation. Мы там делали разный ресёрч, в том числе по масштабированию. У меня есть несколько публикаций на ethresear.ch по Плазме. Я был на последнем Plasma Camp и примерно тогда нашёл критическую уязвимость в Plasma Prime, после чего, собственно, Плазма закончилась. Уже потом эта история пересобралась как optimistic rollups, но это уже другое, потому что там доступность данных гарантируется какими-то внешними протоколами. Вот так я попал в блокчейн.
[04:50] Александра: В блокчейн я пришла несколько позже. Я сначала немного помогала Игорю — по ZeroPool и ещё по другим нашим проектам, которые к блокчейну не относились. В плане блокчейна — помогала по ZeroPool. Проект стал развиваться, и получилось так, что требовалось больше моего вовлечения именно в нетехническую составляющую проекта. Так что у меня было активное вхождение в блокчейн сразу с zk.
[05:21] — Соболезную. [смех]
[05:24] Ведущий: Когда я готовился к этому выпуску, я слушал недавно вышедший, пару месяцев назад, подкаст CPERX с Игорем. Настоятельно рекомендую его нашим слушателям — тем, кому интересен путь Игоря: какой именно баг он нашёл в Плазме, как Ethereum Foundation поступил с этой ситуацией; там больше про BANKEX Foundation, больше про ZeroPool. Очень интересно, сам послушал с большим интересом. Мы же не будем повторять те же самые вопросы и, наверное, больше времени посвятим безопасности, достигаемой с помощью ИИ — и разрушаемой с помощью ИИ. Разве что от себя я хочу задать пару вопросов, которые интересны, наверное, только мне, но я всё равно воспользуюсь служебным положением. Игорь, правильно же я понимаю, что ты учился на физфаке МГУ и был там в аспирантуре?
[06:27] Игорь: Да, это так.
[06:29] Ведущий: Ты защитил диссертацию или нет?
[06:31] Игорь: Нет, примерно тогда я ушёл в блокчейн, диссертацию защищать не стал. У меня такая ситуация: есть публикации в рецензируемых международных журналах, а диссертации нет. У многих людей обычно наоборот.
[06:47] Ведущий: У меня абсолютно такая же ситуация, поэтому мне и стало интересно задать этот вопрос. Не думаешь, кстати, как-нибудь защитить, когда будет свободное время?
[06:56] Игорь: А его не будет.
[06:58] Ведущий: Второй вопрос, который я хотел задать: как думаешь, как так получилось, что BANKEX Foundation собрал такой цветник талантов? По сути, выходцы из BANKEX Foundation сделали огромное количество крутейших проектов: это и Matter Labs, и Tornado Cash, кто-то из BANKEX Foundation пошёл в 1inch. Вы делали ZeroPool, делаете сейчас Savant Chat. Как думаешь, как так получилось?
[07:28] Игорь: Я думаю, просто наша задача в BANKEX Foundation — это был актуальный ресёрч, который, с одной стороны, достаточно сложный, а с другой — очень новый. То есть там требуется не академическое погружение в эту историю на протяжении предыдущих десяти лет, а умение эффективно решать задачи в абсолютно новой сфере. Это привлекает соответствующих людей, которые могут это делать. Такого предложения в семнадцатом году в России было не сильно много — в основном все шли токены делать, поэтому в BANKEX Foundation собралась такая сильная команда. Ну и у Петра есть определённые таланты и достижения в этой сфере — это тоже важный фактор.
[08:33] ZeroPool, приватность в Web3 и регуляция
[08:33] Ведущий: Ещё один вопрос из нашего блица — касательно проекта ZeroPool. Про ZeroPool, повторюсь, много интересного Игорь уже рассказал в подкасте с CPERX, поэтому не будем очень глубоко нырять в его историю, приватность и так далее — адресую к этому замечательному подкасту. ZeroPool, для наших слушателей, — это такой open-source проект, достаточно олдскульный уже: вы его делали в девятнадцатом-двадцатом году. Он, так сказать, не стал коммерческим, тем не менее, если я правильно понимаю, многие команды впоследствии использовали ваши наработки в своей работе с приватностью. И я хотел бы задать такой вопрос. Я уверен, что ты до сих пор следишь за темой приватности в блокчейне. Возможно, это искажение моего информационного пузыря, но мне кажется, что сейчас тема приватности в Web3 — наверное, вторая по хайпу после ИИ. Что тебе лично, как техническому эксперту, кажется самым интересным из того, что сейчас происходит в privacy? Что с FHE, private smart contracts и так далее — что из этого тебе кажется интересным?
[09:52] Игорь: FHE — это сильная технология, но она не для анонимных транзакций. Кто-то, может быть, пытается делать анонимные транзакции при помощи FHE, но это не лучший инструмент для этого, потому что там есть ключ, который распределён по тем, кто вычисляет. В zk этого нет — от сетапа в современных протоколах давно отказались. FHE вычислительно намного тяжелее, чем zk: в zk сейчас можно доказывать очень большое количество расчётов за счёт рекурсии, а у FHE всё-таки больше множитель сложности для того, чтобы делать какие-то вычисления.
[10:44] Ведущий: А какие самые интересные проекты, которые сейчас работают в области privacy, как тебе кажется?
[10:53] Александра: Основной интерес здесь не столько в технологиях, сколько в legal-сфере, потому что legal сейчас, как это ни парадоксально, влияет на рынок privacy намного больше, чем любые технологии, — именно тем, что останавливает прогресс в сторону privacy. Причём я не говорю о том, чтобы регуляция была какая-то определённая, — речь о том, чтобы она в принципе была. Более-менее последнее, что у нас есть по части регуляции, — письмо от американских регуляторов о том, что privacy — это high risk. Оно было несколько лет назад. Что такое high risk, они толком не объяснили: «с комментариями ждите последующих апдейтов» — которых мы ждём до сих пор. Таким образом, у регуляторов получается полная свобода воли решать, что такое хорошо и что такое плохо. И как только появится какая-то прозрачная регуляция — моё мнение, что технологии начнут сразу очень быстро развиваться, потому что и у ZeroPool есть ещё что показать, и у других проектов тоже. Я уверена, что у того же Aztec более чем достаточно, что показать. Как только на этом рынке появится прозрачная регуляция, будет очень много технологических апдейтов, намного более интересных, чем то, что происходит сейчас, и они будут очень быстрыми.
[12:20] — Речь тут скорее не про то, что нужен кто-то, кто даст или не даст пермит, — нужно отсутствие произвола. Сейчас проблема в том, что с каждым privacy-проектом чиновник может делать всё, что в голову взбредёт. То есть это беспредел.
[12:41] — Именно поэтому мы ZeroPool не полностью закрыли — он именно на стопе до какой-то прозрачной регуляции в этой сфере.
[12:50] Ведущий: А вы видите какие-то подвижки? Я не очень глубоко за этой темой слежу, однако в чат нашего подкаста периодически закидывают какие-то вещи: собрался какой-то таск-форс, они обсуждают — мы сейчас институционалов сажаем на блокчейн, нам поэтому нужно соблюдать банковскую тайну, нам нужно гибкое privacy, и так далее. Слово privacy звучит из уст людей в галстуках, которые выступают за дубовыми кафедрами, и от этого у меня ощущение, что подвижки есть. Но, судя по тому, что вы говорите, они пока не выразились в конкретных актах.
[13:30] Александра: Ну да, как я и говорю: это всё началось и пока, по сути, чем-то более-менее осязаемым закончилось вот этим письмом от американских регуляторов. В этом плане Штаты всё-таки играют одну из лидирующих ролей в международной регуляции. И понятно, что, так как у них прецедентное право, кейс Tornado Cash, естественно, будет иметь большое влияние. Я вижу эту историю не так, что эти люди в костюмах и галстуках о чём-то договорятся, — потому что договориться они могут максимум о том, что чей-нибудь кум или сват получит частный билль. О чём-то другом в таких вещах они договариваться не могут. Такие вещи происходят через практику — вроде того, как в итоге разрешится ситуация с Tornado Cash. Это процессы, которые относятся не к privacy, а в целом к тому, как решаются вопросы. Они идут не эволюционно — иногда они ведут себя более революционно. Надо просто больше здравого смысла, потому что если его меньше, можно десятилетиями вести дискуссию про то, могут ли люди пользоваться ножами.
[14:54] Savant Chat: идея и архитектура
[14:54] Ведущий: Давайте перейдём к обсуждению Savant Chat. Начнём, наверное, с такого предварительного разогревающего вопроса: откуда взялась идея сделать Savant Chat? Как он появился?
[15:06] Александра: Наша команда активно следила за тем, что происходит на рынке, и в целом за развитием моделей. Так как у Игоря довольно большой опыт в плане аудитов, в том числе сложных аудитов zk-проектов, мы периодически пробовали — не с точки зрения запуска нового проекта, а с точки зрения того, что могут модели. Аудит — это такой определённый стандарт в плане сложных технологий: если модели что-то могут с точки зрения аудита, то имеет смысл применять их и для разработки в том числе. То есть это как некий экзамен для технологии. И около года назад мы заметили, что LLM доходят до той стадии, когда уже что-то могут в аудитах. Мы попробовали с этим поиграться просто в рамках онлайн-хакатона, результат нас несколько удивил — и мы решили делать продукт.
[16:10] Ведущий: Приятно удивил, я так понял. Хорошо. Расскажите, как Savant Chat устроен.
[16:15] Игорь: Он устроен следующим образом. Мы разбиваем код на семантически корректные чанки. Потом мы генерируем документацию по этим кусочкам кода, по проекту. Также мы берём RAG по документации, которая была предоставлена пользователем при аудите: это может быть скраулинг сайтов, каких-нибудь гитбуков, какие-то whitepaper'ы. Мы устанавливаем связи между кусочками кода и документацией. Дальше мы закидываем эти кусочки в агента — генератора гипотез. Потом гипотезы исследует агент-аудитор, потом агент-критик отфильтровывает ошибки, потом происходит дедупликация. Там много разных более тонких архитектурных моментов, но если говорить в целом, то вот такой пайплайн.
[17:20] Ведущий: То есть на входе для пользователя это выглядит так: он может закинуть в Savant код, документацию, которая у него есть, дальше Savant делает то, что ты только что описал, и на выходе выплёвывает красивый PDF-репорт со списком находок?
[17:39] — Мы делали это так, чтобы для пользователя процесс был максимально привычен и понятен. В том числе мы учитывали особенности Web3-комьюнити: оно довольно интровертное и не очень стремится лишний раз общаться с людьми, поэтому всё максимально автоматизировано. У нас максимально лёгкий вход на платформу, максимально лёгкий этап загрузки: ты просто загружаешь туда свой код практически любым удобным способом и получаешь репорт, который обычно получаешь после аудита в человеческих компаниях, — он максимально приближен к этому формату, чтобы пользователю всё было максимально комфортно. Процесс, который немного отличается от стандартного аудита, — это CI/CD-интеграция: ты можешь подключить проверку для совсем ongoing security и проверять код небольшими кусочками, когда готовишь релиз. Там получается совсем быстрый результат — вплоть до того, что за 10–15 минут можно получить баг-репорт в Telegram.
[18:51] — Я хотел бы задать вопрос касательно того, как устроен пайплайн. Если я правильно понимаю, условно, сначала код, как Игорь сказал, разбивается на кусочки, устанавливается соответствие с документацией. Кстати, как RAG расшифровывается, напомните?
[19:07] Игорь: Прямо сразу не скажу. Но я могу много рассказать про то, как он работает.
[19:12] — Тогда скажи своими словами, что это такое, чтобы нам сейчас не задерживаться.
[19:16] Игорь: Это построение такой системы. Мы берём данные, разделяем их на чанки. Для каждого чанка мы строим эмбеддинг — это вектор в многомерном пространстве, там может быть тысяча измерений. Соответственно, у нас есть эти чанки, есть наше сгенерированное описание для кусочков кода — мы тоже строим для него эмбеддинг. И потом мы смотрим в этом многомерном пространстве, какие кусочки ближе всего к тому, что мы ищем. После этого мы берём сто ближайших кусочков и делаем реранкинг: закидываем в модель, которая выбирает для нашего запроса из ста, допустим, десять самых подходящих кусочков, и уже это закидывается на вход для моделей.
[20:16] — Надеюсь, что я понял. Дальше у тебя есть несколько моделей, я так понимаю, публичных, которые генерируют гипотезы, потом эти гипотезы как-то отфильтровываются, дедуплицируются и попадают в отчёт. Вопрос у меня такой: а все ли так делают? Есть ли другие подходы к тому, как сделать архитектуру AI-аудитора?
[20:41] Подходы к AI-аудиту на рынке
[20:41] — На самом деле на рынке есть несколько подходов. Кто-то делает просто враппер для какой-то одной LLM. Особенно это заметно, как только выходит новая версия одной из Tier-1 моделей, которая более-менее хорошо работает с кодом и подходит для аудитов: сразу появляется пачка новых AI-аудиторов, которые дают почти бесплатную цену и максимально быстрый результат — но это, по сути, работа одного промпта, и результат соответствует. А другой подход — это обучение своей модели на базе существующих уязвимостей.
[21:35] Александра: И мы верим, что AI ценен именно своим новым взглядом и новым подходом к работе с кодом. Таким образом мы часто получаем в отчётах результаты, которые максимально не похожи на то, что находит человек и что человеческие аудиторы обычно могут считать за уязвимости. Это не потому, что человек плохо работает с кодом, а потому, что у человека есть своя база, свой опыт, свои стереотипы и в какой-то степени определённые шаблоны мышления, как бы мы ни хотели от этого отходить. А AI даёт абсолютно другой подход к коду.
[22:12] Следующий релиз: эксперименты с кодом и учебник уязвимостей
[22:12] Игорь: Есть наш подход, и есть подход next-gen — когда агент может проводить эксперименты с работающим кодом: что-то где-то деплоить, подёргать. Это то, над чем мы сейчас работаем, чтобы сделать следующий релиз. Это очень сильно уменьшит количество фолс-позитивов — их у нас достаточно мало, но всё-таки больше, чем в человеческих аудитах. Такой подход позволит радикально уменьшить их количество.
Были тезисы — я не помню, кто именно из AI-ресерчеров это говорил осенью, — что хорошая архитектура — это не супермодель, которая в своих весах знает всё, а модель, которая знает принципы: если ей на вход дать какие-то знания, она применит принципы к знаниям и будет выдавать качественный результат. Мы сейчас, кроме возможности проводить эксперименты с кодом в процессе аудита, делаем учебник по всем уязвимостям, которые были, — для нейросетей и при помощи нейросетей. И мы планируем прикрутить его к Savant Chat, наверное, даже быстрее, чем возможность выполнять код. Соответственно, с ним нейросети, когда будут видеть код, пройдутся в том числе по типовым кейсам — не в ущерб, естественно, тому, чтобы придумать что-то новое. Просто 95% того, что есть, — это всё-таки композиция старого, а не что-то новое. Это повысит качество для наших клиентов.
[24:07] — Ты сказал, что вы делаете справочник для ИИшек на тему того, какие уязвимости уже были. Если я правильно понимаю, вы же уже на чём-то дообучали модели, которые используете? На чём вы дообучаете?
[24:22] Александра: Нет. Поэтому я и сказала, что мы изначально не пошли от подхода, когда обучают своё, — мы заставляем на данный момент разные комбинации LLM думать над кодом. Сейчас наша архитектура такая, что код видится в первый раз и анализируется с нуля: где могут быть уязвимости и слабые места. Теперь это дополнится учебником уязвимостей, но подход, при котором каждый код смотрится с нуля, как в первый раз, останется — учебник просто его дополнит. Основной упор всё равно останется на свежем взгляде.
И как раз хотела дополнить то, что Игорь сказал, — что более-менее уязвимости одни и те же. С одной стороны, это действительно так, это абсолютно валидно для кода, написанного человеком. Но сейчас разработка двигается в сторону вайбкодинга, причём в разных видах: не только когда всё написано с нуля, но и когда очень опытные и классные разработчики дополняют этим свою работу — в том числе у нас в команде это активно используется. И здесь AI может генерировать те уязвимости, которые человек не генерировал, — соответственно, нужен и другой подход. И здесь опять-таки сильная сторона того, что у нас AI смотрит на код со своей точки зрения.
[25:48] Комбинирование разных LLM под разные задачи
[25:48] Игорь: Говоря про разные модели — мы используем их сильные стороны. Допустим, модели от Anthropic неплохи в использовании tools, но слабые в STEM, и у них всё хорошо с творчеством. У моделей от OpenAI с творчеством всё плохо, но всё хорошо с instruction following. У моделей от Google — Gemini — всё хорошо и с творчеством, и со STEM, но без специальных действий со стороны промпт-инжиниринга они будут выдавать нестабильный результат, который существенно сложнее применить. Поэтому мы комбинируем разные модели для разных подзадач: есть задачи креативные, есть задачи, где наоборот нужно некреативно и совсем тщательно проверить, есть задача агрегации разных результатов. Под разные задачи подбираем разные модели, чтобы обеспечить максимальное качество при минимальной цене.
Также запросы делаются параллельно со скидками — мы активно используем batch-запросы, чтобы увеличить количество инференса, доступного нашим пользователям для аудитов. Соответственно, то, что мы делаем, просто завайбкодить нельзя — ни за вечер, ни за неделю, ни за месяц. К тому же, если использовать одну любую модель или даже две, результат будет хуже, а цена больше. И мы постоянно обновляем наш инструмент под новые релизы и проводим бенчмарки.
[27:44] Женя: Поправьте меня, правильно ли я понял: у вас на вход, помимо данных от пользователя, идёт ещё огромный подготовленный вами контекст — вот этот учебник, например, который вы сейчас делаете, со взломами, хаками, уязвимостями. И какие-то, наверное, ваши инструкции в целом: промпты, подсказки, как пользоваться агентами, как взаимодействовать с этой кодовой базой.
[28:12] Игорь: Это не кодовые базы, это принципы. Мы собрали уязвимости, делаем по ним кластеризацию, используем LLM, чтобы очистить все эти уязвимости от контекста проекта, оставить только root cause и описание — что должно в проекте происходить, чтобы такое имело место. Потом мы с этими данными работаем, и учебник получается таким образом — его пишет искусственный интеллект.
Мы вообще отходим от парной работы человека и AI — это то, что было этим летом, мы от этого уходим. Сейчас мы переходим к процессам, когда инженер строит пайплайн, в котором AI может работать над каким-то решением. Смысл в том, что AI не только делает задачу, но и проверяет её: промежуточные проверки делает AI. Есть какие-то критерии, и по ним AI задачу проверяет. Если там какие-то проблемы, он возвращается назад, исправляет их и делает дальше, пока не решит. А человек делает только окончательную приёмку.
Соответственно, говоря про эту базу — это очень большой объём вычислительной работы, потому что нужно обработать при помощи нейросетей все уязвимости, которые когда-либо находили в смарт-контрактах. А перед этим их надо собрать — искусственный интеллект отлично справляется с этой задачей. У нас небольшой стартап, три инженера, и мы можем себе позволить делать такие задачи. Ещё летом не могли, потому что это просто колоссальное количество raw power, которое может делать гигантское количество интеллектуальной работы.
[30:26] Человек и AI: противопоставление или дополнение
[30:26] — Слушай, у меня ощущение, что последние пять минут на фоне присутствует такое противопоставление человека и AI на разных уровнях. Например, тул в основном полагается на AI, а AI думают иначе, чем люди, поэтому и проблемы искать будут другие и по-другому. Или хакеры, которые раньше искали всё руками и думали как люди, — теперь это тоже какой-то AI, и он ищет другие проблемы. Код генерирует тоже AI — теперь другие проблемы. И даже вот эта база данных, учебник, который вы составляете, — он, наверное, в основном состоит из человеческих ошибок и людьми найденных уязвимостей, но обработан AI. Как вообще выглядит эта динамика между человеком и AI, этот баланс сил сейчас? И как он, может быть, меняется по мере того, как AI двигается вперёд?
[31:18] Александра: На мой взгляд, противопоставлять человека и AI — изначально не очень продуктивный подход. Это исключительно про дополнение. Мы как раз и говорим о том, что AI дополняет человека: AI даёт другой взгляд на код. И поэтому мы говорим, что AI-аудиты, в том числе Savant Chat, — это ни в коем случае не замена человеческого аудита. Это инструмент для онгоинг-разработки, для подготовки к человеческому аудиту, для быстрой проверки и повышения безопасности именно в процессе разработки.
Когда мы говорим про то, что вайбкодинг даст другие уязвимости, — он даст ещё и новые уязвимости, но человеческие никуда не денутся, потому что значительную часть разработки всё равно пишут люди, и уязвимости, которые они вносят в код, никуда от этого не денутся. Это просто дополнится, и поэтому нужен AI-аудит, который дополнит человеческий. И то же самое, как ты правильно сказал: это человеческие уязвимости, и AI дополняет их тем, что структурирует. Здесь всё исключительно про совместную работу AI и человека — singularity is not here yet. По крайней мере, пока мы можем говорить только про взаимодействие человека и AI.
[32:52] Опыт аудитора и вопрос интерактивности
[32:52] Женя: Я сам пользуюсь парой инструментов, включая Savant, для аудитов. Я запускаю его на всей кодовой базе, беру результаты и смотрю их ближе к концу ручного аудита, когда уже разобрался в проекте, но хочу посмотреть на код ещё с другой стороны. Savant особенно — действительно прямо по-другому думает, периодически удивляет, и это хорошо. Мне как аудитору приятно подумать ещё под другим углом, посмотреть на уже знакомый код — это повышает мою уверенность, что я разобрал все сценарии, которые могут быть.
При этом реальной возможности как-то взаимодействовать с AI у меня почти нет. Какие-то инпуты на вход я могу подать — я не разработчик, поэтому в основном просто передаю собранные материалы. И на выходе я тоже не могу сказать: «Подумай об этом. Я вижу, ты сделал такое предположение, я понимаю, что ты вычитал его в документации, но это предположение неверное — подумай ещё раз». Это не упрёк Саванту, все тулы сейчас такие, но это то, чего мне как аудитору, может быть, не хватает, — какой-то интерактивности. Как вообще может быть устроено плотное взаимодействие людей и AI? Потому что сейчас его пока нет.
[34:12] Игорь: Это всё-таки больше похоже на построение технического задания — на то, чтобы дать AI документацию. Возможно, после правки ошибок это какой-то реаудит с поправками, когда по второму разу он работает уже с учётом всего этого. Именно на лету — я не уверен, что что-то получится, потому что на серьёзных продакшн-скоупах это может быть 100 000 запросов к LLM, которые идут на протяжении 10 часов и стоят 10 000 долларов. Это вполне нормальная история для Savant Chat.
[35:02] Женя: Тогда, может быть, — вы упоминали CI/CD в начале разговора — может быть, там где-то возможна интерактивность? Понятно, что медленно, но разработчики могут дать какие-то инструкции AI-тулам, чтобы те меньше сходили с ума, меньше галлюцинировали и меньше беспокоили на ровном месте.
[35:21] Игорь: Конечно. Говоря про CI/CD — это, наверное, самое близкое к интерактивности, потому что людям не нужно, чтобы AI за счёт стереотипов и непонимания контекста долбил каждый раз о какой-нибудь фигне при каждом коммите. А он будет делать именно это, если не будет грамотно организованной обратной связи. Сейчас это можно сделать при помощи внесения соответствующих записей в документацию: добавить комментарий к кусочку кода о том, как он на самом деле себя ведёт, — и такие стереотипы у искусственного интеллекта исправятся, он не будет туда долбить.
Но это не работает в формате ChatGPT, потому что ChatGPT — это парная работа, а тут решения подразумевают огромное количество ресёрча, больше, чем у ChatGPT Pro. ChatGPT Pro делает автономный ресёрч сам: пока он его делает, он разве что показывает человеку свой ризонинг. Но, допустим, человек посреди этого ресёрча увидел, что тот копает куда-то не туда. Если человек увидел это на тридцатой минуте, он не будет дропать весь ресёрч, чтобы поправить чат. Почему? Потому что направлений ресёрча не один десяток, и понятно, что какие-то из них будут не самые лучшие, а какие-то — лучшие. Главное — что он потом выберет для референса, а что выбросит как мусор.
У нас же параллелизма больше и взаимодействия больше. Это такой DAG, который имеет несколько этапов и очень широкий — до сотни тысяч запросов к разным моделькам. В этом плане у нас меньше возможности показывать пользователю что-то осмысленное в процессе. Опять же, мы специально настраиваем модели так, чтобы они предлагали самые безумные решения, а потом мы их фильтруем. Причём иногда могут быть зафильтрованы и какие-то хорошие безумные решения, но поскольку их много, не все они будут зафильтрованы — какие-то попадут в репорт, и там можно будет прочитать что-то полезное. А если человек будет вникать во всё это в процессе — это слишком большая когнитивная нагрузка: человеку и так потом разбирать, может быть, 50 листов отчёта, которые написал искусственный интеллект.
Мы работаем над этим. Я думаю, что CI/CD — самое близкое к этому интерактиву. Возможно, в будущем появятся какие-то механизмы: может быть, можно будет сделать такую штуку, чтобы AI мог по моментам, которые ему не очень понятны, спрашивать что-то у человека. Мы про это думали, но сейчас, к сожалению, у нейросетей — особенно с большой креативностью, которая нужна для поиска ишьюс, — всё крайне плохо с осознанием собственного незнания: они скорее что-то напридумывают. Ну а что делать — нам именно это их свойство и нужно, когда мы хотим, чтобы они что-то придумали.
[38:57] Традиционные инструменты и формальная верификация
[38:57] — Интересный получается комплекс проблем: с одной стороны — креативность, с другой — нельзя оперативно получить контроль и фидбэк от человека. CI/CD — понятно, но есть один большой скан. А можно ли что-то из этого компенсировать использованием традиционных инструментов? Статический анализ, любой другой — весь арсенал, который инженеры раньше придумывали, чтобы автоматизировать эту проблему. Может ли AI эффективно им пользоваться и улучшать свои результаты?
[39:30] Игорь: Когда мы выбирали, как делать учебник по проблемам, мы думали в том числе завайбкодить фактически статический анализатор — какой-нибудь гигантский статанализатор, похожий на Slither, но в котором есть всё. Но мы решили, что лучше делать его словами: описать, что плохого может происходить, а дальше нейросети это почитают и что-нибудь найдут. То есть это такой статанализатор, который мы внедряем немного другим путём — не тем, которым это обычно делается.
Говоря про инструменты, я думаю, что самое перспективное — это формальная верификация. Даже когда мы говорим про обучение: нейросети, которые решают математику, сейчас учат с использованием формальной верификации. Формальная верификация была моделью искусственного интеллекта ещё до нейросетей: в середине XX века люди считали, что если научить компьютеры работать с логическими утверждениями, то из этого получится интеллект. Не получилось. Почему? Потому что сложность растёт экспоненциально: это такое многомерное пространство, в котором можно пойти куда угодно, а нам нужно из постановки задачи прийти к решению. Этот путь прокладывает нейросеть, но в нём могут быть ошибки. А вот логическая система — формальный верификатор, прувер — может доказать, что ошибок нет, и это делается быстро. Для поиска пути как раз нужен искусственный интеллект, потому что система из коробки умеет только делать перебор, а перебор при экспоненциально растущей сложности — плохая идея. Зато готовый путь проверяется эффективно.
Что это значит для смарт-контрактов? Если научить AI-агентов пользоваться формальной верификацией, то вместо того, чтобы нейросеть думала над какими-то гипотезами, ковырялась в коде и иногда галлюцинировала — а она будет галлюцинировать, потому что мы используем нейросети в режиме максимальной креативности, — мы берём креативную гипотезу нейросети и сразу прогоняем её через формальный верификатор. В итоге инференса меньше, надёжности больше. Мы делали с этим эксперименты — эксперименты интересные. Мы будем над этим работать и внедрим это в Савант.
[42:29] — Говоря про формальную верификацию в таком её использовании: обязательно нужно делать полное описание всей системы контрактов, которые в скоупе, или можно формально проверять отдельные свойства? Детский пример: сумма балансов всегда равна totalSupply. Можно ли изолированно проверить это свойство с помощью этой математики?
[42:52] Игорь: Да, конечно, можно. Как его правильно формулировать? Правильно формулировать не так, что сумма балансов равна totalSupply, а так: когда у нас меняются балансы, изменение totalSupply равно изменению балансов. Почему? Потому что это локальная история. После этого мы пробегаем по всем местам, где это есть, и проверяем эту локальную историю — и таким образом убеждаемся, что всё нормально. Ситуация, когда AI что-то упустил, абсолютно исключена, потому что мы разбиваем код на маленькие чанки, и каждый чанк смотрим отдельно.
[43:48] Игорь: И, соответственно, если там где-то что-то с балансами происходит, то модель это заметит и построит описание для формального пруфа под каждый отдельный такой кейс. Потом это всё докажут, и мы получим большое утверждение, что сумма балансов всегда равна totalSupply. Это как раз и есть про тот самый путь. Потому что закинуть в формальный верификатор общую задачу, если у нас куча сложных разных логик, — это сложно, а модель может декомпозировать эту историю. Модель даже может потом из этих кусочков составить и общее утверждение: она берёт теоремы отдельно про каждую историю, а потом тривиально составляет из них большое глобальное утверждение. Это как раз про то, чтобы найти путь, как решать задачу в этом многомерном пространстве, в котором можно написать какие-то математические утверждения.
[45:00] —: Звучит как большая голубая мечта: один AI написал, другой прочитал, составил спецификации, верифицировал и доказал, что это работает как надо. При этом интуиция подсказывает мне, что в пределе оно так работать всё равно не будет. Или всё-таки возможно, что когда-нибудь людей вообще можно будет исключить из этого цикла, и оно будет магически всё срабатывать хорошо и без проблем?
[45:28] Игорь: Чтобы ставить задачи, нужно понимать, что это такое. Я сильно сомневаюсь, что из этой истории будут как-то исключены инженеры, потому что не инженер, наверное, не сможет инженерные вещи эффективно обсуждать с искусственным интеллектом и правильно ставить задачи. Если будет AGI, то, конечно, много изменится, но это будет вообще абсолютно другая история — там будет происходить много чего.
Если говорить про время до AGI, то есть до ситуации, когда искусственный интеллект может выполнить любую человеческую задачу, — инженеры точно нужны, потому что нужно ставить задачи, и инженер поставит задачу лучше, чем не инженер. А если мы рассматриваем мир, в котором AI может любого человека заменить, — это уже абсолютно другая история, и там, наверное, основные проблемы не с инженерами.
[46:35] AI-безопасность за пределами Web3
[46:35] Женя: Там уже вопрос, нужно ли тратить время на разработку аудиторов, или можно уже не тратить на это своё время. Я хотел бы задать вопрос более общий. Следите ли вы за тем, как развивается кибербезопасность в разрезе AI вне web3? Наверняка же там кратно больше умных людей работает, чем в web3, и наверняка там тоже есть чем вдохновиться, какие-то более общие подходы. У нас в web3 в целом немножко искажённое восприятие того, что такое кибербезопасность, — в сторону аудитов. Общая кибербезопасность, веб-двушная, не так сильно завязана на человеческие аудиты. Наверняка там AI сейчас больше используется и в других задачах: в мониторинге, в пентестах и так далее. Смотрите ли вы на это?
[47:45] Игорь: Мониторинг — это интересно, смотрим на это. Но всё-таки наш профиль — это больше работа с кодом. Пентесты — тоже интересно и перспективно. Я думаю, AI сейчас может эффективно заниматься и мониторингом, и тестами. Есть много проектов, которые говорят, что они работают с кодом и находят там неэффективный код или какие-то ошибки. В это я верю меньше, потому что я вижу, как это работает в Solidity: код часто максимально оптимизирован, ошибки исправлены, и требуется потратить реально очень много инференса, чтобы найти что-то интересное. Для Web2 эти косты пока слишком дорогие, но цена инференса быстро падает, количество false positives тоже падает.
Я думаю, мы придём к тому, что сможем аудировать код web2-проектов, как смарт-контракты, делать формальную верификацию кода в web2-проектах, и это будет работать — чтобы разработка была эффективной и без таких проблем. К этому мы рано или поздно придём. Но пока пентесты и мониторинг — основные направления, по которым искусственный интеллект может там давать качественный результат.
[49:14] Воспроизведение zero-day и root cause
[49:14] —: Хочу вернуться обратно в web3. В Web2 постоянно бывают zero-day, и обычно это история про какую-нибудь библиотеку: в ней была уязвимость, все ей пользовались, и теперь у всех проблемы — все ждут патча и надеются, что их не коснётся. Web3 устроен всё-таки немножко по-другому. При этом я видел, вы пишете, что большинство взломов вы можете воспроизвести, — потенциально Savant мог предотвратить zero-day, которые случались у нас. Мог бы ты уточнить поподробнее, что означает, что вы их воспроизводите? И в целом поговорить о том, как поменялась бы ситуация, если бы Savant запускали на каждом контракте.
[50:02] —: Здесь имеет смысл дать общий ответ, прежде чем уходить в технические детали. Под воспроизведением zero-day мы имеем в виду, что Savant нашёл в коде то место, откуда произошёл сам взлом. То есть если бы эти проекты — как Abracadabra, Balancer — использовали Savant, мы могли бы предотвратить эти громкие хаки осени. Но мы не заявляем, что Savant воспроизводит 100% хаков. Скорее валидно говорить о том, что AI-инструменты используются не только для усиления безопасности в процессе разработки — blackhat-хакеры тоже используют AI-инструменты. Savant воспроизводит последние хаки осени, которые очень сильно отличаются от того, что было до этого. И на основании того, что Savant это воспроизвёл, мы можем говорить, что хакеры тоже начинают активно использовать AI-инструменты для своих целей.
При этом неправильно говорить, что мы воспроизводим все zero-day. Какую-то значительную, возможно, большую часть мы воспроизводим, но здесь есть свои нюансы. Во-первых, есть full exploit path — это то, что сделал хакер, а есть root cause — строчка, в которой сидит reentrancy или какой-нибудь arithmetic overflow. Это не значит, что это приведёт к краже денег, но это ошибка в коде. То есть root cause — это изолированная ошибка в коде, а exploit path — то, как можно украсть деньги. Мы воспроизводим root cause, то есть находим ошибку в коде. Очень часто мы не идём дальше или идём куда-то не туда, потому что Savant Chat — это штука для защиты, а не для атаки. Мы видим: root cause найден — хорошо, нас это уже устраивает. Можно было бы раскрутить это дальше до exploit path, но это опционально. Для валидации это, наверное, полезно: мы сейчас работаем над тем, чтобы прикрутить execution кода, и может быть полезно докручивать exploit path, чтобы лучше писать proof of concept. Даже написать proof of concept для arithmetic overflow на протоколе — тоже хорошая идея.
Savant нашёл все root causes и нашёл достаточно много exploit path. То есть иногда он пишет прямо верное утверждение, как можно извлечь деньги, а не просто что там какая-то серьёзная ошибка. Это не значит, что Savant умнее людей — скорее это значит, что хакеры используют искусственный интеллект, чтобы искать проблемы. Более того, сейчас волна хаков пошла по closed source смарт-контрактам. Раньше берёшь какую-нибудь декомпиляцию — код выглядит грязно, нечитаемо, а искусственный интеллект может его восстановить. Он может посмотреть на эту декомпиляцию, сделать реверс-инжиниринг, потом профаззить байткод против реверс-инжиниринга, чтобы убедиться, что это одно и то же. А потом в смарт-контракте, который уже отреверсен, он будет искать ошибки и применять их к байткоду. В результате найти уязвимость будет намного дешевле, чем если бы люди ковырялись в этом байткоде или реверсили каждый такой контракт. То есть если контракт не проаудирован и там есть хоть какое-то адекватное количество денег, сотни тысяч долларов, — он под угрозой, потому что его декомпилируют и исследуют хакеры своими инструментами. Security through obscurity не спасает.
[54:32] Женя: Да, кстати, мы дадим ссылку на ваш пост, который вы, я так понял, вчера написали на эту тему, — я сегодня читал, очень познавательно. От себя тоже хочу добавить, что действительно большое количество хакеров работает автоматизированно, и работают уже давно. Я помню случаи как минимум с 2020 года, когда, условно говоря, кто-то деплоил контракт, и его взламывали в течение пяти минут. Человек с глазами не мог успеть всё это посмотреть и придумать — хакеры давно работают автоматизированно.
[55:06] Волна AI-взломов и вайб-аудит
[55:06] Женя: Я хотел задать вопрос ещё касательно этой последней волны AI-взломов. Мне навеяло это следующую мысль: есть подозрение, что большое количество недавних взломов каких-то старых протоколов — это взломы AI-assisted. И я знаю твою позицию, Игорь: от вайб-хакеров нам, условно, единственное средство — это вайб-аудит. Понятно: если вайб-хакер может найти что-то, что человек не видит, то и защититься мы можем чем-то, что человеком не является. Эта позиция мне абсолютно понятна и выглядит рационально. Однако мысль у меня сегодня была такая: тулы-то тоже совершенствуются, AI совершенствуется — сейчас он может делать то, что не мог полгода назад. А смарт-контракт ты разочек задеплоил — и всё, сиди, живи с ним. Допустим, мы сейчас разработали смарт-контракт, сделали прекрасный аудит с помощью AI-тулзов, задеплоили его, прошло полгода — и AI развился настолько, что может найти баг там, где раньше его не находил. И получается, с моей точки зрения, как-то страшно стало жить. Ты не можешь быть уверенным, что, условно, положишь деньги в какой-нибудь DeFi-протокол и можешь о них полгода не вспоминать. Если раньше ты более-менее спокойно мог жить — с поправкой на наши web3-шные особенности, — то сейчас, по мере прогресса AI, становится всё более и более страшно. Что ты можешь на этот счёт сказать?
[56:46] Александра: Вернусь опять к своей точке зрения, что AI дополняет человека. У нас среди клиентов есть примеры, когда довольно крупные протоколы прогоняли через Savant код, который уже лежит на проде, которым пользуются, у которого очень много пользователей, — и находили там уязвимости, слабые места, и это не помешало им их исправить. То есть если код задеплоен, это не значит, что мы не можем его совершенствовать и фиксить. Делать постоянно человеческий аудит — это, естественно, очень дорого и долго, тем более если мы говорим о том, что хакеры всё больше используют AI. А регулярно прогонять свой код, даже тот, который на проде, через Savant, видеть уязвимости и что-то фиксить — это вполне себе решение.
[57:48] Игорь: Проекты будут регулярно аудировать свой код, особенно когда выходят новые модели, — а мы их вкатываем буквально за несколько дней. Может быть, мы достигнем того, чтобы вкатывать день в день. Соответственно, нужно просто сделать реаудит. Если это смарт-контракты, у протокола есть только один вариант — переезжать на следующую версию, это стандарт. Если это upgradable contract, то его можно починить. Ну, только так.
[58:17] Женя: Примерно то, что я на самом деле ожидал услышать. А дальше у меня как раз такой вопрос: есть примеры этого?
[58:24] Александра: Я сейчас, естественно, не буду называть команды, которые это делали, но я знаю по отзывам, что ребята так делают: прогоняют, как я уже сказала, существующий код, на котором много живых юзеров, видят, что там уязвимость, просто её фиксят — и, соответственно, протокол становится более безопасным.
[58:44] AI-аудит как бизнес: тарифы и багбаунти
[58:44] —: Вопрос касательно AI-аудитора как бизнеса. Вы чаржите своих клиентов за аудит, условно, построчно. И одна из мыслей, которые сразу возникают: не пытались ли вы сами такого рода аудиты делать — просто прогонять подряд весь код, который заявлен на багбаунти, находить там баги и репортить их? Почему вы так не делаете? Хакеры же так делают: прогоняют код, что-то находят, хакают — и вроде как в плюс это всё работает. Почему бы не направить этот вектор в белую сторону?
[59:28] Александра: По первому пункту, про то, что мы чаржим за строчку: это было сделано для того, чтобы у юзера был максимально привычный и лёгкий путь использования продукта. По факту это чаржится не за строчку — вычисление более сложное, и правильнее говорить, что за токены, — но для простоты, чтобы быть более понятными пользователю, мы говорим про строчки кода.
Если говорить про багбаунти: во-первых, стоит отметить, что Savant был первым AI-аудитором, который занял шестое место на Sherlock ещё летом, соревнуясь с людьми. Но мы это делали не из желания получить дополнительный источник финансирования, а чтобы посмотреть, как модель работает в том числе на таких площадках. И результат получился более чем впечатляющий: Savant — первое решение, которое достигло такого результата. Но мы до этого с этими площадками как человеческая команда сами не работали. И мы поняли в ходе этого эксперимента, что основная часть работы там — это не сам аудит, а доказывание жюри, что это действительно баг, как это может привести к краже денег и так далее. Savant этим не занимается, и чтобы полноценно этим заниматься, возможно, нужны отдельные люди. Для нас это не наш бизнес, но мы сотрудничаем с аудиторами, кто хочет в этом участвовать, — мы об этом заявляли, и есть примеры сотрудничества. Поэтому, если кто-то хочет получить такой инструмент для использования именно в whitehat-направлении, можно выйти с нами на связь, и мы готовы это поддерживать. Но сами мы считаем, что каждый всё-таки должен заниматься своим делом: если мы будем так распыляться, результат нашего основного продукта может несколько просесть, потому что у нас концентрация именно на решении для клиентов, а не для аудиторских площадок.
[61:48] Игорь: Было много лайфхаков, связанных с нарушением инварианта, когда смарт-контракт менеджит shares разных ликвидити-провайдеров. Там получается, что можно на несколько wei сдвинуть инвариант, а потом с помощью какого-нибудь гигантского флешлоана сделать эти несколько wei значимым процентом от какого-нибудь баланса и таким образом украсть деньги. Savant работает так: он просто найдёт, что инвариант можно сломать, а дальше — уже как повезёт. Так, как он сделан сейчас, он не будет out of the box глубоко копать, к чему это дальше приведёт. Сам по себе сломанный инвариант попадёт в репорт, и его пометят как какой-нибудь low. Но это не значит, что в этом нет вэлью: если исправить все случаи, когда инвариант ломается на несколько wei, то случаев, когда эти несколько wei можно вырастить в несколько миллионов баксов, просто не будет. То есть это такая более защитная тактика. А релиз, над которым мы работаем сейчас, связанный с экспериментами на коде, позволит делать в том числе и более глубокие такие ресёрчи.
Почему это может быть у кого-то ещё, а у нас этого нет? У нас очень строгое требование — простота использования инструмента и его автономность. У многих наших конкурентов AI фактически запускает их команда, и их же команда тонко его настраивает. У нас такого нет. Естественно, если собирается какой-то более хрупкий, более кастомный пайплайн, там можно руками настроить что-то под специфику проекта и в целом получить больший результат. Но это уже тюнинг. И опять же вопрос, какой результат на практике: по идее, так можно получить больше, но мы его почему-то не видим. Про решения, которые так делают, иногда что-то просачивается, но чаще всего это какой-то маркетинг — что у них есть какие-то секретные способы что-то делать.
[64:18] Конкуренты и «секретный соус»
[64:18] —: Это как раз к моему следующему вопросу. AI-аудиторов сейчас действительно очень много кто делает: многие, кто в нашем web3-cybersecurity является относительно зарекомендовавшим себя брендом, сейчас пытаются пивотиться в такого рода продукт — тот же Sherlock, много кто. В чём ваше конкурентное преимущество перед этими игроками? В чём секретный соус?
[64:48] Александра: У нас нет секретных соусов. У нас исключительно надёжная архитектура и уверенный результат. Мы как раз не играем в такие маркетинговые игры: «давайте сделаем 150 звонков, мы всё для вас настроим, а потом вы через пару дней увидите результат AI-аудита кода» — даже такое есть на рынке, причём у довольно крупных игроков. Или: «у нас есть секретный соус, с помощью которого вы получите результат». Нет, мы за максимальную прозрачность: у нас сложная архитектура, мы используем сильные стороны разных AI-решений на рынке, и это даёт стабильно лучший результат на рынке. Что подтверждают множественные бенчмарки — то есть это не какое-то маркетинговое заявление, на это есть результаты.
[65:48] Конкуренты и бенчмарки
[65:48] Александра: О многих из них мы узнаём постфактум вместе с обширной аудиторией, когда результаты опубликованы и нам кто-то бросает ссылку: «Вот, ребята, посмотрите, вас снова в бенчмарке». Ну, здорово.
[66:02] Игорь: Когда я говорил, что некоторые наши конкуренты могут показывать более хорошие результаты по находкам, это не значит, что мы находим что-то меньше. Это значит просто, что у нас больше wide research, а у кого-то больше deep research. Но если речь про аудиты, мне кажется, что wide research лучше. Почему? Потому что если мы нашли что-то, что является хотя бы medium-ошибкой — а нарушенный инвариант это всё-таки medium-ошибка, как минимум не low, — то это должно быть исправлено. А если оно исправлено, то уже не так важно, как атака могла быть совершена, — потому что она не будет совершена.
Но да, кто-то делает решение именно для контестов или багбаунти — там, естественно, нужен более deep research. Мы это собираемся делать, но не в контексте багбаунти, а в контексте решения проблемы с false positives. Понятно, что такое решение позволит радикально уменьшить ещё большее количество false positives в наших отчётах, поэтому мы над этим работаем. Говоря про аудиторов, каждый из которых делает свой AI: сделать такое решение — это серьёзная работа. Это не работа для аудиторов, это работа для билдеров. Тут нужно быть билдером, который умеет в аудиты, а не аудитором, который решил что-то побилдить.
[67:33] Александра: И здесь мы не говорим про какую-то конкуренцию. Мы говорим именно про то, с чего я, собственно, начинала, когда говорила про багбаунти-платформы: мы считаем, что каждый должен делать свой бизнес и то, в чём его сильные стороны. Мы видим, в том числе, что аудиторы, которые делают свои AI-продукты, приходят и используют наш инструмент тоже — это тоже о чём-то говорит. Если возвращаться к багбаунти-платформам, мы опять-таки сотрудничаем с аудиторами, и здесь каждый делает свою сторону: мы предоставляем решение, а аудитор применяет свой опыт — то, в чём силён он, — для достижения результатов.
[68:17] Размер рынка и венчурные перспективы
[68:17] Ведущий: Обращение к whitehat-хакерам: ребята, мы, наверное, оставим контакты команды Savant Chat в шоунотах к этому выпуску. Если вам интересно поработать с Savant Chat в этом направлении — законтачьте их. Мне интересен вопрос, касающийся бизнеса. Оценивали ли вы как-либо размер рынка смарт-контрактов? Александра уже сказала, что вы чаржите не совсем за строку, но давайте возьмём эту грубейшую метрику: если посчитать, сколько вообще в год пишется и деплоится строк смарт-контрактов, и умножить это условно на ваш ценник — это вообще даёт какой-то венчурно интересный рынок? Если представить, что все проекты будут пользоваться AI-аудиторами, это интересно для вас как для стартапа?
[69:11] Александра: Это интересно. И здесь я сразу поправлю тебя в ассампшене: то, как развиваются LLM, даёт нам основание говорить, что AI-аудиторы, и в частности Savant со своей архитектурой, ни в коем случае не ограничиваются только web3-рынком. У нас в планах — думаю, вторая половина 2026 года — выход и на web2-рынок, потому что там сейчас с аудитами всё сложнее: general-языки программирования сложнее поддаются человеческому аудиту, потому что намного больше всего нужно держать в голове. Подход Savant как раз решает эту проблему. Поэтому, если говорить в сторону венчура, здесь намного более широкий подход. Плюс на рынке есть примеры аудиторских компаний и AI-аудиторов, которые с несопоставимо более слабыми результатами, чем у Savant, успешно прошли этот путь и рейзнули.
[70:10] Игорь: Мы как-то замеряли агента Лизы на EVMbench — и там прямо всё было печально. А у них больше 10 миллионов, вроде.
[70:20] —: Двенадцать. То есть в плане венчура интересно получается: у Лизы самые слабые результаты — она рейзнула 12 миллионов. Octane, у которого тоже весьма скромные результаты, но всё-таки лучше, чем у Лизы, рейзнули 6 миллионов. А решения, которые показывают самые сильные результаты — не только Savant, есть ещё намного более сильное решение, чем у Octane, — не рейзнули ничего. Ну, есть ещё Almanax, который похуже, чем Nethermind AuditAgent, по бенчмаркам, которые люди делали, но лучше, чем Octane, — они рейзнули, по-моему, миллион или три.
[70:59] Ведущий: Мне кажется, из этого можно сделать вывод, что качество продукта на венчурном рынке — не принципиальная переменная. [смех]
[71:07] —: Да, закономерность действительно интересная: чем сильнее продукт, тем меньше он рейзнул. Например, Лиза, которая рейзнула больше всего, не справилась с тем, с чем Savant справлялся ещё на запуске, на первых результатах год назад. Причём это уязвимость, про которую уже знают нейросети, потому что она до их cutoff. То есть если спросить general AI, тебе про эту уязвимость скажут — но не Лиза, которая рейзнула 12 миллионов. [смех]
[71:41] Ведущий: Это, конечно, нужно прожевать мозгом. Возможно, венчуры действительно оценивают скорее сейлз: может быть, они подразумевают, что построить такой продукт не так сложно, как его продать, и видят, что люди удачно продают. Не знаю, как это возможно. Я думаю, что здесь как и с любым агентом: если мы говорим про более general-агентов, для каждодневного использования, то часто это может быть какой-то несложный враппер. Отстраняясь от рынка секьюрити: построить агента для условного бронирования билетов или агента для календаря — ничего сложного. И, думаю, таким же образом они смотрят на рынок аудитов и считают: если это AI-агент, то в любом случае это довольно просто строится. Но есть особенности.
[72:32] Свои модели против frontier LLM
[72:32] Игорь: Да. Опять же, люди могли полгода назад обучить свою нейросеть на базе какой-нибудь третьей Llama или даже DeepSeek. Когда инвесторы видят, что люди могут обучить, дообучить свою нейросеть, на них это производит впечатление. Мы этим просто не занимаемся, потому что я слишком много кейсов читал, когда выходит новый ChatGPT или Gemini и пишут: «Мы сравнили специализированную медицинскую нейросеть, обученную на медицинском датасете полгода назад, и эту общую нейросеть — и общая обошла ту медицинскую, которую врачи собирали». Что это значит? Значит, что нужно брать интеллект от лучших решений, доливать туда через in-context learning свою специфику, грамотно спроектировать контекст — и всё будет. И вместо того, чтобы устраивать забег с Google, лучше просто взять то, что Google может дать.
[73:35] Александра: Сейчас часто говорят про риски: не боитесь ли вы, что AI вроде Gemini или OpenAI станут настолько сильными, что смогут давать какой-то результат по аудиту кода? Мой ответ: нет, мы этого не боимся. Мы в какой-то степени, возможно, к этому стремимся, потому что используем их сильные стороны. Для нас это означает: чем сильнее каждая из моделей, тем сильнее наше решение на рынке и тем лучший результат мы можем давать нашим пользователям. Всё равно даже топовые LLM сохраняют свои особенности, свою специфику. Как Игорь говорил в самом начале этого подкаста, каждая из них сильна в чём-то одном. Да, часто это меняется, но своя специфика у них сохраняется, и мы используем эти сильные стороны в нашем решении.
[74:23] Игорь: Я брал, например, скиллы от Trail of Bits для Claude. Что могу сказать — это действительно сильное решение: на EVMbench в шести из семи сэмплов найдена причина. Один не найден — там лишний делитель, причём в таком месте, в котором человек тоже мог бы его написать. Модели Anthropic, как обычно, с математикой несколько слабее — как всегда у них и было. Надо использовать разные модели, надо использовать сложные пайплайны. Решения, основанные на одной модели — даже той, которая сейчас state of the art для разработки, даже если дать ей возможность писать proof of concept согласно этим скиллам, — всё равно будут проседать. Потому что фреймворк важен, но интеллект важен, причём разноплановый интеллект. Мы берём этот разноплановый интеллект и делаем из него пайплайн, в результате которого находятся разные ошибки: и архитектурные, и бизнесовые, и криптография, и математика.
[75:35] Ведущий: Меня сейчас озарило: если пользоваться понятными мне DeFi-аналогиями, вы делаете не DEX, а DEX-агрегатор.
[75:46] —: Да, это так.
[75:47] Фандрейз и angel-раунд
[75:47] Ведущий: Есть ли у вас в планах фандрейз? Если есть, как вы планируете к нему подходить?
[75:52] Александра: Для чего? Мы сейчас закрыли небольшой angel-раунд. Главная цель этого раунда была в том, чтобы показать более серьёзным инвесторам proof of trust: что довольно громкие имена на рынке крипты доверяют нашему решению. Доверяют не в том плане, что готовы поддерживать нас на словах, использовать наш продукт или писать о том, что они его используют, увидев результаты, — а в том, что готовы в прямом смысле голосовать за наш продукт деньгами. Одна из целей этого раунда — привлечь специалиста, который будет отвечать за онлайн-присутствие Savant на разных площадках, и сейчас мы активно этим занимаемся. Я, как единственный нетехнический человек в команде, практически фултайм этим занимаюсь, потому что это очень острая задача, которую нужно закрыть максимально быстро. После этого мы сможем перейти к работе над полноценным раундом с фондами — показывая наши результаты и вот этот proof of trust angel-раунда.
Для чего нужен полноценный раунд? Во-первых, на продвижение: есть определённые маркетинговые инструменты и планы, на которые сейчас нет бюджета. Я бы пока не говорила о них более подробно, но представление о том, куда двигаться, у нас есть. Наверное, в том числе имеет смысл расширить поддержку — чтобы поддержка пользователей была более оперативной и выделенной, потому что сейчас этим занимаются инженеры, что, наверное, не совсем правильно. Слава богу, у нас решение построено так, что поддержка требуется крайне редко, но, как в любом решении с пользователями, это необходимо.
[78:01] Маркетинг на рынке AI-аудитов
[78:01] Игорь: Тут ещё важно сказать, зачем мы, собственно, раунд собирали. У нас есть прибыльные месяцы, но пока это нестабильно — прибыльные не все месяцы. Раунд нужен, чтобы построить отдел, который будет заниматься продвижением в широком смысле. Рынок аудитов, например, отличается от рынка zk тем, что в zk, по крайней мере пару лет назад, если ты сделал state of the art — про тебя все знают и зовут на все round tables. А в случае AI-аудитов это абсолютно другой рынок: маркетинг имеет огромное значение, и без маркетинга очень сложно донести информацию о своём проекте до клиента. К тому же клиенты — это не обязательно фаундеры, которые более рационально смотрят на эти вещи. Часто закупками занимаются другие люди, которые думают о том, какие простые и понятные сигналы они могут приложить к своему decision making, когда что-то выбирают. И нам нужно эти сигналы дать, потому что иначе, даже если мы будем показывать крутые результаты, — не купят.
[79:38] Александра: И когда я говорила про поддержку — есть интересный фидбэк. В самом начале я говорила, что мы построили максимально лёгкий автоматический онбординг, в том числе потому, что в web3 много людей, которые предпочитают лишний раз не взаимодействовать с людьми, а даже в каком-то сервисе полагаться максимально на себя и понимать, что делать. Это больше такой OG-подход: люди приходят и сами понимают, что им это нужно. Таких очень много, и мы, естественно, в первую очередь ориентировались и ориентируемся на них. Но сейчас я часто вижу в обсуждениях, что даже на рынке web3 появляются люди, которые ценят саппорт — когда им что-то продаёт человек. Есть огромное количество людей, которые ценят более традиционный подход в бизнесе: когда к ним приходишь, рассказываешь, делаешь презентации, получаешь фидбэк. И если, допустим, OG от этого просто сбегут и не будут пользоваться продуктом, то есть люди, для которых это обязательная часть и показатель определённого качества. Естественно, над этим мы тоже работаем.
[80:50] Ведущий: Многие из этих людей пришли в блокчейн в последние два года. Мне, кстати, кажется, что даже многие OG-стартапы уже перешли в фазу, когда закупки у них идут отдельно и отдельные люди этим занимаются. Взять даже пример 1inch: они уже превратились в достаточно солидную компанию, где совсем по-другому происходит закупка сервисов и продуктов. С одной стороны, это очень хороший знак для всей нашей индустрии, а с другой — я иногда чувствую себя таким динозавром-переростком: я-то привык, что мы все вопросы по-простому решаем, а тут уже нужно презентацию делать, с PDF быть более знакомым.
Я ещё подумал вот о чём: секьюрити в web3-мире — это же часто отчасти маркетинг. Условно, какая-нибудь компания CertiK пользуется большой популярностью, несмотря на репутацию, что сервис у них, может быть, не самого высокого качества, — потому что это хороший, известный среди ритейла бренд. Условно: я сделал аудит у CertiK, присобачил, блин, на веб-сайт их логотип — ритейл видит известное имя и думает: «О, супер, круто, люди позаботились о безопасности». То есть если ты качаешь свой секьюрити-бренд, его нужно качать так, чтобы про него знали все, а не только фаундеры.
[82:16] Александра: Мы начали с онлайн-присутствия и сейчас ищем человека, который будет полностью за это отвечать — чтобы присутствовать максимально на разных площадках. Сейчас мы более-менее развиваем Twitter, но есть тот же Reddit и другие площадки. Придёт человек, который в этом разбирается, и будет подходить к этому более профессионально.
[82:40] Команда и AI-native подход к найму
[82:40] Игорь: Говоря про техническую команду — мы не планируем её существенно наращивать. Мы планируем больше вертикальное масштабирование: внедрение большего числа AI-процессов для разработки. Это помогает инженерам выполнять существенно больший скоуп за то же время. Мы сейчас нанимаем в компанию только AI-native инженеров — и не инженеров тоже. Подход такой: если человек, может быть, чуть-чуть хуже пишет руками статьи по маркетингу, но при этом знает, как выстроить пайплайн, в котором AI сделает эту работу, — это то, что нам надо. Почему? Потому что сейчас — чуть хуже, но выйдет следующее поколение моделей — будет сильно лучше. Человек, который прежде всего ориентирован на работу руками, не будет конкурентоспособен.
Как я ранее говорил, мы уже перешли на разработку, при которой разработчик взаимодействует одновременно с несколькими агентами и раздаёт им таски, а агенты делают эти таски — от 15 минут до десятка часов, такое тоже бывает, особенно при обработке каких-нибудь данных. В таком формате это работает эффективно: небольшой командой можно делать очень много.
[84:12] Завершение выпуска
[84:12] Ведущий: Кажется, это очень ценный инпут для многих участников рынка труда — касательно того, как им нужно поменять свой подход. Я подумал: если ты хочешь быть конкурентоспособным на бездушном капиталистическом рынке, то и маркетинг надо делать бездушной машиной, которая просто растит охваты, не целясь в каких-то топ-10 людей. Спасибо, ребята. Я задал все вопросы, которые у меня были, и, мне кажется, Жене тоже было очень интересно. Если у вас есть что ещё проанонсировать, о чём заявить, что прорекламировать — вам слово.
[84:57] Александра: Мы тоже всё обсудили и даже сделали анонсы того, над чем работаем и чего ждать в следующих версиях. Приходите, пользуйтесь, увеличивайте безопасность ваших продуктов. Большое спасибо за приглашение — было очень здорово пообщаться.
[85:15] Игорь: Большое спасибо. Наши два основных следующих апдейта я уже рассказал. В целом мы готовы знакомиться, общаться, коллаборировать с проектами, аудиторами, фондами. Мы скоро будем собирать следующий раунд, и я думаю, что для многих фондов наше решение может быть интересным именно как продукт, а не как объект для инвестиций. Как-то так.
[85:49] Ведущий: Спасибо ещё раз, ребята. Спасибо, Игорь. Спасибо, Александра. Спасибо, Жень, за то, что помог мне подготовиться к этому выпуску. И спасибо тем, кто нас поддерживает: всем нашим слушателям, пользователям нашего чата, тем, кто саппортит нас на Патреоне и на Boosty. А также спасибо нашим спонсорам: это 1inch — ведущая экосистема DeFi, это dRPC — enterprise-grade web3 API, это Fluence — децентрализованная облачная платформа, и это Acki Nacki — наибыстрейший блокчейн из возможных. Подписывайтесь на нас на YouTube, в Telegram — вообще мы есть на всех подкаст-платформах. Подписывайтесь на нас везде, заходите к нам в «ББ Чат» — будем рады пообщаться с вами там лично. Всем пока!