Заморозка (внутри) блокчейнов: разоблачение от Bybit

Заморозка средств внутри блокчейнов

Перевод

Это вольный перевод: https://assets.contentstack.io/v3/assets/bltffdbacf2f22e15fa/bltda1597363a4f2a2b/69144b86424c333a34bc9fa8/2509-T68340_Security_Report_1111.pdf

Исследование влияния возможности заморозки средств в блокчейне

Заморозка средств, если говорить простыми словами, - ситуация, когда фонд или управляющая структура может заблокировать активы пользователя без его согласия.

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

Поэтому, когда Sui Foundation вмешалась и заморозила активы, похищенные из протокола Cetus, в блокчейн-сообществе разгорелись острые споры.

Этот инцидент побудил команду Lazarus :) Security Lab от биржи Bybit провести масштабное расследование и выяснить, имеют ли другие блокчейн-сети аналогичные полномочия.

Команда проанализировала 166 разных блокчейнов.

Поскольку большинство сетей не раскрывает наличие таких функций в публичной документации, исследователям пришлось проводить глубокий анализ исходного кода репозиториев. Учитывая огромный объём кода, они разработали системный подход с применением искусственного интеллекта, чтобы выполнить исследование эффективно.

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

(Прим. Menaskop: на самом деле Bybit, конечно же, ищут в очередной раз, на кого свалить вину за свой провал и как в будущем замораживать подобные, похищенные, средства).

Основные результаты исследования

Lazarus Security Lab проанализировали 166 крупных блокчейнов, чтобы определить, обладают ли они функцией заморозки средств.
Исследователи применили ~~новый~~ метод: сначала - автоматизированная фильтрация блокчейнов с помощью кастомного ИИ-агента, затем - глубокий ручной анализ. (Прим. Menaskop: нового здесь ничего нет, т.к. подобным занимаются исследователи уже не первый год).
Подтверждено, что 16 блокчейнов уже имеют встроенную возможность заморозки, а ещё 19 - потенциально могут поддерживать подобный функционал в будущем.
Среди этих 16 блокчейнов выявлены три основных механизма заморозки:

Жёстко прописанная (hardcoded) заморозка;
Заморозка на основе конфигурационных файлов;
Заморозка средствами смарт-контрактов.

(Рассмотрим все случаи подробно).

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

Исследователи обнаружили пять важных инцидентов и уникальных реализаций механизмов заморозки:

Взлом Cetus в сети Sui и оперативное обновление в Aptos;
Инцидент со взломом BNB Chain, после которого появилась возможность чёрного списка (blacklisting);
Cosmos и его модульные аккаунты с возможностью блокировки адресов;
HECO Chain и её возможность добавлять в чёрный список через смарт-контракт;
Взлом VeChain, после которого был реализован механизм блокировки адресов.

1. Блокчейны с реальной возможностью заморозки средств (16 шт.)

Hardcoded (жёстко зашитая в коде) -> всего 5 шт.:

CHILIZ
VIC
XDC
BNB
VECHAIN

Configfile (через конфигурационные файлы) -> 10 шт.:

ONE
HVH
APTOS
SUPRA
EOS
ROSE
WAXP
SUI
LINEA
WAVES

Smart Contract (через смарт-контракт) -> 1 шт.:

HECO

2. Блокчейны с потенциальной возможностью заморозки средств (19 шт.)

ARBITRUM (Arbitrum)
ATOM (Cosmos)
AXL (Axelar)
BABYLON
CELESTIA
DYDX
DYM
DYMEVM
EVMOS
INITIA
KAVA / KAVA EVM
LUNA
MANTRA
Nillion
OKB
RUNE
SEI / SEI EVM
SRCT
XION

Методы заморозки

Во время исследования команда Lazarus Security Lab (Bybit) выявила 16 блокчейнов с возможностью протокольной заморозки средств. Это значит, что фонд или управляющая группа блокчейна может полностью заблокировать выбранные ими адреса.

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

Среди этих 16 блокчейнов команда обнаружила три отдельных метода протокольной заморозки:

1.1.1 Hardcoded - жёстко прописанный механизм (публичный blacklist);
1.1.2 Config-file - механизм через конфигурационные файлы (приватный blacklist);
1.1.3 Заморозка через смарт-контракт (on-chain smart contract freezing).

