пере перечитывал(а) раздел 7 dusk whitepaper прошлой ночью, и меня зацепило кое-что, чего я раньше не замечал(а).
большинство людей говорит о proof of stake так, будто там одна роль: вы делаете стейк, вы валидируете — и всё. в dusk это на самом деле разделено на две отдельные работы.
генераторы предлагают следующий блок, а provisioners валидируют и финализируют его. разные обязанности, разные механизмы извлечения.. даже разные требования к стейку.
самое интересное, что генераторы выбираются через приватность.
сохранение процедуры такое, что лидер для конкретного раунда заранее не известен. provisioners подтягиваются в комитеты через совершенно отдельный процесс. две роли означают, что атакующему нужно контролировать стейк в двух разных местах, а не в одном.
раньше я не думал(а) о дизайне консенсуса как о задаче разделения ролей; в основном представлял(а) это просто как «больше стейка — больше шансов». разделение ролей proposer и validator.
в итоге это реально повышает стоимость атаки на цепочку, или это в основном организационный выбор??
#dusk @Dusk $DUSK
большинство людей говорит о proof of stake так, будто там одна роль: вы делаете стейк, вы валидируете — и всё. в dusk это на самом деле разделено на две отдельные работы.
генераторы предлагают следующий блок, а provisioners валидируют и финализируют его. разные обязанности, разные механизмы извлечения.. даже разные требования к стейку.
самое интересное, что генераторы выбираются через приватность.
сохранение процедуры такое, что лидер для конкретного раунда заранее не известен. provisioners подтягиваются в комитеты через совершенно отдельный процесс. две роли означают, что атакующему нужно контролировать стейк в двух разных местах, а не в одном.
раньше я не думал(а) о дизайне консенсуса как о задаче разделения ролей; в основном представлял(а) это просто как «больше стейка — больше шансов». разделение ролей proposer и validator.
в итоге это реально повышает стоимость атаки на цепочку, или это в основном организационный выбор??
#dusk @Dusk $DUSK