Ключ, который запустить dusk-провайдеру не нужно владеть залогом
Компрометация сервера провайдера не обязана давать атакующему полномочия на вывод DUSK, стоящего за ним.
Ставка Dusk разделяет две роли. Консенсус-ключ — это онлайн-учётные данные, которые узел использует для голосования и подписания блоков. Ключ владельца управляет размораживанием (unstaking) и выводом залога. Если владелец не указан, консенсус-ключ по умолчанию становится владельцем. Но Dusk также поддерживает stake в rusk-wallet —owner <OWNER_ADDRESS>, чтобы разделить их.
Это меняет границу безопасности провайдера.
У узла должно быть consensus.keys, чтобы участвовать в консенсусе; ему не нужен рядом находящийся кошелёк владельца. Текущие рекомендации для операторов Dusk явно советуют держать кошелёк владельца и материалы для восстановления вне узла.
Таким образом, оператор может рассматривать Консенсус-ключ как горячие операционные учётные данные, не предоставляя автоматически этой «горячей» среде возможность выйти (exit) с капиталом.
Разделение не является абсолютной защитой. Украденный Консенсус-ключ всё равно может подписывать конфликтующие или иные недействительные консенсус-сообщения, а жёсткие штрафы Dusk могут сжечь (burn) залог за такое поведение.
Практическое решение, следовательно, принимается ещё до стейкинга: использование конфигурации по умолчанию объединяет полномочия консенсуса и контроля капитала; указание отдельного владельца сужает то, что скомпрометированный хост валидатора может напрямую сделать.
@Dusk $DUSK #dusk
Компрометация сервера провайдера не обязана давать атакующему полномочия на вывод DUSK, стоящего за ним.
Ставка Dusk разделяет две роли. Консенсус-ключ — это онлайн-учётные данные, которые узел использует для голосования и подписания блоков. Ключ владельца управляет размораживанием (unstaking) и выводом залога. Если владелец не указан, консенсус-ключ по умолчанию становится владельцем. Но Dusk также поддерживает stake в rusk-wallet —owner <OWNER_ADDRESS>, чтобы разделить их.
Это меняет границу безопасности провайдера.
У узла должно быть consensus.keys, чтобы участвовать в консенсусе; ему не нужен рядом находящийся кошелёк владельца. Текущие рекомендации для операторов Dusk явно советуют держать кошелёк владельца и материалы для восстановления вне узла.
Таким образом, оператор может рассматривать Консенсус-ключ как горячие операционные учётные данные, не предоставляя автоматически этой «горячей» среде возможность выйти (exit) с капиталом.
Разделение не является абсолютной защитой. Украденный Консенсус-ключ всё равно может подписывать конфликтующие или иные недействительные консенсус-сообщения, а жёсткие штрафы Dusk могут сжечь (burn) залог за такое поведение.
Практическое решение, следовательно, принимается ещё до стейкинга: использование конфигурации по умолчанию объединяет полномочия консенсуса и контроля капитала; указание отдельного владельца сужает то, что скомпрометированный хост валидатора может напрямую сделать.
@Dusk $DUSK #dusk
