Почему останавливается публичный блокчейн? На примере 25-часового простоя Cosmos разбираемся в консенсусе блокчейна

Автор: imToken

Вечером 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 (SGT) 22 сентября отключенные валидаторы уже представляли более трети общего voting power, из-за чего Cosmos Hub не мог продолжать создание новых блоков и окончательно остановился на отметке 33,086,740.

Этот шаг оказался крайне важным.

Он означает, что в Cosmos Hub нет кнопки «Pause» для клика какой-либо компании и не проводилось предварительного голосования по управлению в сети. Фактически остановку сети вызвало то, что достаточное количество валидаторов перестало участвовать в формировании консенсуса.

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

Примерно спустя 4 часа простоя валидаторы получили полный план восстановления: для высоты остановки сети выполнить однократное изменение состояния, переведя оставшиеся ATOM на мультиподписный адрес, совместно управляемый валидаторами сообщества.

После этого Cosmos Labs разработала патч Gaia v28.3.0 на основе согласованного плана, протестировала его и распространила среди валидаторов.

Данная версия Gaia выполнит однократное изменение состояния на указанной высоте восстановления, переведя 1 227 121 ATOM с адресов атакующего на 4-of-6 мультиподписный адрес, совместно контролируемый шестью сторонами: Nansen, Keplr, Enigma, Silknodes, Kiln и Polkachu.

К ранним часам 23 сентября валидаторы, подтвердившие установку v28.3.0, уже превысили 67% общего voting power, поэтому в 12:00 UTC того же дня Cosmos Hub скоординировала перезапуск. Примерно через 6 минут это однократное изменение состояния было выполнено на высоте блока 33,086,741, и сеть вернулась к нормальной генерации блоков.

В конечном итоге, в процессе от останова генерации блоков Cosmos до восстановления работы, валидаторы сначала лишили сеть Liveness, затем более двух третей voting power приняли новый набор правил перехода состояния, превратив эти правила в canonical state восстановленной сети.

На этом фоне возникает на первый взгляд простой вопрос: если это децентрализованная публичная сеть, почему более трети прав валидатора способно остановить её, а для восстановления требуется достаточное количество валидаторов, совместно принимающих и использующих одно и то же ПО?

Ответ, по сути, кроется в самом слове «консенсус».

2. Консенсус по определению не означает «никогда не останавливается»

Одно из самых распространённых заблуждений относительно блокчейна — приравнивание «децентрализации» к «абсолютной отказоустойчивости».

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

Лишь разные публичные сети реализуют это по-разному.

Классическим примером для Bitcoin является PoW — доказательство выполнения работы: майнеры конкурируют за генерацию блоков с помощью вычислительной мощности, а при временном появлении двух законных веток сеть выбирает одну из них для продолжения построения по принципу максимальной накопленной работы.

Поэтому в Bitcoin нет чёткого момента «навсегда Finalized после 67% голосов», здесь скорее речь идёт о вероятностной финальности: чем больше последующих блоков создано, тем дороже становится вычислительная мощность, необходимая для реорганизации предыдущих транзакций.

Именно поэтому ранее считалось, что для транзакции в Bitcoin лучше ждать подтверждения 6 блоков: даже при огромной вычислительной мощности нельзя просто обойти правила консенсуса, выполняемые узлами.

Разумеется, это не означает, что состояние Bitcoin «абсолютно невозможно изменить» при любых обстоятельствах. Теоретически, если вся экосистема примет нового клиента и новые правила консенсуса, посредством Hard Fork можно сделать действующими изменения состояния, которые были недействительны по старым правилам.

Но проблема заключается в следующем: кто сможет заставить достаточное количество майнеров, Full Node, торговых площадок, кошельков и пользователей принять такой набор новых правил?

Практически никто.

Команда разработчиков не может принимать решения о правилах консенсуса от имени всей сети Bitcoin, да и майнерам, и биркам это сложно сделать, так как порог достижения консенсуса чрезвычайно высок. В былом случае кражи 7000 BTC с Binance некоторые предлагали CZ связаться с крупными майнерами для координации, но тогда это так и осталось лишь предложением.

Ethereum же предоставляет ещё один классический пример.