(Рассмотрим и их отдельно и подробно).

1.1.1 Hardcoded Freezing Method (Публичный чёрный список)

Жёстко прописанный в коде механизм заморозки впервые применён VeChain в декабре 2019 года. После взлома, в результате которого было похищено примерно $6,6 млн в VET из официального кошелька байбэка, VeChain Foundation добавила функцию, блокирующую адреса из чёрного списка:

такие адреса не могли подписывать транзакции,
469 адресов, связанных с хакерами, были внесены в GitHub-чёрный список, - это полностью лишило злоумышленников возможности взаимодействовать с блокчейном и вывести украденные средства.

Главное преимущество заморозки - быстрая минимизация ущерба экосистеме: валидаторы и фонд могут оперативно не дать хакерам вывести или продать украденные активы.

В октябре 2022 года BNB Chain также применил hardcoded-заморозку после крупного взлома их crosschain моста… Эксплойт позволил злоумышленнику подделать доказательства вывода и заминтить 2 млн BNB (примерно $570 млн).

Через жёсткое добавление адресов в blacklist ущерб удалось частично ограничить: только $100–110 млн были выведены, остальное удалось заблокировать.

Итог: 5 блокчейнов имеют hardcoded-заморозку:

Формат:

Блокчейн
Гит

Список:

Первый:

Второй:

Третий:

Четвёртый:

Пятый:

1.1.2 Метод заморозки через конфигурационные файлы

(Private Blacklist - приватный чёрный список): логика блокировки определённых адресов такая же, как и в случае с hardcoded-методом.

Разница заключается в том, что чёрный список хранится и обновляется в локальных конфигурационных файлах - таких как YAML, ENV или TOML, - которые доступны только валидаторам, фонду и core-разработчикам.

Вскоре после этого Aptos (который часто называют “сестринской цепочкой Sui”) обновил свой код, добавив собственную функцию для чёрного списка.

Эти действия усилили дискуссии о том, являются ли такие фундаментальные блокчейн-проекты действительно децентрализованными или же по сути остаются централизованными структурами, работающими поверх распределённого реестра. Более подробная информация о реакции Aptos приведена в разделе 1.2.1.

Пример: взлом Cetus на Sui (22 мая 2025). 22 мая 2025 года DEX Cetus, работающий в сети Sui, был взломан. Ущерб составил примерно $223 млн в цифровых активах.

В ответ на инцидент валидаторы Sui и Sui Foundation задействовали свою возможность заморозки средств:

добавили адреса атакующих в свои конфигурационные файлы,
перезапустили ноды,
после чего эти адреса были заблокированы от подписи транзакций в сети.

1.1.2 Метод заморозки через конфигурационные файлы

(Private Blacklist - приватный чёрный список). Всего 10 блокчейнов, включая Sui, обладают возможностью заморозки средств через конфигурационные файлы.

Цепочки и ссылки на GitHub:

Первый:

Второй:

Третий:

HVH / VIC (Havah / Viction fork)
https://github.com/havah-project/goloop-havah/blob/ddeb0cf687a04ff8740267310d763fe1a39a3534/service/transaction/transactionhandler.go#L117

Четвёртый:

Пятый:

Шестой:

Седьмой:

Восьмой:

Девятый:

Десятый:

1.1.3 Метод заморозки через on-chain смарт-контракт

Управление чёрным списком через смарт-контракт на блокчейне - уникальный подход, который используется исключительно в сети HECO (Huobi Eco Chain).

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

Валидаторы проверяют чёрный список, делая запросы к ABI смарт-контракта. Подробности этого механизма приведены в разделе 1.2.4.

1.2 Значимые выводы исследования

1.2.2 Инцидент взлома BNB и последующее внедрение механизма блокировки адресов.

1.2.3 Модульные аккаунты Cosmos с возможностью блокировки адресов.

1.2.4 Механизм блокировки адресов в HECO через смарт-контракт.

1.2.5 Инцидент взлома VeChain и последующее внедрение механизма чёрного списка.

1.2.1 Взлом Cetus в сети Sui и оперативное обновление Aptos

