HM-SHA256-v1. Теория.

Заголовок имеет размер 80 байт и содержит шесть различных полей данных, все в формате little-endian.

little-endian (от меньшего к большему).




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



Предисловие.

This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.

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

BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.

(BIP 34 представил механизм для выполнения изменений софт-форков без предопределенной отметки времени флага (или высоты блока флага), вместо этого полагаясь на измерение поддержки майнера, указанное более высоким номером версии в заголовках блоков. Однако, поскольку он полагается на сравнение номеров версий как целых чисел, он поддерживает одновременное развертывание только одного единственного изменения, требующего координации между предложениями, и не допускает постоянного отклонения: пока один софт-форк не развернут полностью, нет будущего можно запланировать.)

Суть данного абзаца и его машинного перевода, заключается в следующем.

Метод описанный в BIP34, работал, но он имел некоторые недочёты. А именно, первое, отсутствие таймаута (время вышло), и второе, использование для подачи сигнала целых числовых значений, а не битов.

Возможность в любой момент времени иметь несколько активных предложений о софт-форке делает этот механизм более совершенным в сравнении с использованием целочисленных значений согласно BIP34.

Также майнеры могут использовать, и используют поле версии для получения дополнительного пространства поиска хеша. Первоначально, после того как было представлено BIP9, майнеры по-прежнему использовали для расширения пространства поиска все свободные биты поля версии. Однако это привело к тому, что ноды генерировали предупреждения, поскольку пытались интерпретировать биты как сигнал по несуществующим предложениям о софт-форке. С BIP320 эта проблема была решена путём выделения 16 бит для расширения пространства поиска и резервирования 13 бит для подачи сигналов по софт-форкам. Это позволяет майнеру расширить пространство поиска на 2¹⁶ и оставляет место для подачи сигналов по 13 актуальным предложениям о софт-форке.

In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2³¹+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.

(Кроме того, BIP 34 сделал целочисленное сравнение (nVersion> = 2) правилом консенсуса после достижения его 95% порога, удалив 2³¹ + 2 значения из набора допустимых номеров версий (все отрицательные числа, поскольку nVersion интерпретируется как знаковое целое число, а также 0 и 1). Это указывает на ещё один недостаток этого подхода: каждое обновление постоянно ограничивает набор разрешённых значений поля nVersion. Позднее этот подход был повторно использован в BIP 66 и BIP 65, которые в дальнейшем удалили nVersions 2 и 3 как допустимые варианты. Как будет показано ниже, в этом нет необходимости.)


Технические характеристики.

Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):

1. The name specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
   
   
2. The bit determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
   
   
3. The starttime specifies a minimum median time past of a block at which the bit gains its meaning.
   
   
4. The timeout specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
   

