Реорганизация блокчейна (реорг)

Что такое реорг в криптовалюте?

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

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

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

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

О реорганизациях чаще всего говорят применительно к сетям Proof of Work и Proof of Stake, решениям Layer 2, мостам, кошелькам, платежным системам и торговым платформам, которым нужно определить, когда транзакцию можно считать окончательной.

В документации Ethereum об атаках и защите Proof of Stake реорг определяется как изменение порядка блоков, при котором в каноническую цепочку могут добавляться или из нее удаляться блоки.

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

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

Простое определение реорга

Реорг — это изменение того, какие недавние блоки блокчейн считает частью основной цепочки.

Старые блоки могут считаться устаревшими, осиротевшими или неканоническими — термин зависит от конкретной сети.

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

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

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

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

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

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

Почему реорганизации важны

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

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

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

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

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

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

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

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

Как происходит реорг

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

Это может произойти естественным образом: блокчейн — распределенная система, и новые блоки не доходят до всех узлов в один и тот же момент.

Одна группа узлов может первой получить блок A.

Другая группа узлов может первой получить блок B.

Оба блока могут быть действительными, но канонической станет только одна ветка.

Правила консенсуса сети определяют, какая ветка победит.

Если узел узнает, что другая действительная ветка стала сильнее согласно правилу выбора ветки, он переключается на нее.

Это переключение и называется реорганизацией блокчейна.

Реорг и форк

Форк — это разделение истории блокчейна, при котором существует более одной действительной ветки.

Реорг — это процесс переключения с одной ветки на другую.

Не каждый форк приводит к крупному реоргу.

Многие кратковременные форки быстро разрешаются: сеть выбирает одну ветку и отказывается от другой.

Хардфорк отличается тем, что меняет правила протокола и может привести к постоянному разделению сети, если сообщества продолжат поддерживать обе стороны.

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

При постоянном разделении образуются две продолжающие работу сети.

Реорг — это корректировка активного пути блокчейна в рамках процесса консенсуса одной сети.

Реорг и финализация

Финализация — это момент, после которого транзакцию крайне сложно или невозможно отменить в соответствии с правилами сети.

Финализация предотвращает реорг или делает его экономически нецелесообразным.

В документации Ethereum о Proof of Stake говорится, что транзакция финализирована, если она включена в блок, который нельзя изменить без сжигания значительного объема ETH.

В той же документации объясняется, что отмена финализированного блока Ethereum потребовала бы от злоумышленника потерять как минимум треть всего ETH в стейкинге.

В Bitcoin используется вероятностная финализация: каждый новый блок усложняет замену предыдущей истории.

В Solana уровни подтверждения, такие как processed, confirmed и finalized, помогают клиентам оценивать достоверность статуса транзакции.

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

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

Реорг и осиротевший блок

Осиротевший или устаревший блок — это действительный блок, который не остался в канонической цепочке.

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

В разных блокчейн-сообществах эти термины могут использоваться немного по-разному.

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

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

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

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

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

Реорг и двойное расходование

Двойное расходование — это попытка потратить одни и те же средства двумя несовместимыми способами.

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

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

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

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

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

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

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

Распространенные причины реорганизаций

Первая распространенная причина — задержка сети.

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

Вторая причина — одновременное создание блоков.

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

Третья причина — действия валидаторов или майнеров.

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

Четвертая причина — ошибки программного обеспечения или клиента.

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

Пятая причина — вредоносная атака.

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

Короткие реорганизации

При коротком реорге обычно заменяется один или небольшое число недавних блоков.

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

Они могут возникать естественным образом при обычной работе сети.

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

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

Торговое приложение, мост, оракул, бот для ликвидации или платежная система могут реагировать на самые новые блоки.

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

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

Глубокие реорганизации

При глубоком реорге заменяется множество блоков.

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

Они могут указывать на серьезную проблему сети, атаку, ошибку консенсуса, сбой валидаторов или масштабное разделение сети.

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

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

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

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

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

Реорганизации в сетях Proof of Work

В сетях Proof of Work узлы обычно выбирают действительную цепочку с наибольшей совокупной работой.

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

Канонической становится ветка с большей совокупной работой.

Узлы, следовавшие проигравшей ветке, переключаются на победившую.

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

Поэтому подтверждения играют ключевую роль в расчетах в сетях Proof of Work.

Каждый новый блок добавляет объем работы, который злоумышленнику необходимо преодолеть.

