М’який форк — це скоординований перехід від набору валідності V(old) до його підмножини V(new). Активація визначає блок, з якого оновлені повні вузли застосовують обмеження. Сигналізація майнера може координувати готовність, але дійсність визначається правилом, яке виконується у вузлах; проектування, реалізація, розгортання, активація та прийняття – це не одне й те саме.
Позначимо V(old) усі блоки, прийняті правилами до оновлення. Зміна є м’яким форком, лише якщо V(new) знаходиться всередині V(old): новий вузол відхилить наступний клас блоків, але блок, який відповідає новим правилам, також пройде старі перевірки. Назва говорить про сумісність правил дійсності, а не про розмір, безпеку чи соціальну сумісність зміни. Збільшення ліміту, видимого для старого вузла, або дозвіл раніше недійсних витрат розширює пул і зазвичай вимагає хардфорка. [Посібник для розробників біткойнів — Зміни в правилах консенсусу] [Bitcoin Optech — активація програмного форка]
Старий повний вузол може продовжувати слідувати ланцюжку, оскільки оновлені майнери регулярно створюють блоки, які він розпізнає. Але це не перевіряє додану умову. Якщо гілка з більшою кількістю роботи порушує нове правило, старий вузол може це прийняти, а оновлений вузол відхиляє. Ті, кому потрібна нова гарантія, повинні оновити власне програмне забезпечення перевірки; здатність гаманця приймати оплату, сумісність формату та повна консенсусна перевірка – це різні речі. [Посібник розробника біткойнів — Зміни в правилах консенсусу] [BIP 341 — Розгортання Taproot]
Біткойн створив підмножини за допомогою кількох методів. BIP66 заборонив нестрогі підписи DER, які допускалися старими правилами. BIP65 і BIP112 додали умови до кодів операцій NOP, які старий інтерпретатор вважав успішним бездіяльністю. SegWit і Taproot надали значення зарезервованим версіям програми-свідка, які старий вузол розглядає як будь-хто може витратити. У той же час конструкція повинна запобігати обходу нового контролю; Таким чином, SegWit передав дані свідків через coinbase і зберіг старі основні правила блокування. [BIP 66 — Суворі підписи DER] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Сегрегований свідок] [BIP 341 — Розгортання Taproot]
Код може містити неактивне правило задовго до того, як воно почне діяти в основній мережі. BIP і перевірена реалізація не є розгортаннями, параметри розгортання не є блокованими, блокування лише планує майбутнє виконання, і лише стан ACTIVE означає перевірку даного блоку. Кожен вузол обчислює стан від предків своєї власної гілки. Реорганізація на межі може перерахувати його, і програмне забезпечення з іншими параметрами може почати застосовувати несумісні правила. [BIP 9 — біти версії з тайм-аутом і затримкою] [Bitcoin Core — versionbits.cpp]
BIP9 призначає назву, розрядну версію, час початку та час очікування для розгортання. Оригінальний варіант основної мережі оцінює періоди після 2016 блоків: після принаймні 1916 блоків сигналізації, тобто 95%, він переходить від STARTED до LOCKED_IN, очікує один період і потім стає АКТИВНИМ; інакше це може завершитися НЕВДАЄЮ. Повна послідовність: ВИЗНАЧЕНО, ЗАПУЩЕНО, ЗАБЛОКОВАНО, АКТИВНО та НЕВДАНО. Стан блоку залежить від його предків, а не від його власної nVersion, і сигналізація після блокування більше не змінює результат. [BIP 9 — біти версії з тайм-аутом і затримкою]
Versionbits вказує на готовність майнера та координує перехід; вони не надають майнерам постійне право власності на консенсус. BIP8 використовує висоти та за допомогою lockinontimeout може примусово передавати сигнали в останньому вікні. BIP148, з іншого боку, наказує вузлам-учасникам відхиляти сигнальні блоки, що не належать до SegWit; BIP91 знизив поріг майнінгу, щоб узгодити цей тиск. Обов’язкова активація може розділити ланцюжок, якщо вузли, швидкість хешування та економічне впровадження відрізняються, тому навіть метод активації є компромісом для безпеки. [BIP 8 — біти версії з блокуванням за висотою] [BIP 148 — обов’язкова активація SegWit] [BIP 91 — знижений поріг SegWit MASF] [Bitcoin Optech — активація Soft fork]
P2SH під BIP16 був активований у 2012 році сигналом coinbase і часовим обмеженням. BIP34 використовував блочну версію та поріг для обов’язкової висоти в coinbase. Та сама цілочисельна процедура запускала суворий DER у BIP66 та CHECKLOCKTIMEVERIFY у BIP65, але споживала значення версій і не могла виконувати одночасне розгортання. Тому BIP9 представив незалежні біти. Потім BIP68, BIP112 і BIP113 активувалися разом як відносний час блокування та CSV на висоті 419 328 у 2016 році. [BIP 16 — Оплата за хеш сценарію] [BIP 34 — Блок v2, висота в coinbase] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — Суворі підписи DER] [BIP 112 — CHECKSEQUENCEVERIFY]
SegWit активовано на 481 824 у серпні 2017 року. Старий вузол бачить транзакцію без даних свідків і вважає свідок v0 як будь-хто може витратити; оновлений свідок перевірки, новий дайджест підпису та правила запобігання податливості. Зобов’язання Merkle стежити за даними у вихідних даних coinbase запобігає майнеру змінювати або пропускати дані без виявлення. Платіж за вагою збільшив ефективну ємність без базового блоку, видимого для старого вузла, що перевищує старий ліміт в один мегабайт. [BIP 141 — Відокремлений свідок]
BIP341 і BIP342 свідчать про витрати програмного шляху ключа та сценарію версії 1 із підписами Schnorr і Tapscript. Старий вузол знову розглядає зарезервовану програму як будь-хто може витрачати: підмножина зберігається, повна перевірка – ні. Основна мережа використовувала модифікований BIP9 Speedy Trial з порогом 1815 з 2016 блоків, або 90%, і мінімальною висотою активації 709 632. Taproot активовано в ньому 14 листопада 2021 року; Правила Taproot і те, як їх активувати, — це два окремих питання аудиту. [BIP 341 — Розгортання Taproot] [BIP 342 — Tapscript] [Примітки до випуску Bitcoin Core 0.21.1 — Розгортання Taproot]
Коли BIP66 було активовано в липні 2015 року, деякі майнери повідомили про нову версію, але недостатньо перевірили батьківський блок, на якому вони майніли. Вони розширили недійсний блок і 4 липня створили недійсну гілку з шести блоків; наступного дня відбувся ще один коротший інцидент. Оновлені вузли перевірки відхилили обидві гілки. Номер або біт версії є заявою майнера, а не доказом того, що він сам перевірив шаблон, батьків і транзакції. [BIP 66 — Суворі підписи DER] [Bitcoin.org — попередження BIP66 про ланцюгову вилку за липень 2015 р.]
У АКТИВНОМУ стані оновлені вузли відхиляють блок, що порушує, незалежно від частки хеш-рейту; чи виникне постійний поділ, залежить від роботи філій та їх господарського використання. Просте усунення обмеження знову ввімкне сьогоднішні недійсні блоки, і тому це хардфорк; параметри або код можна замінити скоординованим випуском перед активацією. Оператор перевіряє власну версію, getdeploymentinfo або getblockchaininfo, точні параметри, висоту активації та журнали. Ні граф сигналізації, ні мітка дослідника не можуть замінити локальну перевірку. [Посібник розробника біткойнів — зміни в правилах консенсусу] [Bitcoin Core — versionbits.cpp] [Примітки до випуску Bitcoin Core 0.21.1 — розгортання Taproot]
Для повної картини прочитайте також Правила консенсусу, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Hard Fork, Bitcoin. На цю статтю також посилаються Hard Fork, BIP (Bitcoin Improvement Proposal), Правила консенсусу, Reorg.