После перехода на PoS текущий Ethereum использует консенсус Gasper, состоящий из Casper FFG и LMD-GHOST. Проще говоря, одни компоненты определяют «какой цепочке следовать прямо сейчас», а другие обеспечивают для блоков подлинную Finality.

Блок получает дальнейшее подтверждение только при достижении консенсуса валидаторами, представляющими не менее двух третей залогиненного ETH по соответствующему checkpoint. Наоборот, если более трети stake надолго прекращает корректное голосование, сеть временно теряет возможность формирования Finality. Однако в Ethereum предусмотрена функция inactivity leak, которая постепенно снижает эффективный вес оффлайн-валидаторов при длительном отсутствии finalizing, позволяя сети в итоге восстановить Finality.

Чтобы реально изменить подобный исход, также потребуется изменить правила протокола и клиентское ПО.

Так произошло во время инцидента The DAO в 2016 году: сообщество Ethereum в итоге осуществило Hard Fork и на блоке 1,920,000 выполнило специальное изменение состояния, которое тогда Фонд Ethereum напрямую назвал irregular state change, переведя соответствующие ETH в контракт восстановления.

Однако часть майнеров и участников сообщества, отказавшихся от обновления и решивших сохранить оригинальное состояние, в итоге образовала Ethereum Classic (ETC), что привело к известному разделению ETH и ETC, продемонстрировав: не все приняли этот набор правил.

Cosmos Hub функционирует иначе: она использует CometBFT, что ближе к классическому BFT-консенсусу.

Можно считать это наиболее классической моделью BFT-консенсуса, где для окончательного подтверждения блока требуется получить Commit от более чем двух третей voting power.

Его преимущество — абсолютная ясность Finality: как только блок был подтверждён достаточным весом голосов, нет нужды дожидаться множества последующих блоков, как в PoW, чтобы обменять вероятность на безопасность.

Но обратная сторона очевидна: если одна треть или больше voting power перестаёт отдавать голоса, необходимые для формирования Commit, любые усилия оставшихся валидаторов не позволят набрать требуемые две трети.

В такой ситуации самым безопасным выбором для сети становится приостановка генерации блоков, как это произошло此次. Поэтому с точки зрения распределённых систем кратковременная остановка Cosmos Hub не выглядит чем-то загадочным.

Если кратко сказать, когда группа валидаторов с достаточным voting power прекращает участие, протокол консенсуса по своим правилам предпочитает потерять доступность, вместо того чтобы продолжать подтверждать новые блоки в условиях недостаточного консенсуса.

За этим стоят два понятия из теории распределённых систем, которые обычные пользователи часто смешивают:

• Safety: предотвращение одновременного подтверждения разными узлами двух взаимно исключающих конечных состояний;
• Liveness: способность сети продолжать работу и обработку новых транзакций;

Для систем BFT приостановка иногда является ценой поддержания Safety при недостаточном количестве участвующих в консенсусе узлов. Говоря прямым языком, этот децентрализованный реестр предпочитает просто остановиться, нежели позволить остальным вести учёт независимо друг от друга.

Если посмотреть на это с такой точки зрения, многие кажущиеся совершенно разными инциденты в истории публичных сетей оказываются сосредоточены вокруг одной и той же проблемы:

Что делать сети, когда распределённые узлы больше не могут прийти к единому мнению о «правильном состоянии»?

3. От Bitcoin до Solana: где настоящие границы рисков публичных сетей?

Это далеко не первый раз, когда Cosmos выносит этот вопрос на публику.

Ещё в 2013 году в Bitcoin произошел классический инцидент с расхождением цепочки блоков.

Тогда обновление Bitcoin 0.8 переключило базовую базу данных с Berkeley DB на LevelDB. Появился блок со множеством входных транзакций: новые узлы обработали его штатно, однако старые узлы из-за лимита количества блокировок в Berkeley DB посчитали этот блок недействительным.

В результате возникла неловкая ситуация: все запускали Bitcoin, но клиенты старой и новой версии стали давать противоречивые ответы на вопрос «легален ли этот блок».

Из-за этого сеть разделилась на две цепочки, причём новая версия 0.8 временно обладала около 60% вычислительной мощности, из-за чего сеть не могла быстро самостоятельно сойтись в ходе обычного соревнования хешрейтом.

