Обговорення викликів децентралізації крос-ланцюгового протоколу

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

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

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

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

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

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

Існує думка, що відкриття ретрансляторів і дозволення більшій кількості учасників здійснювати їх, може підвищити ступінь Децентралізації. Але просте збільшення кількості операторів не є еквівалентом Децентралізації; цей підхід лише забезпечує бездозвільний доступ, а не справжню Децентралізацію. Збільшення кількості надійних суб'єктів з 1 до 30 не може кардинально змінити характеристики продукту або суттєво підвищити безпеку крос-ланцюга.

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

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

Справжня інфраструктура повинна забезпечувати послідовну безпеку для всіх проектів в її екосистемі. Якщо проект стверджує, що він є інфраструктурою, він повинен, як і інша інфраструктура, надавати спільну безпеку для всіх екосистемних проектів. Таким чином, деякі з так званих "Layer 0" протоколів можуть бути точніше описані як проміжне програмне забезпечення (Middleware), а не справжня інфраструктура (Infrastructure).

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

Оглядаючи білий папір Bitcoin, ми можемо побачити, що основною характеристикою консенсусу Сатоші Накамото є усунення наявності надійних третіх сторін, реалізація бездокументності (Trustless) та децентралізації (Decentralized). Протокол крос-ланцюгової комунікації в основному має бути схожим на Bitcoin, це також система рівний до рівного, яка дозволяє одній стороні безпосередньо відправляти з ланцюга A до іншої сторони на ланцюзі B, не вдаючись до будь-якої надійної третьої сторони.

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

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