Я предположил, что стейкинг в PoS-сети означает: один ключ отвечает за всё — ввести DUSK, получать вознаграждения, и тот же ключ управляет процессом от начала до конца.
Официальные документы оператора Dusk разделяют это на две части.
Консенсусный ключ — это ключ, который узел использует для подписи и голосования в консенсусе. Он должен находиться на узле, имеющем доступ в интернет, и участвовать в работе валидатора. Ключ владельца — отдельный: это ключ, который может разморозить стейк или вывести средства, и в документации сказано, что ему вообще не нужно взаимодействовать с узлом.
Польза для безопасности заключается не просто в наличии двух ключей. Важно то, что полномочия участвовать в консенсусе и полномочия выводить средства не обязаны находиться в одном и том же месте. Если консенсусный ключ будет скомпрометирован из‑за взлома сервера, на котором он размещён, злоумышленник может вмешаться в участие в консенсусе, но всё равно не сможет разморозить стейк или вывести его. Эти полномочия изначально не размещаются на той машине, которая вообще открыта для атак через интернет. Поэтому реальный вопрос безопасности — не только в том, сколько застейкано. Вопрос в том, где именно физически/логически находится полномочие на вывод относительно той машины, которая подвергается атакам.
Но есть один нюанс, который в документации не скрывают: такое разделение не является настройкой по умолчанию. Если вы делаете стейк, не указав отдельный ключ владельца, консенсусный ключ автоматически становится владельцем тоже — один ключ, одна граница, обратно к модели, которую я изначально предполагал. Более безопасная схема — это выбор, который оператор должен осознанно сделать, а не то, что протокол навязывает.
«Граница безопасности, в которую нужно явно войти, — это гарантия иного рода, чем гарантия, встроенная в путь по умолчанию, даже когда технически доступны оба варианта».
Что мне на самом деле хотелось бы знать: сколько активных провайдеров работают с отдельным ключом владельца по сравнению с настройкой по умолчанию, потому что это показывает, действительно ли применяется более надёжная граница, а не просто доступна.
#dusk $DUSK @Dusk
Официальные документы оператора Dusk разделяют это на две части.
Консенсусный ключ — это ключ, который узел использует для подписи и голосования в консенсусе. Он должен находиться на узле, имеющем доступ в интернет, и участвовать в работе валидатора. Ключ владельца — отдельный: это ключ, который может разморозить стейк или вывести средства, и в документации сказано, что ему вообще не нужно взаимодействовать с узлом.
Польза для безопасности заключается не просто в наличии двух ключей. Важно то, что полномочия участвовать в консенсусе и полномочия выводить средства не обязаны находиться в одном и том же месте. Если консенсусный ключ будет скомпрометирован из‑за взлома сервера, на котором он размещён, злоумышленник может вмешаться в участие в консенсусе, но всё равно не сможет разморозить стейк или вывести его. Эти полномочия изначально не размещаются на той машине, которая вообще открыта для атак через интернет. Поэтому реальный вопрос безопасности — не только в том, сколько застейкано. Вопрос в том, где именно физически/логически находится полномочие на вывод относительно той машины, которая подвергается атакам.
Но есть один нюанс, который в документации не скрывают: такое разделение не является настройкой по умолчанию. Если вы делаете стейк, не указав отдельный ключ владельца, консенсусный ключ автоматически становится владельцем тоже — один ключ, одна граница, обратно к модели, которую я изначально предполагал. Более безопасная схема — это выбор, который оператор должен осознанно сделать, а не то, что протокол навязывает.
«Граница безопасности, в которую нужно явно войти, — это гарантия иного рода, чем гарантия, встроенная в путь по умолчанию, даже когда технически доступны оба варианта».
Что мне на самом деле хотелось бы знать: сколько активных провайдеров работают с отдельным ключом владельца по сравнению с настройкой по умолчанию, потому что это показывает, действительно ли применяется более надёжная граница, а не просто доступна.
#dusk $DUSK @Dusk
