Моё первое впечатление от консенсуса SA было таким: как вообще получилось число 1000 DUSK? У whitepaper есть только итог, но нет выводов и промежуточных шагов. Поэтому я пошёл от заданных там параметров и попытался всё восстановить.
Там задан epoch — 2160 блоков. По текущей скорости генерации в Dusk это примерно 6 часов на один epoch. Затем они дают формулу созревания: M = 2 × epoch - (height mod epoch). То есть, если вы застейкаете одну транзакцию DUSK, вам нужно ждать от половины до целого epoch, прежде чем вы реально начнёте «работать».
Интересная часть этого дизайна в том, что время вступления всех новых стейков синхронизировано с границей epoch. Это не «вступил — и сразу активировался», а «все активируются коллективно с одного и того же старта». Я предполагаю, что это сделано для того, чтобы у DS-алгоритма детерминированного подбора (лотереи) был стабильный снимок пула валидаторов/проvisioner на момент распределения. Если бы каждый мог войти в любой момент и сразу начать действовать, то в каждом блоке менялся бы состав кандидатов provisioner, и тогда детерминированное распределение было бы сделать сложнее $DUSK
А что насчёт самого 1000 DUSK? Я прикинул: если порог сделать равным 100, то число provisioner резко вырастет. Конкуренция за 64 slot’а в каждом epoch станет намного жёстче, но при этом объёмы стейка у отдельных нод окажутся слишком малы — и безопасность сети, возможно, даже будет размыта. Если поставить 10000, то рядовым пользователям почти не попасть: provisioner превратятся в игру для узкого круга крупных нод, и децентрализация пострадает. @Dusk
1000 — это число «посередине». Я посмотрел параметры ещё нескольких PoS-сетей: порог Dusk не выглядит ни слишком высоким, ни совсем низким. Это похоже на месседж: я не хочу, чтобы вы могли просто накинуть случайную «мелочь» и начать запускать ноду, но также я не хочу, чтобы участвовать могли только очень крупные держатели.
Однако у меня всё же остался вопрос, который я не до конца продумал. В whitepaper нет целевого диапазона по общему числу provisioner, и не указано, при каком соотношении «интенсивности» конкурса за 64 slot’а достигается оптимум. Без этих данных я на самом деле не могу оценить, насколько правильно выбран именно порог 1000. Возможно, его обоснованность можно будет проверить только на практике — после запуска в mainnet, с использованием реальных данных. #dusk
Там задан epoch — 2160 блоков. По текущей скорости генерации в Dusk это примерно 6 часов на один epoch. Затем они дают формулу созревания: M = 2 × epoch - (height mod epoch). То есть, если вы застейкаете одну транзакцию DUSK, вам нужно ждать от половины до целого epoch, прежде чем вы реально начнёте «работать».
Интересная часть этого дизайна в том, что время вступления всех новых стейков синхронизировано с границей epoch. Это не «вступил — и сразу активировался», а «все активируются коллективно с одного и того же старта». Я предполагаю, что это сделано для того, чтобы у DS-алгоритма детерминированного подбора (лотереи) был стабильный снимок пула валидаторов/проvisioner на момент распределения. Если бы каждый мог войти в любой момент и сразу начать действовать, то в каждом блоке менялся бы состав кандидатов provisioner, и тогда детерминированное распределение было бы сделать сложнее $DUSK
А что насчёт самого 1000 DUSK? Я прикинул: если порог сделать равным 100, то число provisioner резко вырастет. Конкуренция за 64 slot’а в каждом epoch станет намного жёстче, но при этом объёмы стейка у отдельных нод окажутся слишком малы — и безопасность сети, возможно, даже будет размыта. Если поставить 10000, то рядовым пользователям почти не попасть: provisioner превратятся в игру для узкого круга крупных нод, и децентрализация пострадает. @Dusk
1000 — это число «посередине». Я посмотрел параметры ещё нескольких PoS-сетей: порог Dusk не выглядит ни слишком высоким, ни совсем низким. Это похоже на месседж: я не хочу, чтобы вы могли просто накинуть случайную «мелочь» и начать запускать ноду, но также я не хочу, чтобы участвовать могли только очень крупные держатели.
Однако у меня всё же остался вопрос, который я не до конца продумал. В whitepaper нет целевого диапазона по общему числу provisioner, и не указано, при каком соотношении «интенсивности» конкурса за 64 slot’а достигается оптимум. Без этих данных я на самом деле не могу оценить, насколько правильно выбран именно порог 1000. Возможно, его обоснованность можно будет проверить только на практике — после запуска в mainnet, с использованием реальных данных. #dusk