Дізнайтеся більше про те, навіщо Rollups потрібен комітет з безпеки?

ОРИГІНАЛЬНИЙ АВТОР: ПАТРІК МАККОРРІ

Оригінальна збірка: Luffy, Foresight News

Будь-яка база даних, яка взаємодіє з криптоактивами, одного разу вибере Rollup як стек технологій. Є низка вагомих причин для прийняття такого рішення розробниками:

• Аудит в режимі реального часу
• Сертифікат платоспроможності за замовчуванням
• Умовне депонування коштів користувача не є обов’язковим
• Чесний учасник партії захищає всю систему

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

Навіть якщо вся система знаходиться в автономному режимі, користувачі можуть повернути свої кошти самостійно.

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

Потрібно докласти багато зусиль, щоб змусити ролап працювати правильно.

А як щодо мультипідписів?

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

Отже, кого цікавлять Rollups? десь на КТ.

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

Обов’язки Комітету з безпеки

Мультипідпис — це технічний термін, який позначає систему, яка вимагає кількох підписантів для авторизації дії. Наприклад, K з N підписантів заповнюють цифровий підпис, щоб транзакція була дозволена.

У контексті зведення мультипідпис часто називають комітетом з безпеки, де підписанти отримують повноваження оновлювати всі пов’язані смарт-контракти.

Давайте подивимося на Раду Безпеки в Арбітражі (оскільки я з нею добре знайомий), щоб отримати уявлення про типи обов’язків, які може мати ця організація:

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

Звичайно, найголовніше, що першим обов’язком комітету з безпеки є реагування на надзвичайні ситуації та оперативні дії для захисту коштів користувачів.

Члени комітету з безпеки повинні бути людьми, які заслуговують на довіру.

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

Виберіть правильний поріг мультипідпису

Є два важливі фактори, які слід враховувати при прийнятті рішення про створення комітету з безпеки:

• Скільки підписантів?
• Яка мінімальна кількість підписантів необхідна для схвалення дії?
• Це може здатися тривіальним питанням, адже це всього лише два числа, але є баланс, який необхідно враховувати:
• Порушення безпеки: K учасників можуть вступати в змову з метою зміни смарт-контрактів і крадіжки коштів користувачів.
• Активне порушення: N-K+ 1 учасники вступають у змову, щоб запобігти будь-яким змінам у смарт-контракті, особливо якщо знайдено критичну вразливість.

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

Розглянемо конкретний приклад. Скажімо, поріг встановлено на 9/10, коли 9 підписантів мають підписати повідомлення. Це суворий поріг безпеки, оскільки 9 підписантів повинні вступити в змову, щоб вкрасти кошти. Недоліком, однак, є те, що будь-які два підписанти можуть заблокувати будь-які дії в надзвичайній ситуації. Наприклад, якщо два підписанти полетять трансатлантичним рейсом далеко, Комітет з безпеки не зможе виконувати свої обов’язки.

Звичайно, якщо поріг безпеки низький, скажімо, 2/10, то для того, щоб кошти користувача були вкрадені, потрібно лише двом підписантам вступити в змову (або скомпрометовано приватний ключ).

Сприйняття цілісності людини, ймовірно, з часом зміниться

Вибір відповідного порогу – це скоріше соціальне питання, ніж технічне, і я думаю, що це більше мистецтво, ніж наука. Безпека значною мірою залежить від цілісності особи, яка підписала документ. Як ми побачимо незабаром, існують способи знизити довіру до мультипідпису, але це пов’язано з низкою компромісів.

Член Комітету з безпеки

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

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

• Етап розробки роллапа,
• Для захисту особистої безпеки членів,
• Вважають, що анонімність є найкращим варіантом захисту коштів користувачів.
• З іншого боку, є три Rollup-проекти, які публічно оголосили про своє членство в комітеті з безпеки:
• Арбітраж: Підписанти обираються публічно, і поточний список можна переглянути на Tally. З проектом Arbitrum пов’язані лише три підписанти (два з Offchain Labs і один з Arbitrum Foundation).
• Базовий: мультипідпис 2/2, один контролюється базою, а інший – оптимізмом.
• Polygon zkEVM: Ще не реалізовано, але вони оголосили, що оновлять свій мультипідпис до 10/13, який включає двох учасників з Polygon Labs і одного консультанта з Polygon Labs.
• zkSync Lite: zkSync Lite слід відрізняти від ZkSync Era, комітет з безпеки якої публічно оголошений і не включає прямих афіліатів з проекту Rollup (за винятком інвесторів в zkSync).