По мере увеличения глубины блока риск реорганизации снижается.

Реорганизации в сетях Proof of Stake

В сетях Proof of Stake реорганизация зависит от голосов валидаторов, правил выбора ветки, механизмов финализации, штрафов и условий слешинга.

В Ethereum используются правило выбора ветки LMD-GHOST и система финализации на основе голосования за контрольные точки.

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

Это означает, что до финализации возможны кратковременные расхождения.

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

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

Реорг в Proof of Stake оценивается не только по числу блоков.

Важно также учитывать, были ли замененные блоки финализированы, оправданы, подтверждены или только недавно предложены.

Реорганизации и подтверждения

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

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

Два подтверждения означают, что поверх этого блока построен еще один.

Как правило, чем больше подтверждений, тем ниже риск реорга.

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

Для небольших платежей может быть достаточно меньшего числа подтверждений.

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

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

Реорганизации и финализированные блоки

Финализированный блок сеть считает крайне сложным для удаления.

Финализация надежнее, чем простое включение транзакции в блок.

В Ethereum отмена блока после финализации повлекла бы серьезные экономические штрафы для злоумышленников.

В документации Solana о статусах подтверждения указано, что статус finalized присваивается, когда над целевым блоком построено не менее 31 подтвержденного блока.

В мостах и платежных системах финализация может определяться правилами исходной сети и политикой управления рисками приложения.

Финализированная транзакция обычно гораздо безопаснее транзакции, которая только обработана или недавно включена в блок.

Однако механизмы финализации в разных блокчейнах различаются.

Разработчикам не следует устанавливать одинаковый срок ожидания для всех сетей без учета их механизмов консенсуса.

Реорганизации и кошельки

Кошельки следует проектировать так, чтобы они корректно реагировали на реорганизации.

Сначала кошелек может показывать транзакцию как ожидающую подтверждения.

Затем — отображать одно или несколько подтверждений.

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

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

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

Кошелькам не следует слишком рано помечать транзакции на крупные суммы как окончательные.

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

Реорганизации и обозреватели блокчейна

Обозреватели блокчейна отслеживают текущую каноническую цепочку и отображают пользователям статус транзакций.

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

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

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

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

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

Индексаторам необходимо хранить достаточно истории, чтобы откатывать данные, затронутые реоргом.

Обозреватель удобен для просмотра информации, но источником достоверных данных являются каноническая цепочка узла и правила финализации.

Реорганизации и биржи

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

Это снижает вероятность того, что депозит исчезнет в результате реорга после зачисления средств пользователю.

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

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

Во время необычной активности реоргов платформа может также приостанавливать депозиты и выводы средств.

Пользователям может казаться, что ожидание зачисления депозита — лишь задержка, но это также мера контроля рисков.

Если платформа зачислит депозит слишком рано, а реорг его удалит, она может понести убытки.

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

Реорганизации и мосты

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

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

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

Это может привести к недостаточному обеспечению активов или расхождениям в учете.

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

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

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

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

Реорганизации и сети Layer 2

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

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

В документации Circle по финализации отмечается, что некоторые системы Layer 2 зависят от того, когда пакеты публикуются в Ethereum и когда финализируется соответствующий блок Ethereum.

Поэтому необходимо учитывать два уровня финализации.

Это может быть локальное подтверждение в Layer 2 и финализация на расчетном уровне.

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

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

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

Реорганизации и MEV

MEV, или максимальная извлекаемая стоимость, — это стоимость, которую производители блоков или участники, упорядочивающие транзакции, могут получить, включая, исключая или переставляя транзакции.

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

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

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

Финализация снижает такой риск, делая глубокую замену блоков более затратной.

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

Риск реорганизаций, связанных с MEV, особенно важен для крупных сделок в DeFi, ликвидаций, арбитража, обновлений оракулов и операций с мостами.

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

Реорганизации и оракулы

Оракулы передают данные из внешних источников или других сетей в смарт-контракты.

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

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

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

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

В кроссчейн-оракулах реорг в исходной сети может повлиять на контракты в целевой сети.

При проектировании оракулов необходимо четко определять допущения о финализации.

Смарт-контрактам, использующим оракулы, следует учитывать, являются ли данные оракула немедленными, подтвержденными или финализированными.

Реорганизации и индексаторы

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

Реорганизации создают серьезную проблему для индексаторов: уже проиндексированные данные может потребоваться откатить.

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

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

