Риски мостов: валидаторы, мультиподписи и повтор сообщений

2026-08-12

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

Вопрос, который сортирует любой мост

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

Механика почти не меняется. На исходной цепи что-то происходит. Некая сторона удостоверяет, что это произошло. Контракт на цепи назначения сверяет это удостоверение с правилом и, если оно проходит, разблокирует или чеканит. Всё, что нужно атакующему, лежит по другую сторону этого правила.

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

Размер денег делает этот обмен беспощадным. К августу 2022 года Chainalysis насчитала 13 отдельных взломов кросс-чейн мостов примерно на 2 миллиарда долларов — около 69% всего украденного в крипте за тот год к тому моменту. Мосты притягивают атаки потому, что собирают обеспечение ровно в той точке, где проверяется одно правило.

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

Внешний набор валидаторов — система, которую вы не аудировали

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

Вывод прямолинеен: кто владеет M ключами, тот может чеканить. Возьмём набор из 9 участников с порогом 5. Атакующему с 5 ключами не нужны ни ошибка в контракте, ни слабость какой-либо из цепей, ни дополнительная проверка. Пока он опустошает мост, мост делает ровно то, для чего был построен.

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

Значит, спрашивать нужно про состав. Кто эти N и раскрыты ли они вообще? Это разные организации или одна организация с девятью машинами? Чему равно M? Есть ли у участников что-то на кону, что можно отобрать, если они подпишут ложное сообщение? И кто может менять состав, ведь набор, переписываемый одним ключом, — это односигнатурный мост в костюме комитета.

Порог считается только там, где ключи отказывают независимо

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

Часто они не могут. Ключи внутри одной компании делят один процесс найма, один образ ноутбука, один VPN, один облачный сервис ключей и один интерфейс подписи. Если одно фишинговое письмо достаёт всех девятерых держателей или пять ключей лежат в одном облачном аккаунте, то N — это число на дашборде, а настоящее N ближе к 1.

Поднять порог это не чинит, и стоит такое решение дорого. При высоком M потеря нескольких ключей оставляет мост без возможности подписать вообще: не украдено ничего, но и не движется ничего, а тот, чьи активы остались не на той стороне, ждёт. Любой порог — это выбор между «слишком легко украсть» и «слишком легко заморозить».

Поверхность подписи заслуживает не меньшего внимания, чем хранение. Подписанты одобряют данные, которые в большинстве своём прочесть не могут, так что если интерфейс показывает дружелюбную сводку, а байты под ней говорят другое, честные подписанты выдают действительную вредоносную подпись. Слепая подпись превращает комитет M-of-N в резиновую печать M-of-N, и никакой порог от этого не защищает.

Лёгкие клиенты и оптимистичная проверка ставят на разное

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

Проверка лёгким клиентом помещает клиент исходной цепи внутрь цепи назначения. Цепь назначения хранит консенсусное состояние исходной цепи и проверяет, доказано ли заявленное событие относительно него. В IBC каждая сторона соединения использует лёгкий клиент другой цепи, чтобы проверять входящие сообщения, так что допущение сводится к консенсусу исходной цепи плюс корректности кода клиента. Новая версия IBC говорит прямо: клиент — это просто модель проверки, и с тем же успехом он может быть лёгким клиентом, мультиподписью или верификатором доказательств. Допущение задаёт не название, а тип клиента.

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

Бесплатных семей тут нет, и издержки структурные, а не случайные. Лёгкие клиенты стоят газа и разработки для каждой пары цепей, а ошибка в клиенте — это ошибка в самом правиле. Оптимистичные конструкции подключаются дёшево, но заставляют каждого честного пользователя пересидеть задержку, выбранную разработчиком. Документация Ethereum называет обе издержки прямо: ограничения по связности у мостов на лёгких клиентах и по скорости у оптимистичных.

Повтор — это действительное сообщение, засчитанное дважды

Сообщение моста — это разрешение. Повтор как атака состоит в том, что действительно выданное разрешение предъявляют снова: второй раз в том же месте или первый раз там, где оно вообще не должно было действовать. Ничего не подделывается — просто те же действительные байты используются повторно.

Канонический ответ есть в истории самого Ethereum. EIP-155 вкладывает chain ID в данные, которые хешируются и подписываются, поэтому подпись, сделанная для одной цепи, не проходит проверку на другой. Обратите внимание, как это внедрялось: старый формат из шести элементов остался действительным, то есть защита включается по выбору подписывающего, а не гарантируется форматом.

Для структурированных сообщений, которые мосты и передают, EIP-712 определяет разделитель домена. Он может нести имя, версию, chain ID и адрес проверяющего контракта, а также salt как разделитель на крайний случай; стандарт добавляет, что кошелёк должен отказаться подписывать, если chain ID не совпадает с цепью, на которой пользователь находится сейчас. Другая цепь, другой контракт, другая версия — другое сообщение. Вот что разделение доменов означает на практике: адресат попадает внутрь того, что подписано.

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

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

Риски мостов по допущениям о доверии: внешние наборы валидаторов, пороги мультиподписи, лёгкие клиенты и оптимистичная проверка, повтор сообщений и ключи обновления

Ключи обновления стоят выше всех остальных допущений

Всё сказанное выше описывает правило, которое мост применяет сегодня. Ключ обновления решает, кто заменит это правило завтра.

Большинство контрактов мостов — прокси, а ERC-1967 стандартизирует, где прокси хранит свою проводку: один слот для адреса реализации, которой он делегирует, другой — для адреса admin, которому разрешено эту реализацию менять. Одна транзакция от admin направляет прокси на новый код, а новый код волен определять действительность как угодно.

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

Утешение в том, что как раз это проверяется. Стандарт указывает, куда смотреть, и требует, чтобы изменения этих слотов порождали события: Upgraded при смене реализации и AdminChanged при смене admin. Прочитайте слот admin. Посмотрите, что в нём: обычный внешний адрес, мультиподпись или таймлок; а если таймлок, то какова задержка и кто вправе отменить.

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

Итог

Риски моста раскладываются чисто, стоит спросить, кто проверяет. Внешний набор валидаторов — отдельная система, порог которой и есть её бюджет безопасности, и держится этот порог только если стоящие за ним ключи способны отказать независимо. Лёгкие клиенты переносят допущение на консенсус исходной цепи и корректность кода клиента; оптимистичные конструкции — на то, что хотя бы один наблюдатель останется живым и незаблокированным всё окно. Защита от повтора — отдельное требование: адресат должен входить в подписанное, а каждому сообщению нужен порядковый номер или квитанция. Над всем этим стоит ключ обновления, заменяющий остальное одной транзакцией. Именно эти пять ответов, а не бренд в интерфейсе, вы и берёте на доверие.

Дисклеймер: эта статья — образовательный материал Bitbase Academy, только для информационных целей. Она не является инвестиционным, торговым, налоговым или финансовым советом. Криптоактивы волатильны — оценивайте риски самостоятельно. Написано в августе 2026 года; сверяйтесь с актуальной официальной информацией.