CIP-94: On-chain DAO голосование за параметры сети

Простая сводка

Этот CIP предлагает использовать on-chain DAO голосование для принятия решений и обновления параметров вознаграждения без хардфорка.

Обзор

В настоящее время все параметры вознаграждения жестко прописаны в коде. Данный CIP предлагает хранить эти параметры как часть глобального состояния, чтобы мы могли использовать существующие возможности голосования on-chain (посредством стейкинга и блокировки CFX через внутренний контракт Стейкинга) для голосования за изменение параметров без хардфорка. Голосование начинается периодически (каждые 2 месяца), и доступно только фиксированное количество вариантов (увеличить параметр, уменьшить параметр или оставить его неизменным). Аккаунты могут голосовать, отправляя транзакции. Состояние параметра обновляется по окончании периода голосования.

Мотивация

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

Кроме того, вопрос о том, менять ли параметры и как их менять, часто решался путем голосования управления DAO. Однако разработчики по-прежнему должны решать, следовать ли этим решениям, а майнеры должны решать, применять ли этот хардфорк. Это делает голосование менее обязательным, как мы того хотим.

Интегрировав обновление параметров и голосование DAO on-chain, мы можем получить регулярный механизм обновления параметров без хардфорка.

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

Когда блок с номером BN исполниться, будет инициализирован новый ParameterControlвнутренний контракт, а параметры по умолчанию для базового вознаграждения PoW и процента вознаграждения PoS будут сохранены в виде специальных записей хранилища (процент вознаграждения PoS хранился в хранилище до этого CIP, а базовое вознаграждение PoW будет храниться под ключом «pow_base_reward» в контракте ParameterControl). Помимо используемого в данный момент значения параметра, записи в хранилище для хранения сводки текущего и расчетного голосования также инициализируются как CURRENT_VOTES_ENTRIESи SETTLED_VOTES_ENTRIES.

Список параметров для голосования:

  1. Награда за базовый блок PoW.
  2. Базовая процентная ставка вознаграждения PoS.

И варианты каждого параметра:

  1. Оставить без изменений.
  2. Увеличение на 100%.
  3. Снижение на 50%.

Внутренний контракт имеет ParameterControlструктуруVote

struct Vote {
uint16 index;
uint256[3] votes;
}
где index— индекс параметра, за который нужно проголосовать, а массив votes— количество голосов, отданных за каждый вариант (т. е. без изменений, увеличения и уменьшения по порядку).

Контракт имеет два интерфейса для подачи голоса и для чтения голоса:

  • function castVote(uint64 version, Vote[] vote_data) external;. Первый параметр — это номер версии, указывающий, какой период голосования требуется. Второй параметр — это закодированный список файлов Vote.
  • function readVote(address addr) external view returns (Vote[]). Прочитать данные голосов учетной записи.

Аккаунт может распределять свое право голоса на разные варианты одного и того же параметра. Для любого параметра общее количество голосов за его варианты не должно превышать текущую общую силу голосования учетной записи. И для каждого вызова castVoteпараметра можно проголосовать не более одного раза. Если функция вызывается несколько раз в течение периода голосования, для каждого параметра только последний успешный вызов вступает в силу и переопределяет предыдущие голоса. Например, если учетная запись проголосовала за оба параметра в первой транзакции TX1 и проголосовала за параметр 2 во второй транзакции TX2, ее голос за параметр 1 останется таким же, как и в TX1, а ее голос за параметр 2 изменится на в ТХ2.

В конце периода голосования (учитывается как номера блоков) SETTLED_VOTES_ENTRIESиспользуется для вычисления новых значений параметров. В частности, если общее количество голосов за каждый вариант параметра равно [n_unchange, n_increase, n_decrease], новое значение для этого параметра вычисляется как

new = old * 2 ** ((n_increase - n_decrease) / (n_increase + n_decease + n_unchange))

После обновления параметров в хранилище мы перемещаем текущие голоса CURRENT_VOTES_ENTRIESв SETTLED_VOTES_ENTRIESи сбрасываем значения CURRENT_VOTES_ENTRIESна 0 для голосов в следующем периоде.

Событие также генерируется для каждого успешного голосования. Для каждой учетной записи последние голоса и версия этих голосов также будут храниться в качестве записей хранилища в контракте ParamsControl.

Период голосования установлен на 2 месяца и основан на номере блока, поэтому каждый период составляет 2 * 60 * 60 * 24 * 30 * 2 = 10 368 000 блоков.

Обоснования

Обоснование сохранения результатов голосования SETTLED_VOTES_ENTRIESвместо их немедленного применения заключается в том, что, если результатом будут неожиданно манипулировать, все еще есть шанс отменить его с помощью хардфорка. А добавление задержки позволяет голосовать за большее количество параметров (связанных с заголовком, например, сложностью) в будущем, потому что последнее состояние для нового блока может быть недоступно.

Мы хотим, чтобы учетная запись голосовала за несколько вариантов по двум причинам. Во-первых, контракт пула PoS теперь может собирать выбор своих пользователей и помогать отдавать их голоса. Другая причина заключается в том, что учетная запись может комбинировать эти параметры, чтобы иметь детальный параметр для параметра. Это позволяет нам сделать диапазон изменения параметров относительно большим без побочного эффекта.

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

Обратная совместимость

Это критическое изменение, потому что оно добавляет новый внутренний контракт и добавляет новые записи в состояние.

Тестовые случаи

Уточняется

Реализация

Уточняется

Вопросы безопасности

Уточняется

Авторские права

Отказ от авторских и смежных прав через CC0

Ссылка на оригинал: CIP-94: On-chain DAO Vote for Chain Parameters

Присоединяйся к сообществу Conflux Russia

Чат Telegram | Официальные новости Telegram| Twitter | Reddit | Discord | Forum |Medium | Официальный сайт