Reorg

Анна отримує 20 000 сатоші — дрібних одиниць біткоїна. Гаманець показує одне підтвердження: платіж є в блоці, який прийняв її вузол. Потім вузол дізнається про конкурентну дійсну гілку, де цього платежу поки немає. Щойно вона засвідчує більше накопиченої роботи майнінгу, вузол переходить на неї. Така заміна частини історії називається Reorg. Платіж Анни може знову чекати підтвердження, хоча ніхто не викрадав її ключі й не змінював підпис. Вирішує не голосування і не просто кількість блоків, а chainwork: сума роботи, яку кожен блок засвідчує відповідно до своєї складності. Недійсну гілку вузол відхилить навіть за більшої роботи. [1] [4]

Що Анна побачить далі, залежить від нової гілки. Якщо платіж є і в ній, він залишається підтвердженим, хоча кількість підтверджень може змінитися. Інакше Bitcoin Core може спробувати повернути його до Mempool — свого тимчасового списку непідтверджених транзакцій, що чекають на блок. Повернення не гарантоване. Вихід попередньої транзакції містить запис суми та умов її витрачання. Нова гілка могла вже витратити ті самі кошти іншою транзакцією; також може бракувати попереднього виходу, який витрачається, або не виконуватися часові чи інші умови прийняття. Тому платіж, який знову чекає, відрізняється від платежу, якого нова історія вже не допускає. [1]

Одне підтвердження означає блок із платежем. Кожен наступний блок додає підтвердження і роботу, яку конкурентній гілці потрібно перевершити. Отже, платіж в останньому блоці має одне підтвердження; що глибше він у прийнятій історії, то складніше зазвичай замінити цю її частину. Проте жодна скінченна кількість підтверджень не гарантує математично, що заміна неможлива. Тому продавці й біржі обирають час очікування відповідно до суми платежу та прийнятного ризику. [3] [5]

Сам Reorg не доводить атаки. Двоє майнерів можуть майже одночасно знайти блоки зі спільним попередником. Інформація поширюється не миттєво, тому вузли певний час бачать різні кінці ланцюга. Коли одна дійсна гілка накопичить більше роботи, вузли перейдуть на неї; залишений блок — це Stale Block. Однак цей механізм можна використати для атаки Double Spend: нападник намагається нав’язати історію, де ті самі кошти сплачено в інше місце. Тому важливо з’ясувати причину переходу й те, які платежі він змінив. [4] [5]

Під час Reorg вузол зберігає ті самі правила та вибирає між історіями, які їм відповідають. Hard Fork змінює правила допустимості блоків: старе й нове програмне забезпечення можуть по-різному оцінити той самий блок. Отже, реорганізація сама собою не створює нової валюти й не переписує правил Bitcoin. Наступні розділи пояснюють, як вузол технічно змінює історію. [4]

Tip — це останній блок гілки, яку вузол наразі приймає. Точка розгалуження — останній спільний блок поточного активного ланцюга й альтернативної гілки. Глибину Reorg зазвичай описують кількістю блоків із кінця активного ланцюга, які треба від’єднати, щоб повернутися до цього спільного предка. Одноблоковий Reorg замінює вершину, глибший скасовує кілька підтверджених блоків. Глибина залежить від погляду конкретного вузла. [1]

Full Node самостійно перевіряє правила. Назви функцій нижче описують їх реалізацію в Bitcoin Core. Bitcoin Core не обирає просто найвищу чи найпопулярнішу гілку. Під час активації ланцюг-кандидат має відповідати правилам консенсусу вузла; більший chainwork не робить невалідний блок валідним. FindMostWorkChain обирає кандидата з найбільшою роботою, про невалідність якого ще не відомо. Це ще не означає повної перевірки: додаткові перевірки виконуються під час приєднання блоків у ActivateBestChain. Відомі невалідні гілки відкидаються. [1]

UTXO — невитрачений вихід транзакції; набір UTXO охоплює такі доступні виходи. Дані undo зберігають інформацію для скасування наслідків блоку. DisconnectTip і пов’язана логіка перевірки скасовують наслідки від’єднаних блоків у зворотному порядку. Витрачені UTXO відновлюються, а виходи, створені вилученим блоком, втрачають підтвердження. Саме тому Bitcoin Core зберігає дані скасування: він має точно відновити набір UTXO в точці розгалуження. [1]

Rollback тут означає повернення до стану перед від’єднаними блоками; chainstate — робочий стан вузла, що відповідає прийнятій історії. Після відкату ConnectTip приєднує блоки гілки з більшим chainwork у прямому порядку. Кожна транзакція знову перевіряється щодо відновленого набору UTXO та правил, чинних на відповідній висоті. Результат — chainstate, що відповідає одній конкретній історії, а не суміш транзакцій з обох гілок. [1]

Coinbase Transaction — перша транзакція блоку, яка призначає майнеру винагороду. Висота h позначає місце блоку в ланцюзі. Транзакція coinbase є винятком: після від’єднання вона не повертається до mempool. За правилами консенсусу вихід coinbase, створений на висоті h, можна вперше витратити в блоці h + 100. Коли вершина перебуває на h + 99, вихідний блок має 100 підтверджень, а умова зрілості дозволяє включити витрату до наступного блоку. Якщо Reorg вилучає блок із coinbase, винагорода цього блоку зникає з активного chainstate. Невалідними можуть стати й залежні транзакції, що спиралися на вилучену історію. [1] [2] [3]

Далі наведено назви функцій конкретної версії програми, а не додаткові дії користувача гаманця. У Bitcoin Core v29.0 кроки визначені явно: FindMostWorkChain знаходить кандидата з найбільшим chainwork без відомої невалідності, ActivateBestChainStep може від’єднати поточну вершину, ConnectTip перевіряє й приєднує альтернативні блоки, а MaybeUpdateMempoolForReorg повторно перевіряє транзакції з від’єднаних блоків. Активація може виявити невалідність кандидата й продовжити пошук іншої гілки. Великий Reorg потребує обробки більшої кількості від’єднаних і приєднаних блоків, тому може подовжити виконання ActivateBestChain. [1]