Привет, сообщество Lisk!

За последнюю неделю команда разработчиков Lightcurve проделала невероятно продуктивный путь к выпуску Lisk Core 1.0.0 для Mainnet. В среду мы выпустили кандидат на выпуск Lisk Hub 1.0.0, первый кандидат на выпуск версии 1.0.0, совместимый с Lisk Core 1.0.0 API. Мы также успешно связались с рядом бирж, чтобы проинформировать их о прогрессе в выпуске Lisk Core 1.0.0.

Мы также приняли множество прогрессивных и необходимых мер для обеспечения плавной и безопасной миграции Lisk Core 1.0.0 в Mainnet. Мы работаем над рядом улучшений и изменений, которые подробно описаны ниже.

Lisk Core 1.0.0-rc.2:

Проблема # 2199: возможно, что после миграции с Lisk Core 0.9.16 на 1.0.0 унаследованная цепочка по-прежнему будет двигаться быстрее, чем недавно перенесенная цепочка. Это может произойти, если после миграции в старую цепочку продолжит формироваться достаточное количество делегатов. Также существует вероятность того, что кто-то выполнит миграцию в этой цепочке и покажет цепочку в уже работающей сети 1.0.0 (которая имеет более короткую цепочку). Чтобы предотвратить это, мы решили увеличить свойство блока version, которое также включается в процесс генерации подписей блока, чтобы его нельзя было изменить для существующих блоков. После подробного обсуждения между нашими разработчиками мы определили, какими должны быть требования к свойству блока version. И вот результаты:

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

Следуя нашим выводам, мы решили реализовать следующее решение:

  • Мы повышаем блок версии в Lisk Core 1.0.0 с 0 до 1.
  • По этой причине только 1.0.0 и любые последующие выпуски могут обрабатывать только блоки версии 1.
  • Следовательно, все предыдущие блоки (которые действительны и являются частью цепочки блоков) теперь считаются недействительными выпуском 1.0.0, поскольку они содержат версию 0.

Чтобы обработать исторические треки этих блоков и позволить им быть принятыми выпуском Lisk Core 1.0.0 во время процесса синхронизации и создания моментальных снимков, мы предпримем следующие шаги:

  • Мы добавим исключение для блоков с версией 0 для определенных сетей (Mainnet и Testnet).
  • Это исключение сообщит программе, от какой высоты блоки с версией 0 допустимы и должны быть приняты.
  • Высота будет такой же, как высота фактической миграции.
  • Изменение со свойством блока версия считается хард-форком для обеих сетей.

Проблема # 2154: проблема с отключением поддержки SSL для уровня P2P уже описывалась в предыдущем обновлении разработки. Однако мы решили, что важно включить их в версию Lisk Core 1.0.0, поскольку это может помочь избежать проблем для операторов узлов, у которых включена опция SSL.

Проблема # 2226: мы обновили нашу документацию, включив в нее инструкции по включению и отключению форжинга на узле.

Проблема # 2227: во время миграции конфигурации мы заметили, что иногда в качестве имени пользователя базы данных конфигурации задавалась пустая строка. Мы устранили эту проблему, установив в качестве имени пользователя базы данных имя пользователя по умолчанию lisk, если оно оставлено пустым.

Проблема # 2208: ранее сценарий миграции сохранял пароли, предоставленные пользователями для шифрования парольных фраз делегатов, как defaultPassword в файле конфигурации (config.json). Эта функция используется только в целях разработки и не может использоваться в производственной среде, поскольку она ставит под угрозу весь механизм кодовой фразы шифрования. По этой причине мы больше не сохраняем эти пароли в файле конфигурации во время миграции.

Lisk Core 1.1.0:

Проблема # 1992: ведение журнала, связанное с добавлением / удалением одноранговых узлов, было несовместимым, поскольку каждый из них поддерживал свой уровень журнала. Мы исправили это, чтобы журналы, относящиеся к одноранговым узлам, имели одинаковый уровень журнала.

Проблема # 2148: Отсутствие стандарта привело к тому, что наши журналы выводились в текстовом формате. Это затрудняло автоматизацию процесса анализа логов. Затем мы решили переписать наш механизм ведения журнала, чтобы ввести новый способ хранения журналов:

  • Для вывода на консоль мы будем использовать текстовый формат из-за удобства чтения.
  • Журналы, которые сохраняются в файле, будут в формате JSON, что упростит поиск определенных журналов, сбор информации для отладки и использование автоматизированных инструментов для анализа журналов. Пример записи в журнале:

{
«name»: «logs / lisk.log»,
«hostname»: «my.local»,
«pid»: 48673,
«module »:« Сверстники »,
« уровень »: 20,
« msg »:« Консенсус Broadhash: 0% »,
« время »:» 2018–06–29T09: 48: 13.966 Z »,
« src »: {
« file »:» / lisk / modules / peers.js »,
« line »: 879,
« func »:» calculateConsensus »
},
« v »: 0
}

  • Мы также будем использовать стандартизированный формат и ключи для более оптимальной возможности поиска.

Изменение формата версии журнала нарушит совместимость инструментов, основанных на журналах.

Дальнейшие действия

Теперь, когда фаза разработки Lisk Core 1.0.0-rc.2 готова, этот выпуск перейдет к самому важному следующему этапу - фазе QA. Миграция будет протестирована так же, как и до выпуска 1.0.0-rc.1. Выпуск 1.0.0-rc.2 Testnet будет хард-форком из-за изменения версии блока, описанного выше. Дата релиза будет объявлена ​​после завершения раунда QA этого релиза. Процесс миграции в Mainnet останется таким же, как и планировалось изначально.

Первый этап тестирования версии 1.1.0 был успешным. Однако мы решили скорректировать распределение проблем между версиями 1.1.0 и 1.2.0. Завершенные задачи из Lisk Core 1.2.0 были объединены с веткой 1.1.0 и будут выпущены и протестированы вместе. Текущее разделение проектов 1.1.0 и 1.2.0 в наших проектах GitHub уточняет, какие проблемы будут включены в какой выпуск. Что касается раунда контроля качества для этого выпуска, мы все еще ждем, пока не будут устранены проблемы с lisk-build и lisk-script после того, как произошло существенное изменение файла конфигурации.

Мы с нетерпением ждем новых новостей на следующей неделе!

Как всегда, еще раз спасибо за постоянную поддержку!

-Команда Lisk