Вникаю в то, как на самом деле Resolves итерацию Succinct Attestation, и кое-что в сценарии отказа постоянно не давало мне покоя.
Очевидная история: комитет валидирует блок, ратифицирует его — и всё. Но протокол Dusk не просто отслеживает «валидно» — он отслеживает Attestations, и Failed Attestation (кворум, согласившийся, что блок *не* валиден) является исходом первого класса, а не чем-то второстепенным.
Вот что я не учёл: отклонять структурно проще, чем принимать. Чтобы ратифицировать валидный блок, комитет должен фактически проверить переходы состояния, подписи, всё содержимое кандидата. Чтобы получить Failed Attestation, членам комитета достаточно согласия супербольшинства, что *что-то* не так — некорректные данные, плохой пропозер, таймаут. Это куда более поверхностная проверка.
Так что механически плохой блок может быстрее набрать свой порог кворума, чем хороший блок проходит валидацию — не потому, что сеть «предпочитает» неверные блоки, а потому что отклонение не требует заново восстанавливать корректность, достаточно обнаружить её отсутствие. Это не баг. На самом деле именно так устроено существование итераций: проваливаться быстро, передавать слот следующему провайдеру и сохранять предсказуемость времени блока.
Но я всё ещё разбираюсь, что означает эта асимметрия, когда размеры комитетов меняются в зависимости от распределения доли. Станет ли более быстрое отклонение поверхностью для атаки или это просто устойчивость, заложенная в дизайне?
@Dusk_Foundation #dusk $DUSK
Очевидная история: комитет валидирует блок, ратифицирует его — и всё. Но протокол Dusk не просто отслеживает «валидно» — он отслеживает Attestations, и Failed Attestation (кворум, согласившийся, что блок *не* валиден) является исходом первого класса, а не чем-то второстепенным.
Вот что я не учёл: отклонять структурно проще, чем принимать. Чтобы ратифицировать валидный блок, комитет должен фактически проверить переходы состояния, подписи, всё содержимое кандидата. Чтобы получить Failed Attestation, членам комитета достаточно согласия супербольшинства, что *что-то* не так — некорректные данные, плохой пропозер, таймаут. Это куда более поверхностная проверка.
Так что механически плохой блок может быстрее набрать свой порог кворума, чем хороший блок проходит валидацию — не потому, что сеть «предпочитает» неверные блоки, а потому что отклонение не требует заново восстанавливать корректность, достаточно обнаружить её отсутствие. Это не баг. На самом деле именно так устроено существование итераций: проваливаться быстро, передавать слот следующему провайдеру и сохранять предсказуемость времени блока.
Но я всё ещё разбираюсь, что означает эта асимметрия, когда размеры комитетов меняются в зависимости от распределения доли. Станет ли более быстрое отклонение поверхностью для атаки или это просто устойчивость, заложенная в дизайне?
@Dusk_Foundation #dusk $DUSK