Увечері 22 вересня користувач надіслав переказ ATOM.
Після ночі транзакція все ще залишалася «в очікуванні підтвердження».
Приватний ключ не було втрачено, і гаманець не показував жодних аномалій підпису. Коли наступного дня перевірили ще раз, кілька публічних RPC показали, що Cosmos Hub зупинився на висоті блоку 33 086 740.
Оскільки нові блоки не створювалися, природно, не було місця, яке могло б запакувати цю транзакцію.
Лише приблизно через день, після того як Cosmos Hub відновив виробництво блоків, цей переказ ATOM, який весь час перебував у стані очікування, нарешті успішно завершився.
Для звичайних користувачів це, можливо, найнаочніший урок для розуміння блокчейн-консенсусу.
Ми звикли говорити, що «жодна центральна установа не може вимкнути публічний ланцюг», але реальність, очевидно, набагато складніша. Достатньо децентралізований блокчейн справді зазвичай не має тієї «кнопки вимкнення» в серверній, але він все одно може зупинитися.
Ця пауза Cosmos Hub якраз і повністю викрила цей набір механізмів, зазвичай прихованих на нижньому рівні, для звичайних користувачів.
1. Чому Cosmos раптово «перестав виробляти блоки»?
Спочатку необхідно прояснити питання, яке легко сплутати: те, на що цього разу було безпосередньо здійснено атаку, не був Cosmos Hub.
Інцидент стався спочатку на Neutron.
22 вересня було прийнято пропозицію управління Neutron під назвою «AIATO: AI Agent Takeover». Атакувальник скористався прогалиною в дозволах управління на рівні ланцюга та використав привілейовані інструкції, нативно надані фреймворком wasmd, щоб змінити адміністраторів контрактів таких застосунків, як Astroport і Drop, на адреси, контрольовані атакувальником.
Це не те, що ми зазвичай розуміємо як «вразливість коду» або «недолік протоколу».
Це можна просто зрозуміти так: самі застосунки мають власні «дверні замки», але управління на рівні ланцюга Neutron також володіє «майстер-ключем» вищого привілею, і коли атакувальник контролює результат управління, це рівнозначно отриманню цього ключа, що дозволяє йому перепризначати адміністраторів, мігрувати контракти та далі переказувати активи всередині.
Те, що справді втягнуло Cosmos Hub, — це подальше переміщення коштів між ланцюгами.
Постмортем Cosmos Labs показує, що перед тим як Neutron припинив роботу, атакувальник уже перемістив частину активів до кількох мереж, серед яких близько 1,7 мільйона ATOM було переказано до Cosmos Hub і почало обмінюватися через міжланцюгову ліквідність.
Іншими словами, сам Cosmos Hub не був безпосередньо атакований, і кошти звичайних користувачів Hub не були безпосередньо викрадені через вразливість Neutron.
Але ATOM, отримані в результаті атаки, вже увійшли до Hub, і щоб запобігти подальшому витоку решти ATOM, деякі валідатори Cosmos Hub почали зупиняти свої вузли.
Приблизно о 19:18 22 вересня (SGT) валідатори, які зупинили роботу, вже представляли понад одну третину загальної потужності голосування, тому Cosmos Hub більше не міг продовжувати формувати нові блоки й остаточно зупинився на 33 086 740.
Цей крок дуже критичний.
Це означає, що Cosmos Hub не має кнопки «Пауза», яку якась компанія могла б безпосередньо натиснути, і він також не проходив спочатку голосування управління на ланцюзі. Те, що справді зупинило мережу, — це те, що достатня кількість валідаторів більше не брала участі у формуванні консенсусу.
Але що більш примітно, це насправді процес відновлення після цього.
Приблизно через 4 години після зупинки ланцюга валідатори отримали повний план відновлення: виконати одноразову модифікацію стану на висоті зупинки ланцюга, переказавши залишок ATOM з адреси атакуючого на мультипідписну адресу, якою спільно керують валідатори спільноти.
Потім Cosmos Labs створила патч Gaia v28.3.0 на основі плану, вже узгодженого валідаторами, протестувала його та розповсюдила серед валідаторів.
Ця версія Gaia мала виконати одноразову зміну стану на вказаній висоті відновлення, переказавши 1 227 121 ATOM з адреси атакуючого на мультипідписну адресу 4-з-6, що складається з шести сторін: Nansen, Keplr, Enigma, Silknodes, Kiln і Polkachu.
До ранку 23 вересня валідатори, які підтвердили встановлення v28.3.0, вже перевищили 67% загальної потужності голосування, тому о 12:00 UTC того дня Cosmos Hub скоординував перезапуск. Приблизно через 6 хвилин цю одноразову модифікацію стану було виконано на висоті блоку 33 086 741, і мережа відновила нормальне виробництво блоків.
У підсумку, протягом усього процесу від зупинки виробництва блоків Cosmos до відновлення роботи, валідатори спочатку змусили мережу втратити живучість, а потім більше двох третин потужності голосування прийняли новий набір правил переходу стану, зрештою зробивши цей набір правил канонічним станом після відновлення.
На цьому етапі виникає, здавалося б, просте питання: оскільки це децентралізований публічний ланцюг, чому більше однієї третини потужності валідації може його зупинити, тоді як для відновлення мережі потрібно, щоб достатньо валідаторів спільно прийняли та запустили одне й те саме програмне забезпечення?
Відповідь насправді прихована в слові «консенсус».
2. Так званий консенсус ніколи не означав «ніколи не зупиняється»
Одне з найбільш легко неправильно зрозумілих речей щодо блокчейну — це ототожнення «децентралізації» з «ніколи не падає».
Насправді механізм консенсусу справді вирішує як, без центрального бухгалтера, багато вузлів можуть досягти згоди щодо порядку транзакцій і стану реєстру.
Однак різні публічні ланцюги реалізують це не однаково.
Наприклад, найкласичніший механізм Bitcoin — це PoW, доказ роботи — майнери змагаються за виробництво блоків, використовуючи обчислювальну потужність. Коли в мережі на короткий час з’являються дві дійсні гілки, вузли вибирають одну з них, щоб продовжити будувати на ній відповідно до сукупної роботи.
Тож Bitcoin не має чіткого моменту, коли «після 67% голосування цей блок назавжди фіналізовано». Це ближче до свого роду ймовірнісної фінальності: чим більше наступних блоків, тим більше витрат обчислювальної потужності потрібно для реорганізації та видалення попередніх транзакцій.
Це також причина, чому раніше казали, що транзакцію Bitcoin найкраще зачекати 6 підтверджень блоку. Зрештою, навіть із вищою обчислювальною потужністю не можна просто обійти правила консенсусу, які виконують вузли.
Звичайно, це не означає, що стан Bitcoin «абсолютно неможливо змінити» за будь-яких обставин. Теоретично, якщо вся екосистема прийме нового клієнта та нові правила консенсусу через хардфорк, так само можливо зробити зміни стану, які були недійсними за старими правилами, дійсними.
Але тут і криється проблема: хто має здатність змусити достатньо майнерів, повних вузлів, торгових платформ, гаманців і користувачів спільно прийняти такий новий набір правил?
Майже ніхто.
Команда розробників не може самостійно вирішувати правила консенсусу для всієї мережі Bitcoin, і це також важко для майнерів і торгових платформ, оскільки поріг консенсусу, який потрібно подолати, дуже високий. Коли Binance було зламано на 7 000 BTC, дехто пропонував, щоб CZ зв’язався з великими майнерами для операції, але зрештою нічого з цього не вийшло.
Ethereum надає інший дуже класичний приклад.
Після переходу на PoS Ethereum тепер використовує консенсус Gasper, що складається з Casper FFG і LMD-GHOST разом. Простіше кажучи, одна частина механізму відповідає за визначення «якого ланцюга слід зараз дотримуватися», тоді як інша частина відповідає за надання блокам справжньої фінальності.
Лише коли валідатори, які представляють щонайменше дві третини стейкнутого ETH, погоджуються щодо відповідної контрольної точки, блок може просуватися далі до фіналізації; навпаки, якщо більше однієї третини стейку протягом тривалого часу не бере участі в правильному голосуванні, мережа може тимчасово бути не в змозі сформувати фінальність. Однак Ethereum також розробив витік неактивності, який поступово зменшує ефективну вагу офлайн-валідаторів, коли фіналізація не може бути досягнута протягом тривалого часу, даючи мережі шанс зрештою відновити фінальність.
Щоб справді змінити цей результат, так само необхідно змінити правила протоколу та клієнти.
Як і в інциденті The DAO 2016 року, спільнота Ethereum зрештою здійснила хардфорк, виконавши на блоці 1 920 000 спеціальну зміну стану, яку Ethereum Foundation на той час прямо назвала нерегулярною зміною стану, перевівши відповідні ETH у контракт відновлення.
Однак деякі майнери та члени спільноти, які відмовилися оновлюватися й продовжували підтримувати початковий стан, зрештою сформували Ethereum Classic (ETC), що призвело до відомого форку ETH і ETC, показуючи, що не всі прийняли цей набір правил.
Cosmos Hub знову інший. Він використовує CometBFT, який ближчий до типового консенсусу BFT.
Це можна зрозуміти як більш типовий консенсус BFT, тобто для того, щоб блок справді був зафіксований, йому потрібно отримати Commit від більш ніж двох третин голосуючої потужності.
Його перевага в тому, що фінальність дуже чітка. Щойно блок було зафіксовано після голосування достатньої потужності верифікації, немає потреби продовжувати чекати на все більше й більше блоків, як у PoW, обмінюючи ймовірність на відчуття безпеки.
Але його інший бік також дуже прямий: якщо одна третина або більше голосуючої потужності більше не надає голосів, потрібних для формування Commit, тоді незалежно від того, як сильно намагаються решта валідаторів, вони не можуть зібрати більше двох третин.
У цей момент найбезпечніший вибір для мережі — саме ця «пауза у виробництві блоків», яку ми бачили цього разу, тож з погляду розподілених систем ця коротка зупинка Cosmos Hub насправді не є загадковою.
Одним словом, після того, як група валідаторів, що володіє достатньою голосуючою потужністю, припиняє брати участь, протокол консенсусу, згідно з власними правилами, радше втратить доступність, ніж продовжить підтверджувати нові блоки без достатнього консенсусу.
За цим насправді стоять два поняття в розподілених системах, які звичайні користувачі часто плутають:
- Безпека: різні вузли не повинні одночасно підтверджувати два конфліктні фінальні стани;
- Живучість: чи може мережа все ще продовжувати працювати вперед і обробляти нові транзакції;
Для BFT-систем, коли недостатньо вузлів бере участь у консенсусі, пауза іноді є саме тією ціною, яку платять за підтримку безпеки. Простіше кажучи, цей децентралізований реєстр радше спочатку зупиниться там, ніж дозволить решті вести кожен свої власні записи.
Озираючись назад під цим кутом, можна виявити, що багато, здавалося б, цілком різних інцидентів в історії публічних блокчейнів насправді обертаються навколо одного й того самого:
Коли розподілені вузли більше не можуть сформувати консенсус щодо «правильного стану», що має робити мережа?
III. Від Bitcoin до Solana: де справжня межа ризику публічних блокчейнів?
Це не перший раз, коли Cosmos ставить це питання на порядок денний.
Ще у 2013 році Bitcoin пережив дуже класичний інцидент розгалуження ланцюга.
Тоді Bitcoin 0.8 переключив свою базову базу даних з Berkeley DB на LevelDB. Згодом з’явився блок, що містив велику кількість входів транзакцій. Вузли нової версії могли обробити його нормально, але деякі вузли старої версії через обмеження кількості блокувань Berkeley DB визнали цей блок недійсним.
Так виникла дуже незручна сцена: усі запускали Bitcoin, але старі й нові клієнти почали давати різні відповіді на питання «чи цей блок легальний».
Тож мережа розділилася на два ланцюги, і сторона нової версії 0.8 свого часу мала близько 60% хешрейту й не могла покладатися на звичайну конкуренцію хешрейту, щоб швидко зійтися самостійно.
Зрештою великі майнінгові пули скоординувалися, щоб переключитися назад на стару версію, повернули більше хешрейту на бік старих правил, і лише тоді мережа знову зійшлася. Bitcoin пізніше спеціально розглянув цей інцидент у BIP 50.
До 2016 року інцидент The DAO в Ethereum просунув проблему ще на крок далі.
Як згадувалося вище щодо інциденту з The DAO, спільнота Ethereum зрештою здійснила хардфорк, виконавши на блоці 1 920 000 спеціальну модифікацію стану, яку Фонд Ethereum явно назвав нерегулярною зміною стану, перевівши відповідні ETH до контракту відновлення.
Але не всі погодилися з таким підходом. Деякі майнери та члени спільноти, які відмовилися прийняти модифікацію стану, продовжили дотримуватися початкових правил, що призвело до давно існуючого Ethereum Classic (ETC).
Цей DAO-форк також був класичною подією, рівнозначною тому, щоб сказати всім, що коли трапляються екстремальні події, крім консенсусу коду існує також соціальний консенсус. Якщо не вдається сформувати достатньо узгоджені думки, ланцюг справді може розділитися на два.
Solana у 2021 році продемонструвала інший цілком відмінний шлях збою.
У вересні того року величезна кількість ботових транзакцій заполонила мережу, через що вузли валідаторів вичерпали пам'ять і багато вузлів зазнали краху. Зрештою вся мережа не змогла сформувати консенсус щодо поточного стану й приблизно 17 годин не підтверджувала нові блоки, після чого валідатори спільно скоординувалися, щоб відновити мережу.
Склавши ці інциденти разом, можна побачити, що вони не є одним і тим самим:
- Проблема Bitcoin у 2013 році полягала в тому, що різні клієнти почали застосовувати різні правила валідності;
- Проблема Solana у 2021 році полягала в тому, що велика кількість вузлів валідаторів більше не могла нормально брати участь у консенсусі, і мережа втратила живучість (Liveness);
- Те, з чим зіткнувся Ethereum DAO, було ближче до питання, чи повинна спільнота активно змінювати стан через нові правила протоколу;
- А цього разу Cosmos Hub має ще один рівень особливості: мережа спочатку активно втратила живучість через координацію валідаторів, щоб запобігти подальшому переміщенню атакованих активів; згодом достатньо висока частка голосової потужності спільно прийняла нове програмне забезпечення та стан відновлення, дозволивши мережі знову сформувати консенсус;
Тож замість того, щоб просто зводити ці події до «отже, блокчейни насправді можуть зупинятися» або «децентралізація — це все фікція», краще визнати реальніший факт:
Механізм консенсусу ніколи не був машиною, яка не може зламатися. Те, що він насправді забезпечує, — це набір децентралізованих правил, як-от: хто вирішує, який ланцюг є правильним, коли виникають розбіжності; скільки учасників потрібно, щоб стан набув фінальності; чи вирішує мережа продовжувати роботу чи зупинитися, коли трапляються збої; і за екстремальних обставин, який тип колективних дій може змінити правила функціонування надалі.
Це також залишає цей інцидент із Cosmos із питанням, яке для звичайних користувачів варте більшого обмірковування, ніж «чи слід зупиняти ланцюг».
Остаточні думки
Ми часто говоримо: не ваші ключі — не ваші монети.
Це твердження, звісно, досі залишається справедливим, просто воно наголошує на контролі над активами — поки приватний ключ у ваших руках, гаманці, торгові платформи чи інші треті сторони не можуть підписати переказ від вашого імені.
Передумова полягає в тому, що блокчейн, у якому ви перебуваєте, має бути здатним обробити цей підпис у будь-який момент.
Того дня, коли Cosmos Hub припинив виробляти блоки, користувачі все ще володіли власними приватними ключами, і активи не зникли через це в повітря, просто навіть якщо ви правильно підписали транзакцію, не було нового блоку, щоб її прийняти.
Процес відновлення додатково ілюструє, що якщо достатньо учасників консенсусу приймають новий набір правил стану, стан конкретних акаунтів у ланцюзі також може змінитися без підпису приватним ключем початкової адреси.
Це не робить «Не ваші ключі — не ваші монети» недійсним, але це нагадує нам, що суверенітет приватного ключа та базова сила консенсусу ніколи не були одним і тим самим.
І для гаманців це так само справедливо.
Гаманці можуть забезпечити, щоб приватні ключі та права підпису залишалися в руках самих користувачів, можуть якнайшвидше виявляти аномалії на рівні ланцюга, точно відображати статус транзакцій, створювати резервування RPC та вузлів, а також повторно підтверджувати кінцевий результат транзакцій після відновлення мережі.
Але гаманці не можуть відновити консенсус для публічного ланцюга, не можуть гарантувати, що базова мережа ніколи не буде перервана, і тим більше не можуть гарантувати, що правила та стан у ланцюзі ніколи не зазнають змін на рівні консенсусу.
Отже, те, чого справді має прагнути зріла децентралізована система, можливо, ніколи не було «ніщо ніколи не може бути змінено»; навпаки, вона повинна максимально прояснити ці недосконалі межі: Хто може призупинити консенсус? Скільки ваги для цього потрібно? За яких обставин дозволено екстрене втручання?
Тому що справжня децентралізація не може зробити так, щоб система ніколи не стикалася з аваріями; ключове полягає в тому, що навіть якщо аварія справді станеться, ми все ще можемо знати, хто, на основі яких правил і з яким рівнем консенсусу вирішив, як цей реєстр має бути записаний далі.
