Block Size War — період суперечок про місткість і правила Bitcoin, кульмінацією яких у 2017 році стали активація SegWit, відокремлення Bitcoin Cash і призупинення запланованого форка SegWit2x. Це три різні події з різними причинами й технічними механізмами.
Уявімо дві звичайні потреби. Анна хоче переказати біткоїни без довгого очікування та високої комісії. Павел утримує повний вузол — комп’ютер, який сам перевіряє блоки й транзакції. Він хоче перевіряти свої гроші без дорогого обладнання. Обидві потреби зрозумілі, але більше даних у блоці означає більше передавання та перевірок. Саме цей баланс був у центрі Block Size War. Блок — це набір транзакцій, який додається до спільної історії платежів у мережі. Анна й Павел — умовні персонажі. У справжній дискусії 2015–2017 років брали участь розробники, оператори майнінгу, бірж, гаманців і користувачі. Вони сперечалися як про місткість, так і про безпечний спосіб змін. Bitcoin не мав директора, який міг би вибрати варіант і наказати всім перейти на нього. [1] [11] [13]
До SegWit правила обмежували блок величиною 1 MB, тобто 1 000 000 байтів. Це не фіксована кількість платежів: транзакції займають різний обсяг. Новий блок з’являється в середньому приблизно раз на десять хвилин. Коли попит перевищує місткість, майнери зазвичай віддають перевагу транзакціям із вищими ставками комісій, а решта чекають. Прихильники більших блоків хотіли додати місце безпосередньо в базовій мережі та зберегти доступні платежі. Опоненти хвилювалися через вимоги до з’єднання, комп’ютерів і швидкого поширення блоків. Якщо менше людей зможуть перевіряти самостійно, більше користувачів залежатимуть від чужих сервісів. Саме підвищення ліміту не прискорює появу блоків і не гарантує низьких комісій назавжди: важливі також попит і фактичне використання місця. [1] [2] [13]
Розробник може написати програму, майнер — створити за нею блок. Але оператор Full Node сам обирає правила, які перевіряє його вузол. Навіть більшість обчислювальної потужності не може змусити незмінений вузол прийняти блок, що порушує його правила. Потужність допомагає вибирати між ланцюгами, що відповідають правилам; вона не робить недійсний блок дійсним. Це не дає кожному вузлу голос на всесвітніх виборах і не дозволяє одній людині заборонити іншим піти. Компанії обирають, що приймати, майнери — що видобувати, користувачі — що цінувати. Несумісні правила можуть створити дві мережі. Отже, бізнесова угода могла підтримати зміну, але не переписати автоматично програми та рішення всіх учасників. [11] [12]
Пропозиції оформлювали як BIP — Bitcoin Improvement Proposal. Такий документ пояснює пропозицію, щоб інші могли її розглянути й обговорити. Надання номера ще не означає, що мережа її прийняла. Gavin Andresen запропонував у BIP 101 збільшити ліміт до 8 MB і надалі підвищувати його за визначеним графіком. План передбачав приблизне подвоєння кожні два роки та умови активації. Mike Hearn разом з Andresen просував Bitcoin XT — альтернативне програмне забезпечення для цього підходу. Однак опублікувати програму не означало змінити правила всієї мережі. Старі вузли відхилили б блок понад попередній ліміт. Це був Hard Fork: розширення набору дозволених блоків, для приймання яких потрібні інші правила. Тому дискусія вийшла за межі питання про додаткове місце. Хто перейде, як узгодити перехід і що станеться, якщо значна частина учасників відмовиться? [1] [18] [13]
Eric Lombrozo, Johnson Lau та Pieter Wuille описали інший підхід у BIP 141. SegWit змінив організацію даних транзакцій і ввів вагу блоку з лімітом 4 000 000 weight units. Частина witness містить, зокрема, дані для перевірки права витратити кошти. Вони не зникли, їх не перестали перевіряти; змінився їхній внесок у розрахунок ваги. Місткість залежить від складу транзакцій, а не від простого дозволу на звичайні чотиримегабайтні блоки. Вага визначає, як дані враховують у ліміті блоку: байт базових даних рахується як 4 одиниці, а байт додаткових даних, пов’язаних із witness, — як 1. Тому однакові за розміром у байтах транзакції можуть займати різну частину дозволеної ваги. Пропускна здатність залежить і від типів транзакцій, якими користуються люди. Для відповідних транзакцій SegWit також усунув можливість змінювати ідентифікатор через модифікацію даних підпису. Це полегшило створення платіжних каналів Lightning Network. SegWit розробили як Soft Fork: нові дійсні блоки відповідають старим правилам, але старі вузли не перевіряють усі нові обмеження. Bitcoin Core 0.13.1 містив механізм активації; сам випуск програми ще не вмикав SegWit. [2] [3]
23 травня 2017 року Digital Currency Group опублікувала New York Agreement — угоду компаній і майнерів. Вона поєднувала підтримку SegWit з обіцянкою Hard Fork до 2 MB протягом шести місяців. Другий крок став відомий як SegWit2x, а реалізацію забезпечував проєкт btc1. Частина учасників бачила прийнятний компроміс: кожна сторона отримає частину бажаного. Інші заперечували проти другої зміни та способу її просування. Згода компанії не означала автоматичної згоди всіх клієнтів. Згодом Bitcoin Core прямо уточнив: btc1 — не обов’язкове оновлення його програми, а підтримка SegWit не дорівнює підтримці SegWit2x. Читаючи тодішні новини, важливо пам’ятати: дві зміни в одній угоді залишалися окремими змінами правил. [6] [7] [11]
Автор під псевдонімом Shaolin Fry запропонував BIP 148 — варіант UASF, тобто Soft Fork, активований користувачами. З 1 серпня 2017 року за Median Time Past вузли з цим правилом мали відхиляти блоки без сигналу SegWit, якщо його активація ще не була зафіксована або здійснена. Розбіжність між видобуванням і прийманням блоків загрожувала поділом мережі. Це не був безризиковий перемикач, яким усі керували разом. Median Time Past — значення посередині впорядкованого списку часових позначок останніх 11 блоків, а не час на годиннику кожного користувача. Сигнал означав позначку в заголовку блоку, якою майнер висловлював підтримку цього впровадження; сама позначка ще не вмикала нових правил. James Hilliard описав у BIP 91 координацію майнерів із нижчим порогом: 269 із 336 блоків, приблизно 80 %. Після запуску учасники мали відхиляти блоки без сигналу для початкового розгортання SegWit. Липнева координація зменшила ризик конфлікту навколо серпневого терміну. Вона не означала, що сам SegWit уже був зафіксований або активний у липні: він і далі проходив власний механізм BIP 9. [4] [5] [9] [19]
Bitcoin Cash відокремився 1 серпня 2017 року. Програма Bitcoin ABC підтримувала більші блоки для цієї гілки, тоді зі стандартним лімітом 8 MB. Після поділу мережі мали різні правила та власні монети. Спільна попередня історія не дозволяла вільно переносити наступні платежі між BTC і BCH. Bitcoin Cash не був SegWit2x, а Bitcoin ABC — btc1. Плутанина в назвах поєднує серпневий поділ з іншим, згодом призупиненим планом. Відрізнялася й replay protection — захист від повторення транзакції на іншому ланцюзі. Для користувача це мало практичний наслідок: дія в одній гілці не мала ненавмисно витрачати кошти в іншій. Також небезпечно було вводити спільні ключі в довільні інструменти, що обіцяли нові монети. [8] [15] [11]
SegWit перейшов у стан LOCKED_IN від блоку 479 808, 9 серпня 2017 року. Період ухвалення рішення завершився; перед застосуванням нових правил залишався ще період очікування. Активація настала на блоці 481 824, 24 серпня. Між цими висотами — 2 016 блоків. Липневий BIP 91, серпнева фіксація та сама активація — різні події. Залишався другий крок SegWit2x, запланований на висоту 494 784. 8 листопада організатори на чолі з Mike Belshe оголосили призупинення: за їхнім повідомленням, достатньої згоди для плавного переходу не досягли. Bitcoin не втратив уже активний SegWit, а окремий Bitcoin Cash не зник. Завершилася саме ця спроба перетворити підтримку компаній і майнерів на підвищення ліміту Bitcoin. [9] [10] [12] [14] [16] [17]
Суперечка показала, що Bitcoin можна змінювати, але написати код, зібрати підписи компаній і домогтися прийняття правил — різні завдання. Вона не довела, що розробники не мають впливу, майнери неважливі або всі майбутні рішення матимуть однаковий результат. Місткість, доступна перевірка й згода учасників не вирішуються простим перейменуванням оновлення. Читаючи нову пропозицію, спочатку з’ясуйте, що вона змінює, які вузли після цього не погоджуватимуться та як відбуватиметься активація. Потім розрізняйте пропозицію, випущену програму й реально чинні правила. Тодішні BIP і код документують механізми; заяви сторін — їхні позиції. Жодна окрема заява учасника сама собою не є неупередженою історією всього конфлікту. [1] [6] [11] [12]
Для повної картини прочитайте також SegWit, Soft Fork, Hard Fork, Full Node, Bitcoin, Правила консенсусу. На цю статтю також посилаються Soft Fork, Hard Fork, Block Weight, Jeff Garzik.