Сегодня я изучал стейкинг в ноде Dusk и застрял на одном вопросе: раз стейкинг идет из одного и того же кошелькового набора, почему официально рекомендуют разделять Owner Key и Consensus Key? После того как я прочитал гайд по кошелькам ноды, стало ясно: это скорее разделение «прав дежурить» и «прав забрать деньги».
Consensus Key я представил как пропуск для сменной работы в компании. Нода использует его для участия в консенсусе, голосования и подписи сообщений о блоках — значит, ключ должен находиться в месте, где он доступен онлайн-серверу. Owner Key похож на главный ключ от сейфа в бухгалтерии: он отвечает за анстейкинг (разблокировку) и вывод средств. Официальные настройки по умолчанию сделаны максимально просто: если не указать адрес владельца дополнительно, Consensus Key автоматически становится Owner Key. Но это означает, что если онлайн-машина будет скомпрометирована, злоумышленник получит соответствующий ключ — и тогда права на анстейкинг и вывод средств тоже могут оказаться под угрозой. Другая рекомендуемая официальная практика — указать для стейкинга отдельный адрес владельца, чтобы нода хранила только файл с ключом консенсуса, а права на средства были сохранены отдельно.
У этой аналогии есть важная граница: разнесение ключей не гарантирует, что после компрометации сервера все будет в порядке. Consensus Key по-прежнему может подписывать сообщения консенсуса; а если его использовать неправомерно или если одна и та же консенсус-«сущность» одновременно запущена на двух активных нодах, это может привести к конфликтующим сообщениям и сработать hard penalty. Иными словами, разделение главным образом защищает права на вывод и анстейкинг, но риски для консенсуса все равно нужно снижать корректной эксплуатацией.
Интуиция пользователей BTC о том, что «долгосрочные активы нельзя намертво привязывать к онлайн-машинам», знакома многим; в ETH-стейкинге это тоже хорошо объясняется: подписи и права на вывод управляются отдельно. Dusk встроила такой подход в гайд по нодам — и это заставило меня задуматься о том, где именно хранятся ключи, а не только о том, сможет ли нода «работать».
Для обычных стейкеров @Dusk я бы хотел, чтобы кошелек или инструменты ноды прямо отмечали, являются ли Owner Key и Consensus Key одним и тем же адресом, и подсказывали, какая именно ключевая сущность должна храниться на сервере. $DUSK требует, чтобы в консенсусе участвовало больше людей в долгую — значит безопасность не должна сводиться к попытке получить «минимум настроек». Если в будущем я действительно решу поднять ноду, я сначала сохраню seed-фразу в офлайн-среде и буду хранить Owner Key отдельно, а уже потом подумаю о том, как организовать онлайн-доступ и вознаграждения; это гораздо спокойнее, чем складывать все права в одну серверную машину.
#dusk
Consensus Key я представил как пропуск для сменной работы в компании. Нода использует его для участия в консенсусе, голосования и подписи сообщений о блоках — значит, ключ должен находиться в месте, где он доступен онлайн-серверу. Owner Key похож на главный ключ от сейфа в бухгалтерии: он отвечает за анстейкинг (разблокировку) и вывод средств. Официальные настройки по умолчанию сделаны максимально просто: если не указать адрес владельца дополнительно, Consensus Key автоматически становится Owner Key. Но это означает, что если онлайн-машина будет скомпрометирована, злоумышленник получит соответствующий ключ — и тогда права на анстейкинг и вывод средств тоже могут оказаться под угрозой. Другая рекомендуемая официальная практика — указать для стейкинга отдельный адрес владельца, чтобы нода хранила только файл с ключом консенсуса, а права на средства были сохранены отдельно.
У этой аналогии есть важная граница: разнесение ключей не гарантирует, что после компрометации сервера все будет в порядке. Consensus Key по-прежнему может подписывать сообщения консенсуса; а если его использовать неправомерно или если одна и та же консенсус-«сущность» одновременно запущена на двух активных нодах, это может привести к конфликтующим сообщениям и сработать hard penalty. Иными словами, разделение главным образом защищает права на вывод и анстейкинг, но риски для консенсуса все равно нужно снижать корректной эксплуатацией.
Интуиция пользователей BTC о том, что «долгосрочные активы нельзя намертво привязывать к онлайн-машинам», знакома многим; в ETH-стейкинге это тоже хорошо объясняется: подписи и права на вывод управляются отдельно. Dusk встроила такой подход в гайд по нодам — и это заставило меня задуматься о том, где именно хранятся ключи, а не только о том, сможет ли нода «работать».
Для обычных стейкеров @Dusk я бы хотел, чтобы кошелек или инструменты ноды прямо отмечали, являются ли Owner Key и Consensus Key одним и тем же адресом, и подсказывали, какая именно ключевая сущность должна храниться на сервере. $DUSK требует, чтобы в консенсусе участвовало больше людей в долгую — значит безопасность не должна сводиться к попытке получить «минимум настроек». Если в будущем я действительно решу поднять ноду, я сначала сохраню seed-фразу в офлайн-среде и буду хранить Owner Key отдельно, а уже потом подумаю о том, как организовать онлайн-доступ и вознаграждения; это гораздо спокойнее, чем складывать все права в одну серверную машину.
#dusk