Взлом Cetus. Cetus, децентрализованная биржа (DEX) в сети Sui, была взломана 22 мая 2025 года. Ущерб составил около 223 млн долларов в цифровых активах. Атакующий использовал уязвимость в математической библиотеке Cetus, что позволило ему манипулировать ценами пулов ликвидности с помощью поддельных токенов. Из-за потенциального ущерба экосистеме Sui, Sui Foundation и валидаторы задействовали свою протокольную возможность заморозки средств и сумели заморозить 162 млн долларов украденных активов.

Восстановление средств. После заморозки команда Sui предприняла дополнительное действие - инициировала процедуру возврата средств с адреса хакера. Сообщество Sui успешно провело голосование по управлению (governance), в котором 90,9% валидаторов поддержали решение вернуть 162 млн долларов, замороженных после взлома протокола Cetus.

Одобренное голосование позволило:

перевести замороженные средства с адреса хакера;
на указанный мультисиг-кошелёк Cetus.

Оттуда средства будут храниться в доверительном режиме и позднее возвращены пострадавшим пользователям:

Данные голосования

2.1 Взлом Cetus в Sui и оперативное обновление Aptos

Обновление Aptos после взлома Cetus. Aptos и Sui унаследовали язык программирования Move, который был разработан как безопасный и универсальный язык для смарт-контрактов, основанный на принципах владения ресурсами и их ограниченности.

Однако недавнее исследование выявило важное отличие в поддержке протокольной заморозки средств.

В Sui эта возможность существовала ещё с апреля 2023 года.
В Aptos подобная функция не была реализована до тех пор, пока Sui не задействовала её в ответ на взлом Cetus.

Именно после использования этой функции Sui и стало известно широкой публике, что такие механизмы вообще существуют. Наши данные показывают, что Aptos добавил поддержку механизма Transaction Filter 4 июля, примерно через месяц после взлома Cetus (22 мая).

Это обновление вводит функциональность, аналогичную Sui - позволяет отклонять транзакции, если их отправитель находится в чёрном списке. Чёрный список может обновляться через YAML или TOML файлы, но чтобы изменения вступили в силу, требуется перезапуск ноды.

СМ. подробности: https://github.com/aptos-labs/aptos-core/blob/fb06376c4461795699cb7d49605b54ac494a5972/config/src/config/transaction_filters_config.rs#L22

Заключение. Краеугольным камнем блокчейна является его способность обрабатывать транзакции децентрализованным образом.

Функциональность, применённая в Sui, а также недавно добавленная в Aptos, демонстрирует устойчивость этих сетей к взлому и их способность быстро применять механизмы управления рисками для восстановления потерянных средств.

Однако всё это одновременно указывает блокчейн-сообществу на наличие централизованной власти внутри таких систем.

1.2.2 Инцидент взлома BNB и последующее внедрение механизма блокировки адресов

Предыстория. 6 октября 2022 года BNB Chain столкнулась с крупным инцидентом безопасности на своём кроссчейн-мосту. Причиной стал уязвимый участок в процессе проверки доказательств дерева IAVL.

Эта уязвимость позволила хакеру подделать доказательства вывода и заминтить 2 миллиона BNB, что на тот момент соответствовало примерно 570 млн долларов. Процесс проверки доказательств дерева IAVL используется для валидации кроссчейн-транзакций между BNB Chain и BSC Token Hub.

Уязвимость возникла из-за того, что алгоритм проверки пропускал проверку правого потомка (right child). Используя эту дыру, злоумышленник создал вредоносное доказательство, которое выставляло новый лист в дерево, полностью обходя проверку, и тем самым фактически "создавал" токены BSC из воздуха.

Ответные меры. Команда BNB Chain совместно с валидаторами оперативно приостановила работу блокчейна, чтобы остановить дальнейший вывод активов. Затем был выпущен обновлённый софт, который жёстко (hardcoded) внёс адрес хакера в протокольный чёрный список, фактически заморозив оставшиеся на цепи украденные токены. Как и Sui, BNB Chain внедрила протокольный механизм заморозки средств после инцидента.

См. подробности: https://github.com/bnb-chain/bsc/blob/e7b198c10cc8c3e32a5b6d98cd34938115f08ade/core/types/blacklist.go#L6

1.2.3 Модульные аккаунты Cosmos с возможностью блокировки адресов

