Одна небольшая деталь в стейкинг-дизайне Dusk привлекла мое внимание, потому что она решает очень практичную проблему безопасности.

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

Dusk разделяет эти обязанности на Consensus Key и Owner Key.

Consensus Key используется провайдером (provisioner) для голосования и подписания блоков. Owner Key может оставаться контролирующим чувствительные действия, такие как анстейкинг (unstaking) и вывод позиции (withdrawing).

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

Валидатору нужны его консенсусные учетные данные, чтобы выполнять сетевые обязанности. Это естественным образом создает уязвимость (exposure). Ключ, который контролирует лежащие в основе средства, не обязан нести ровно тот же риск.

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

Вот такого рода архитектуру я нахожу интересной в Dusk. Некоторые из самых полезных идей — это не броские функции. Это решения, принятые о том, как финансовая инфраструктура фактически ведет себя на практике.

Вы бы сохранили ваше право собственности отдельно от операций валидатора?

@Dusk_Foundation #dusk $DUSK