Поздний результат не всегда является тем, который должен победить.
Представьте два поезда, которые отправляются с одной и той же станции по разным маршрутам. Один уезжает раньше, но другой прибывает первым.
Вы автоматически решаете, что более позднее прибытие должно заменить более раннее?
Именно поэтому дизайн механизма разрешения форков @Dusk оказался для меня интересным.
Краткое подтверждение (Succinct Attestation) работает итерациями. Если на одной итерации не удаётся достичь требуемого кворума, консенсус может продолжиться к следующей. Если итерация 2 и итерация 5 обе приводят к кандидатам, достигшим кворума, Dusk отдаёт приоритет более низкой итерации — более ранней позиции в процессе консенсуса.
Вот где важной становится «плавная финальность» (rolling finality). Более поздний кворум не автоматически делает последний кандидат решающим; более ранние итерации всё ещё имеют значение при определении того, какому кандидату будет отдан приоритет.
И есть ещё один вопрос «второго порядка», который мне кажется интересным: если более поздние итерации не автоматически заменяют ранее нерешённые, то могут ли валидаторы иметь стимул помогать в разрешении более ранних итераций, а не просто ждать самого нового кандидата?
Для финансовых расчётов эта разница имеет значение: недостаточно просто прийти к согласию — вам нужна детерминированная процедура, определяющая, какое именно соглашение становится окончательным.
Вот та часть консенсус-дизайна Dusk, которую я хочу продолжать наблюдать.
$DUSK #dusk #bullish
Представьте два поезда, которые отправляются с одной и той же станции по разным маршрутам. Один уезжает раньше, но другой прибывает первым.
Вы автоматически решаете, что более позднее прибытие должно заменить более раннее?
Именно поэтому дизайн механизма разрешения форков @Dusk оказался для меня интересным.
Краткое подтверждение (Succinct Attestation) работает итерациями. Если на одной итерации не удаётся достичь требуемого кворума, консенсус может продолжиться к следующей. Если итерация 2 и итерация 5 обе приводят к кандидатам, достигшим кворума, Dusk отдаёт приоритет более низкой итерации — более ранней позиции в процессе консенсуса.
Вот где важной становится «плавная финальность» (rolling finality). Более поздний кворум не автоматически делает последний кандидат решающим; более ранние итерации всё ещё имеют значение при определении того, какому кандидату будет отдан приоритет.
И есть ещё один вопрос «второго порядка», который мне кажется интересным: если более поздние итерации не автоматически заменяют ранее нерешённые, то могут ли валидаторы иметь стимул помогать в разрешении более ранних итераций, а не просто ждать самого нового кандидата?
Для финансовых расчётов эта разница имеет значение: недостаточно просто прийти к согласию — вам нужна детерминированная процедура, определяющая, какое именно соглашение становится окончательным.
Вот та часть консенсус-дизайна Dusk, которую я хочу продолжать наблюдать.
$DUSK #dusk #bullish