Cosmos использует специальные модульные аккаунты - аккаунты, создаваемые модулями Cosmos SDK для управления средствами и выполнения операций, специфичных для каждого модуля. В отличие от обычных пользовательских аккаунтов, такие аккаунты контролируются логикой модуля, а не приватными ключами.

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

Это делается потому, что они предназначены для выполнения внутренних функций протокола, а не для использования пользователями. Каждый модуль поддерживает список под названием blockedAddrs.

По умолчанию в этот список включены все модульные аккаунты (те, что используются модулями сети для стейкинга, управления (governance), распределения токенов и др.).

Назначение такого списка двойное:

Не позволять пользователям случайно отправлять токены напрямую на модульные аккаунты.
Предотвращать вывод средств из модульных аккаунтов в случае взлома.

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

Кроме того, внедрение такой возможности потребует хардфорка, а также небольших доработок - вероятнее всего, в файле anteHandler - или других изменений в коде.

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

См. доп. информацию: https://github.com/initia-labs/initia/blob/7947f7cf73cfdd7973fe4f69140c24043264444b/x/bank/keeper/send.go

1.2.4 Блокировка адресов в HECO через смарт-контракт

В отличие от других блокчейнов, использующих протокольный уровень для заморозки средств, HECO (Huobi ECO Chain) применяет уникальный подход к чёрным спискам.

Вместо того чтобы требовать хардфорк, HECO позволяет администраторскому адресу добавлять любой адрес в чёрный список напрямую, и обновление вступает в силу немедленно.

Как извлекается чёрный список?

Проверка кэша: Система сначала пытается получить чёрный список из LRU-кэша в оперативной памяти (c.blacklists), привязанного к хешу родительского блока.
Быстрый путь при отсутствии недавних обновлений: Если последнее обновление было давно и в кэше нет записи, система рекурсивно проверяет чёрный список родительского блока. Это быстрый путь для блоков, в которых давно не было изменений.
Вызов смарт-контракта: Если чёрный список не найден ни в кэше, ни у родительского блока, система обращается к системному смарт-контракту напрямую, используя его ABI, читая состояние блокчейна.
Вызов методов контракта: Система вызывает два метода смарт-контракта AddressListContract:

getBlacksFrom - чёрный список отправителей;
getBlacksTo - чёрный список получателей.

Эти вызовы возвращают списки адресов, которые заблокированы как отправители, как получатели или оба сразу.
Формирование итоговой структуры:

Построение отображения (mapping): Система формирует карту адресов → статус блокировки (from, to или both) на основе результатов вызовов методов смарт-контракта.
Кэширование: Полученные данные сохраняются в LRU-кэше,
чтобы ускорить последующие обращения к чёрному списку.

1.2.4 Блокировка адресов в HECO через смарт-контракт (продолжение)

Как обновляется чёрный список? Чёрный список управляется on-chain смарт-контрактом AddressListContract, расположенным по адресу: 0x000000000000000000000000000000000000F004. Этот системный контракт содержит встроенные методы для управления заблокированными адресами.

Чтение чёрного списка. Контракт предоставляет функции, такие как:

getBlacksFrom - получить список заблокированных отправителей;
getBlacksTo - получить список заблокированных получателей.

Добавление или удаление адресов. Чтобы добавить или убрать адрес, необходимо отправить транзакцию, вызывающую административные функции контракта, например:

addBlackFrom(address);
addBlackTo(address).

Только администратор контракта - обычно это мультисиг или governance-аккаунт - имеет право обновлять чёрный список.

Автоматическое обновление узлов. Ноды сети автоматически считывают обновления чёрного списка из состояния контракта. Поэтому:

перезапуск нод не требуется,
хардфорк также не нужен.

Заключение. HECO обладает архитектурой, которая позволяет команде оперативно добавлять любой адрес в чёрный список. Так как хардфорк не требуется, скорость вступления обновления в силу полностью зависит от того, насколько быстро выполняется мультисиг-подпись.

1.2.5 Инцидент взлома VeChain и последующее внедрение механизма чёрного списка

13 декабря 2019 года VeChain Foundation подверглась взлому, в результате которого было украдено около 6,6 млн долларов в VET-токенах из официального байбэк-кошелька.

