Namada Кубический Proof-of-stake

В этой статье описывается кубический Proof-of-stake проекта Namada и ключевые усовершенствования, реализованные в нем, в том числе эпохальный стейкинг, кубический слэш и автокомпаунд вознаграждений.

График кубической скорости слешинга Namada

Namada — Namada — это proof-of-stake L1 для конфиденциальной передачи активов между цепочками. В основе Namada лежит широко используемый в экосистеме Cosmos механизм консенсуса Byzantine fault-tolerant (BFT), представленный Tendermint (реализация Go с привязкой rust), который обеспечивает быстрое время завершения блока и гораздо меньшие вычислительные затраты, чем в механизмах консенсуса proof-of-work (PoW), как в Bitcoin. Для достижения консенсуса в системе BFT необходимо, чтобы как минимум 2/3 взвешенного большинства узлов (называемых валидаторами) были честными и вели себя в соответствии с протоколом.

В системе Namada используется метод доказательства доли (PoS), обеспечивающий защиту от атак типа Sybil, когда злоумышленник получает достаточное количество голосов, чтобы нарушить консенсус в цепи. Вместо того чтобы в системах PoW майнеры соревновались в создании следующего блока путем хэширования с использованием большого количества вычислительных мощностей, автор блока выбирается из набора валидаторов с вероятностью, пропорциональной облигационному пакету (или силе голоса) валидатора. Эта сила голоса затем используется валидаторами для определения того, достигнуто ли большинство в 2/3 консенсуса. Кроме того, механизм предложения блоков позволяет цепочкам PoS быть гораздо более экологичными, чем цепочки PoW, которым для достижения консенсуса необходимо потреблять огромное количество энергии.

Модуль PoS компании Namada в значительной степени вдохновлен системой PoS хаба Cosmos и предыдущими обсуждениями ее будущих улучшений, которые пока не реализованы. Проблема “ничего не стоит на кону” решается путем “резания” недобросовестных валидаторов, что сводится в основном к конфискации их облигационных токенов.

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

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

Эпохальный Proof of Stake

Родной стейкинг токен в Namada обозначается как NAM. Наименьший номинал этого токена мы называем namnam, где 1 млн. namnam равен 1 NAM. Под эпохой понимается сгруппированный набор последовательных блоков и период времени, в течение которого происходит некоторая фиксированная настройка PoS-системы. Например, набор валидаторов, участвующих в протоколе консенсуса, и связанные с ними полномочия по голосованию при консенсусе могут меняться только на границе двух эпох и являются постоянными в течение всей одной эпохи.

В системе Namada используется эпохальный стейкинг по двум основным причинам:

• Light-клиенты становятся более эффективными, поскольку им приходится отслеживать меньше изменений состояния (в частности, изменений набора валидаторов), что приводит к более быстрой проверке состояния.
• В конечном итоге Namada (и вся экосистема Anoma) будет полагаться на протокол Ferveo DKG для шифрования транзакций в mempool. Ferveo должен знать набор валидаторов для ближайшей эпохи, чтобы иметь достаточно времени для вычисления DKG перед данной эпохой.

Таким образом, изменения состояния PoS системы ставятся в очередь на вступление в силу в некоторую эпоху в будущем, длительность которой мы называем смещением относительно эпохи, в которую подается транзакция. Большинство изменений состояния, включая обновление наборов валидаторов, вступают в силу при смещении трубопровода — на 2 эпохи в будущее. Другим важным смещением в модели является смещение разблокировки, равное 21 эпохе, — это, прежде всего, время, в течение которого разблокированная облигация становится доступной для снятия.

Важные параметры модели PoS Namada (с указанием их значений по умолчанию)

• Продолжительность блока: ~ 5–10 seconds
• Продолжительность эпохи: ~ 1 day
• Длина смещения трубопровода: 2 epochs
• Длина смещения без привязки: 21 epochs

Ниже мы рассмотрим правила, касающиеся важных действий с PoS

• Связующий tx, поданный в эпоху n инициирует изменения в эпоху n + pipeline_offset (n+2)
• Облигация становится активной, и набор валидаторов обновляется
• Подается tx развязывания в эпоху n
• Обновление набора валидаторов с уменьшением числа голосов валидаторов на эпоху n + pipeline_offset = (n+2)
• Сумма облигаций, подлежащая выводу в эпоху n + unbonding_offset + pipeline_offset = (n+23)
• Ределегация tx, поданная в эпоху n
• Обновление набора валидаторов с правом голоса для старых и новых валидаторов на эпоху n + pipeline_offset = (n+2)
• Поддерживается только ределегирование 100% токенов
• Релегированная облигация (bond) не может быть вновь релегирована до эпохи n + unbonding_offset + pipeline_offset = (n+23)
• Слэши обрабатываются должным образом, чтобы гарантировать, что затронуты будут только те токены, которые внесли вклад в количество голосов валидатора на момент нарушения

Наборы валидаторов

Валидаторы Namada относятся к одному из трех наборов:

