#dusk $DUSK Я пересчитал заново экономическую модель узлов Dusk и обнаружил, что самая нелогичная вещь — это не порог стейкинга, а разница в правах между «легкими узлами» и «полными узлами». В большинстве PoS‑сетей наличие монет означает наличие голоса; но в архитектуре Dusk не все узлы могут участвовать в консенсусе.
У Dusk уровень консенсуса разделён на два слоя: Provisioner‑узлы отвечают за выпуск блоков и подтверждения. Минимальный стейк — не менее 1000 монет $DUSK , и при этом узел должен быть онлайн. Лёгкие узлы могут запрашивать и транслировать транзакции, но не выпускают блоки и не получают вознаграждение. Это первая «ступенька», которую многие частные пользователи пропускают: вы купили монеты и положили их в кошелёк — не значит, что вы «участвуете» в этой цепочке; вы просто пассажир.
Ещё глубже — в механизмах наград и штрафов. Если Provisioner‑узел корректно выпускает блоки, доход поступает за счёт новых эмиссий и комиссий. Если узел отключается, стейк помечается как locked или приостанавливается. Если же злоумышленничать, стейк может быть сожжён. Логика здесь простая: принудительно связать выгоды узла с безопасностью сети — нельзя просто «отдать голос» и рассчитывать на пассивную прибыль.
Но по-настоящему меня волнует другой вопрос: есть ли у легких узлов право на верификацию? Лёгкие узлы Dusk могут подтверждать транзакции через заголовки блоков, не скачивая весь объём данных. Теоретически, даже не запуская Provisioner, вы всё равно можете независимо проверять состояние цепочки. Но в реальности большинство пользователей не будет этим заниматься — они полагаются на браузер или кошелёк с их стандартным RPC.
И это снова возвращает нас к тому, что легкие узлы могут верифицировать на уровне архитектуры, но на практике часто этого не делают. Когда большинство пользователей передаёт доверие нескольким RPC‑эндпойнтам, децентрализация незаметно уходит в тень — растворяясь в удобстве пользовательского опыта.
Поэтому, глядя на #dusk распределение узлов, я не буду ограничиваться только общим объёмом стейка. Мне куда важнее: географическое распределение Provisioner‑узлов и концентрация у хостинг‑провайдеров; реальная частота использования клиентов легких узлов; и достаточно ли пользователей выбирают самостоятельную верификацию, а не полагаются на сторонних.
Оборона распределённого реестра в итоге находится не в коде, а в тот момент, когда каждый пользователь решает «кому доверять».
#dusk @Dusk