(Каждое развертывание софт-форка определяется следующими параметрами для каждой цепочки (более подробно описаны ниже):

1. Название задаёт очень краткое описание софт-форка, подходящее для использования в качестве идентификатора. Для развёртываний, описанных в одном BIP, рекомендуется использовать имя «bipN», где N - соответствующий номер BIP.
   
   
2. Этот бит определяет, какой бит в поле nVersion блока должен использоваться для сигнализации блокировки и активации программной вилки. Выбирается из множества {0,1,2, ..., 28}.
   
   
3. Время начала определяет минимальное медианное время, прошедшее после блока, в котором бит приобретает своё значение.
   
   
4. Тайм-аут указывает время, когда развёртывание считается неудачным. Если среднее время истёкшего блока >= таймаута и софт-форк ещё не заблокирован (включая битовое состояние этого блока), развертывание считается неудачным для всех потомков блока.
   

Если в кратце и для большего понимания, то это можно описать так:

1. Отличительное название.
   
   
2. Бит в поле версии, изменение которого будет сигнализировать о готовности майнера принять изменения. Номер позиции бита обозначается N.
   
   
3. Время старта: с какого момента определенный бит обретает актуальное сигнальное значение.
   
   
4. Тайм-аут: если предложение не будет принято к определенной дате X, оно будет считаться не прошедшим.
   

Рекомендации по выбору.

The following guidelines are suggested for selecting these parameters for a soft fork:

1. name should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
   
   
2. bit should be selected such that no two concurrent softforks use the same bit.
   
   
3. starttime should be set to some date in the future, approximately one month after a software release date including the soft fork. This allows for some release delays, while preventing triggers as a result of parties running pre-release software.
   
   
4. timeout should be 1 year (31536000 seconds) after starttime.
   

(Следующие рекомендации предлагаются для выбора этих параметров для софт-форка:

1. name. Имя должно быть выбрано таким образом, чтобы никакие две программные вилки, параллельные или другие, никогда не использовали одно и то же имя.
   
   
2. bit. Бит должен быть выбран таким образом, чтобы никакие две параллельные программные вилки не использовали один и тот же бит.
   
   
3. starttime. Время начала должно быть установлено на некоторую дату в будущем, примерно через месяц после даты выпуска программного обеспечения, включая софт-форк. Это допускает некоторые задержки выпуска, предотвращая при этом срабатывания из-за того, что стороны запускают предварительное программное обеспечение.
   
   
4. timeout. Тайм-аут должен составлять 1 год (31536000 секунд) после времени запуска.
   

A later deployment using the same bit is possible as long as the starttime is after the previous one's timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.

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


Состояния.

With each block and soft fork, we associate a deployment state. The possible states are:

1. DEFINED is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
   
   
2. STARTED for blocks past the starttime.
   
   
3. LOCKED_IN for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion.
   
   
4. ACTIVE for all blocks after the LOCKED_IN retarget period.
   
   
5. FAILED for one retarget period past the timeout time, if LOCKED_IN was not reached.
   

(С каждым блоком и софт-форком мы связываем состояние развертывания. Возможные состояния:

1. DEFINED. Это первое состояние, с которого начинается каждый софт-форк. Генезисный блок по определению находится в этом состоянии для каждого развертывания.
   
   
2. STARTED. Начало для блоков, прошедших время начала.
   
   
3. LOCKED_IN. Для одного периода перенацеливания после первого периода перенацеливания с STARTED блоками, для которых, по крайней мере, порог имеет связанный бит, установленный в nVersion.
   
   
4. ACTIVE. Для всех блоков после периода перенацеливания LOCKED_IN.
   
   
5. FAILED. Для одного периода перенацеливания после тайм-аута, если LOCKED_IN не был достигнут.
   

Битовые флаги (Bit flags).

The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number.

(Поле заголовка блока nVersion должно интерпретироваться как 32-битное целое число с little-endian порядком байтов (как есть), и биты выбираются в этом целом числе как значения (1 << N), где N - номер бита.)

Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.

(Блоки в состоянии STARTED получают nVersion, бит позиции которого установлен в 1. Верхние 3 бита таких блоков должны быть 001, поэтому диапазон фактически возможных значений nVersion составляет [0x20000000 ... 0x3FFFFFFF] включительно.)

Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available. This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011). When a block nVersion does not have top bits 001, it is treated as if all bits are 0 for the purposes of deployments.

(Из-за ограничений, установленных BIP34, BIP66 и BIP65, у нас есть только 0x7FFFFFFB возможных значений nVersion. Это ограничивает нас максимум 30 независимыми развертываниями. Ограничивая 3 старших бита значением 001, мы получаем 29 из них для целей этого предложения и поддерживаем два будущих обновления для различных механизмов (старшие биты 010 и 011). Когда блок nVersion не имеет старших битов 001, он обрабатывается так, как если бы все биты равны 0 для целей развертывания.)

Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules.

(Майнеры должны продолжать устанавливать бит в фазе LOCKED_IN, чтобы захват был виден, хотя это не влияет на правила консенсуса.)

Дальнейшее изучение BIP9, на этом этапе, не требуется. Суть понятна есть у нас первые 4 байта в системе little-endian, это поле Version.
Которое может иметь диапазон от 0x20000000 до 0x3FFFFFFF в системе big-endian, ну или
от b0100 0000 0000 0000 0000 0000 0000 0000 до b0011 1111 1111 1111 1111 1111 1111 1111.
Соответственно в little-endian это будет выглядеть так: от 0x00000020 до 0xFFFFFF3F или
от b0000 0000 0000 0000 0000 0000 0000 0010 до b1111 1111 1111 1111 1111 1111 0011 1111.

Позже к этому всё равно придётся вернуться и рассмотреть более детально...