Взлом протокола Hinkal: анализ критической уязвимости

Где именно выглядит уязвимость

Из опубликованного описания следует минимальная трасса атаки: внешний аккаунт сделал несколько вызовов Transact, после чего неизвестные смогли вывести средства через proofless deposit. Деталей кода, конкретного контракта и патча в источниках нет, поэтому аккуратнее: мы не знаем, был ли это баг в проверке zk-доказательства, ошибка маршрутизации вызова, неверная авторизация или дефект в бизнес-логике депозита.

Но сам класс симптомов неприятный. Если контракт принимает депозит без доказательства, значит где-то нарушена граница между «пользователь заявил состояние» и «контракт криптографически проверил состояние». В нормальной архитектуре приватного протокола это разные сущности. Заявление без proof — мусор. Proof без корректной привязки к состоянию, сумме, получателю и nullifier — тоже мусор. Смарт-контракт обязан отбрасывать оба варианта.

Пока публично озвучена только операционная картина: атакующий использовал конкретный EOA, дергал Transact, затем вывел активы. Этого достаточно, чтобы считать риск не рыночным, а протокольным. Не «ликвидность ушла», не «пользователи испугались», а проверяемая логика контракта дала неверный результат.

Как двигались средства

По данным источников, похищенные USDC были оперативно конвертированы в эфир. Затем 410 ETH, оцениваемые примерно в $700 000, были внесены в Tornado Cash. Ещё 44,67 ETH ушли через децентрализованный мост Thorchain из Ethereum в Bitcoin. Конечный биткоин-адрес начинается с bc1qr2sf.

Эта схема не добавляет технической глубины самой уязвимости, но полезна для triage. Если вы ведёте комплаенс, мониторинг депозитов или риск-скоринг контрагентов, нужны не общие слова про «взлом Hinkal», а конкретные индикаторы: EOA 0xbB3f01a1b1C68F3DEB36C55342b5F5706c32fc20, серия Transact, конвертация USDC в ETH, депозит 410 ETH в Tornado Cash, перевод 44,67 ETH через Thorchain, BTC-адрес с префиксом bc1qr2sf.

Отдельная ирония архитектуры: Hinkal сам позиционируется как privacy-протокол для крупных компаний, позволяющий проводить транзакции без раскрытия баланса кошелька и контрагентов. То есть система продаёт сокрытие метаданных как продуктовую функцию. После такой атаки аудитору важна не декларация конфиденциальности, а вопрос проще: можно ли формально доказать, что приватный переход состояния не создаёт право на вывод без валидного proof.

Что проверять пользователям и интеграторам

Hinkal работает в пяти сетях: Ethereum, Arbitrum, Base, Polygon и OP Mainnet. Поэтому проверка не должна ограничиваться одной цепочкой, если у вас были разрешения, интеграции или операционные кошельки, связанные с протоколом. Минимальный набор действий скучный, но правильный: проверить approvals, историю взаимодействий с контрактами Hinkal, входящие и исходящие транзакции вокруг вызовов Transact, а также внутренние правила казначейства для адресов, которые могли пользоваться приватными переводами.

Для команд, которые рассматривали Hinkal как корпоративный слой конфиденциальности, важен ещё один пункт. В мае протокол был интегрирован разработчиками Polygon для корпоративных клиентов, которым нужно скрывать транзакции со стейблкоинами. За день до взлома Hinkal объявил партнёрство с Turnkey, поставщиком инфраструктуры кошельков. Эти факты не доказывают причастность интеграций к атаке. Но они расширяют поверхность вопросов: где проходила граница ответственности между кошельком, privacy-слоем, контрактами и цепочками исполнения.

Контекст тоже не успокаивает. В июне, по данным источников, произошло 40 крупных атак на кроссчейн-мосты, DeFi-протоколы и смарт-контракты; суммарно вывели около $75,8 млн, крупнейшей назывался взлом Humanity. Hinkal попадает в тот же неприятный класс: сложная архитектура, много сетей, приватность, мосты, конвертация активов. Чем больше оверхед вокруг доказательств и маршрутизации, тем меньше права на нестрогую проверку входных условий.

Технический вердикт простой. Пока Hinkal не опубликует разбор причины, затронутый контракт, условия эксплуатации бага и исправление, протокол следует рассматривать как небезопасный для новых депозитов и корпоративных сценариев. Privacy без корректной верификации proof — это не криптография. Это интерфейс к потере средств.