З правильного управління гаманець лонгуючого обчислення з подій Multichain

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

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

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

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

Отже, як можна повністю використати особливості лонгуючого обчислення? Основними є такі три пункти:

1. Підвищення прозорості, запобігання конфлікту інтересів;
2. Суворо дотримуватися децентралізованого способу зберігання, уникати надмірної концентрації влади;
3. Розробити план дій на випадок екстремальних ситуацій.

Запобігання конфлікту інтересів: відмова від непрозорих операцій

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

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

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

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

Децентралізоване зберігання: уникнення ризику одноточкового збою

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

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

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

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

Розробка плану відновлення соціальних зв'язків у крайніх випадках

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

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

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

Щоб запобігти зловживанням з боку власників фрагментів SOS, можна ввести деякі обмеження, такі як встановлення затримки вступу в силу режиму "SOS"; під час цього періоду звичайні фрагменти приватного ключа можуть скасувати режим "SOS"; або після термінового переведення активів в режимі "SOS" встановити період блокування, протягом якого подальші переведення не можливі, щоб запобігти втраті активів.

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