Договариваться делегатам, конечно, нужно, но лучше, если будет конкретный стандарт принятия хардфорков (проще будет договариваться).
Стандарт означает, что если разработчик(и) хардфорка не внесут дату и время в соответствии с написанным ниже, предлагают изменение в репозиторий https://github.com/viz-blockchain/viz-cpp-node.
Дата прописывается по пути libraries/chain/hardfork.d/ в файле с номером HF и расширением .hf. Например, в этом ХФ — это был libraries/chain/hardfork.d/9.hf Строка с ней, скорее всего, будет 4. Вот какая в текущем ХФ
#define CHAIN_HARDFORK_9_TIME 1589173200 // 11 May 2020 05:00:00 GMT
Дата выпуска ХФ должна зависеть от преоритета ХФ
- Стандартное: вносятся новые функции и изменяются старые по причине того, что настало время. Время начала голосования (принятия): через неделю после завершения разработки.
- Средняя срочность: появились баги или недочёты, которые не критичны. Примеры:
Спам сети, не приводящий к её падению; ошибки в рассчётах неконсенсусных параметров; другое… Срок: 1 день (24 часа). - Высокая срочность: взлом, падение сети и т.п. Срок: 12-24 часа.
Конечное решение за делегатами
Предлагается при разработке ХФ обсуждать степень его критичности, выбирать дату, после чего тот, кто готов, пушит изменение в репозиторий с указанной датой. Если он отправил изменение согласно договорённости, делегаты устанавливают обновление с указанием этой даты и времени.
Для справки
Значение даты и времени представлено в unixtime: можно для перевода воспользоваться любым unix time конвертером, например, этим.
Желаю нам всем научиться договариваться, а также перестать спорить и выплёскивать негатив.
С вами был незрячий пользователь, делегат, разработчик и инвестор в Viz @denis-skripnik.
Наградить автора поста
