Вечером 22 сентября пользователь отправил перевод ATOM.
Прошла одна ночь, а транзакция все еще «ожидала подтверждения».
Приватный ключ не был утерян, и в кошельке не было исключений подписи. Повторная проверка на следующий день показала, что несколько общедоступных RPC показали, что Cosmos Hub остановился на высоте блока 33 086 740.
Если новый блок не будет сгенерирован, естественно, некуда будет упаковать эту транзакцию.
И только через день Cosmos Hub возобновил производство блоков, ожидавшая передача ATOM наконец увенчалась успехом.
Для обычных пользователей это может быть наиболее интуитивным уроком для понимания консенсуса блокчейна.
Мы привыкли говорить, что «ни одна центральная организация не может закрыть публичную сеть», но реальность, очевидно, намного сложнее. Достаточно децентрализованный блокчейн обычно не имеет «кнопки выключения» в серверной, но он все равно может остановиться.
Приостановка Cosmos Hub на этот раз полностью раскрыла для обычных пользователей этот механизм, который обычно скрыт внизу.
1. Почему Cosmos вдруг «перестал производить блоки»?
Прежде всего, нам нужно прояснить легко запутанный вопрос. На этот раз атаке подвергся не Космос-Хаб.
Инцидент впервые произошел в Нейтроне.
22 сентября было принято предложение по управлению Neutron под названием «AIATO: захват ИИ-агента». Злоумышленник воспользовался лазейками в разрешениях на управление на уровне цепочки и использовал привилегированные инструкции, изначально предоставляемые инфраструктурой wasmd, чтобы изменить администраторов контрактов таких приложений, как Astroport и Drop, на адреса, контролируемые злоумышленником.
Это не тот тип «уязвимости кода» или «недостатка протокола», который мы обычно понимаем.
Можно просто понять, что само приложение имеет свой собственный «дверной замок», но управление на уровне цепочки Neutron также имеет «мастер-ключ» с более высоким авторитетом. Когда злоумышленник контролирует результаты управления, это эквивалентно получению этого ключа и может переназначить администратора, перенести контракт и в дальнейшем передать активы.
Что действительно привлекло Cosmos Hub, так это последующий межсетевой перевод средств.
Обзор Cosmos Labs показывает, что до того, как Neutron перестал работать, злоумышленник перенес некоторые активы в несколько сетей. Около 1,7 миллиона ATOM были переведены в Cosmos Hub и начали обмениваться посредством кроссчейновой ликвидности.
Другими словами, сам Cosmos Hub не подвергался прямой атаке, а средства обычных пользователей Hub не были напрямую украдены из-за уязвимости Neutron.
Однако полученный в результате атаки АТОМ уже попал в Хаб. Чтобы предотвратить утечку остатков 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 сентября количество валидаторов, подтвердивших установку версии 28.3.0, превысило 67% от общего числа голосов. Поэтому в тот же день в 12:00 по всемирному координированному времени Cosmos Hub координировал перезапуск. Примерно через 6 минут это единоразовое изменение статуса было выполнено на высоте блока 33 086 741, и сеть вернулась к нормальному производству блоков.
В конечном итоге, на протяжении всего процесса, с момента прекращения производства блоков Cosmos до возобновления работы, именно валидаторы сначала заставили сеть потерять жизнеспособность, а затем более двух третей голосов приняли новый набор правил перехода состояний, в конечном итоге сделав этот набор правил восстановленным каноническим состоянием.
В этот момент возникает, казалось бы, простой вопрос: поскольку это децентрализованная публичная цепочка, почему более трети прав на верификацию могут остановить ее, а для восстановления сети необходимо достаточное количество валидаторов, чтобы принять и запустить один и тот же набор программного обеспечения?
Ответ на самом деле кроется в слове «консенсус».
2. Так называемый консенсус не «никогда не прекращается».
Одна из наиболее неправильно понимаемых вещей в блокчейне заключается в том, что «децентрализация» приравнивается к «непрерывному простою».
Фактически, проблема, которую действительно решает механизм консенсуса, заключается в том, сколько узлов смогут достичь соглашения о последовательности транзакций и статусе реестра в отсутствие центрального бухгалтера.
Однако разные публичные сети реализуют это по-разному.
Самым классическим примером Биткойна является PoW, который является доказательством работы: майнеры конкурируют за производство блоков на основе вычислительной мощности. Когда в сети за короткий промежуток времени появляются две легальные ветки, узел выбирает одну из них для продолжения строительства в соответствии с накопленной нагрузкой.
Таким образом, у Биткойна нет четкого момента «этот блок будет завершен навсегда после 67% голосов». Это ближе к вероятностной окончательности. Чем больше будет последующих блоков, тем выше и выше потребуются затраты вычислительной мощности для реорганизации предыдущих транзакций.
Вот почему все говорили, что для транзакции Биткойн лучше всего дождаться подтверждения в течение 6 блоков. В конце концов, какой бы высокой ни была вычислительная мощность, она не может просто обойти правила консенсуса, выполняемые узлами.
Конечно, это не означает, что состояние Биткойна «абсолютно неизменяемо» ни при каких обстоятельствах. Теоретически, если вся экосистема примет новый набор клиентов и новые правила консенсуса посредством хард-форка, изменения статуса, которые были недействительны в соответствии с предыдущими правилами, также могут стать действительными.
Но вот вопрос: у кого есть возможность собрать достаточное количество майнеров, полных узлов, торговых платформ, кошельков и пользователей, чтобы принять такой новый набор правил?
Едва ли.
Команда разработчиков не может определить правила консенсуса для всей сети Биткойн. Это также сложно для майнеров и торговых платформ, поскольку порог консенсуса, который им необходимо преодолеть, очень высок. Когда у Binance было украдено 7000 BTC, некоторые люди предложили CZ связаться с крупными майнерами для работы, но в итоге ничего не произошло.
Эфириум представляет собой еще один классический пример.
После перехода на PoS Ethereum теперь использует консенсус Gasper, состоящий из Casper FFG и LMD-GHOST. Проще говоря, одна часть механизма отвечает за определение того, «какой цепочке следует следовать в данный момент», а другая часть отвечает за достижение окончательности блока в истинном смысле этого слова.
Когда валидаторы, представляющие не менее двух третей поставленного ETH, достигают соглашения по соответствующей контрольной точке, блок может перейти к финализации; и наоборот, если более одной трети ставок в течение длительного времени не участвуют в правильном голосовании, сеть может временно оказаться неспособной сформировать окончательность. Тем не менее, Ethereum также разработал утечку бездействия, чтобы постепенно уменьшить эффективный вес автономных валидаторов, когда финализация не может быть завершена в течение длительного времени, давая сети шанс наконец восстановить окончательность.
Чтобы действительно изменить этот результат, вам также необходимо изменить правила протокола и клиента.
Как и в случае с инцидентом с DAO в 2016 году, сообщество Ethereum, наконец, реализовало специальную модификацию состояния, называемую Ethereum Foundation нерегулярным изменением состояния, на блоке 1 920 000 посредством хард-форка и перевело соответствующий ETH в контракт восстановления.
Однако некоторые майнеры и сообщества, которые отказались от обновления и продолжали поддерживать исходное состояние, в конечном итоге сформировали Ethereum Classic (ETC), что привело к известному форку ETH и ETC, что указывает на то, что не все принимают этот набор правил.
Cosmos Hub снова стал другим. Он использует CometBFT, который ближе к типичному консенсусу BFT.
Его можно понимать как более типичный консенсус BFT, то есть для того, чтобы блок был действительно отправлен, он должен получить подтверждение, составляющее более двух третей голосов.
Его преимущество в том, что Finality очень очевиден. Как только блок будет отправлен посредством голосования с достаточными правами проверки, нет необходимости продолжать ждать все новых и новых блоков, таких как PoW, обменивая вероятность на чувство безопасности.
Но другая сторона тоже очень проста: если одна треть или более голосов больше не обеспечивает голосов, необходимых для формирования коммита, оставшиеся валидаторы не смогут получить больше двух третей, как бы усердно они ни работали.
Самый безопасный выбор для сети на данный момент — «приостановить производство блоков», поэтому с точки зрения распределенной системы эта краткая приостановка Cosmos Hub на самом деле не является загадочной.
Словом, после того, как группа валидаторов с достаточным количеством голосов перестанет участвовать, протокол консенсуса, согласно его собственным правилам, скорее потеряет доступность, чем продолжит подтверждать новые блоки без достаточного консенсуса.
За этим на самом деле стоят две концепции в распределенных системах, которые обычные пользователи часто путают:
Безопасность: разные узлы не могут одновременно подтвердить два конфликтующих конечных состояния;
Живучесть: может ли сеть продолжать двигаться вперед и обрабатывать новые транзакции?
Для системы BFT, когда в консенсусе участвует недостаточно узлов, приостановка иногда является платой за поддержание безопасности. Грубо говоря, этот децентрализованный реестр скорее остановится на этом, чем позволит оставшимся людям вести свои собственные счета.
Оглядываясь назад с этой точки зрения, вы обнаружите, что многие, казалось бы, совершенно разные происшествия в истории публичных сетей на самом деле вращаются вокруг одного и того же:
Что делает сеть, когда распределенные узлы больше не могут договориться о «правильном состоянии»?
3. От Биткойна до Соланы, где находится реальная граница риска публичных сетей?
Это не первый раз, когда Cosmos поднимает эту проблему.
Еще в 2013 году у Биткойна произошла классическая авария с разветвлением цепи.
В то время Биткойн 0.8 переключил базовую базу данных с Berkeley DB на LevelDB, а затем появился блок, содержащий большое количество входных транзакций. Новая версия узла могла его нормально обработать, но некоторые узлы старой версии считали блок недействительным из-за ограничения на количество блокировок Berkeley DB.
Так возникла очень неловкая сцена. Все использовали Биткойн, но старые и новые клиенты начали по-разному отвечать на вопрос, «законен ли этот блок».
В результате сеть разделилась на две цепочки, и новая сторона версии 0.8 когда-то владела около 60% вычислительной мощности и не могла полагаться на нормальную конкуренцию по вычислительной мощности, чтобы быстро сходиться самостоятельно.
В конце концов, крупные майнинговые пулы объединились, чтобы вернуться к старой версии, вернув себе больше вычислительной мощности на стороне старых правил, и сеть снова объединилась. Позже Биткойн специально рассмотрел аварию с BIP 50.
В 2016 году инцидент с DAO в Ethereum еще больше продвинул проблему.
Как упоминалось выше в «Инциденте с DAO», сообщество Ethereum наконец реализовало специальную модификацию состояния, явно названную Ethereum Foundation «нерегулярным изменением состояния» посредством хард-форка на блоке 1 920 000, перенеся соответствующий ETH в контракт восстановления.
Но не все согласились с этим решением. Некоторые майнеры и сообщества, отказавшиеся принять изменение статуса, продолжали придерживаться первоначальных правил, и позже появился давний Ethereum Classic (ETC).
Этот форк DAO также является классическим событием, которое эквивалентно сообщению всем, что когда происходят экстремальные события, помимо консенсуса по коду существует также социальный консенсус. Если не удается сформировать достаточно последовательное мнение, цепочку действительно можно разделить на две части.
Solana 2021 года демонстрирует совершенно другой путь отказа.
В сентябре того же года в сеть хлынуло большое количество транзакций роботов, что привело к исчерпанию памяти узла проверки и сбою большого количества узлов. В итоге вся сеть не смогла прийти к единому мнению по текущему статусу и прекратила подтверждение новых блоков примерно на 17 часов. Затем валидаторы вместе работали над восстановлением сети.
Собрав эти случайности вместе, вы обнаружите, что это не одно и то же:
Проблема Биткойна в 2013 году заключается в том, что разные клиенты начинают применять разные правила действительности;
Проблема Соланы в 2021 году заключается в том, что большое количество узлов верификации не могут продолжать нормально участвовать в консенсусе, и сеть теряет Живучесть;
То, с чем сталкивается Ethereum DAO, ближе к вопросу о том, должно ли сообщество активно изменять статус с помощью новых правил протокола;
На этот раз Cosmos Hub имеет еще одну особенность. Сеть сначала активно теряет жизнеспособность из-за координации валидаторов, чтобы предотвратить дальнейшее перемещение активов атаки; затем достаточно высокая доля прав на проверку совместно принимает новое программное обеспечение и восстанавливает состояние, снова делая сеть согласованной;
Поэтому вместо того, чтобы просто приписывать эти инциденты тому, что «блокчейны могут отключиться» и «децентрализация — это фейк», лучше признать более реальный факт:
Механизм консенсуса никогда не является неразрушимой машиной. На самом деле он обеспечивает набор децентрализованных правил, например, кто будет определять правильную цепочку в случае возникновения разногласий; сколько участников смогут выйти в государственный финал; при возникновении сбоя сеть решает продолжить работу или остановиться; и в крайнем случае, какие коллективные действия могут изменить очередные правила работы.
Это также заставляет этот инцидент с Cosmos оставить вопрос, более достойный рассмотрения обычных пользователей, чем «стоит ли остановить цепочку?»
напиши в конце
Мы часто говорим: не ваши ключи, не ваши монеты.
Конечно, это предложение по-прежнему остается верным, но в нем подчеркивается контроль над активами — пока закрытый ключ находится в ваших руках, кошельки, торговые платформы или другие третьи стороны обычно не могут подписать за вас перевод.
Предполагается, что блокчейн, в котором вы находитесь, должен иметь возможность обрабатывать эту подпись в любое время.
В тот день, когда Cosmos Hub перестанет производить блоки, пользователи по-прежнему будут хранить свои закрытые ключи, а активы не исчезнут из воздуха. Однако даже если вы правильно подпишете транзакцию, нового блока для ее принятия не будет.
Процесс восстановления далее объясняет, что если достаточное количество участников консенсуса примут новый набор правил статуса, статус конкретной учетной записи в сети также может измениться без подписи закрытого ключа исходного адреса.
Это не отменяет фразу «Не ваши ключи, не ваши монеты», но напоминает нам, что автономия закрытого ключа и основные права консенсуса никогда не являются одним и тем же.
То же самое касается и кошельков.
Кошелек может гарантировать, что приватный ключ и права подписи находятся в руках пользователя, максимально быстро выявлять аномалии на уровне цепочки, точно отображать статус транзакции, устанавливать RPC и избыточность узлов, а также повторно подтверждать окончательный результат транзакции после восстановления сети.
Однако кошелек не может восстановить консенсус для публичной цепочки, а также не может гарантировать, что базовая сеть никогда не будет прервана, а также не может гарантировать, что правила и статус цепочки никогда не изменятся на уровне консенсуса.
Следовательно, то, к чему действительно должна стремиться зрелая децентрализованная система, никогда не может быть «ничего нельзя изменить»; напротив, эти несовершенные границы должны быть как можно более ясными: кто может приостановить консенсус? Какой вес нужен? В каких случаях допускается экстренное вмешательство?
Из-за истинной децентрализации система не может никогда не сталкиваться с авариями. Ключевым моментом является то, что даже если авария действительно произойдет, мы все равно можем знать, кто, в соответствии с какими правилами и с каким уровнем консенсуса определяет, как этот аккаунт должен быть записан дальше.