МАШИНЕ, КОТОРАЯ РАСПИСЫВАЕТСЯ ЗА PREVISIONER НА ЗАКАТЕ, НЕ НУЖНО ВЛАДЕТЬ СТАВКОЙ.
Я думал о валидаторском ключе так, будто он представляет собой одну сущность:
управление.
Но @Dusk разделяет это управление на две совершенно разные роли.
Консенсусный ключ — это то, чем узел пользуется для участия в консенсусе: голосование и подпись блоков.
Ключ владельца — это то, что позволяет снять стейк и вывести капитал, стоящий за этим провайдером.
Dusk по умолчанию позволяет обеим ролям использовать один и тот же ключ.
Но документация оператора рекомендует разделять их.
Для меня это различие куда интереснее, чем звучит на первый взгляд:
консенсусная власть ≠ власть владения.
Провайдер должен держать свой консенсусный ключ доступным для онлайн-машины, которая постоянно участвует в сети.
Именно такую среду я меньше всего хотел бы наделять ненужной властью над самой ставкой.
Если узел или консенсусный ключ окажутся скомпрометированы, разделение Ключа владельца означает, что злоумышленник не получает автоматически возможность снять стейк и вывести средства.
Значит, в этом дизайне заложена тонкость.
Он защищает не только ключ.
Он ограничивает зону поражения того ключа, который должен оставаться в рабочем состоянии.
Но есть компромисс.
Перенос власти владения с узла означает, что Ключ владельца теперь нужно где-то защищать иначе, но при этом сохранять возможность восстановления, когда оператору действительно потребуется снять стейк или вывести средства.
Большее разделение может снизить один вид риска, одновременно увеличив операционную ответственность в другом месте.
Вот эту часть я и оцениваю.
Не просто то, насколько сложно скомпрометировать провайдер Dusk.
Я спрашиваю:
Если консенсусная машина будет скомпрометирована завтра, какую именно власть злоумышленник реально унаследует?
Для инфраструктуры, которая должна оставаться в сети 24/7, возможно, самая сильная модель безопасности — не давать машине больше защиты.
Вместо этого — дать машине меньше власти с самого начала.
#dusk $DUSK @Dusk
$BOME $ETH
Я думал о валидаторском ключе так, будто он представляет собой одну сущность:
управление.
Но @Dusk разделяет это управление на две совершенно разные роли.
Консенсусный ключ — это то, чем узел пользуется для участия в консенсусе: голосование и подпись блоков.
Ключ владельца — это то, что позволяет снять стейк и вывести капитал, стоящий за этим провайдером.
Dusk по умолчанию позволяет обеим ролям использовать один и тот же ключ.
Но документация оператора рекомендует разделять их.
Для меня это различие куда интереснее, чем звучит на первый взгляд:
консенсусная власть ≠ власть владения.
Провайдер должен держать свой консенсусный ключ доступным для онлайн-машины, которая постоянно участвует в сети.
Именно такую среду я меньше всего хотел бы наделять ненужной властью над самой ставкой.
Если узел или консенсусный ключ окажутся скомпрометированы, разделение Ключа владельца означает, что злоумышленник не получает автоматически возможность снять стейк и вывести средства.
Значит, в этом дизайне заложена тонкость.
Он защищает не только ключ.
Он ограничивает зону поражения того ключа, который должен оставаться в рабочем состоянии.
Но есть компромисс.
Перенос власти владения с узла означает, что Ключ владельца теперь нужно где-то защищать иначе, но при этом сохранять возможность восстановления, когда оператору действительно потребуется снять стейк или вывести средства.
Большее разделение может снизить один вид риска, одновременно увеличив операционную ответственность в другом месте.
Вот эту часть я и оцениваю.
Не просто то, насколько сложно скомпрометировать провайдер Dusk.
Я спрашиваю:
Если консенсусная машина будет скомпрометирована завтра, какую именно власть злоумышленник реально унаследует?
Для инфраструктуры, которая должна оставаться в сети 24/7, возможно, самая сильная модель безопасности — не давать машине больше защиты.
Вместо этого — дать машине меньше власти с самого начала.
#dusk $DUSK @Dusk
$BOME $ETH