#dusk $DUSK @Dusk
На этой неделе я читал документацию по консенсусу Dusk, в основном чтобы понять, действительно ли «быстрая финализация» сохраняется под нагрузкой, а не только в «чистый» день. Сжатые аттестации проводят каждую итерацию через три шага — предложение, валидация и ратификация — при участии генератора блоков и двух комитетов, выбранных детерминированной сортицией, с весами по доле, а не по численности участников. В целом это объясняет обычные условия.
Меня же насторожило то, что оказалось спрятано за сценарием «всё идёт по плану» — пункт об Emergency Mode (аварийном режиме). Если итерации продолжают не проходить, протокол не просто повторяет попытки по таймеру: он отключает тайм-ауты полностью и продолжает работать, пока не будет достигнут кворум. Это существенно иная модель отказа, чем у большинства PoS-сетей: они обычно просто ждут, пока сбой закончится, и надеются, что валидаторы снова выйдут в сеть. Удаление тайм-аута выглядит устойчивым на бумаге, но это также означает, что время финализации становится неограниченным ровно в том сценарии, где уверенность важнее всего — во время сбоя, а не после того, как он уже закончился.
Для сети, которая позиционирует себя для регулируемых финансов, этот компромисс стоит обдумать, а не замалчивать. Система расчетов, которая гарантирует «eventually correct» (в конце концов корректность), не совсем то же обещание, что «fast» (быстро), и я не уверен, что @Dusk полностью разобрался, что именно она продаёт. Интересно, как часто Emergency Mode реально срабатывал на mainnet до сих пор.
$DUSK #DUSK
На этой неделе я читал документацию по консенсусу Dusk, в основном чтобы понять, действительно ли «быстрая финализация» сохраняется под нагрузкой, а не только в «чистый» день. Сжатые аттестации проводят каждую итерацию через три шага — предложение, валидация и ратификация — при участии генератора блоков и двух комитетов, выбранных детерминированной сортицией, с весами по доле, а не по численности участников. В целом это объясняет обычные условия.
Меня же насторожило то, что оказалось спрятано за сценарием «всё идёт по плану» — пункт об Emergency Mode (аварийном режиме). Если итерации продолжают не проходить, протокол не просто повторяет попытки по таймеру: он отключает тайм-ауты полностью и продолжает работать, пока не будет достигнут кворум. Это существенно иная модель отказа, чем у большинства PoS-сетей: они обычно просто ждут, пока сбой закончится, и надеются, что валидаторы снова выйдут в сеть. Удаление тайм-аута выглядит устойчивым на бумаге, но это также означает, что время финализации становится неограниченным ровно в том сценарии, где уверенность важнее всего — во время сбоя, а не после того, как он уже закончился.
Для сети, которая позиционирует себя для регулируемых финансов, этот компромисс стоит обдумать, а не замалчивать. Система расчетов, которая гарантирует «eventually correct» (в конце концов корректность), не совсем то же обещание, что «fast» (быстро), и я не уверен, что @Dusk полностью разобрался, что именно она продаёт. Интересно, как часто Emergency Mode реально срабатывал на mainnet до сих пор.
$DUSK #DUSK