В ответ команда внедрила механизм чёрного списка, нацеленный на адреса злоумышленника. Всего 469 адресов, связанных с инцидентом, были добавлены в чёрный список на GitHub, что эффективно заблокировало их взаимодействие с блокчейном VeChain.

См. подробности: https://github.com/vechain/thor/blob/b01ac99428e18130f57a8b4b19e005bfc6921184/thor/blocklist.go#L493

Общие наблюдения

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

Блокчейны внутри одной семейства (EVM, Cosmos, UTXO и др.) показывают схожие характеристики. Это связано с общей архитектурой и используемыми языками программирования.

1. Семейство: EVM

Доминирующий язык программирования: Go
Управление чёрным списком:

Обычно используется жёстко зашитый hardcoded blacklist, видимый публично.
Исключения:

HECO - использует смарт-контракт
HVH - использует config-файл

Логика заморозки:

Основная логика встроена в tx_pool или код валидаторов
Подход сильно вдохновлён моделью BNB Chain

2. Семейство: Object-Based (Move/Sui/Aptos)

Доминирующий язык программирования: Rust
Управление чёрным списком:

Ведётся в локальных конфигурационных файлах
Управляют валидаторы или организации, поддерживающие блокчейн
Чёрный список не виден публично

Логика заморозки:

Находится в отдельном Rust-файле (обычно называется transaction deny config)
Выполняется как часть node-кода

3. Семейство: Cosmos

Доминирующий язык программирования: Go
Управление чёрным списком:

Если механизм существует, blacklist обычно жёстко зашит и виден публично

Логика заморозки:

Cosmos-цепочки не имеют полнофункционального механизма заморозки на уровне протокола
Но такой механизм может быть добавлен через модификацию кода в модульных аккаунтах

4. Семейство: Other (другие типы блокчейнов)

Доминирующий язык: Разный (varies)
Управление чёрным списком:

Методы отличаются от цепи к цепи
Используются и hardcoded blacklists, и конфигурационные файлы

Логика заморозки:

Зависит от механизма консенсуса и архитектуры
Обычно реализована в tx_pool или коде валидаторов

Когда мы обнаружили, что некоторые блокчейны содержат встроенные механизмы заморозки адресов, мы столкнулись с серьёзной задачей: проанализировать 166 сетей, поддерживаемых Bybit, чтобы оценить их возможности цензуры. Из-за огромного объёма кода ручная проверка была невозможна, поэтому мы разработали системный конвейер обнаружения на базе ИИ. Наш рабочий процесс состоял из трёх ключевых этапов:

3.1 Краткое описание

1) Подготовка тестовых данных:

В качестве первого тестового кейса мы выбрали блокчейн Sui,
Поскольку из бизнес-операций мы уже знали, что он включает механизмы заморозки адресов.
Этот реальный пример идеально подошёл как валидационный набор данных для нашей AI-методологии.

2) Разработка экспериментальных промптов:

Используя кодовую базу Sui, мы провели масштабные тесты с разными версиями промптов.
Цель - определить наиболее эффективный способ обнаружения таких механизмов.
Через серию итераций мы сравнивали качество работы промптов
по точности выявления механизмов заморозки.
В итоге был выбран вариант промпта, который показал наивысшую точность по фактическим результатам.

3) Масштабное применение:

После того как метод был успешно проверен на Sui, мы применили оптимизированную систему обнаружения (комбинация промпта + AI-модели Claude-4.1 Opus) ко всем 166 блокчейнам.
Таким образом мы систематически выявили, какие сети имеют аналогичные возможности заморозки средств.

3.2. Далее

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

Чтобы решить задачу, мы сосредоточились на поиске базовых характеристик, которые определяют наличие механизма заморозки. Это позволило создать методологию, способную выявлять разные реализации одной функции. В результате анализа мы выделили три критически важные характеристики, определяющие способность блокчейна замораживать транзакции:

1) Извлечение начальных признаков. В ходе ручного экспертного анализа кодовой базы Sui были выявлены ключевые компоненты:

Конфигурация чёрного списка адресов (механизмы вида deny_list, address_blacklist и т.п.);
Загрузка конфигурации в реальном времени - позволяет основным обработчикам транзакций считывать конфигурацию во время выполнения;
Фильтрация транзакций во время обработки - отклонение транзакций от адресов из чёрного списка на разных этапах жизненного цикла транзакции.

