45 / 691REORG

Reorg

Реорганизация цепочки

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

Reorg — это локальное изменение chainstate, а не правил консенсуса Bitcoin. Full Node применяет собственные правила проверки и активирует прошедшую их ветвь с наибольшим совокупным chainwork. Если она ответвляется ниже текущей вершины, узел отменяет изменения UTXO отключённых блоков, применяет альтернативную ветвь и заново оценивает затронутые транзакции относительно mempool.

Bitcoin Core не выбирает просто самую высокую или популярную ветвь. При активации цепочка-кандидат должна соответствовать правилам консенсуса узла; больший chainwork не делает невалидный блок валидным. FindMostWorkChain выбирает кандидата с наибольшей работой, о невалидности которого ещё не известно. Это пока не означает полной проверки: дополнительные проверки выполняются при подключении блоков в ActivateBestChain. Ветви с известной невалидностью исключаются. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

Точка ветвления — последний общий блок текущей активной цепочки и альтернативной ветви. Глубину Reorg обычно описывают числом блоков активной вершины, которые необходимо отключить, чтобы вернуться к этому общему предку. Reorg одного блока заменяет вершину, более глубокий отменяет несколько подтверждённых блоков. Глубина зависит от состояния конкретного узла. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

DisconnectTip и связанная логика проверки отменяют последствия отключённых блоков в обратном порядке. Потраченные UTXO восстанавливаются, а выходы, созданные удалённым блоком, теряют подтверждение. Поэтому Bitcoin Core хранит данные отмены: он должен точно восстановить набор UTXO в точке ветвления. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

После отката ConnectTip подключает блоки ветви с большим chainwork в прямом порядке. Каждая транзакция заново проверяется относительно восстановленного набора UTXO и правил, действующих на данной высоте. Результат — chainstate, соответствующий одной конкретной истории, а не смесь транзакций обеих ветвей. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

Транзакции из отключённых блоков не обязательно исчезают. Bitcoin Core пытается вернуть подходящие транзакции, кроме coinbase, в mempool. Некоторые уже могут находиться в новой ветви, конфликтовать, потерять входы, перестать удовлетворять временным условиям или политике mempool. Поэтому кошелёк должен учитывать, что Reorg может отменить подтверждение. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

Транзакция coinbase — исключение: после отключения она не возвращается в mempool. По правилам консенсуса выход coinbase, созданный на высоте h, можно впервые потратить в блоке h + 100. При вершине h + 99 исходный блок имеет 100 подтверждений, и условие зрелости позволяет включить трату в следующий блок. Если Reorg удаляет блок с coinbase, награда этого блока исчезает из активного chainstate. Невалидными могут стать и зависимые транзакции, опиравшиеся на удалённую историю. [Bitcoin Core v29.0 — chain activation and mempool reconciliation] [Bitcoin Core v29.0 — coinbase maturity validation] [Bitcoin Core v29.0 — confirmation depth]

Число подтверждений включает блок с транзакцией и все последующие блоки в текущей активной цепочке конкретного узла. Транзакция в текущей вершине имеет одно подтверждение. Каждый дополнительный блок обычно увеличивает работу, необходимую для замены истории, но никакое конечное число подтверждений не создаёт математически абсолютной окончательности. Биржи и продавцы выбирают порог в соответствии с суммой платежа и своей моделью риска. [Bitcoin Core v29.0 — confirmation depth] [Bitcoin whitepaper — Sections 5 and 11]

Короткий Reorg может возникнуть естественным образом, когда два майнера почти одновременно находят конкурирующие блоки и разные части сети некоторое время следуют разным вершинам; ветвь с меньшим chainwork становится неактивной. Атака Double Spend использует тот же механизм намеренно. Техническая процедура выбора цепочки одинакова, различаются причина и экономическая цель. [Bitcoin Developer Guide — Block Chain] [Bitcoin whitepaper — Sections 5 and 11]

Reorg происходит в рамках одного набора правил: узел выбирает между ветвями, которые считает валидными. Hard Fork изменяет правила валидности так, что старое и новое программное обеспечение могут не соглашаться уже в том, валиден ли блок. Поэтому реорганизация сама по себе не меняет консенсус. [Bitcoin Developer Guide — Block Chain]

В Bitcoin Core v29.0 шаги заданы явно: FindMostWorkChain находит кандидата с наибольшим chainwork без известной невалидности, ActivateBestChainStep может отключить текущую вершину, ConnectTip проверяет и подключает альтернативные блоки, а MaybeUpdateMempoolForReorg заново проверяет транзакции отключённых блоков. Активация может выявить невалидность кандидата и продолжить поиск другой ветви. Крупный Reorg требует обработки большего числа отключённых и подключённых блоков, поэтому может увеличить время выполнения ActivateBestChain. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]

Для полной картины прочитайте эту статью вместе с Подтверждение, Proof of Work, Stale Block, Двойная трата, Full Node, UTXO. На эту статью также ссылаются Подтверждение, Двойная трата, Coinbase-транзакция, Soft Fork.

DOC · 001Bitcoin Core v29.0 — chain activation and mempool reconciliationПервичный источник ↗DOC · 002Bitcoin Core v29.0 — coinbase maturity validationПервичный источник ↗DOC · 003Bitcoin Core v29.0 — confirmation depthПервичный источник ↗DOC · 004Bitcoin Developer Guide — Block ChainДокументация ↗DOC · 005Bitcoin whitepaper — Sections 5 and 11Первичный источник ↗
Сначала источники · Не является инвестиционной рекомендацией