(Ре)Делегирование в Cosmos Hub

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

Что такое делегирование?

Cosmos Hub использует Tendermint в качестве базового механизма консенсуса BFT и использует протокол BPoS для выбора генератора блока, где каждый кандидат (валидатор) взвешивается в соответствии с их относительной общей застеканой долей токенов и где общая доля валидатора напрямую коррелирует с их шансом предложить блок и количеством вознаграждений, которые они получают за это. Протокол поддерживает фиксированное число валидаторов [1].

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

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

Однако важно отметить, что эти ATOM будут заморожены на UnbondingPeriod[2], параметризованный период времени, в течение которого все делегаты, включая валидаторы, должны ждать, пока их ATOM станут полностью “несвязанными”. До тех пор, пока UnbondingPeriod не пройдет, ATOM, по существу, будут заблокированы. Кроме того, эти ATOM все еще могут быть потенциально урезаны при совершении валидатором любого византийского поведения. UnbondingPeriod обеспечивает различные меры безопасности в сети, такие как учет предположений о сетевой синхронизации, обеспечение безопасности при определенных атаках[3] и решение проблемы “nothing-at-stake”.

Прежде чем мы углубимся в некоторые ограничения и более тонкие детали, которые следует учитывать при делегировании, нам нужно также определить, что такое ределегирование. Ределегирование-это просто повторное делегирование или перемещение части (или всего количества) ваших застейканых ATOM из одного валидатора в другой. Это может быть полезно по ряду причин. Например, если делегатор больше не доволен услугами или комиссией, которые предоставляет валидатор, он может решить переместить свои связанные ATOM в другой валидатор, не дожидаясь полного UnbondingPeriod, чтобы сделать перемещение. Тем не менее, есть некоторые ограничения, и мы обсудим их ниже.

Ограничения (ре)делегирования

Итак, теперь, когда у нас есть четкое понимание роли (ре)делегирования в сети и UnbondingPeriod, давайте рассмотрим некоторые из более тонких деталей. Как мы уже упоминали ранее, застейканые ATOM подвержены UnbondingPeriod. В дополнение к этому существует еще один важный параметр, а именно MaxEntries[4]. Параметр MaxEntries влияет на общее количество:

• Unbonding(разлоченых) токенов между уникальной парой делегат/валидатор
• Ределегированных токенов между уникальной тройкой делегат/валидатор-источник/валидатор-получатель

Понятие "entries"(запись) используется в Cosmos Hub для хранения информации о связи делегата, количества unbonding токенов и соответствующим валидатором.

Чтобы проиллюстрировать это лучше, мы используем следующий пример. Предположим, что делегат D застейкал N ATOM валидатору X. Конечно, D может иметь другие застейканые токены другим валидаторам, но в этом примере мы рассмотрим только один валидатор. Теперь делегат D хочет разлочить некоторые из своих ATOM от X, поэтому D посылает транзакцию MsgUndelegateна M ATOM. Это создает "entries" в блокчейне между D и X. Если D хочет дополнительно разлочить еще несколько ATOM из X, он отправит еще одну транзакцию MsgUndelegate. Однако D может делать это только до MaxEntriesраз! Любые дальнейшие попытки приведут к следующей ошибке:

too many unbonding delegation entries in this delegator/validator duo, please wait for some entries to mature

Таким образом, делегату D придется ждать полного UnbondingPeriod, прежде чем он сможет попытаться разлочить еще какие-либо ATOM из валидатора X.

То же самое относится и к ределегированию. Другими словами, если делегат D хочет перераспределить некоторые из своих ATOM из валидатора X в другой валидатор Y, он может сделать это только до MaxEntriesраз. Обратите внимание, что для ределегирования это относится к уникальной тройке делегат/валидатор-источник/валидатор-получатель.

Существует еще один важный ключевой фактор, который следует отметить о ределегировании — “транзитивные” ределегирования запрещены. Транзитивные ределегирования можно рассматривать как перемещение токенов от одного валидатора к другому несколько раз. Например, если делегат D ределегирует валидатору X, а затем хочет дополнительно ределегировать из X в другой валидатор Y. Делегату D придется ждать полного UnbondingPeriod, чтобы сделать это. Однако рекомендуется не делегировать только одному валидатору, поэтому это ограничение не должно быть проблемой в большинстве случаев. Это также не означает, что транзитивные ределегирования всегда будут запрещены. В будущем они могут быть разрешены, но с ограничением на общее количество "прыжков". Возможно, это произойдет через предложение по управлению?

Сокращение(Slashing)

Еще одним важным аспектом, который следует иметь в виду при (ре)делегировании, является сокращение. Любое количество токенов, которые у вас есть в валидаторе, либо застейканы, либо находится в процессе разлока, подлежат сокращению, если данный валидатор совершает уклонение или любое другое наказуемое византийское поведение в течение периода, в котором нарушение является “действительным” [5]. Для получения дополнительной информации о сокращении, пожалуйста, просмотрите спецификацию.

Что касается ределегирования, есть несколько важных вещей, которые стоит иметь в виду. Учитывая наш предыдущий пример, когда делегат D перераспределяет часть своей доли от валидатора X к другому валидатору Y, делегат D по-прежнему несет ответственность перед обоими валидаторами! Расширяя этот пример, предположим, что некоторое нарушение произошло на блоке H₁ валидатором X (валидатор-источник) и позже было обнаружено и исправлено в H₂. Делегат D может быть сокращен только в том случае, если выполняются оба следующих условия:

• Ределегирование было сделано после блока H₁
• Ределегирование не окончено (т. е. время завершения после блока H₂)

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

Надеюсь, теперь у вас есть четкое понимание о (ре)делегировании и роли, которую они играют в Cosmos Hub, и некоторых ограничениях и запретах, которые следует иметь в виду при их выполнении. Удачного делегирования!

Точка зрения, выраженная в этой статье, принадлежит All In Bits Inc (Tendermint Inc) и не обязательно совпадает с Interchain Foundation.

Отдельная благодарность Jack Zampolin и Chjango Unchained.

Чтобы получить доступ к исходной статье, посетите официальный блог Cosmos.

Для получения более актуальной информации, пожалуйста, присоединяйтесь к нам в социальных сетях:

Telegram(Eng): t.me/cosmosproject
Telegram(Rus): t.me/cosmosprojectRu