Soft Fork

Уявімо Анну й Павла, які перевіряють Bitcoin кожен на власному комп’ютері. Анна оновила програму, Павло ще ні. З’являється зміна на зразок BIP66: цифрові підписи, що підтверджують право витратити певні біткоїни, мають відповідати точніше визначеному формату. Деякі раніше прийнятні способи кодування більше не дозволені. Платіж із правильним підписом у новому обов’язковому форматі проходить цю перевірку в обох. Але якщо підпис закодовано способом, який раніше дозволявся, а тепер заборонений, Анна його відхилить, тоді як Павло ще може прийняти. Припускаємо, що платіж відповідає решті правил. Саме в цьому суть Soft Fork: нові правила забороняють додаткові випадки, не дозволяючи нічого з того, що забороняли старі. Поки майнери створюють блоки за суворішими правилами, обидва можуть далі стежити за ланцюгом. Проте Павло сам не перевіряє додану умову. Отже, Soft Fork дозволяє змінювати Bitcoin без одночасного оновлення всіх вузлів. Це не означає, що стара програма перевіряє все те саме, що нова, і саме собою не створює другої валюти. [1] [6]

Full Node — це комп’ютер, який самостійно перевіряє правила Bitcoin. Обираючи між чинними гілками, він порівнює накопичену роботу, доведену майнінгом, а не голоси прихильників. Старий повний вузол може йти за ланцюгом, бо оновлені майнери зазвичай створюють прийнятні для нього блоки. Додаткову умову він не перевіряє: гілку з більшою роботою, яка її порушує, він може прийняти, а нові вузли — відкинути. Для нової гарантії треба оновити власний валідатор. Отримати платіж, розпізнати формат і перевірити весь консенсус — не одне й те саме. [1] [12]

BIP — це пронумерована технічна пропозиція. Її публікація ще не змінює мережу: потрібно розробити й перевірити програму, а користувачі мають вирішити, чи запускатимуть її. Mainnet — основна мережа Bitcoin, де переказують справжні біткоїни. Активація визначає, відколи оновлені вузли вимагатимуть дотримання нового правила. Отже, наявність коду в програмі ще не означає його застосування для перевірки блоків. В описаних тут процедурах lock-in означає, що умову подальшої активації виконано; саме правило може ще не діяти. Вузол перевіряє його лише у стані ACTIVE. Цей стан він обчислює за попередніми блоками власної гілки. Якщо реорганізація змінить історію поблизу межі активації, результат теж може змінитися. Тому дві програми з різними параметрами активації можуть одночасно приймати різні блоки. [2] [15]

Майнер будує блок на попередньому блоці, який також називають батьківським. Якщо його не перевірити, можна змарнувати роботу на гілку, яку інші вузли відхилять. У липні 2015 року деякі майнери сигналізували BIP66, але недостатньо перевіряли батьківський блок. Вони продовжили нечинний блок, утворивши 4 липня шестиблокову нечинну гілку; наступного дня сталася ще одна. Оновлені вузли їх відхилили. Версія — твердження майнера, а не доказ незалежної перевірки шаблону, предка й транзакцій. [6] [14]

Щоб дізнатися, які правила насправді застосовує ваш вузол, почніть із версії програми та даних, які він повертає сам. Залежно від версії команди getdeploymentinfo і getblockchaininfo повідомляють про впроваджені зміни та ланцюг. Разом із документацією випуску, висотою активації й журналами вони допомагають відрізнити підготовлене правило від уже активного. Вебоглядач блоків показує погляд іншого сервісу, а не доводить, що перевіряє ваш комп’ютер. Hashrate вимірює обчислювальну потужність майнінгу. Він не дає майнерам права обходити правила вашого вузла: у стані ACTIVE оновлений вузол відхилить блок, що порушує нову умову, навіть якщо за ним стоїть більшість потужності. Тривалість розколу залежить також від накопиченої роботи гілок та їхнього економічного використання. Просте скасування активного обмеження знову дозволило б нині нечинні блоки, тож було б зміною типу Hard Fork. До активації параметри можна змінити узгодженим випуском програми, але така зміна теж не встановиться сама на чужих вузлах. [1] [15] [16]

V(стара) містить усі блоки, прийняті до оновлення. Soft Fork існує лише коли V(нова) лежить усередині: новий вузол відкидає додаткові випадки, а кожен новий чинний блок проходить старі перевірки. Назва описує сумісність правил, а не масштаб, безпеку чи суспільну згоду. Збільшення видимого старим вузлам ліміту або дозвіл раніше нечинної витрати розширює множину й зазвичай потребує зміни типу Hard Fork. [1] [17]

Суворіші правила можуть додавати й нові можливості. BIP66 уточнив DER — формат кодування даних підпису. BIP65 і BIP112 додали часові умови витрачання до окремих команд NOP, які раніше нічого не вимагали. SegWit запровадив програми witness і дані перевірки witness, зокрема підписи. Згодом Taproot використав їхню зарезервовану версію 1. Старі вузли не перевіряють відповідні нові умови. Anyone-can-spend описує цей обмежений погляд, а не спосіб обійти оновлені вузли й витратити чужі кошти. SegWit також криптографічно пов’язує дані witness із блоком через witness commitment. Цей зв’язок записаний у coinbase-транзакції, першій транзакції з винагородою майнеру, й зберігає сумісність зі старими правилами базового блоку. [6] [5] [7] [8] [12]