Индексаторам следует отслеживать хеши блоков, хеши родительских блоков, номера блоков, статус финализации и глубину отката.

Не следует сразу считать новые блоки окончательными.

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

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

Реорганизации и смарт-контракты

Смарт-контракты выполняются в соответствии с состоянием канонической цепочки.

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

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

Это важно для DeFi, поскольку состояние может меняться быстро.

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

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

Смарт-контракты сами по себе не «помнят» историю удаленного блока, если она не входит в каноническую цепочку.

Офчейн-сервисы, связанные со смарт-контрактами, должны учитывать возможность реорганизаций.

Реорганизации и обработка платежей

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

Прием платежей без подтверждений ускоряет процесс, но сопряжен с риском.

Одно подтверждение снижает риск, но не устраняет его.

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

Подходящая политика зависит от суммы платежа и стоимости мошенничества.

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

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

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

Реорганизации и статус транзакции

Во время реорга транзакция может пройти несколько статусов.

Она может быть отправлена в сеть, но оставаться неподтвержденной.

Она может быть включена в блок.

Она может получить подтверждения.

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

Если транзакция остается действительной, она может снова перейти в статус ожидающей подтверждения.

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

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

Реорганизации и комиссии за газ

Поведение комиссии за газ во время реорга зависит от устройства блокчейна и итогового канонического статуса транзакции.

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

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

Если транзакция не была выполнена в канонической истории, значит, в итоговой цепочке такое исполнение не состоялось.

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

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

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

При высокой нагрузке на сеть из-за реорганизаций и волатильности комиссий отслеживание транзакций может выглядеть непоследовательно.

Управление риском реорганизации

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

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

Второй инструмент — политика с учетом особенностей сети.

В разных сетях различаются время создания блока, механизмы финализации, наборы валидаторов и стоимость атаки.

Третий инструмент — мониторинг.

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

Четвертый инструмент — отложенное проведение расчетов.

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

Реорганизации и атаки 51%

Атака 51% — это ситуация, в которой злоумышленник контролирует достаточно мощности майнинга или влияния на стейк, чтобы воздействовать на каноническую историю сети.

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

В системах Proof of Stake злоумышленник может попытаться повлиять на выбор ветки, задержать финализацию или провести более серьезные атаки, за которые предусмотрены штрафы.

В документации Ethereum отмечается, что злоумышленники в Proof of Stake могут пытаться вызвать реорг, добиться двойной финализации или задержать ее.

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

Стоимость и осуществимость атаки зависят от модели безопасности сети.

Атаковать зрелые сети, как правило, сложнее, чем небольшие сети с недостаточной защитой майнинга или стейкинга.

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

Реорганизации и разделение сети

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

Во время такого разделения разные группы узлов могут строить разные ветки блокчейна.

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

Разделение сети может быть вызвано сбоями интернет-маршрутизации, проблемами клиентов, атаками типа «отказ в обслуживании» или отказами инфраструктуры.

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

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

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

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

Реорганизации и ошибки клиентов

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

Если один клиент принимает блок, который другой отклоняет, сеть может разделиться до устранения проблемы.

Поэтому важны разнообразие клиентов, тестирование, аудит и координация обновлений.

Разделение сети из-за ошибки может быть опаснее обычного реорга на один блок, поскольку оно может затронуть сам механизм консенсуса.

Во время нестандартной работы сети приложениям следует отслеживать официальные уведомления о клиентах.

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

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

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

Реорганизации и откат

Откат — это более общий термин, обозначающий возврат состояния к более ранней точке.

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

После реорга приложению может потребоваться откатить внутреннее состояние.

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

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

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

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

Системам, которые не могут допустить откат, следует дождаться надежной финализации.

Реорганизации и безопасность пользователей

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

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

Следует учитывать, что в разных сетях действуют разные нормы подтверждения.

Будьте особенно осторожны во время форков, перебоев, атак, операций с мостами и необычной работы сети.

Используйте кошельки и сервисы, которые понятно отображают статус подтверждения.

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

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

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

Безопасность разработчиков при реорганизациях

Разработчикам следует исходить из того, что реорганизации возможны.

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

Храните хеши блоков и родительских блоков, а не только номера блоков.

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

Реализуйте логику отката проиндексированных событий.

Определите пороги подтверждений для каждой сети и уровня стоимости операции.

Различайте финализацию и включение в блок.

Тестируйте работу систем в тестовых сетях, где можно моделировать реорганизации.