• Консенсус: валидаторы, активные в механизме консенсусного голосования, выбранные как наибольшие валидаторы max_consensus_validators взвешенные по их силе голоса. Это единственные валидаторы, которые могут получать вознаграждение за блок от инфляции PoS.
• Ниже мощности: валидаторы, чей облигационный пакет меньше, чем у валидаторов консенсуса, но выше некоторого небольшого порога min_validator_stake.
• Ниже порога: все остальные валидаторы, чья ставка ниже min_validator_stake.

Наборы валидаторов консенсуса и ниже порога явно хранятся в хранилище, упорядочены по их облигационному пакету и обновляются на каждой границе эпохи. Однако упорядоченный набор валидаторов, работающих ниже порога, не хранится. Такое построение набора валидаторов и порог min_validator_stake существуют в первую очередь для того, чтобы предотвратить возможность существенного замедления обновления системы PoS из-за создания спам-аккаунтов валидаторов. Таким образом, исключается неограниченная итерация при обновлении и проверке изменений состояния PoS-системы. И наоборот, для корректной обработки изменений в наборе валидаторов, при которых валидаторы могут выбывать или входить в консенсус набор валидаторов, необходимо хранить упорядоченный по связям набор валидаторов меньшей емкости. Обратите внимание, что такое построение наборов валидаторов важно только для механизма консенсуса; все валидаторы могут участвовать в управлении своим правом голоса.

Важные значения конфигурации наборов валидаторов по умолчанию, изменяемые через управление:

• max_consensus_validators = 100
• min_validator_stake = 1 NAM

Кубический слэшэшинг

Как и во многих других блокчейнах с системой PoS, слэш применяется для наказания недобросовестных валидаторов. Если валидатор обнаруживает неправомерные действия, то часть его облигационного пакета будет урезана или изъята. Это распространяется и на доли делегатов, связанных с провинившимся валидатором. К нарушениям валидатора, которые влекут за собой списание, относятся:

• подписание недействительного блока
• подписание двух разных блоков на одной и той же высоте
• атаки амнезии (когда они будут поддерживаться tendermint, см. тут).

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

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

Когда протокол обнаруживает неправомерное поведение валидатора, он немедленно попадает в тюрьму (не может участвовать в консенсусе или совершать PoS-транзакции). Слэш за нарушение ставится в очередь на обработку в эпоху n + unbonding_len для нарушения, совершенного в эпоху n, что позволяет протоколу иметь достаточно большой промежуток времени (~21 день) для обнаружения нарушений. Кубический алгоритм слэшинга применяется при обработке слэшинга на unbonding_len пох после эпохи нарушения и работает следующим образом:

1. Для каждого слэша, поставленного в очередь на обработку в эпоху n + unbonding_len, собрать набор известных слэшей, которые должны быть обработаны в эпохи [n-1, n+1].
2. Просуммируйте дробные числа голосов валидатора, связанные с каждым слэшем в этом окне:

Обратите внимание, что в приведенном выражении сила голоса — это сила голоса валидатора на момент совершения нарушения.

3. В этом случае скорость нарезки является функцией квадрата этой суммы, ограниченной снизу некоторым настраиваемым минимальным значением скорости нарезки r min (с соответствующим графиком):

Коэффициент 9 включен таким образом, что максимальное значение косой черты составляет 100 для суммарной силы голоса 1/3. Это критическая точка в модели консенсуса BFT, так как суммарное количество голосов при сговоре, превышающее 1/3 может помешать цепочке достичь консенсуса. Для наглядности здесь также построена кубическая диаграмма скорости резания:

График кубической скорости слешинга Namada

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

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

Инфляция и вознаграждения

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

Система инфляции (PD контроллер)

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

Теперь подробно опишем механизм инфляции на основе PD контроллера. Сначала необходимо ввести некоторые постоянные параметры:

• r_max: максимальная ставка вознаграждения, выраженная в годовых процентах (или APR)
• R_target: коэффициент целевых застейканых токенов (общее количество токенов в стейкинге / общее количество токенов)
• epochs_per_yr: ожидаемое количество эпох в году
• KP_nom: коэффициент пропорционального усиления (P в PD контроллере)
• KD_nom: коэффициент дифференциального усиления (D в PD контроллере)

Далее идут некоторые значения протокола, зависящие от эпохи:

• S: общее предложение токенов
• L: общее количество токенов в стаках (заблокированных в системе PoS)
• π: величина последней инфляции (в единицах токенов за эпоху)
• R_last: соотношение количества токенов в последней эпохе

Далее следует механизм расчета новой величины инфляции π_new:

1. Рассчитайте некоторые начальные значения, которые будут полезны на следующих этапах

• Максимально возможная инфляция π_max = S * r_max / epochs_per_yr
• Коэффициенты усиления для новой эпохи
• KD = KD_nom * π_max
• KP = KP_nom * π_max

2. Рассчитать значения ошибок для PD контроллера

• EP = R_target - L/S
• ED = EP - EP_last = R_last - L/S

