Що таке Soft Fork Activation? визначення, контекст і джерела

01Що таке Soft Fork Activation?

Механізм activation задає параметри, переходи станів і висоту, з якої validating nodes відхиляють блоки, що порушують нове зворотно сумісне правило.

02Суть

Soft fork звужує множину валідних блоків, а нові умови застосовуються лише в ACTIVE. Випуск software, початок signaling і LOCKED_IN ще не activation; затримка дає час оновитися вузлам, майнерам, wallets і сервісам. [2]

03Механізм

BIP 9 оцінює version bit періодами по 2016 блоків і проходить DEFINED, STARTED, LOCKED_IN, ACTIVE та FAILED. Початковий типовий поріг — 1 916 блоків, або 95 %; недосягнення до timeout веде у FAILED. [2]

04Проблема, яку розв’язує

BIP 8 використовує startheight, timeoutheight і minimum_activation_height замість дат Median Time Past. lockinontimeout додає необов’язковий MUST_SIGNAL і може гарантувати LOCKED_IN не пізніше timeoutheight. [1]

05Модель безпеки

За LOT=false deployment без порога до timeoutheight стає FAILED. За LOT=true останній період може відхиляти надмір несигнальних блоків; вибір змінює ризик chain split і має бути відомий до enforcement. [1]

06Стан розгортання

BIP 8 радить поріг 1 815 із 2016 блоків, тобто 90 %, і щонайменше один період LOCKED_IN перед ACTIVE. Кожен soft fork повинен оприлюднити власні параметри; назва механізму не визначає поріг чи дату. [1]

07Обмеження

Taproot використав варіант BIP 9 Speedy Trial: bit 2, поріг 1 815 із 2016 блоків і фіксовану мінімальну висоту 709 632. Він locked in і фактично активувався в mainnet на блоці 709 632. [3]

08Зв’язки в Атласі

Сигнал у header показує готовність hashrate будувати сумісні блоки; це не голосування за coins і не самостійне правило вузла. Після activation кожен validating full node дотримується свого коду й параметрів. [4]

09Як перевіряти твердження

Для перевірки ‘активовано’ потрібні точний BIP, release з параметрами, мережа, version bit, період, поріг, LOCKED_IN і висота ACTIVE. Результат Taproot не переноситься автоматично на інші параметри. [4]

Soft fork звужує множину валідних блоків, а нові умови застосовуються лише в ACTIVE.
BIP 9 оцінює version bit періодами по 2016 блоків і проходить DEFINED, STARTED, LOCKED_IN, ACTIVE та FAILED.
BIP 8 використовує startheight, timeoutheight і minimum_activation_height замість дат Median Time Past.
За LOT=false deployment без порога до timeoutheight стає FAILED.
BIP 8 радить поріг 1 815 із 2016 блоків, тобто 90 %, і щонайменше один період LOCKED_IN перед ACTIVE.
Taproot використав варіант BIP 9 Speedy Trial: bit 2, поріг 1 815 із 2016 блоків і фіксовану мінімальну висоту 709 632.
Сигнал у header показує готовність hashrate будувати сумісні блоки; це не голосування за coins і не самостійне правило вузла.
Для перевірки ‘активовано’ потрібні точний BIP, release з параметрами, мережа, version bit, період, поріг, LOCKED_IN і висота ACTIVE.
Механізм activation задає параметри, переходи станів і висоту, з якої validating nodes відхиляють блоки, що порушують нове зворотно сумісне правило.

Читайте в контексті

Для повної картини прочитайте також Soft Fork, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Правила консенсусу, Війна за розмір блока. На цю статтю також посилаються Schelling Point.

?Практичні запитання

01Чи голосують майнери за правила Bitcoin?

Не в юридичному чи майновому сенсі. Signaling вимірює готовність у конкретному механізмі; валідність визначають правила validating nodes.

02Що означає LOT=true?

Lock-in-on-timeout у BIP 8 додає MUST_SIGNAL перед timeout, тому deployment досягає LOCKED_IN без раннього порога. Надлишкові несигнальні блоки тоді невалідні для LOT=true nodes.