Изменения протокола после внедрения последнего хард-форка "Лима"

Это обновление, описывающее новый механизм жестких изменений протокола, которые будут использоваться после Лимы.

Обзор

Все хард-форки уже запланированы. Хард-форк “Лима” станет последним запланированным хард-форком, после этого будет только хард-форки сообщества. Это означает, что Aeternity обеспечит реализацию новых функций (некоторые из которых будут нарушать консенсус) и позволит майнерам решить, хотят ли они перейти на новый протокол консенсуса или остаться с текущим.

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

--- [ ] --- ... --- [ ] --- ... --- [ ] --- [ ] ---
     H1              HS            HE - 1    HE

«H1» - высота, на которой узел имеет протокол «C1».
«HS» - начало интервала сигнализации (включительно)
'HE` - конец интервала сигнализации (исключительно)

Новый согласованный протокол должен быть строго больше, чем C1. На высоте HS мы предполагаем, что все узлы, желающие участвовать в сигнализации майнера, обновляются до версии, способной сигнализировать и следовать новому согласованному протоколу. «HE - 1» - последний сигнальный блок, и форк происходит (в зависимости от результата сигнализации) на высоте «HE». Хард-форк происходит на цепной форк:

                            [ ] --- [ ] --- [ ] --- v5  <--- High difficulty
                             |
--- [ ] --- ... --- [ ] --- ... --- [ ] --- [ ] --- v4  <--- Low difficulty
     H1              HS            HE - 1    HE

Если в интервале передачи сигналов было разветвление, в «HE» может быть несколько конкурирующих цепочек с разными исходами сигнализации. Решение о том, может ли цепь быть обновлена до согласованного протокола, может быть принята после того, как цепь рационализировано обосновывается (после 'HE`).

Внедрение

Работа по достижению консенсуса в отношении майнеров началась в конце июля / начале августа. Сначала мы должны были определить, где мы смогли бы получить версию протокола с высоты блока. Поскольку были только запланированные хард- форки, не было никаких сомнений в том, что версия протокола должна была быть эффективной на определенной высоте. Тем не менее, это изменилось с помощью форков сообщества, и теперь невозможно определить, какой протокол эффективен на данной высоте (после Лимы), потому что это зависит от результата передачи сигналов форка. Поэтому нам пришлось рефакторировать много кода, который предполагал версию протокола с высоты. Реализация была разделена на две части: рефакторинг кода и вычисление результата сигнала.

Рефакторинг кода

Основой этой работы было в основном избавление от вызовов функции aec_hard_forks: protocol_effective_at_height / 1, которая возвращает протокол на заданной высоте. Например, эту функцию нужно было удалить из синхронизации. Представьте себе ситуацию, когда форк сообщества может произойти на высоте 1000, а цепочка локального узла - на высоте 999, синхронизация получает блок с высотой 1010. Синхронизация в этой точке не выполняется. В этом ключе она не знает какая версия протокола будет на высоте 1010, поэтому получение протокола с высоты не имеет значения.

Рефакторинг PRs: PR #2678, PR #2686, PR #2697, PR #2705, PR #2760, PR #2763, PR #2769, PR #2774, PR #2778, PR #2793, PR #2800, PR #2802, PR #2804, PR #2837, PR #2847. Результатом рефакторинга стало то, что функция для получения протокола с высоты может использоваться только когда:

  • новый блок добавляется в цепочку;
  • новый ключевой блок-кандидат подготовлен.

Вычисление результата сигнала

Сначала мы разработали механизм, который использовал асинхронные рабочие для вычисления результата сигнала для разветвления цепи. Эта реализация позволила изменить конфигурацию сигналов форка, перезапустить узел и вернуть правильный результат для данной конфигурации. Хотя остальные разработчики решили, что это можно сделать другим способом, когда мы не разрешаем изменение конфигурации для ae_mainnet иae_uat, чтобы пользователи не допустили случайных ошибок.

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

Эта часть также включает в себя изменения конфигурации. Для ae_mainnet иae_uat можно использовать fork_management> fork> enabled, для которого можно установить значениеtrue или false. Это указывает на то, что узел будет следовать за сигналом разветвления (true) или останется с текущим протоколом (false). Если конфигурация отсутствует, значением по умолчанию является true. Другие среды (отличающиеся от основной сети и тестовой сети) могут использовать полную конфигурацию, например:

enabled: true                                
signalling_start_height: 1000
signalling_end_height: 2000
# How many blocks at least must include signal to make new protocol active.
signalling_block_count: 900
# The signal value (it's part of key block header - info field).   
info_field: 1234
# The new protocol version.
version: 5

PR, который реализует все это, теперь в мастерской (PR #2868). Также есть ожидающий PR в протоколе репо(PR #385).

Вывод

Сигналы с использованием поля заголовка ключевого блока info обратно совместима, так как значение значения такого поля не согласовано.

Активация нового согласованного протокола, основанного на передаче сигналов майнера, должна быть временной мерой в течение интервала времени, когда новый протокол может быть активирован в сети во время работы узла. Как только сеть обоснованно решит, активировать ли новый согласованный протокол, пользователь должен обеспечить выполнение такого решения при возможном перезапуске узла либо путем конфигурации, либо путем обновления узла до новой версии.

Команда

Весь первоначальный дизайн был сделан Luca Favatella с помощью Juraj Hlista . Реализация была проведена Juraj Hlista .