Біт має значення 0 або 1. Окремі біти у nVersion, полі версії заголовка блоку, можуть сигналізувати про готовність майнера. BIP9 призначає кожному впровадженню назву, певний біт, час початку й кінцевий термін. Початкова процедура mainnet оцінює періоди по 2016 блоків. Якщо у стані STARTED сигнал подадуть щонайменше 1916 блоків, тобто 95 %, наступний період перейде до LOCKED_IN. Після ще одного періоду очікування настає ACTIVE. Якщо умову не виконано до кінцевого терміну, процедура може завершитися у FAILED. Початковий стан до запуску називається DEFINED. Кожен вузол обчислює цю послідовність за попередніми блоками. Отже, власне поле nVersion блоку не визначає, чи застосовується до нього нове правило. Сигнали допомагають узгодити перехід, а не голосувати за чинність окремих блоків. Після досягнення lock-in подальші сигнали вже не змінюють результат цієї процедури. [2]

Versionbits дає майнерам змогу сигналізувати готовність, але не переписувати правила інших вузлів. BIP8 використовує висоти блоків замість часових меж. Якщо lockinontimeout має значення true і розгортання ще не досягло lock-in, останній період може перейти в MUST_SIGNAL з обов’язковою сигналізацією. BIP148 вимагав від вузлів-учасників відхиляти блоки, що не сигналізували SegWit; BIP91 використав нижчий поріг майнерської сигналізації для координації переходу. Якщо застосування правил, hashrate й економічне прийняття розійдуться, ланцюг може розділитися. Вибір способу активації тому передбачає безпекові компроміси. [11] [9] [10] [17]

P2SH (BIP16) дозволяє надіслати кошти на хеш скрипту — програми з умовами їх подальшого витрачання. Під час запровадження у 2012 році сигнали в coinbase-транзакціях допомагали оцінити готовність майнерів. Проте самі нові перевірки почали діяти від заданої межі часових позначок блоків: сигнал не замінював перевірку. Coinbase — перша транзакція блоку, що містить винагороду майнера. Наступні зміни використовували версію блоку й пороги сигналізації. BIP34 зобов’язав записувати в coinbase висоту блоку, його позицію в ланцюгу. BIP66 посилив вимоги до формату підписів DER, а BIP65 запровадив CHECKLOCKTIMEVERIFY — перевірку найранішого часу чи висоти, коли дозволено витратити кошти. Послідовне збільшення номера версії ускладнювало паралельне впровадження незалежних змін, тому BIP9 увів окремі біти. У 2016 році на висоті 419328 разом активували BIP68, BIP112 і BIP113, але вони стосуються різних часових умов. BIP68 запроваджує відносне очікування від підтвердження виходу, який витрачають. BIP112 дозволяє вимагати цього очікування у скрипті через CHECKSEQUENCEVERIFY, або CSV. Натомість BIP113 змінює часову основу абсолютного блокування транзакції: замість позначки часу оцінюваного блоку він використовує Median Time Past, медіану часових позначок попередніх 11 блоків. Спільна активація не означає, що всі три пропозиції вводять однакове відносне блокування. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit активувався на висоті 481824 у серпні 2017 року. Він відокремив перевірні дані witness, зокрема підписи, від частини транзакції, за якою обчислюють її ідентифікатор txid. Чому це важливо? За старого кодування можна було змінити запис підпису й разом із ним ідентифікатор транзакції, не змінюючи одержувача чи суму платежу. Цю можливість називають malleability, або пластичністю транзакції. Зміна лише witness-даних не змінює txid; проте це не усуває таким способом проблему входів, які досі використовують старий формат. Старий вузол бачить транзакцію без witness і вважає програму witness v0 випадком anyone-can-spend. Оновлений вузол додатково перевіряє witness і дайджест підпису — відбиток підписуваних даних. Witness commitment у виході coinbase криптографічно пов’язує witness-дані з блоком, тож повна перевірка може виявити їх зміну чи пропуск. Weight, вага даних під час підрахунку місткості блоку, збільшив ефективну місткість. Базовий блок, який бачить старий вузол, залишився у початковій межі одного мегабайта. [8]

Key-path дозволяє витрачання з підписом для ключа виходу; script-path — за виконання умов розкритого скрипту. Schnorr — схема підпису, а Tapscript — мова цих скриптів. BIP341 і BIP342 визначають витрачання через key-path та script-path із підписами Schnorr і Tapscript для нативних виходів SegWit із 32-байтовою witness-програмою версії 1. Старі вузли бачать anyone-can-spend: сумісність є, повної перевірки немає. Speedy Trial використав змінений BIP9, поріг 1815/2016 (90 %) і мінімальну висоту 709632. Taproot активувався там 14 листопада 2021 року. Правила й спосіб активації слід оцінювати окремо. [12] [13] [16]