Вечером 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 нет кнопки «Pause», которую какая-либо компания могла бы напрямую нажать, и он также не проходил сначала голосование по управлению на цепочке. То, что действительно остановило сеть, — это то, что достаточное количество валидаторов перестало участвовать в формировании консенсуса.
Но что более примечательно, так это фактически процесс восстановления после этого.
Примерно через 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 до возобновления работы валидаторы сначала заставили сеть потерять Liveness, а затем более двух третей мощности голосования приняли новый набор правил перехода состояния, в конечном итоге сделав этот набор правил каноническим состоянием после восстановления.
На этом этапе возникает, казалось бы, простой вопрос: поскольку это децентрализованная публичная цепочка, почему более одной трети мощности валидации может её остановить, тогда как для восстановления сети требуется, чтобы достаточное количество валидаторов совместно приняли и запустили одно и то же программное обеспечение?
Ответ на самом деле скрыт в слове «консенсус».
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 в то время прямо назвал нерегулярным изменением состояния, переведя соответствующие ETH в контракт восстановления.
Однако некоторые майнеры и члены сообщества, которые отказались обновляться и продолжали поддерживать исходное состояние, в конечном итоге сформировали Ethereum Classic (ETC), что привело к известному форку ETH и ETC, показывая, что не все приняли этот набор правил.
Cosmos Hub снова отличается. Он использует CometBFT, который ближе к типичному консенсусу BFT.
Это можно понять как более типичный консенсус BFT, означающий, что для того, чтобы блок был действительно зафиксирован, ему необходимо получить Commit от более чем двух третей голосующей мощности.
Его преимущество в том, что Finality очень ясна. Как только блок был зафиксирован после голосования достаточной проверяющей мощности, нет необходимости продолжать ждать все больше и больше блоков, как в PoW, обменивая вероятность на чувство безопасности.
Но его другая сторона также очень прямолинейна: если одна треть или более голосующей мощности больше не предоставляет голоса, необходимые для формирования Commit, то независимо от того, как усердно стараются оставшиеся валидаторы, они не могут собрать более двух третей.
В этот момент самый безопасный выбор для сети — это именно «пауза в производстве блоков», наблюдаемая на этот раз, поэтому с точки зрения распределенных систем эта кратковременная остановка Cosmos Hub на самом деле не загадочна.
Одним словом, после того как группа валидаторов, обладающая достаточной голосующей мощностью, прекращает участие, протокол консенсуса, согласно своим собственным правилам, скорее потеряет доступность, чем продолжит подтверждать новые блоки без достаточного консенсуса.
За этим фактически соответствуют две концепции в распределенных системах, которые часто путают обычные пользователи:
- Safety: разные узлы не должны одновременно подтверждать два конфликтующих конечных состояния;
- Liveness: может ли сеть по-прежнему продолжать работать вперед и обрабатывать новые транзакции;
Для BFT-систем, когда недостаточно узлов участвуют в консенсусе, пауза иногда является именно той ценой, которую платят для поддержания Safety. Говоря прямо, этот децентрализованный реестр скорее остановится на месте, чем позволит оставшимся людям вести каждый свои собственные записи.
Оглядываясь назад с этой точки зрения, можно обнаружить, что многие, казалось бы, совершенно разные инциденты в истории публичных блокчейнов на самом деле вращаются вокруг одного и того же:
Когда распределенные узлы больше не могут сформировать консенсус относительно «правильного состояния», что должна делать сеть?
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 есть ещё один уровень особенности: сеть сначала намеренно потеряла Liveness посредством координации валидаторов, чтобы предотвратить дальнейшее перемещение атакованных активов; впоследствии достаточно высокая доля голосующей силы совместно приняла новое программное обеспечение и состояние восстановления, позволив сети снова сформировать консенсус;
Поэтому вместо того, чтобы просто сводить эти события к «значит, блокчейны действительно могут останавливаться» или «децентрализация — это всё фальшь», лучше признать более реальный факт:
Механизм консенсуса никогда не был машиной, которая не может сломаться. То, что он действительно предоставляет, — это на самом деле набор децентрализованных правил, таких как: кто решает, какая цепочка является правильной при возникновении разногласий; сколько участников необходимо, чтобы состояние получило финальность; выбирает ли сеть продолжать работу или остановиться при возникновении сбоев; и при экстремальных обстоятельствах, какого рода коллективные действия могут изменить правила работы в дальнейшем.
Это также оставляет в этом инциденте с Cosmos вопрос, более достойный размышления для обычных пользователей, чем «следует ли останавливать цепочку».
Заключительные мысли
Мы часто говорим: не твои ключи — не твои монеты.
Это утверждение, конечно, по-прежнему верно, просто оно подчёркивает контроль над активами — пока приватный ключ находится в ваших собственных руках, кошельки, торговые платформы или другие третьи стороны не могут подписать перевод от вашего имени.
Предпосылка в том, что блокчейн, в котором вы находитесь, должен быть способен обработать эту подпись в любой момент.
В день, когда Cosmos Hub прекратил производство блоков, пользователи по-прежнему владели своими приватными ключами, и активы не исчезли в воздухе из-за этого, просто даже если вы правильно подписали транзакцию, не было нового блока, чтобы её принять.
Процесс восстановления дополнительно иллюстрирует, что если достаточное количество участников консенсуса примет новый набор правил состояния, состояние конкретных аккаунтов в цепочке также может измениться без подписи приватным ключом исходного адреса.
Это не делает утверждение «Не твои ключи — не твои монеты» недействительным, но напоминает нам, что суверенитет приватного ключа и базовая сила консенсуса никогда не были одним и тем же.
И для кошельков это тоже верно.
Кошельки могут гарантировать, что приватные ключи и права подписи находятся в руках самих пользователей, могут как можно быстрее выявлять аномалии на уровне цепочки, точно отображать статус транзакций, обеспечивать резервирование RPC и узлов, а также повторно подтверждать окончательный результат транзакций после восстановления сети.
Но кошельки не могут восстановить консенсус для публичной цепочки, не могут гарантировать, что базовая сеть никогда не будет прервана, и тем более не могут гарантировать, что правила и состояние в цепочке никогда не претерпят изменений на уровне консенсуса.
Таким образом, то, к чему действительно должна стремиться зрелая децентрализованная система, возможно, никогда не было «ничто никогда не может быть изменено»; напротив, она должна как можно более чётко определить эти несовершенные границы: Кто может приостановить консенсус? Какой вес для этого необходим? При каких обстоятельствах допускается экстренное вмешательство?
Потому что истинная децентрализация не может сделать так, чтобы система никогда не сталкивалась с авариями; ключевое в том, что даже если авария действительно произойдёт, мы всё ещё сможем знать, кто, на основании каких правил и с каким объёмом консенсуса решил, как этот реестр должен быть записан далее.
