Важливість безпеки крос-ланцюгового протоколу та недоліки LayerZero

Проблеми безпеки крос-ланцюгових протоколів в останні роки викликали великий інтерес. Судячи з суми збитків, завданих безпековими інцидентами на різних блокчейнах за останні два роки, збитки, пов'язані з крос-ланцюговими протоколами, займають перше місце. Важливість і терміновість вирішення проблем безпеки крос-ланцюгових протоколів навіть перевищує плани масштабування Ethereum. Взаємодія між крос-ланцюговими протоколами є внутрішньою вимогою зв'язування екосистеми Web3 в мережу. Такі протоколи зазвичай отримують величезне фінансування, їх загальна заблокована вартість (TVL) та кількість угод також зростає під впливом жорсткого попиту. Однак, через низький рівень впізнаваності цих протоколів серед населення, важко точно оцінити їхній рівень безпеки.

Давайте спершу розглянемо типову архітектуру дизайну крос-ланцюгового продукту. У процесі комунікації між Chain A та Chain B конкретні операції виконує Relayer, в той час як Oracle здійснює контроль над Relayer. Перевагою такої архітектури є те, що вона уникає необхідності традиційним способом використовувати третій ланцюг (зазвичай не розгортається dApp) для виконання алгоритму консенсусу та складного процесу верифікації кількох вузлів, тому вона може надати кінцевим користувачам досвід "швидкого крос-ланцюга". Завдяки легкості архітектури, невеликій кількості коду та можливості безпосереднього використання готового Chainlink як Oracle, такі проекти легко швидко запускати, але одночасно їх також легко імітувати, технічний бар'єр практично нульовий.

Однак ця архітектура має принаймні дві проблеми:

1. Спрощення процесу верифікації десятків вузлів до єдиної верифікації Oracle значно знижує рівень безпеки.

2. Після спрощення до єдиного підтвердження, необхідно припустити, що Relayer та Oracle є взаємно незалежними. Це припущення довіри важко підтримувати постійно, воно не відповідає рідній ідеї криптовалюти і не може принципово гарантувати, що обидва не змовляться на злочин.

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

Навіть якщо дозволити декільком сторонам запускати реле, це не може повністю вирішити вищезазначені проблеми. По-перше, децентралізація не означає лише збільшення кількості операторів або те, що кожен може підключитися. Попит завжди був бездозволеним, і перетворення пропозиції на бездозволену не є епохальною зміною, це лише зміна на ринку, яка не має великого відношення до безпеки самого продукту. Реле деяких протоколів за суттю лише відповідають за пересилання інформації, так само як і Oracle, вони належать до довірених третіх сторін. Спроби підвищити безпеку крос-ланцюга, збільшивши кількість довірених суб'єктів з 1 до 30, є марними, адже це не змінює характеристики продукту і може викликати нові проблеми.

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

Якщо якийсь протокол не може ділитися безпекою, як Layer1 або Layer2, то його не можна називати інфраструктурою. Інфраструктура називається "базовою", тому що вона може ділитися безпекою. Якщо якийсь проект самопроголошується інфраструктурою, то він повинен забезпечувати однакову безпеку для всіх своїх екосистемних проектів, тобто всі екосистемні проекти повинні ділитися безпекою цієї інфраструктури. Тому, якщо говорити точно, деякі крос-ланцюгові протоколи не є інфраструктурою, а є посередницьким програмним забезпеченням. Розробники застосунків, які підключаються до цього посередницького SDK/API, дійсно можуть вільно визначати свої стратегії безпеки.

Деякі дослідницькі групи зазначили, що припущення, що власник застосунку (або особа, яка має приватний ключ) не буде чинити зло, є неправильним. Якщо зловмисник отримає доступ до конфігурації крос-ланцюг протоколу, він може змінити oracle та реле з компонентів за замовчуванням на компоненти, контрольовані ним, що дозволить маніпулювати смарт-контрактами, які використовують цей механізм, що призведе до крадіжки активів користувачів.

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

Оглядаючись на джерела біткоїна, ми можемо побачити основну ідею, запропоновану Сатоші Накамото в білому документі: повністю децентралізована система електронних грошей, що дозволяє онлайн-платежі безпосередньо від однієї сторони до іншої, без участі фінансових установ. Ця ідея підкреслює децентралізацію та відсутність довіри, що стало метою, яку всі розробники інфраструктури прагнули досягти.

Однак деякі крос-ланцюгові протоколи в реальному функціонуванні вимагають, щоб ролі Relayer і Oracle не змовлялися на шкоду, а також вимагають, щоб користувачі, які використовують цей протокол для створення додатків, розглядалися як надійні треті сторони. Учасники "мультипідпису" є попередньо визначеними привілейованими ролями. Що більш важливо, під час всього крос-ланцюгового процесу не було створено жодних доказів шахрайства або доказів дійсності, не кажучи вже про те, щоб ці докази були записані в ланцюг і перевірені в ланцюзі. Таким чином, ці протоколи насправді не відповідають "консенсусу Сатоші Накамото" і не можуть вважатися справжніми децентралізованими та бездоказовими системами.

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

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