В Arbitrum і в майбутньому Polygon лише кілька підписантів безпосередньо пов’язані з проектом Rollup, і їх кількість досить мала, щоб гарантувати, що афілійовані особи не зможуть вступити в змову, щоб заблокувати дії, вжиті Комітетом з безпеки. У zkSync Lite, крім інвесторів zkSync, призначають підписантів, які не залежать від проєкту.

У будь-якому випадку Rollup надає великого значення підписувачам, які не мають безпосереднього відношення до проекту.

Однак, схоже, що немає консенсусу щодо того, що являє собою хороший мультипідпис, що підводить нас до кількох питань дизайну:

• Чи повинні бути дозволені анонімні учасники?
• Чи повинні члени Церкви бути з різних географічних регіонів?
• Членами повинні бути фізичні особи чи корпорації?
• Чи повинні члени призначатися чи обиратися?
• Скільки учасників з однієї компанії (або країни) має бути дозволено?
• Чи існує мінімальний розмір і поріг, які вважаються доцільними?

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

P.S. Шість членів Комітету з безпеки Arbitrum наразі попередньо призначені, але вони будуть замінені на березневих виборах.

Послабити повноваження Комісії

Поки що ми розглянули лише один комітет, який має повноваження негайно оновити смарт-контракт, але є способи обмежити повноваження комітету:

Затримка в часі. Усі дії, санкціоновані Комісією, не будуть виконуватися та набудуть чинності до закінчення часу.

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

• Доставити повідомлення з L2 на L1 (тобто вивести гроші),
• Завершіть сортування транзакцій, що очікують на розгляд,
• Заповніть нові контрольно-пропускні пункти/сертифікати,
• Приймайте нові зведені дані (тобто транзакції, що очікують на розгляд).

Обхідна комісія (знята). Покиньте комітет і покладіться на інший механізм управління, наприклад, DAO, щоб схвалити оновлення.

Це, звичайно, обмежує здатність Комісії діяти швидко та її здатність ефективно реагувати на надзвичайні ситуації, які загрожують коштам користувачів.

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

Наприклад, CVE-2018-17144 у BTC спочатку рекламувався як уразливість DDoS-атак у спробі приховати більш серйозну вразливість до інфляції токенів. Швидкість оновлення має вирішальне значення, щоб запобігти його використанню.

Оцініть захисні механізми лише паузи

Розглянемо потенційний сценарій активного використання вразливості зловмисником:

• Шкідливі повідомлення L2 → L1. Зловмисник може створювати довільні повідомлення, що походять від смарт-контракту, у зведенні та пересилати повідомлення смарт-контракту на ETH через власний кросчейн-міст.
• Неприпустимі переходи станів. Зловмисник може виконати транзакцію у зведенні, яка порушує правила функції переходу станів і, як правило, повинна вважатися недійсною.
• Лазівки для виведення. Зловмисник може вивести кошти з рідного кросчейн-мосту, просто здійснивши транзакцію на ETH Іклі (рівень 1).

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

Ми оцінимо лише можливість призупинення роботи системи та ступінь призупинення роботи системи.

У випадку зі шкідливими повідомленнями L2 → L1 функція паузи може пом’якшити атаку, не заважаючи торговій діяльності. Комітет має призупинити обмін повідомленнями та/або доопрацювати функціонал нових пунктів пропуску. Існує аргумент, що перед виконанням повідомлення L2 → L1 має бути часова затримка, щоб комітет встиг виявити помилки та відреагувати на надзвичайні ситуації.

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

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

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

Це пов’язано з тим, що певні системи, такі як швидкі кросчейн-мости, які переводять кошти з одного ролапу в інший, можуть санкціонувати переказ коштів, коли вважають, що транзакції зведення (включаючи недійсні транзакції) відсортовані. У цьому прикладі це може дозволити зловмиснику використати протокол DeFi у Rollup, а потім швидко переказати кошти, перевівши їх на інший Rollup через швидкий крос-чейн міст.