Преимущества понимания реорганизаций

Во-первых, это помогает безопаснее принимать платежи.

Во-вторых, это способствует более надежному проектированию мостов.

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

В-четвертых, повышает надежность индексаторов и приложений.

В-пятых, улучшает управление рисками при зачислении депозитов и выводе средств для торговли.

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

В-седьмых, повышает защиту от попыток двойного расходования.

Понимание реорганизаций помогает пользователям осознать, что расчет в блокчейне — это процесс, а не единичный момент.

Ограничения защиты от реорганизаций

Подтверждения снижают риск реорганизации, но не исключают все возможные атаки.

Финализация еще сильнее снижает риск реорга, но механизмы финализации различаются в разных сетях.

В небольшой сети с низким уровнем безопасности по-прежнему возможен глубокий реорг.

Мост может выйти из строя, если неправильно учитывает финализацию в исходной сети.

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

Даже стабильная сеть не защищает смарт-контракт от других ошибок.

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

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

Распространенные заблуждения о реорганизациях

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

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

Другое заблуждение — считать все реорганизации атаками.

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

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

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

Также ошибочно полагать, что финализация везде означает одно и то же.

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

Тревожные признаки реорганизации

Насторожить должна платформа, зачисляющая крупные депозиты без правил подтверждения.

Еще один тревожный признак — мост, который выпускает активы до ясной финализации в исходной сети.

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

Еще один тревожный признак — индексатор, который хранит только номера блоков, но не их хеши.

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

Насторожить должна необычная серия реорганизаций в сети, где обычно финализация проходит стабильно.

Еще один тревожный признак — небольшая сеть Proof of Work с низкой мощностью хеширования, принимающая крупные депозиты после слишком малого числа подтверждений.

Опасность представляет dApp, реагирующее на самые новые блоки без объяснения допущений о финализации.

Рекомендации для пользователей

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

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

Будьте осторожны во время форков, перебоев или необычной активности сети.

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

Учитывайте, что в разных сетях используются разные механизмы финализации и подтверждения.

Для отслеживания транзакций используйте надежные кошельки и обозреватели.

При кроссчейн-переводах выбирайте более медленные варианты финализации, если безопасность важнее скорости.

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

Рекомендации для разработчиков

Отслеживайте хеши блоков и родительских блоков, номера блоков, хеши транзакций и статус финализации.

Проектируйте индексаторы и базы данных с поддержкой отката.

Используйте пороги подтверждений, подходящие для каждой сети.

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

Четко отображайте статус подтверждения в интерфейсе.

Для выявления расхождений в представлении цепочки используйте несколько надежных узлов или провайдеров.

Тестируйте работу приложения в условиях смоделированных реорганизаций.

Документируйте допущения о финализации для пользователей, аудиторов и партнеров по интеграции.

Почему реорг важен для AEO и поисковых запросов

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

Краткий ответ: реорг происходит, когда сеть заменяет недавние блоки другой действительной веткой блокчейна.

Также пользователи хотят знать, не потеряны ли их средства.

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

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

Ответ зависит от блокчейна, суммы транзакции, механизма финализации и готовности к риску.

Главный вывод для пользователей криптовалют прост.

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

FAQ

Что такое реорг?

Реорг — это реорганизация блокчейна, при которой узел заменяет часть текущей принятой цепочки другой действительной веткой.

Что означает реорганизация блокчейна?

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

Может ли реорг удалить мою транзакцию?

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

Реорг всегда является атакой?

Нет. Короткие реорги могут происходить естественным образом из-за задержки сети или одновременного создания блоков, но возможны и вредоносные реорги.

Что такое реорг на один блок?

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

Что такое глубокий реорг?

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

Почему подтверждения снижают риск реорганизации?

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

Сколько подтверждений достаточно?

Это зависит от сети, суммы транзакции, механизма финализации и готовности к риску.

Могут ли финализированные блоки подвергнуться реорганизации?

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

Как реорганизации влияют на мосты?

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

Как реорганизации влияют на кошельки?

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

Как разработчики работают с реорганизациями?

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

Какова главная ошибка при работе с реорганизациями?

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

Заключение

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

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

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

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

Поэтому подтверждения и финализация имеют ключевое значение для расчетов в криптовалюте.

Системы на основе Bitcoin в значительной степени опираются на увеличение глубины подтверждений, а системы на основе Ethereum с Proof of Stake сочетают выбор ветки с экономической финализацией.

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

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