Реорганизации цепочки Bitcoin и накопленная работа: смысл подтверждений

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

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

Кандидат должен выполнить целевое значение proof-of-work и все применимые правила консенсуса. Каждый допустимый блок добавляет работу, рассчитанную по его цели. Накопленная работа цепочки — сумма работы всех её блоков, поэтому простого подсчёта недостаточно, если ветви содержат блоки с разными целями сложности.

Две ветви от общего родителя могут иметь одну высоту, но различную накопленную работу. Если допустимая ветвь накопила больше работы и стала сильнейшим кандидатом, узел может переключиться на неё. Bitcoin Core 31.0 показывает общую работу активной цепочки в поле chainwork команды getblockchaininfo. Сравнивайте хеши блоков и контекст работы, а не только высоту.

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

Выражение «цепочка с наибольшей работой» ограничено и информацией, полученной узлом. Узлы узнают о заголовках и блоках от пиров, поэтому задержка сети временно создаёт разные представления. Изолированный, не синхронизированный или устаревший узел может не знать допустимую ветвь, известную обновлённому узлу. Руководство по P2P-сети Bitcoin объясняет, как объявляют и передают блоки. Проверка блоков узлом и получение сетевой информации — разные процессы.

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

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

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

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

Если выбранная ветвь содержит конфликтующую трату, прежняя транзакция может стать недопустимой при текущем состоянии UTXO. В других случаях её включат позже, она останется неподтверждённой или исчезнет из мемпула конкретного узла. После реорганизации кошелькам и сервисам следует обновить связь транзакции с блоком и число подтверждений. Bitcoin Core getchaintips показывает вершины, известные этому узлу, а не всей сети.

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

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

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

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

Bitcoin Core 31.0 в getblockchaininfo сообщает сеть, высоту проверенной цепочки, число заголовков, хеш лучшего блока, накопленную работу активной цепочки и поля синхронизации. getchaintips перечисляет известные этому узлу вершины со статусами active, valid-fork, valid-headers, headers-only или invalid. Это помогает отличить проверенную боковую ветвь от заголовков, которые узел ещё не обработал полностью.

Результат RPC — снимок одной машины, а не заявление всей сети. При начальной синхронизации или плохом соединении узел может отставать или знать меньше ветвей. Проверьте сеть, последний хеш блока, состояние проверки и синхронизации, а также активность наблюдаемой вершины. Справочник RPC Bitcoin Core 31.0 привязан к версии; сверяйте поля и команды с версией Core, которую запускаете.

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

Подтверждения протокола при депозите и политика зачисления получателя — разные вещи. Руководство по подтверждениям депозита рассматривает зачисление биржей и поддержку актива; здесь объясняется выбор ветви Bitcoin. Об проверке узла, pruning и ограничениях локального представления читайте в [руководстве по полному узлу Bitcoin](/ru/learn/bitcoin-full-node-pruning-archive-storage-validation-wallet-trust-explained). Не отправляйте транзакцию повторно лишь из-за изменения экрана: сначала проверьте её состояние и инструкции сервиса.