На той час, коли комісія виправить порушення та відновить недійсну транзакцію, шкода може бути вже завдана. LP як у протоколах DeFi, так і в кросчейн-мостах можуть нести витрати на атаку.

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

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

Наприклад, якщо кросчейн-міст повідомлення L2→L1 призупинено, результати голосування DAO не можуть бути передані зі зведеного до рідного кросчейн-мосту на ETH, і має бути альтернативний спосіб для DAO надіслати схвалення та виконати оновлення.

Поступове припинення роботи Ради Безпеки

У спільноті є ті, хто вважає, що комітет з безпеки має бути скасований, але, на мою думку, це породжує дві проблеми:

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

Можливості відновлення обмежені. Без комітету з безпеки громада не може дати відсіч нападникам. Єдиний доступний варіант – запустити паралельний злом білих капелюхів і, сподіваюся, повернути частину коштів.

На мою думку, комітети з безпеки завжди будуть потрібні, але повноваження, які їм надаються, потрібно поступово зменшувати.

З огляду на це, питання дизайну має бути таким:

Як ми можемо змусити комітет з безпеки призупинити роботу системи з мінімальним впливом на користувачів, дозволяючи широкій спільноті брати участь у прийнятті рішень про те, як виправити помилки та повторно активувати систему?

Іншими словами, нам потрібна програма, яка дійсно дозволить спільноті втрутитися і відновити систему, а потім обмежити повноваження Ради Безпеки ООН.

У блокчейн-просторі рівня 1 до спільноти дійсно можна дістатися безпосередньо, використовуючи форки, що активуються користувачем, але цей метод не працює для смарт-контрактів на ETH квадратах (таких як Rollups), оскільки немає необхідності форкувати весь ETH. У деяких випадках спільнота ETH може колективно вирішити зберегти Rollup, як, наприклад, TheDAO у 2016 році, але Rollup ніколи не повинен покладатися на такий результат або очікувати його.

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

Як згадувалося раніше, якщо Rollup делегує свою безпеку DAO, то має бути реалізація, яка дозволяє DAO голосувати безпосередньо на ETH. Це дуже складно, особливо якщо протокол голосування існує в Rollup.

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

Навіщо турбуватися про зведення, якщо у вас мультипідписи?

Ми витратили досить багато часу на те, щоб зрозуміти обов’язки, дизайн і потреби комітету з безпеки, але важливо повернутися до початкового питання в цій статті:

Rollup – це просто мультипідпис?

Відповідь – ні.

Щоб зрозуміти чому, краще зробити крок назад і зрозуміти, що насправді хоче зробити блокчейн-система.

Протокол блокчейну — це інструмент, який дозволяє користувачам обчислити копію бази даних і бути впевненими, що вони мають таку саму базу даних, як і всі інші.

З огляду на це, будь-яка блокчейн-система має два компоненти:

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

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

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

Системи управління відповідають за реалізацію людського втручання, і за ці роки з’явилося кілька підходів:

• Тоталітарні політичні партії: односторонні партії можуть самостійно вирішувати, як модернізувати систему (багато проектів, включаючи BTC, починалися саме таким чином).
• Приблизний консенсус: Більшість учасників заявили, що вони готові розгорнути оновлення, визначити день знаменування, а потім виконати оновлення в день позначки (BTC/ETH).
• Угода про голосування: Усі партії беруть участь у виборах і відкрито голосують за те, чи схвалювати ескалацію.
• Відсутність втручання: смарт-контракти можуть бути незмінними, а систему ніколи не можна змінити.

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

Рада Безпеки не припиняє атаку. Це пасивний механізм, який працює разом з управлінням, коли кошти користувачів або надійність/продуктивність блокчейн-протоколу піддаються атаці.

На закінчення

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

Це хороший приклад траст-інжинірингу: інженерної дисципліни, яка зосереджена на виявленні, вимірюванні та зменшенні/усуненні елементів довіри в системі.

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

Ось чому для членів спільноти здорово скептично ставитися до ролі комітету з безпеки, але вони несуть відповідальність за те, щоб знайти кращі рішення під час надзвичайних ситуацій, щоб захистити кошти користувачів у реактивний спосіб.

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