2) Итеративное тестирование промптов:

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

3) Финальная оптимизация промпта:

После масштабной доработки и успешной проверки на известных механизмах заморозки Sui был создан окончательный промпт, способный:

точно выявлять ограничения нативных токенов уровня L1,
а также контро́ль токенов проектов уровня L2.

Промпт инструктирует ИИ анализировать:

модули чёрных списков;
механизмы загрузки конфигураций;
логику фильтрации транзакций.

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

Пример промта

3.3. Ограничения AI-анализа и практические соображения

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

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

3.3.1 Ошибочная идентификация роли и уровня полномочий, связанных с заморозкой

Предыстория. Мы использовали оптимизированный промпт вместе с Claude-4.1-Opus для анализа основных репозиториев блокчейнов. На этапе автоматизированного сканирования казалось, что ИИ корректно интерпретирует механизмы заморозки.

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

Технически ИИ не ошибался, но выявил ограничение в корректности формулировки промпта - в частности, в области:

различения уровня полномочий;
и реального протокольного уровня механизма заморозки.

Это подчёркивает, что ручной аудит остаётся необходимой частью исследовательского процесса.

Наблюдение (пример). В случае Symbol Chain ИИ обозначил потенциальные способности к заморозке и дал следующие ответы на проверочные вопросы:

Первый:

Вопрос: Имеет ли проект модули: blacklist, ограничения адресов, динамическая загрузка конфигурации и т.п.?
Ответ модели: Да.

Второй:

Вопрос: Существует ли логика фильтрации транзакций на уровне адреса для ключевых токенов?
Ответ модели: Да, через AccountAddressRestrictionTransaction и механизмы поддержки XYM (XYM - нативный токен Symbol Chain).

Третий:

Вопрос: Поддерживается ли быстрое управление запретом этих транзакций через конфигурацию? Есть ли hot-loading или загрузка конфигурации при перезапуске?
Ответ модели: Механизма горячего обновления не найдено. Ограничения задаются динамически через AccountAddressRestrictionTransaction, а не через статические конфигурационные файлы. После перезапуска ноды восстанавливаются автоматически.

Четвёртый:

Вопрос: На каком этапе срабатывает логика фильтрации транзакций? Например: проверка подписи, предпакетные проверки, отклонение при исполнении?
Ответ модели: Во время проверки подписи транзакции.

Пятый:

Вопрос: Для L2-проектов: одинаковы ли механизмы заморозки для проектных токенов и нативных токенов?
Ответ модели: Нет, это блокчейн уровня L1.

Вывод ИИ: Да- Symbol имеет способность быстро замораживать транзакции с ключевыми токенами.

Ошибочная идентификация уровня полномочий при заморозке

Выявление ошибки (Manual Review):

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

Анализ:

Этот механизм принципиально отличается от административной/протокольной заморозки на уровне всей сети, которая была основным объектом нашего исследования.
ИИ действительно корректно обнаружил логику фильтрации адресов в коде,
но не смог различить:

механизмы пользовательского уровня, и
механизмы администраторского/сетевого уровня.

На уровне кода обе функции выглядят схожими:

проверка адресов;
фильтрация транзакций;
условное выполнение.

Однако их назначение и влияние радикально различаются:

User-level blocking - влияет только на кошелёк одного пользователя;
Admin-level freezing - может остановить перевод токенов по всей сети.

Решение:

Именно поэтому ручная проверка является критически важным вторым уровнем валидации.
Ни один тестовый набор данных не может охватить все варианты реализации механизма заморозки в разных блокчейнах.
Важно, что у всех сетей с настоящей протокольной заморозкой есть общие фундаментальные признаки.
Аналитики используют тестовые данные, чтобы убедиться, что ИИ правильно понимает существо механизма заморозки, но краевые случаи - такие как разница между пользовательским и административным уровнем - неизбежны.
Этот пример стал ценным прецедентом.
Добавив различие по уровням полномочий в промпты, мы смогли улучшить качество обнаружения и использовать это как критерий фильтрации при ручной проверке.

3.3.2 Отсутствие комплексного анализа путей исполнения кода

Предыстория:

