Взрывная правда о криптоботах, которые опережают воров, чтобы «спасти» средства — но именно они решают, кому вернуть деньги

Источник: CryptoNewsNet Оригинальный заголовок: Explosive truth behind crypto bots that front-run thieves to “save” funds — but they decide who gets paid back Оригинальная ссылка:

Инцидент с Makina Finance

Makina Finance потеряла 1299 ETH, примерно 4,13 миллиона долларов, в результате эксплуатации с флеш-лоаном и манипуляциями с оракулами.

Атакующий истощил средства протокола и транслировал транзакцию в публичный мемпул Ethereum, где она должна была быть замечена валидаторами и включена в следующий блок.

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

Транзакция хакера не прошла. Средства оказались на двух адресах, связанных с MEV-строителем.

Немедленный вывод — пользователи Makina избежали полного потери. Более глубокий сигнал — кто в итоге держит деньги и что это значит для развивающейся системы экстренного реагирования в крипте.

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

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

MEV как резервный механизм уже является шаблоном

Инцидент с Makina — не единичный случай. Chainalysis зафиксировала подобную динамику во время эксплойтов Curve и Vyper 2023 года, отметив, что белые хакеры и операторы MEV-ботов помогли восстановить средства, что снизило фактические убытки ниже первоначальных оценок.

Шаблон механический: пока эксплойты или попытки спасения видны в публичных транзакциях, опытные поисковики и строители могут конкурировать за переупорядочивание транзакций.

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

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

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

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

Почему зависимость от строителей MEV вызывает дискомфорт

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

На Ethereum доминирует MEV-Boost. Ландшафт реле Rated показывает, что примерно 93,5% последних блоков проходят через MEV-Boost, по сравнению с примерно 6% — через обычное производство блоков.

В рамках MEV-Boost доля рынка реле дополнительно концентрируется: Ultra Sound Money составляет примерно 29,84% трафика реле, а Titan — примерно 24,24%, что означает, что два крупнейших реле вместе обрабатывают более 54% производства блоков.

Если большинство блоков проходят через MEV-Boost, а трафик этого сервиса — через два реле, слой спасения структурно зависит от небольшого числа посредников. Это быстро создает проблемы с управлением.

Если строитель в итоге держит спасённые средства, кто уполномочен на хранение? Кто устанавливает вознаграждение? Что мешает вымогательству или вымогательским требованиям? Что если строитель находится за границей, анонимный или работает в юрисдикции с слабым правоприменением?

Дело Makina иллюстрирует проблему. Средства находятся в распоряжении строителя, но нет публичного SLA, предопределенного вознаграждения или ясного механизма возврата средств Makina или его пользователям.

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

Частная маршрутизация усугубляет проблему

Научная статья 2025 года под названием “Sandwiched and Silent” зафиксировала широкое распространение частной маршрутизации транзакций и обнаружила, что многие жертвы мигрируют в частные каналы после того, как их “зажимают” MEV-боты.

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

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

Попытка цивилизовать хаос

Safe Harbor — это рамочная концепция, разработанная SEAL, которая стремится заменить модель “строитель MEV как случайного хранителя” на авторизованных реагирующих, четкие SLA и ограниченные стимулы.

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

Основное правило — что спасённые средства должны быть отправлены на официальные адреса восстановления в течение 72 часов, с заранее определенными, исполнимыми вознаграждениями.

SEAL говорит, что Safe Harbor был мотивирован взломом Nomad, когда белые хакеры были готовы помочь, но сталкивались с юридической неопределенностью, связанной с возможностью преследования за возврат средств как за несанкционированный доступ к компьютерам.

Safe Harbor устраняет эту неопределенность, давая протоколам возможность заранее уполномочивать вмешательство и устанавливать ясные условия. SEAL утверждает, что Safe Harbor уже защищает более $16 миллиарда долларов в рамках крупных протоколов, включая некоторые DEX, Pendle, решения второго уровня и zkSync.

Платформа по поиску багов Immunefi реализовала Safe Harbor с более строгими условиями.

Immunefi описывает Safe Harbor как структуру, разработанную SEAL, которая перенаправляет средства в хранилище, контролируемое протоколом, на платформе Immunefi. На странице программы Safe Harbor Immunefi указано: “У вас есть 6 часов, чтобы вернуть средства.”

Несоблюдение шестичасового срока — существенный нарушение. Это в четыре раза быстрее базового требования SEAL в 72 часа.

Safe Harbor не устраняет зависимость от инфраструктуры MEV. Вместо этого он пытается ее формализовать.

Если строитель фронтранит эксплойт, а протокол внедрил Safe Harbor, ожидается, что строитель признает вмешательство авторизованным и перенаправит средства на указанный протоколом адрес восстановления в рамках SLA.

Но это предполагает, что строители следят за регистрациями Safe Harbor, уважают условия и ставят соблюдение правил выше прибыли.

Диапазон сценариев

Ожидаемый уровень восстановления пользователя при эксплойте можно смоделировать как: ожидаемое восстановление равно вероятности вмешательства, умноженной на один минус процент вознаграждения, умноженной на один минус процент неудач или утечек.

Safe Harbor стремится повысить вероятность вмешательства, сокращая юридическую неопределенность и заранее ограничивая процент вознаграждения.

В базовом сценарии внедрение Safe Harbor увеличится за следующие 12 месяцев. Все больше протоколов добавляют условия Safe Harbor в свои управленческие рамки, и все больше белых хакеров регистрируются как авторизованные реагенты.

Вероятность вмешательства возрастает, потому что реагенты получают юридическую ясность и фиксированные условия вознаграждения. Уровень восстановления улучшается, особенно для протоколов, внедряющих более строгие SLA, такие как шестичасовое окно Immunefi.

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

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

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

Управление становится зависимым от посредников, которые держат средства и устанавливают условия в одностороннем порядке.