Ризики мостів: валідатори, мультипідпис і повтор повідомлень

2026-08-24

Міст нічого не переносить. Він робить твердження на одному ланцюзі й переконує другий ланцюг діяти за ним, і будь-який злам моста — це той другий ланцюг, що повірив твердженню, яке мав відхилити. Тому ризики мостів корисно сортувати за припущенням про довіру, а не за назвою продукту: чому вірить ланцюг призначення і що потрібно, аби він повірив у неправду. Ця стаття проходить п'ять структурних джерел — від зовнішніх наборів валідаторів до ключів оновлення.

Питання, яке впорядковує будь-який міст

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

Механіка майже не змінюється. На вихідному ланцюзі щось стається. Якась сторона засвідчує, що це сталося. Контракт на ланцюзі призначення звіряє це свідчення з правилом і, якщо воно проходить, розблоковує або карбує. Усе, чого хоче зловмисник, лежить по той бік цього правила.

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

Розмір грошей робить цей обмін безжальним. Станом на серпень 2022 року Chainalysis нарахувала 13 окремих зламів крос-чейн мостів приблизно на 2 мільярди доларів — близько 69% усього вкраденого в крипті того року до того моменту. Мости притягують атаки, бо збирають заставу рівно в тій точці, де перевіряється одне правило.

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

Зовнішній набір валідаторів — це система, яку ви не перевіряли

Найпоширеніша довірена конструкція ставить між двома ланцюгами набір із N сторін. Вони стежать за вихідним ланцюгом, підписують свідчення про те, що подія відбулася, а контракт призначення приймає його, якщо перевіряються щонайменше M із цих підписів. Жодної іншої думки про дійсність контракт не має.

Наслідок прямолінійний: хто володіє M ключами, той може карбувати. Візьмімо набір із 9 сторін і поріг 5. Зловмиснику з 5 ключами не потрібні ні помилка в контракті, ні слабкість жодного з ланцюгів, ні додаткова перевірка. Поки він спорожнює міст, міст робить рівно те, для чого його збудували.

Зверніть увагу, яку безпеку ви насправді купуєте. Набір валідаторів — це власна система з власними операторами, машинами та стимулами, і від ланцюгів, які він з'єднує, вона не успадковує нічого. Міст, що його перевіряє зовнішній набір, міцний рівно настільки, наскільки міцний цей набір, і не більше — хоч якими великими були б мережі з обох боків.

Отже, варті уваги питання — це питання про склад. Хто ці N і чи їх узагалі розкрито? Це окремі організації чи одна організація з дев'ятьма машинами? Чому дорівнює M? Чи мають учасники щось на кону, що можна в них забрати, якщо вони підпишуть хибне повідомлення? І хто може змінювати склад, адже набір, який переписує один ключ, — це односигнатурний міст у костюмі комітету.

Поріг має значення лише тоді, коли ключі відмовляють незалежно

M з N — це твердження про незалежність, а не арифметика. П'ять із дев'яти відчутно важчі за один з одного лише тоді, коли ці дев'ять ключів можуть відмовити дев'ятьма не пов'язаними між собою способами.

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

Підняти поріг це не лікує, і коштує воно недешево. За високого M втрата кількох ключів залишає міст без змоги підписати бодай щось: нічого не вкрадено, але нічого й не рухається, а той, чиї активи опинилися не з того боку, чекає. Кожен поріг — це вибір між надто легко вкрасти та надто легко заморозити.

Поверхня підпису заслуговує на не меншу увагу, ніж зберігання. Підписанти схвалюють дані, яких здебільшого не можуть прочитати, тож якщо інтерфейс показує привітне резюме, а байти під ним кажуть інше, чесні підписанти видають дійсний зловмисний підпис. Сліпий підпис перетворює комітет M з N на гумову печатку M з 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 на цю тему:

- Розв'язання стейкінгу та виведення: як повернути токени

- Децентралізація валідаторів: коефіцієнт Накамото, різноманіття клієнтів і концентрація

- Економіка валідаторів: комісія, дохід від комісій і беззбитковість

Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на серпень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.