Генеральный директор BlockSec Энди Чжоу был приглашен для участия в подкасте Spraping Bits, чтобы обсудить тему того, как команда BlockSec выявляет и предотвращает потенциальные уязвимости безопасности в бурной и запутанной среде Web3. Ниже представлен подготовленный нами сборник интересного контента. Чтобы прослушать полную версию подкаста, нажмите здесь.
Энди Чжоу 00:00
У нас в команде работает система, которая может обнаружить атакующий смарт-контракт еще до того, как хакеры отправят транзакции атаки. Это связано с тем, что им необходимо развернуть атакующий контракт, а затем отправить транзакции для атаки на протокол. Таким образом, еще до начала транзакций атаки, когда хакеры развертывают такой смарт-контракт, наш движок на базе ИИ может точно идентифицировать вредоносный контракт.
Энди Чжоу 00:53
Спасибо, DeGatchi. Для меня большая честь быть здесь.
DeGatchi 00:56
Честь для нас. Большое спасибо. Для тех, кто с вами не знаком: кто вы и чем занимаетесь?
Энди Чжоу 01:02
Меня зовут Энди. Я генеральный директор BlockSec, а также профессор Чжэцзянского университета, одного из ведущих вузов Китая. У меня более 10 лет опыта в сфере кибербезопасности. Ранее я работал в области безопасности смартфонов, а затем переключился на безопасность смарт-контрактов, которой занимаюсь уже несколько лет.
DeGatchi 01:22
Как начинался ваш путь в безопасности смарт-контрактов? Вы занимались ручным аудитом или сразу перешли к автоматизации? Примерно так же, как я.
Энди Чжоу 01:30
Что касается безопасности смарт-контрактов, то в компании и в нашей исследовательской группе мы используем как статический, так и динамический анализ. Для статического анализа мы разработали несколько различных методов, чтобы улучшить его качество. Это важно, потому что большинство инструментов, существующих сегодня в сообществе, имеют общую проблему: слишком много ложных срабатываний (false positives). Например, если вы используете такой инструмент для обнаружения уязвимости повторного входа (reentrancy) и загружаете простой смарт-контракт, инструмент может выдать множество ложных предупреждений. Но когда вы проверяете отчет вручную, обнаруживается, что большая часть из них — ложные срабатывания. Поэтому мы считаем, что именно они являются главной проблемой современных инструментов статического анализа.
Энди Чжоу 02:20
Фундаментальная причина таких ошибок заключается в отсутствии понимания семантики смарт-контракта. Семантика относится к смыслу переменных и взаимосвязям между ними внутри контракта. Например, если у вас есть токен стандарта ERC-20, у него есть переменные, отражающие баланс каждого владельца и сумму одобрения (approved value), указывающую, кто и какой объем средств разрешил перевести кому-либо. Чтобы повысить точность статического анализа, важно точно определять, какие переменные соответствуют балансу, а какие относятся к одобрениям и другим специфическим функциям. Поступая так, мы можем достичь гораздо большей точности в статическом анализе.
Энди Чжоу 03:00
Один из выводов, к которому мы пришли в ходе разработки инструмента статического анализа, заключается в необходимости создания надежного механизма анализа потоков данных (taint analysis engine) для установления корреляций между переменными. Анализ потоков данных — фундаментальный метод, используемый инструментами статического анализа, играет решающую роль. Он включает в себя моделирование памяти и хранилищ, а также способы эффективного и точного применения методов анализа потоков данных внутри инструмента. Эти два ключевых метода — taint-анализ и анализ потоков данных — доказали свою высокую эффективность в улучшении возможностей нашего инструмента.
Энди Чжоу 03:48
Наша исследовательская группа разработала этот инструмент статического анализа и развернула его, чтобы анализировать каждый новый смарт-контракт, создаваемый в блокчейне. Мы сообщаем разработчикам об обнаруженных нами уязвимостях «нулевого дня». К сожалению, некоторых разработчиков эти уязвимости не заботят. К тому же мы не всегда находим эффективные каналы связи, чтобы сообщить им об этом. Это очень печально.
Энди Чжоу 04:13
Если вам нужен эффективный инструмент статического анализа, вам необходимы семантика и движок taint-анализа. Это наш опыт работы с такими инструментами. Помимо инструментов статического анализа, в нашей исследовательской группе есть и инструменты динамического анализа. Ведь помимо уязвимых смарт-контрактов, нам также нужно выявлять вредоносные транзакции, верно?
Энди Чжоу 04:31
Речь идет не только об анализе уязвимых смарт-контрактов, но и об обнаружении транзакций, которые могут атаковать протоколы или другие контракты. Для достижения этой цели у нас есть настроенная виртуальная машина с возможностями инструментации. Это позволяет нам писать собственные правила обнаружения, которые легко подключаются к виртуальной машине или среде исполнения любого смарт-контракта. Мы фиксируем различные сигналы, чтобы определить, является ли транзакция вредоносной. Например, мы проверяем, не совершал ли отправитель транзакции атаки ранее, или не приходят ли средства из подозрительных источников. Комбинируя различные сигналы, мы оцениваем риск, связанный с каждой транзакцией. Наша команда развернула этот механизм обнаружения, что позволяет нам быстро фиксировать и идентифицировать транзакции атак.
DeGatchi 05:41
Да, это интересно. Я делал то же самое со своими статическими анализаторами. Taint-анализ, по сути, необходим, но затем вы используете статический анализатор. Вы передаете все эти данные в фаззер, верно? Я тоже создавал свой фаззер. И очень интересно видеть, как люди подходят к этому вопросу. Существуют очень любопытные решения. Люди в этой сфере часто мыслят последовательно, а здесь гораздо больше измерений, которые нужно учитывать, так что последовательный подход — не всегда правильный ответ.
DeGatchi 06:08
Давайте поговорим об измерениях. Предположим, у вас есть calldata транзакции, верно? Еще есть функции и контракты. И есть еще одно измерение — стадия/контекст. Все очень зависит от контекста. И вот у вас четыре разные переменные, измерения, и они все влияют друг на друга при малейшем изменении. Например, у вас есть контракты A и B, и все их функции. Теперь вы должны выстроить их в разном порядке, но дело не только в последовательности «функция А, функция Б» или «функция Б, функция А». У вас также есть возможность сделать «функция А, функция Б, функция Б, функция Б, функция А». Это очень сложная проблема.
DeGatchi 06:43
И я думаю, что то, что вы делаете, довольно интересно. Я знаю, что вы недавно расширили возможности Phalcon, включив туда обнаружение транзакций. Так что это больше похоже на обобщенный инструмент для опережения транзакций (front-running), но для взломов. И это наводит на размышления. Игра в front-running доминирует среди этих специализированных MEV-команд, верно? Они занимаются front-running, сэндвич-атаками, back-running и так далее. У них есть специальная инфраструктура, высокочастотная торговля с низкой задержкой, они сотрудничают друг с другом, с создателями блоков, реле и всей этой инфраструктурой. Вопрос в том, как вам удается опережать эти транзакции быстрее, чем этим MEV-командам?
Энди Чжоу 07:24
Да, это очень хороший вопрос. По сути, основная цель нашей системы — не опережать MEV-ботов, а защищать протоколы, и мы фокусируемся на хакерах.
DeGatchi 07:37
Но когда хакер отправляет транзакцию в публичный пул памяти (mempool), если она приватная, никто ее не увидит. Но если она публичная, то все остальные обобщенные фронтраннеры тоже ее увидят. Вам нужно их опередить. Как вы их побеждаете?
Энди Чжоу 07:51
Да, мы всегда говорим, что безопасность — это гонка вооружений между «хорошими» и «плохими» парнями. В начале пути это было легко, потому что плохие парни не знали о существовании нашей команды и MEV-ботов. Тогда всё зависело от того, как вы платите цену за газ или как вы платите взятку валидаторам. В те времена это было намного проще, но сегодня хакеры используют методы, чтобы защитить себя от опережения транзакций. Например, мы видели интересную технику: хакеры, чтобы предотвратить опережение своих транзакций MEV-ботами, сначала проверяют некоторые значения, например, вытягивают определенное значение из другого смарт-контракта, чтобы проверить, равно ли это значение начальному. При выполнении атаки хакеры сначала отправляют транзакцию для настройки переменной в другом контракте, чтобы условие проверки выполнялось, а вторым транзакцией уже проводят сам взлом. Большинство обычных MEV-ботов симулируют только одну транзакцию. Если симулировать только вторую, вы потерпите неудачу, потому что условие не выполнено. И именно это условие настраивается первой транзакцией атаки. Из-за этой хитрости некоторые MEV-боты не могут с этим справиться. Мы можем, потому что у нас есть технология анализа корреляции различных транзакций.
DeGatchi 09:40
Да, вам нужно делать сразу несколько транзакций. Нельзя просто сделать одну, потому что если вы просто занимаетесь обобщенным фронтраннингом, стандарт — это просто заменить адрес, или, если адресов много, заменить их все, перебирая все варианты.
Энди Чжоу 09:52
Именно.
DeGatchi 09:53
Если они используют несколько контрактов для настройки, они сначала развертывают контракт, затем вызывают функцию в этом контракте для настройки, а потом используют его в контракте эксплойта. Чтобы это исправить, нужно выполнять симуляцию снова, но фактически проверять состояние вызываемых компонентов. И если оно не совпадает с состоянием развертывания исходного контракта, вам нужно как-то настроить его: найти ту функцию, как в CFG (графе потока управления), и изменить контракт эксплойта, чтобы он установил нужные параметры, или вообще удалить их полностью. Это очень сложно, но поразительно, что вы это реализовали и это работает.
Энди Чжоу 10:33
Да, это работает, но для этого нужно приложить много усилий в разработку. Вам также нужен очень хороший и эффективный движок анализа.
DeGatchi 10:42
Это впечатляет. Вы уже предотвратили 20 взломов и около 15 миллионов долларов убытков. И это за шесть месяцев до запуска вашего продукта.
Энди Чжоу 10:51
Предотвращение взломов длится уже полтора года. Это не за месяц или два. Это непрерывная работа в течение полутора лет.
DeGatchi 11:04
Все равно, больше никто этого не делает. Это великое дело, и я думаю, что каждый должен хотя бы воспользоваться этим, потому что это важно. Даже если это не спасет на 100% всех, потому что нужно подписаться, возможно существуют методы обфускации, которые будут отличаться, но это всё же лучше, чем ничего. Вы сохраняете вещи, ведь быть взломанным — это крах всей компании, всех пользователей, всей репутации, всё исчезает. Как вы это построили? Использовали ли вы ИИ? Невозможно, чтобы это было лишь чисто эвристическим подходом.
Энди Чжоу 11:41
По сути, мы комбинируем разные методы. Для обнаружения взломов мы объединяем ИИ-решения с анализом поведения. Для ИИ-решений мы используем методы машинного обучения для обнаружения атакующего контракта. У нас работает система, которая может обнаружить его еще до транзакций атаки. Им нужно развернуть атакующий смарт-контракт, а затем отправить транзакции. Еще до того как произойдет атака, наш движок на базе ИИ может точно идентифицировать вредоносный контракт. Я не говорю, что у нас нет ложных срабатываний, но их уровень довольно низок. Мы способны обнаружить атакующий контракт даже на этой стадии. Проблема в том, что когда вы идентифицируете такой контракт, вы можете не знать настоящего «пострадавшего» от взлома. Иногда адрес цели не жестко закодирован в смарт-контракте, а передается в виде параметров. Нужно использовать фаззинг, чтобы это вызвать. Но если все целевые адреса передаются через параметры, то даже фаззинг помочь не может.
Энди Чжоу 13:05
Поэтому со сложными случаями такого рода мы не можем идентифицировать атакующий смарт-контракт на ранней стадии, нам приходится иметь с ними дело на этапе обнаружения транзакций атаки. Для них мы используем решения, основанные на поведении. Общая идея в том, что каждый хакер хочет получить прибыль. Чтобы получить ее, транзакции должны быть точными. После обнаружения транзакций атаки мы автоматически синтезируем аналогичную транзакцию, как это делает MEV-бот, заменяем адрес получателя прибыли и отправляем её в сеть. Вот как система работала изначально, до запуска BlockSec Phalcon.
DeGatchi 13:54
Насчет ИИ: мне трудно представить здесь модель обучения с учителем. Мне кажется, тут нужно обучение с подкреплением, ведь взломов не так много, верно? Недостаточно данных для того, чтобы обучить такую модель.
Энди Чжоу 14:08
Думаю, это очень верное замечание. В случае с обнаружением вредоносных смарт-контрактов, из-за малого количества образцов для обучения модели, этот подход неэффективен. Ключевой вывод в том, что вам нужно извлекать ключевые признаки внутри смарт-контракта. Кто-то просто использует последовательность байт-кода для обучения модели. Это не работает, потому что последовательность байт-кода слишком универсальна и типична для смарт-контрактов. Вам нужно извлекать отличительные признаки. То, что мы используем сейчас, включает в себя граф потока управления, связь потоков данных между ключевыми функциями, а также мы используем метки адресов или свойства создателя смарт-контракта для обучения модели. Это доказывает свою эффективность.
DeGatchi 14:55
Итак, вы извлекаете ключевые признаки. Например, жестко закодированные адреса или адреса, переданные в качестве данных вызова (call data). Может быть, они используют маскирование, если пишут на Solidity. В Solidity это довольно распространено. Но если это кастомный контракт с кодом, то это, скорее всего, очень изощренный хакер. Но продвинутые хакеры, которые четко всё планируют, наверняка используют приватные транзакции, кастомный байт-код и, возможно, даже «рои» транзакций для обфускации. Я исследовал это, мне это было интересно, и это оказалось эффективно. Я на самом деле никогда не видел, чтобы кто-то использовал методы, к которым я пришел. Возможно, я напишу об этом статью, потому что сам бы их не использовал. Но это было интересно.
Энди Чжоу 15:46
Да, перед началом этого исследовательского проекта я тоже не думал, что это сработает. Но через шесть месяцев мы доказали, что это очень эффективно.
DeGatchi 16:02
Да, это сумасшествие. Полагаю, это замечательный шаг в нужном направлении, и инструментов подобного типа должно быть больше. Но это также вызывает вопрос: вы используете ИИ. Как вы оцениваете, насколько ИИ повлияет на ваш бизнес? Что устареет из-за ИИ, и что можно сделать прямо сейчас, чтобы подготовиться к этой революции?
Энди Чжоу 16:23
Да, честно говоря, я не эксперт по ИИ. Мы просто применяем ИИ в нашей области исследований для обнаружения вредоносных смарт-контрактов. Я думаю, что потенциал ИИ в сфере безопасности еще не полностью изучен. Одна из причин: для применения ИИ в кибербезопасности нужно глубокое понимание проблемы, которую вы решаете. Потому что если вы глубоко понимаете проблему, вы можете выделить очень хорошие признаки (features). Я считаю, что признаки очень важны, правда ведь? Поэтому даже для одного и того же контракта или транзакции, если у вас нет хороших признаков для обучения, результат будет совершенно иным. С моей точки зрения, потенциал ИИ еще не раскрыт, потому что нужно сочетание хорошего специалиста по ИИ и отличного эксперта в предметной области, чтобы извлечь нужные признаки.
DeGatchi 17:30
Согласен. Это сочетание двух областей. Во-первых, быть хорошим специалистом в ИИ — это сложно. Нужно время, чтобы выучить все это. Вы должны знать математику, знать всё, что связано с ИИ: пакеты, библиотеки. И при этом нужно быть внутри крипто-пространства со своим доменом — байт-кодом и кибербезопасностью, что тоже требует времени. Но я думаю, что людям, которые приходят из сферы ИИ в крипто, будет не так сложно, как тем, кто идет из крипто в ИИ. Потому что в чистом ИИ труднее погрузиться в тему из-за требуемой математики и общего понимания архитектур.
DeGatchi 18:13
Но это супер интересно. Как вы думаете, что станет устаревшим? ИИ ведь очевидно изменит всё. Я думаю, если вы не используете ИИ, у вас не будет преимущества перед другими в бизнесе, потому что конкурировать сложно. Я занимался тем же самым через фаззеры, но я знаю людей, которые занимаются ИИ. Это логично, потому что если вы думаете об этом бесконечном пространстве действий, вы не сможете просто использовать грубую силу (brute force). Вам нужна своего рода интуиция, чтобы отфильтровать все действия и знать, что именно нужно атаковать. Для этого нужен ИИ. Нужно то, что может учиться на повторяющихся примерах, особенно если вы запускаете это на таких протоколах, где миллионы контрактов и транзакций. Вам нужно уметь обучаться интуиции. В противном случае вы строите эту интуицию в себе. А это очень затратно по времени и, кроме того, довольно ошибочно, потому что вы не можете думать во всех этих измерениях. Лично я считаю, что если вы этим не занимаетесь, вам стоит начать, вне зависимости ни от чего. Я даже не знаю математику, и я в это погружаюсь. Если я могу это сделать, значит, любой может. Посмотрим. Но это требует большой отдачи.
Энди Чжоу 19:36
Именно. Могу поделиться недавним экспериментом с ИИ. Как я уже сказал, у нас есть фаззинг-система для смарт-контрактов для поиска уязвимостей. Мы можем использовать ИИ для генерации начальных входов (seed inputs) для фаззинга, и это оказалось очень эффективно. Как мы это делаем? Например, у нас есть пять смарт-контрактов для фаззинга. Мы сначала вводим их в ChatGPT и просим резюмировать ключевые функции: «Эта функция делает то-то, та — это». После этого я прошу GPT: «Пожалуйста, сгенерируй 50 разных входных данных для этих функций». И это оказывается очень эффективным. Мы используем это как начальные данные для фаззинга смарт-контрактов.
DeGatchi 20:38
Интересно. Я думаю, LLM действительно хороши. Это лучшее, что у нас есть в плане понимания эмбеддингов. Я не знаю намного большего, но на данный момент это лучший подход. Так что это логично. Многие используют ChatGPT, но это кажется действительно хорошим кейсом использования. Я знаю, что некоторые используют его, чтобы просто объяснить контракты. Это помогает быстро войти в курс дела, вместо того чтобы пытаться понять всю кодовую базу. Ведь это может быть код на тысячу строк или мульти-контракты. Очень трудно увидеть взаимосвязи между всеми частями программы.
DeGatchi 21:18
Но я хотел спросить: раз уж вы сделали это новое блокирование транзакций, почему бы не пойти на шаг вперед и не попытаться найти все уязвимости «нулевого дня» во всех контрактах? Если подумать, если хакеры изощренные, знают свое дело и нацеливаются на кого-то, например, взлом на 600 миллионов долларов, как Ronin, они просто отправят приватную транзакцию, и вы не сможете их заблокировать. Почему бы вам не инвестировать полностью в поиск уязвимостей нулевого дня? Если вы их найдете, вы просто проведете приватную транзакцию и заранее всё сохраните.
Энди Чжоу 22:02
Да, очень хороший вопрос. На самом деле у нас есть несколько предложений для проектов внутри BlockSec. В настоящее время для BlockSec Phalcon мы можем обнаруживать вредоносные транзакции в цепочке или в Mempool. Но приватные транзакции мы видеть не можем. Это текущий этап. Мы также хотим приложить усилия, чтобы обнаружить уязвимости смарт-контрактов еще до того, как к ним придут хакеры. Как я уже сказал, у нас есть системы фаззинга для этого, но мы все еще совершенствуем наш фаззинг, чтобы обнаруживать уязвимости в контрактах, развернутых в блокчейне.
Энди Чжоу 22:55
Я считаю, что есть несколько проблем при проведении фаззинга для смарт-контрактов. Одна из них — генерация входных данных, особенно транзакций для целевого контракта. Более того, для смарт-контракта нужно генерировать не одну транзакцию, а последовательность, чтобы вызвать уязвимости. Иногда эти транзакции зависят друг от друга. Вы должны выполнить первую, вторую и третью, и только тогда последовательность вызовет уязвимость. Вам нужно генерировать серии транзакций и понимать их зависимости. Это пока довольно сложно. Это первая задача. Вторая задача — вам нужен оракул, чтобы определить, есть ли уязвимость. Допустим, вы отправили транзакцию, как понять, что она вызвала уязвимость? Конечно, можно использовать похожую технику для расчета прибыли. Если транзакция вызывает очень высокую прибыль или нарушает фактор здоровья в протоколе кредитования, значит, есть уязвимость. Но нужно иметь обобщенные типы оракулов для фаззеров. Это вторая задача.
DeGatchi 24:35
Это вторая часть. Очень интересно, потому что если выходит новый протокол с токеном, у которого нет пулов ликвидности с крупными токенами, а есть только с другими токенами, вы даже не можете оценить его цену, правда? Это огромное препятствие. Думали ли вы, как подойти к этому с таким видом оракула?
Энди Чжоу 24:57
Да, именно. Это еще одна проблема: нужно подготовить среду для фаззеров и пулы DEX. Вам нужно подготовить разные токены, нужно подавать цену каждого токена в систему. Это всё очень сложно. С простыми уязвимостями типа reentrancy фаззеры справляются легко. Но со сложными, вроде манипуляции ценой, это тяжело. Мы все еще работаем над системой, нужно время. Но вы правы, мы движемся в этом направлении.
DeGatchi 25:43
Да, это совсем не тривиальная задача. Она требует огромной сложности. Вам нужно учитывать множество вещей, которые зависят от других вещей. Вы задаете вопрос и получаете два новых, связанных между собой, и это уводит всё дальше и дальше. Но оракулы — это, пожалуй, одна из самых сложных вещей. И одна из самых важных, потому что манипуляция оракулом — это, наверное, самый большой вектор атаки. Все на этом держится.
DeGatchi 26:22
Или какие-то арбитражи, которые они не учли. Баги есть везде, человеческая ошибка неизбежна. Новые протоколы выходят каждый день. Ваш текущий протокол может взаимодействовать с ними. Это может быть последовательность из пяти разных протоколов.
DeGatchi 26:45
Это нелегко. Думаю, вам нужен ИИ, потому что вы должны мыслить пространственно, охватывая все эти разные функции в разных контрактах. Вы не можете разобраться в них последовательно, потому что существует слишком много возможностей. Я разговаривал в начале этого года с кем-то об эксплойте Pickle Finance — это очень интересный случай. Там было восемь уязвимостей. Если бы вы пропустили одну из них, эксплойт бы не удался, и всё должно было происходить в определенной последовательности. В этом эксплойте было задействовано пять кастомных контрактов.
DeGatchi 27:44
А другая часть заключалась в понимании того, что, например, в Solidity адрес и bytes20 — одно и то же. Люди упускают это. Они создали контракты, которые выглядели как фейковые базовые токены. И balanceOf возвращал адрес вместо реального количества. Это работало, потому что на самом деле сумма — это bytes32, а адрес — bytes20. Можно передать адрес как uint256. В итоге возникла ситуация с delegatecall. Это невероятно фасцинирующий и сложный случай.
DeGatchi 29:06
Такие вещи очень сложны. Думали ли вы обо всем этом? Какие методы вы сейчас рассматриваете? Очевидно, «пространственное» мышление, изучение изолированных функций и их взаимодействия. Взаимосвязь — определенно одна из самых сложных частей. Один лишь taint-анализ откровенно недостаточен.
Энди Чжоу 29:26
Да. Относительно связи между смарт-контрактами мы делаем одну интересную вещь. Мы вручную собираем смарт-контракты ведущих DeFi-протоколов. Затем проводим анализ, чтобы нарисовать схему взаимосвязей. Например, если wstETH можно использовать как обеспечение в протоколе ABC, мы рисуем линию между ними.
Энди Чжоу 30:02
Мы вручную, с помощью скриптов, создаем общую картину связей между топовыми протоколами. И используем эти данные для статического анализа и фаззинга.
Энди Чжоу 30:15
Это то, над чем мы сейчас работаем. Еще ранняя стадия, но это помогает. Еще мы работаем над выводом типов данных (type inference). Мы хотим определять тип входных данных, например, calldata при вызове смарт-контракта. Это очень помогает при фаззинге.
DeGatchi 30:55
Интересно. Это похоже на граф. То, что вы делаете — сложно. Ведь есть контракты, которые даже не ссылаются друг на друга напрямую. Можно ссылаться через calldata или создать пул, который ссылается на новый контракт.
Энди Чжоу 31:33
Да, это нелегко, но мы можем использовать транзакции в цепочке, чтобы их связать, так как они раскрывают взаимодействия.
DeGatchi 31:44
Но проблема в том, что вы смотрите на «нормальные» последовательности функций. А чтобы найти уязвимость нулевого дня, нужно нарушить норму. Интересно. Каковы ваши планы относительно фаззера? Будете ли вы применять нейросетевой фаззинг? Что вы планируете в дальнейшем?
Энди Чжоу 32:23
Для фаззинга мы в первую очередь стремимся создать хорошую систему вывода типов, чтобы облегчить генерацию и мутацию входных данных. Мы также используем ИИ для генерации начальных условий. Мы пытаемся ускорить процесс фаззинга, чтобы быстро находить уязвимости. Мы работаем над тремя направлениями улучшения фаззеров.
DeGatchi 33:01
Интересно. Есть кое-что отличное от темы инструментов. Как вы планируете дифференцировать себя от новых игроков и фирм, которые приходят в эту сферу?
Энди Чжоу 33:55
Это сложный вопрос. С моей точки зрения, нужно хорошо понимать тренды в сфере безопасности DeFi-протоколов. Появляются новые векторы атак. Мое преимущество — способность быстро учиться и усваивать новые знания. Конечно, придут очень умные люди. Но поскольку я прошел обучение в аспирантуре (PhD), я знаю, как быстро погрузиться в новую область, как быстро найти хорошую проблему для работы и как позаимствовать методы из другой области для решения текущей проблемы. Думаю, это и отличает меня от других.
DeGatchi 34:56
На сто процентов согласен. Самое главное — это творческий подход. Если все равны в знаниях, именно креативность решает. Нужно верить в себя, верить, когда другие не верят, что это возможно. И быть в нужное время в нужном месте с правильными навыками. Думаю, ИИ — это следующий рубеж.
DeGatchi 36:55
Где вы видите себя и BlockSec в будущем? И куда движется индустрия?
Энди Чжоу 37:05
Web3 — очень новая область, мы на ранних стадиях. Индустрия движется очень быстро, но проблем безопасности по-прежнему очень много. Мы используем свои решения, чтобы экосистема двигалась быстро, но безопасно. В будущем будет много разных пользователей Web3, и им тоже нужна безопасность, потому что для них всё это пока слишком сложно. Мы должны создать систему защиты для пользователей DeFi, вопрос которой в индустрии еще толком не решен.
DeGatchi 38:27
Я думаю, в дополнение к фаззеру вы могли бы расшириться до чего-то вроде кошелька. Интегрировать анализ прямо в кошелек, даже если это будет быстрый анализ транзакции перед ее подписанием.
Энди Чжоу 39:01
Компании уже занимаются этим — симулируют транзакцию и показывают последствия пользователю.
DeGatchi 39:10
Это умно. Но симуляции часто ошибочны из-за кастомного байт-кода и условий. Нужно проверять каждый путь функции. Какие у вас планы в комбинации кибербезопасности и ИИ?
Энди Чжоу 40:06
Мы продолжаем инвестировать ресурсы в ИИ, так как комбинация ИИ и безопасности Web3 создаст лучшие продукты. Мы хотим улучшить системы обнаружения атак, фаззинга и защиты активов пользователей. Таков наш текущий план в BlockSec.
DeGatchi 40:36
Интересно. Вы уже много делаете. Здорово, что есть здоровая конкуренция для предотвращения взломов. Конечная цель — заменить CeFi, ведь ждать вывода средств из банков — нелепость. Спасибо, что пришли, Энди, это был отличный разговор.
Энди Чжоу 41:38
Для меня честь быть здесь. Спасибо, DeGatchi.
