Почему публичная цепочка может остановиться? На примере остановки Cosmos на 25 часов, действительно понимаем консенсус блокчейна

Автор: imToken

22 сентября вечером пользователь осуществил перевод ATOM.

Прошла ночь, и транзакция все еще оставалась в статусе «ожидание подтверждения».

Приватный ключ не был потерян, кошелек не показал никаких аномалий в подписи, на следующий день при повторной проверке несколько публичных RPC показали, что Cosmos Hub остановился на высоте блока 33,086,740.

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

Только примерно через день после этого Cosmos Hub восстановил создание блоков, и этот перевод ATOM, который все это время находился в состоянии ожидания, наконец, был успешно завершен.

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

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

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

I. Почему 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 начали останавливать работу узлов.

К 22 сентября около 19:18 (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 и восстановления работы был таков, что валидаторы сначала заставили сеть потерять Liveness, а затем более двух третей голосующего веса приняли новый набор правил изменения состояния, в конечном итоге сделав эти правила каноническим состоянием после восстановления.

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

Ответ, на самом деле, скрыт в слове «консенсус».

II. Так называемый консенсус не является «никогда не останавливающимся»

Самая легко недопонимаемая вещь о блокчейне - это приравнивание «децентрализованности» к «никогда не отключающемуся».

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

Просто разные публичные цепочки реализуют это по-разному.

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

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

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

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

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

Почти никто.

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

Ethereum же предлагает другой классический пример.

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

Когда валидаторы, представляющие как минимум две трети заложенного ETH, согласны с соответствующей контрольной точкой, блок может продвигаться к окончательному подтверждению; наоборот, если более трети доли долгое время не участвуют в правильном голосовании, сеть может временно не сформировать финальность, хотя Ethereum также разработал механизм утечки бездействия, который постепенно снижает эффективный вес оффлайн-валидаторов, позволяя сети в конечном итоге восстановить финальность.

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

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

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

Cosmos Hub отличается тем, что использует CometBFT, что ближе к типичному BFT консенсусу.

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

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

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

В этот момент самым безопасным выбором для сети, как и в случае с «остановкой создания блоков», поэтому с точки зрения распределенной системы эта краткая приостановка Cosmos Hub на самом деле не является чем-то загадочным.

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

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

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

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

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

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

Три. От 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 Foundation четко назвала irregular state change, переведя соответствующий ETH в контракт восстановления.

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

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

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

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

Если собрать эти инциденты вместе, можно заметить, что они не являются одним и тем же:

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

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

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

Это также оставляет после себя вопрос, который стоит больше, чем «должен ли блокчейн остановиться», для обычных пользователей.

Заключение

Мы часто говорим: not your keys, not your coins.

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

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

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

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

Это не делает «Not your keys, not your coins» недействительным, но напоминает нам, что автономия приватного ключа и право на консенсус в основе никогда не были одним и тем же.

И для кошельков это также верно.

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

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

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

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