Виклики безпеки крос-ланцюгових протоколів та важливість справжньої Децентралізації
В останні роки крос-ланцюгові протоколи відіграють все більш важливу роль в екосистемі блокчейн. Однак ці протоколи також стикаються з серйозними викликами безпеки. За даними за останні два роки, збитки від безпекових інцидентів, спричинених крос-ланцюговими протоколами, займають перше місце серед усіх видів безпекових інцидентів у блокчейн, а їхня важливість і терміновість навіть перевищують рішення щодо масштабування Ethereum.
Інтероперабельність між крос-ланцюговими протоколами є внутрішньою потребою мережі Web3. Такі протоколи зазвичай можуть отримувати величезне фінансування, їх загальна заблокована вартість (TVL) та обсяги торгівлі також постійно зростають. Проте, рівень безпеки цих протоколів не є добре зрозумілим для широкої аудиторії, що ускладнює точну оцінку їх ризиків.
Давайте спочатку проаналізуємо типову архітектуру крос-ланцюгового зв'язку. У цій архітектурі зв'язок між Chain A і Chain B виконується Relayer, а Oracle відповідає за нагляд за Relayer. Перевагою цього дизайну є уникнення складностей традиційних методів, що вимагають третього ланцюга (як правило, не розгортається dApp) для виконання алгоритму консенсусу та багатонодової перевірки, що забезпечує користувачам "швидкий крос-ланцюг" досвід. Завдяки легкій архітектурі, невеликій кількості коду та можливості використовувати готові рішення Oracle (такі як Chainlink), такі проекти легко швидко запускати, але одночасно їх також легко наслідувати, технологічний бар'єр є низьким.
Однак ця архітектура має принаймні дві основні проблеми:
Спростити багатонодальну верифікацію до єдиної верифікації Oracle, що значно знижує коефіцієнт безпеки.
Спрощена валідаційна модель повинна припускати, що Relayer та Oracle є незалежними, але ця довірча припущення важко підтримувати постійно, не відповідає криптоорієнтованій концепції і не може в принципі запобігти змові між сторонами.
Деякі крос-ланцюгові рішення використовують цей "суперлегкий" режим. Як легке крос-ланцюгове рішення незалежного типу безпеки, вони відповідають лише за передачу повідомлень, але не несуть відповідальності за безпеку застосунків і не мають можливості взяти на себе таку відповідальність.
Дехто може запитати, чи відкриття Relayer, що дозволяє більшій кількості учасників управляти релейерами, може вирішити зазначені вище проблеми? Однак просто збільшення кількості операторів не є рівнозначним децентралізації. Децентралізація не лише означає збільшення кількості учасників або відкритість доступу; це лише зміна на ринку, яка має мало спільного із безпекою самого продукту. У деяких рішеннях Relayer за суттю є лише посередником, відповідальним за пересилання інформації, подібно до Oracle, і обидва є надійними третіми сторонами. Намагатися підвищити безпеку крос-ланцюга шляхом збільшення кількості довірених суб'єктів є марним, оскільки це не лише не змінює суттєві характеристики продукту, але й може ввести нові проблеми.
Якщо крос-ланцюговий проект дозволяє змінювати конфігурацію своїх вузлів, зловмисник може замінити їх на вузли, які він контролює, що дозволяє підробляти будь-які повідомлення. У такому випадку проекти, які використовують цей протокол, можуть зіткнутися з величезними ризиками безпеки, особливо в складних ситуаціях. У величезних системах, якщо хоча б один елемент буде замінено, це може викликати ланцюгову реакцію. Деякі крос-ланцюгові протоколи самі по собі можуть не вирішувати цю проблему, і якщо станеться інцидент безпеки, вони можуть перекласти відповідальність на зовнішні додатки.
Якщо проект, що називає себе "інфраструктурою", не може ділитися безпекою як Layer 1 або Layer 2, то його не можна по-справжньому назвати інфраструктурою. Інфраструктура є "базовою", оскільки вона може забезпечити однорідну безпеку для всієї екосистеми. Тому деякі крос-ланцюгові протоколи можуть бути точніше описані як проміжне програмне забезпечення (Middleware), а не інфраструктура (Infrastructure).
Деякі безпекові команди вказали на потенційні ризики деяких крос-ланцюгових протоколів. Наприклад, є дослідження, які показують, що якщо власник програми (або особа, яка має приватний ключ) отримає доступ до конфігурації протоколу, він може змінити орієнтири і ретранслятори на компоненти, які контролює, що дозволяє маніпулювати крос-ланцюговими транзакціями. Крім того, деякі ретранслятори протоколів можуть мати критичні вразливості, хоча наразі вони можуть бути захищені багатопідписом, все ще існує ризик, що їх можуть використовувати внутрішні особи або члени команди з відомими особистостями.
При оцінці крос-ланцюгових протоколів ми повинні повернутися до коренів технології блокчейн. Основна ідея, викладена в білому папері Біткоїна «Біткоїн: система електронних грошей з рівними можливостями», а саме децентралізація та безумовна довіра, стала метою, яку спільно прагнуть досягти всі розробники інфраструктури. Крос-ланцюгові протоколи, які не відповідають цим характеристикам, можуть бути важко названі справжніми децентралізованими крос-ланцюговими протоколами.
Справжній децентралізований крос-ланцюговий протокол має здатність реалізувати прямий зв'язок між сторонами без необхідності покладатися на будь-які надійні треті сторони. Він повинен мати здатність до протидії атакам та генерувати перевіряємі докази шахрайства або докази дійсності. Ці докази мають можливість бути записаними в блокчейн та перевіреними на ланцюзі, щоб забезпечити безпеку та надійність системи.
Будівництво справжнього Децентралізація крос-ланцюг протоколу є складним завданням. Деякі інноваційні підходи, такі як використання технології нульових знань, можуть надати нові ідеї для вирішення цих проблем. Однак ключовим є те, що команда розробників протоколу повинна усвідомлювати існуючі виклики безпеки та активно шукати способи їх покращення, а не просто заперечувати існування проблем.
Сьогодні, коли технологія блокчейн постійно розвивається, нам потрібно більш обережно та відповідально оцінювати та проектувати крос-ланцюгові протоколи. Лише реалізувавши дійсну децентралізацію та довіру, можна побудувати безпечну, надійну та таку, що має довгострокову цінність, крос-ланцюгову інфраструктуру, що сприятиме здоровому розвитку всієї екосистеми блокчейн.
Переглянути оригінал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
8 лайків
Нагородити
8
4
Поділіться
Прокоментувати
0/400
BlockchainTherapist
· 12год тому
Заблокований протокол, давайте поговоримо про безпеку!
Переглянути оригіналвідповісти на0
MetaverseHermit
· 13год тому
крос-ланцюг被黑一个就够麻烦了
Переглянути оригіналвідповісти на0
Lonely_Validator
· 13год тому
Менше переворотів, тим краще. Рано чи пізно це станеться.
Крос-ланцюг протокол безпеки викликів: справжня Децентралізація важливість та реалізація
Виклики безпеки крос-ланцюгових протоколів та важливість справжньої Децентралізації
В останні роки крос-ланцюгові протоколи відіграють все більш важливу роль в екосистемі блокчейн. Однак ці протоколи також стикаються з серйозними викликами безпеки. За даними за останні два роки, збитки від безпекових інцидентів, спричинених крос-ланцюговими протоколами, займають перше місце серед усіх видів безпекових інцидентів у блокчейн, а їхня важливість і терміновість навіть перевищують рішення щодо масштабування Ethereum.
Інтероперабельність між крос-ланцюговими протоколами є внутрішньою потребою мережі Web3. Такі протоколи зазвичай можуть отримувати величезне фінансування, їх загальна заблокована вартість (TVL) та обсяги торгівлі також постійно зростають. Проте, рівень безпеки цих протоколів не є добре зрозумілим для широкої аудиторії, що ускладнює точну оцінку їх ризиків.
Давайте спочатку проаналізуємо типову архітектуру крос-ланцюгового зв'язку. У цій архітектурі зв'язок між Chain A і Chain B виконується Relayer, а Oracle відповідає за нагляд за Relayer. Перевагою цього дизайну є уникнення складностей традиційних методів, що вимагають третього ланцюга (як правило, не розгортається dApp) для виконання алгоритму консенсусу та багатонодової перевірки, що забезпечує користувачам "швидкий крос-ланцюг" досвід. Завдяки легкій архітектурі, невеликій кількості коду та можливості використовувати готові рішення Oracle (такі як Chainlink), такі проекти легко швидко запускати, але одночасно їх також легко наслідувати, технологічний бар'єр є низьким.
Однак ця архітектура має принаймні дві основні проблеми:
Деякі крос-ланцюгові рішення використовують цей "суперлегкий" режим. Як легке крос-ланцюгове рішення незалежного типу безпеки, вони відповідають лише за передачу повідомлень, але не несуть відповідальності за безпеку застосунків і не мають можливості взяти на себе таку відповідальність.
Дехто може запитати, чи відкриття Relayer, що дозволяє більшій кількості учасників управляти релейерами, може вирішити зазначені вище проблеми? Однак просто збільшення кількості операторів не є рівнозначним децентралізації. Децентралізація не лише означає збільшення кількості учасників або відкритість доступу; це лише зміна на ринку, яка має мало спільного із безпекою самого продукту. У деяких рішеннях Relayer за суттю є лише посередником, відповідальним за пересилання інформації, подібно до Oracle, і обидва є надійними третіми сторонами. Намагатися підвищити безпеку крос-ланцюга шляхом збільшення кількості довірених суб'єктів є марним, оскільки це не лише не змінює суттєві характеристики продукту, але й може ввести нові проблеми.
Якщо крос-ланцюговий проект дозволяє змінювати конфігурацію своїх вузлів, зловмисник може замінити їх на вузли, які він контролює, що дозволяє підробляти будь-які повідомлення. У такому випадку проекти, які використовують цей протокол, можуть зіткнутися з величезними ризиками безпеки, особливо в складних ситуаціях. У величезних системах, якщо хоча б один елемент буде замінено, це може викликати ланцюгову реакцію. Деякі крос-ланцюгові протоколи самі по собі можуть не вирішувати цю проблему, і якщо станеться інцидент безпеки, вони можуть перекласти відповідальність на зовнішні додатки.
Якщо проект, що називає себе "інфраструктурою", не може ділитися безпекою як Layer 1 або Layer 2, то його не можна по-справжньому назвати інфраструктурою. Інфраструктура є "базовою", оскільки вона може забезпечити однорідну безпеку для всієї екосистеми. Тому деякі крос-ланцюгові протоколи можуть бути точніше описані як проміжне програмне забезпечення (Middleware), а не інфраструктура (Infrastructure).
Деякі безпекові команди вказали на потенційні ризики деяких крос-ланцюгових протоколів. Наприклад, є дослідження, які показують, що якщо власник програми (або особа, яка має приватний ключ) отримає доступ до конфігурації протоколу, він може змінити орієнтири і ретранслятори на компоненти, які контролює, що дозволяє маніпулювати крос-ланцюговими транзакціями. Крім того, деякі ретранслятори протоколів можуть мати критичні вразливості, хоча наразі вони можуть бути захищені багатопідписом, все ще існує ризик, що їх можуть використовувати внутрішні особи або члени команди з відомими особистостями.
При оцінці крос-ланцюгових протоколів ми повинні повернутися до коренів технології блокчейн. Основна ідея, викладена в білому папері Біткоїна «Біткоїн: система електронних грошей з рівними можливостями», а саме децентралізація та безумовна довіра, стала метою, яку спільно прагнуть досягти всі розробники інфраструктури. Крос-ланцюгові протоколи, які не відповідають цим характеристикам, можуть бути важко названі справжніми децентралізованими крос-ланцюговими протоколами.
Справжній децентралізований крос-ланцюговий протокол має здатність реалізувати прямий зв'язок між сторонами без необхідності покладатися на будь-які надійні треті сторони. Він повинен мати здатність до протидії атакам та генерувати перевіряємі докази шахрайства або докази дійсності. Ці докази мають можливість бути записаними в блокчейн та перевіреними на ланцюзі, щоб забезпечити безпеку та надійність системи.
Будівництво справжнього Децентралізація крос-ланцюг протоколу є складним завданням. Деякі інноваційні підходи, такі як використання технології нульових знань, можуть надати нові ідеї для вирішення цих проблем. Однак ключовим є те, що команда розробників протоколу повинна усвідомлювати існуючі виклики безпеки та активно шукати способи їх покращення, а не просто заперечувати існування проблем.
Сьогодні, коли технологія блокчейн постійно розвивається, нам потрібно більш обережно та відповідально оцінювати та проектувати крос-ланцюгові протоколи. Лише реалізувавши дійсну децентралізацію та довіру, можна побудувати безпечну, надійну та таку, що має довгострокову цінність, крос-ланцюгову інфраструктуру, що сприятиме здоровому розвитку всієї екосистеми блокчейн.