3. Рассчитать управляющее воздействие для PD контроллера

• C = KP * EP - KD * ED

4. Рассчитать новую величину инфляции

• π_new = max(0, min( π + C , π_max ))

Распределение вознаграждений

После определения суммы инфляции π_new новые токены чеканятся на адрес PoS-счета, где они остаются до тех пор, пока валидатор или делегатор не снимет их. Используемая в Namada схема распределения вознаграждений, основанная на распределении F1 Fee, позволяет автоматически накапливать вознаграждения за стейкинг и эффективно автоматически ребондить их. Таким образом, для получения вознаграждения по ставке в Namada не требуется никаких пользовательских операций. Для достижения этих целей протокол должен отслеживать вознаграждения, причитающиеся валидаторам и делегатам, на протяжении всего срока действия их облигаций.

Процедура отслеживания вознаграждений описывается следующим образом. Сначала в течение эпохи протокол Namada отслеживает долю вознаграждения за блок, причитающуюся каждому валидатору из набора валидаторов consensus (единственные валидаторы, которые могут получать вознаграждение). По завершении эпохи эти доли могут быть использованы для определения количества токенов из π_new причитающихся каждому валидатору и его делегатам. Для каждого валидатора протокол хранит список значений, упорядоченных по эпохам, где каждое значение указывает на дробное увеличение облигационного пакета валидатора за счет вознаграждений, заработанных с эпохи 0. Назовем эти списки продуктами вознаграждений. В частности, каждая запись в продуктах вознаграждений валидатора, соответствующая эпохе e, имеет вид:

где rV(e) — количество инфляционных токенов, заработанных за счет вознаграждения блока в эпоху e, а sV(e) — ставка валидатора в эпоху e
Для вычисления одного из этих значений в конце эпохи
e, нам нужно только значение из эпохи e-1 в дополнение к новому вознаграждению и ставке. Тогда вознаграждение, начисленное за диапазон эпох, может быть определено как отношение этих значений на граничных эпохах рассматриваемого диапазона.

Фактически в хранилище хранятся два набора продуктов вознаграждения — один (описанный выше) с учетом самооблигаций валидаторов, другой — с учетом делегаций. В продуктах вознаграждения делегаций хранятся значения вида:

где cV(e) — размер комиссии валидатора за делегации в эпоху e.

Использование премиальных продуктов имеет ряд приятных преимуществ:

• Хранение продуктов вознаграждения позволяет немедленно обновлять право голоса валидаторов, учитывая продукты вознаграждения вместе с токенами, поставленными в облигацию.
• Количество токенов, которое должно быть зачислено делегату (или валидатору для самооблигации), необходимо вычислять только в момент изъятия, учитывая первоначальную сумму в облигации и продукты вознаграждения за время жизни облигации.
• Можно избежать множества ненужных итераций в хранилище.
• Делегаторам не нужно многократно снимать вознаграждения и затем переделегировать их.

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

Распределение вознаграждения за блок между автором, подписями(signers) и другими валидаторами consensus зависит от суммарной доли всех подписей валидаторов, включенных в блок автором. Распределение построено таким образом, что предлагающий всегда заинтересован в том, чтобы включить в блок как можно больше подписей валидаторов. Такое поведение поощряется, поскольку эффективность работы легкого клиента возрастает с увеличением количества подписей. В текущей конфигурации Namada 1,00–1,33% вознаграждения за блок получает исключительно автор предложения. Кумулятивное вознаграждение в виде токенов распределяется между всеми валидаторами подписей в соответствии с их взвешенной долей в общей доле подписей. Аналогичным образом, токены, зарезервированные исключительно для участия в consensus, пропорциональны доле валидатора. Более подробно это описано тут.

Заключение

В данной статье были описаны различные части Кубической системы Proof-of-stake проекта Namada и те улучшения, которые она использует по сравнению с другими системами proof-of-stake блокчейна. Эти усовершенствования сводятся к следующему:

• Эпохальный стейкинг: применение изменений состояния PoS только на границах эпох делает light-клиентов более эффективными и позволяет правильно запустить протокол DKG для шифрования транзакций в mempool для оптимизации конфиденциальности.
• Кубический слэшинг: учет коррелированного поведения валидаторов (нарушения, совершенные рядом друг с другом) и увеличение строгости слэш-наказаний обеспечивает более высокий уровень безопасности.
• Автокомпаунд вознаграждений: концепция продуктов вознаграждения повышает эффективность протокола для обработки изменений состояния PoS и помогает максимизировать вознаграждения и UX для пользователей (делегаторов).

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

Оригинал статьи на английском: English (28.02.2023)
Автор перевода: Nick Shakel

Будьте в курсе новостей и присоединяйтесь к сообществу Namada!

Сайт / Блог / Твиттер / Дискорд / Форум / Подкасты / Документы / Specs / Ютуб / Календарь сообщества / Телеграм / Reddit /

Подпишитесь, для получения обновлений на свой email.