Мы использовали тот же оптимизированный промпт с моделью Claude-4.1-Opus, но расширили зону анализа, включив в неё поиск уязвимостей библиотеки IAVL.
Это стало необходимым после того, как было выявлено, что библиотека IAVL сыграла ключевую роль во взломе моста BSC, где атакующие использовали уязвимость в процессе проверки доказательств.
Поскольку функциональность заморозки в BSC была связана с уязвимым использованием IAVL, мы улучшили промпт так, чтобы он выявлял:

появление реализаций IAVL,
соответствующие исправления (hotfixes),
и делал это как часть общей линии расследования.

Анализ:

Этот случай выявил ключевое ограничение ИИ: поверхностное сканирование кода без глубокого анализа путей исполнения (runtime analysis).
ИИ выполнял только поверхностное обнаружение, определяя:

наличие импортов IAVL,
вызовы функций IAVL.

Однако он не анализировал механизмы переключения, которые определяют реальный путь выполнения кода.
Модель увидела наличие IAVL-кода и сразу сделала вывод, что сеть уязвима, не учитывая:

конфигурационные флаги,
условную логику,
механизм перенаправления выполнения, которые могут полностью устранять риск.

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

Наблюдение. Пример Sei blockchain:

ИИ обнаружил большое количество IAVL-кода в репозитории и заключил, что
"Sei всё ещё использует библиотеку IAVL".
На самом деле Sei уже перешёл на memIAVL через runtime-флаг конфигурации: sc-enable = true
Вместо полной переписки всего кода IAVL проект реализовал механизм переключения, который перенаправляет операции IAVL на более безопасный memIAVL, если флаг включён.

Решение:

Чтобы устранить это ограничение, промпты должны быть улучшены и явно запрашивать:

механизмы переключения исполнения,
конфигурационные флаги,
наличие замещающих реализаций IAVL.

Мы уже определили это как существующий пробел.
Ручная проверка истории коммитов GitHub также даёт надёжные доказательства того, что исправления действительно реализованы.
Наиболее надёжный подход - двойная система проверки:

ИИ-анализ, учитывающий runtime-логику.
Ручная проверка истории и архитектурных решений.

Это позволяет выявлять как поверхностное использование IAVL, так и глубинные архитектурные особенности, которые влияют на реальную уязвимость сети.

3.4 Критически важные напоминания

В нашем первоначальном анализе мы упустили один важный момент: некоторые блокчейн-проекты распределяют свою ключевую функциональность по нескольким репозиториям.

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

Пример: Plume Chain:

plume-go-ethereum - отвечает за основной execution-layer.
plume-nitro - управляет инфраструктурой rollup и механизмами sequencer’а.

Когда мы анализировали только репозиторий plume-go-ethereum, мы ошибочно пришли к выводу, что Plume не имеет полноценной функции заморозки средств.

На самом деле необходимые механизмы заморозки были реализованы в репозитории plume-nitro. То есть если анализировать только go-ethereum-часть, можно полностью пропустить важную функциональность.

Подобное разделение архитектуры широко распространено в современных L2-решениях.

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

Учёт таких мультирепозиторных взаимосвязей - важная тонкость анализа.

Исследование, инициированное вмешательством SUI Foundation после взлома Cetus, дало важный анализ возможностей цензуры в 166 блокчейн-сетях. Работа была выполнена с использованием оптимальной комбинации кастомизированных AI-агентов и глубокого ручного анализа кода.

Наши результаты подтверждают, что:

16 блокчейнов имеют встроенные механизмы заморозки активов,
ещё 19 - обладают потенциальной возможностью внедрить такие механизмы.

Исследование выделило три отдельные методологии заморозки активов:

Hardcoded-заморозка (жёстко прописанная в коде);
Заморозка через конфигурационные файлы (config file freezing);
Заморозка через смарт-контракт (on-chain smart contract freezing).

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

Однако одновременно эти механизмы уже предотвратили кражи средств хакерами.

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

Завершающий перечень чейнов

См. подробности: https://assets.contentstack.io/v3/assets/bltffdbacf2f22e15fa/bltda1597363a4f2a2b/69144b86424c333a34bc9fa8/2509-T68340_Security_Report_1111.pdf

И, как говорится, -

До!