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

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

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

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

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

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

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

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

Щодо проектів, які стверджують, що є інфраструктурою, якщо вони не можуть забезпечити спільну безпеку, як Layer 1 або Layer 2, тоді така позиція "інфраструктури" викликає сумніви. Справжня інфраструктура є "основою" тому, що вона забезпечує єдину безпеку для всієї екосистеми. Отже, більш точна позиція деяких крос-ланцюгових протоколів може бути проміжним програмним забезпеченням (Middleware), а не інфраструктурою.

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

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

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

Справжній децентралізований крос-ланцюговий протокол має бути здатним генерувати доказ про шахрайство або доказ дійсності протягом усього процесу крос-ланцюга і завантажувати ці докази в ланцюг для перевірки. Лише так можна досягти справжньої децентралізації та недовіри.

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