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

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

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

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

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

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

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

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

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

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

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

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