Причиною була не суперечка щодо нового правила, а прихована залежність валідації від реалізації бази даних: новіша LevelDB опрацювала блок із незвично великою кількістю входів, тоді як попередні версії вичерпали стандартну кількість блокувань Berkeley DB; майнери скоординовано повернулися до сумісної гілки, а наступний випуск 0.8.1 підготував керований перехід.
11 березня 2013 року вузол із Bitcoin 0.8 видобув блок 225 430. Нова версія прийняла його, а частина вузлів версії 0.7.2 і старіших відхилила; від одного батьківського блока почали зростати гілка з цим блоком і гілка без нього. Різниця полягала не в hash чи proof of work, а в тому, чи вважало локальне програмне забезпечення блок узагалі дійсним. [2]
Тригером був не просто розмір блока в байтах. Блок містив небачену раніше кількість входів транзакцій, і старі вузли під час запису вичерпали стандартну кількість блокувань Berkeley DB. Потрібна кількість блокувань також залежала від розташування сторінок бази даних конкретного вузла, тому менший, але в іншому дійсний блок міг завершитися помилкою там, де попередні тестові блоки максимального розміру проходили. [1]
Bitcoin 0.8 переніс індекси блоків і транзакцій з Berkeley DB до LevelDB, яка не мала такого ліміту блокувань. Спочатку приблизно 60 % хешрейту будувало гілку 0.8, але старіші вузли не враховували її роботу, бо відхилили початковий блок. Правило найважчого ланцюга обирає лише серед історій, які вузол спочатку визнав дійсними, тому саме по собі не могло усунути розбіжність. [1]
Pieter Wuille опублікував екстрене попередження й порадив продавцям призупинити обробку платежів. Після обговорення між розробниками та операторами пул BTCGuild під керівництвом Michael Marsee, відомого як Eleuthria, і Slush Pool Marek Palatinus повернулися до Bitcoin 0.7. Метою було не назавжди оголосити технічно новішу гілку хибною, а швидко зосередити роботу на історії, яку могли перевірити обидві поширені версії. [3]
Коли сумісна гілка вийшла вперед за накопиченою роботою, вузли 0.8 реорганізувалися на неї, а блоки, видобуті лише в початковій гілці 0.8, стали застарілими. BIP 50 фіксує щонайменше один великий double spend під час розділення; за post-mortem це був експеримент, а не спроба крадіжки. Подія все одно показала, чому біржі та продавці зупиняють депозити й чекають додаткових підтверджень за невизначеної вершини ланцюга. [1]
Bitcoin Core 0.8.1 вийшов 18 березня 2013 року. Він додав тимчасове правило прийняття блоків, що діяло з 21 березня до 15 травня й не дозволяло приймати блоки, які старіші піри не могли опрацювати, а також вбудований checkpoint на блоці 225 430. Post-mortem також визначив оцінювальний ліміт 10 000 блокувань, майнінговий ліміт 500 000 байтів і backport із лімітом 537 000 блокувань Berkeley DB. [4]
Тимчасова сумісність не була кінцевим станом. Оператори старіших вузлів мали до 15 травня перейти на 0.8.1, оновлений backport або явно збільшити ліміт блокувань; майнерам не слід було підвищувати його до скоординованої дати, щоб знову не створити блок, який решта мережі відхилить. 16 серпня 2013 року мережа прийняла блок 252 451 й остаточно залишила невиправлені вузли позаду. [5]
Інцидент показав, що консенсус — це більше, ніж опис формату блока. Він охоплює точну поведінку коду валідації, бібліотек, транзакцій бази даних, шляхів помилок і граничних тестів. Тому подальші заходи включали стресове генерування транзакцій у testnet, кращі сповіщення для сервісів, моніторинг довгих бічних гілок і обережнішу координацію змін; швидке відновлення водночас виявило тодішню залежність від кількох доступних розробників і великих пулів. [1]
Для повної картини прочитайте також Bitcoin Core, Правила консенсусу, Hard Fork, Reorg, Full Node, Mining Pool. На цю статтю також посилаються Schelling Point.
01Чи одна група вирішила, який блокчейн справжній?+
Розробники й великі пули координували екстрені дії, але не могли віддалено переписати вузли. BTCGuild і Slush змінили програмне забезпечення своїх майнерів, а користувачі запускали версії з власними правилами валідації. Сумісна гілка перемогла лише після того, як її прийняла достатня кількість вузлів і вона накопичила більше роботи з погляду вузлів Bitcoin 0.8.
02Чи були обидві гілки одночасно дійсними?+
Це залежало від версії, яка виконувала валідацію. Bitcoin 0.8 вважав блок 225 430 і його гілку дійсними, а частина старіших вузлів відхилила блок через ліміт Berkeley DB і знала лише іншу гілку. Різні відповіді на однакові вхідні дані і є відмовою консенсусу; сьогоднішня активна історія продовжує скоординовано обрану сумісну гілку.