Неустойчивые разветвления

Не все изменения в правилах консенсуса приводят к устойчивым разветвлениям. Только те изменения механизма консенсуса, которые не являются совместимыми снизу вверх, вызывают разветвление. Если изменение реализовано таким способом, что необновленный клиент продолжает оценивать транзакции и блоки как корректные по предыдущей версии правил, то изменение может произойти без разветвления.

Термин «неустойчивое разветвление» (soft fork) был введен, чтобы отличить описанный выше способ обновлений от случаев «устойчивого разветвления». С практической точки зрения неустойчивое разветвление вообще не является разветвлением. Неустойчивое разветвление — это совместимое снизу вверх («вперед» — forward-compatible) изменение правил консенсуса, которое позволяет необновленным клиентам продолжать работу с механизмом консенсуса после ввода новых правил.

Одна из особенностей неустойчивых разветвлений состоит в том, что обновления, используемые для ограничения правил консенсуса, а не для их расширения, заметны не сразу. Для соблюдения совместимости снизу вверх транзакции и блоки, создаваемые по новым правилам, обязательно должны быть корректными (валидными) и по старым правилам, но не наоборот. В новых правилах могут быть введены только ограничения по условиям валидности, в противном случае, если блок не будет принят по старьм правилам, возникнет устойчивое разветвление.

Неустойчивые разветвления могут быть реализованы различными способами — сам термин определяет не какой-либо единственный метод, а целую группу методов, которые обладают одним общим свойством: они не требуют обязательного обновления всех узлов и не исключают принудительно не обновленных узлов из процедуры консенсуса.