Я за эти годы, наблюдая за экономическими моделями PoS-цепочек, выработал привычку: не смотреть на то, что официально раздувают в годовых, а сначала разобраться, как там спроектированы «стоимость злонамеренных действий» и «стоимость халтуры». Когда эти два показателя посчитаны, только тогда можно сказать, что долгосрочная безопасность этой цепочки действительно стоит на ногах.

Распределение наград за выпуск блоков в Dusk устроено так: 80% — валидаторам, выпускающим блок, 10% — в пользу избирательного комитета, 10% — в технический казначейский фонд. На первый взгляд ничего особо нового. Но то, из‑за чего я задержал взгляд подольше, в том, что внутри этих 80% у валидатора есть ещё один слой структуры: 70% — фиксированная сумма, а оставшиеся 10% — переменная. Она привязана к тому, сколько подписей избирателей собрано вместе с этим блоком. Чем полнее «набор» голосов, тем больше валидатор забирает из переменной части. Этот дизайн решает конкретную проблему: не дать валидатору ради экономии времени собрать меньше голосов и всё равно сразу выпустить блок, тем самым «утопив» вероятности вознаграждения у самих избирателей.

Дальше — ещё один механизм, на который раньше я не слишком обращал внимание: так называемая «проблема мотивации будущих валидаторов». В каждой эпохе заранее можно вычислить, кто именно и на каком этапе итераций будет валидатором. У будущих кандидатов теоретически появляется стимул надеяться на срыв в предыдущих раундах, чтобы очередь дошла до них и они получили награду. Dusk смягчает это четырьмя уровнями: сам процесс голосования тоже приносит награды, чтобы избиратели не бросали дело в попытке рискнуть ради более крупной, но более маленькой по вероятности награды; награда валидатора зависит от полноты набора голосов; в каждой эпохе кандидатов следующего раунда исключают из права голосовать; и, наконец, для каждой итерации задают верхний предел числа раундов.

По отдельности каждое правило само по себе не выглядит чем‑то удивительным, но когда эти четыре меры складываются и закрывают одну и ту же уязвимость, подход «слой за слоем ставим заплатки» — это как раз сигнал, по которому я оцениваю, действительно ли команда прогоняла испытательную сеть, видела злонамеренные сценарии, а не просто «нарисовала архитектурную схему на бумаге и запустила». В части наказаний тоже есть разделение по степени тяжести: небольшие ошибки приводят к мягкой блокировке с понижением веса, а серьёзные — например, широковещательно неэффективные блоки или двойное голосование — напрямую сжигают часть залога. Разделение на мягкий и жёсткий уровни, и конкретная «зернистость» настройки, как мне кажется, зрелее, чем у многих PoS-цепочек, которые вышли пару лет назад.

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

Какой способ оценки зрелости PoS-цепочки вам ближе?
@Dusk $DUSK #dusk