В итоге крупные пулы после координации переключились обратно на старую версию, восполнив вычислительную мощность на стороне старых правил, после чего сеть снова сошлась. Позже Bitcoin официально закрепил выводы из этого инцидента в BIP 50.

В 2016 году инцидент The DAO в Ethereum снова продвинул эту проблему дальше.

Как упоминалось выше, сообщество Ethereum реализовало Hard Fork и на блоке 1,920,000 выполнило специальное изменение состояния, которое Фонд Ethereum напрямую назвал irregular state change, переведя соответствующие ETH в контракт восстановления.

Но не все согласились с таким решением. Часть майнеров и сообщества, отказавшаяся от изменений состояния и решившая сохранить прежние правила, в итоге породила долгое время существующий Ethereum Classic (ETC).

Этот DAO Fork стал классическим событием, наглядно показав всем: при наступлении крайних обстоятельств помимо технического консенсуса кода существует социальный консенсус; если не удаётся достичь достаточного единства мнений, одна цепочка действительно может разделиться на две.

В 2021 году Solana продемонстрировала совершенно другой сценарий сбоя.

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

Если объединить все эти инциденты, станет ясно, что они ничего общего между собой не имеют:

• проблема Bitcoin 2013 года заключалась в том, что различные клиенты начали применять разные правила валидации;
• проблема Solana 2021 года возникла из-за того, что множество валидаторных нод больше не могло нормально участвовать в консенсусе, из-за чего сеть потеряла Liveness;
• ситуация Ethereum DAO ближе к вопросу, следует ли сообществу активно изменять состояние через новые правила протокола;
• а данная Cosmos Hub привносит дополнительный уровень специфики: сначала сеть добровольно теряла Liveness благодаря координации валидаторов, чтобы остановить движение украденных активов; затем значительно большая доля voting power совместно приняла новое ПО и состояние восстановления, позволив сети вновь достичь согласия;

Так что вместо того чтобы сводить подобные события к простым выводам вроде «блокчейны тоже умеют выключаться» или «децентрализация — это ложь», стоит признать более реалистичный факт:

механизм консенсуса никогда не бывает абсолютно надёжной машиной; по сути, он предлагает лишь набор децентрализованных правил, согласно которому решается, кто указывает правильную цепочку при возникновении разногласий; сколько участников необходимо для придания состоянию финальности; продолжает ли сеть работать или останавливается при возникновении сбоев; а также какие коллективные действия способны изменить рабочие правила в экстремальных условиях.

Именно этот инцидент с Cosmos оставляет обычным пользователям вопрос гораздо более важный для осмысления, чем «следовало ли останавливать сеть».

Заключение

Мы часто повторяем, что «не твои ключи — не твои монеты».

Это утверждение, безусловно, остаётся верным, но оно подчёркивает контроль над активами: пока приватный ключ находится у вас, кошельки, торговые площадки или иные третьи лица не смогут легитимно подписывать за вас переводы.

При условии, что блокчейн, в котором вы находитесь, всегда обладает технической возможностью обработать эту подпись.

В день останова генерации блоков Cosmos Hub пользователи сохраняли свои приватные ключи, а активы не исчезали бесследно; просто если вы правильно подписали транзакцию, новые блоки уже не могли бы её принять.

Процесс восстановления дополнительно доказывает: если достаточное число участников консенсуса примет новый набор правил состояния, on-chain статус определённого аккаунта может измениться даже без подписи приватным ключом оригинального адреса.

Это не делает принцип «Не твои ключи — не твои монеты» несостоятельным, но напоминает нам, что право контроля над приватным ключом и право влияния на базовый консенсус — это вовсе не одно и то же.

То же самое справедливо и для кошельков.

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

Но кошельки не способны восстановить консенсус за публичную сеть, не могут гарантировать непрерывности работы базовой сети и тем более не могут обеспечить вечную неизменность on-chain правил и состояний на уровне консенсуса.

Так что зрелая децентрализованная система должна стремиться вовсе не к принципу «ничего нельзя изменить ни при каких обстоятельствах»; напротив, ей следует максимально чётко обозначать эти несовершенные границы: кто способен приостановить консенсус? Какой вес голоса для этого необходим? В каких ситуациях допускается экстренное вмешательство?

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