#dusk $DUSK
Недавно я продолжил разбираться с документацией по жизненному циклу транзакций для @Dusk и только тогда понял, что раньше слишком упрощал одну вещь：
Успешное выполнение транзакции не означает, что этот статус уже можно считать «фактом» для финансовой системы.
В DuskDS транзакция сначала принимается, распространяется, выполняется, а затем ей еще предстоит пройти финальное подтверждение.
Официальная документация даже отдельно напоминает：
included、accepted、confirmed нельзя напрямую трактовать как payment finality.
Причина довольно простая.
Транзакция попала в block уровня accepted — этот блок все еще может быть откат (отменен).
И только когда все доходит до finalized, это означает, что статус перешел в deterministic finality.
В Succinct Attestation от Dusk дальнейший путь выглядит так：
Proposal
→ Validation
→ Ratification
И лишь после завершения Ratification block действительно становится final.
Мне кажется, что эта деталь важнее, чем «сколько TPS».
Потому что биржи и финансовые системы больше всего боятся не того, что транзакцию увидят на несколько секунд позже.
Они боятся вот чего：
Я уже зачислил деньги пользователю на основании этого статуса, а затем выясняется, что базовый статус на самом деле изменился.
Поэтому integration-документация Dusk для бирж прямо требует не делать предварительный учет из‑за mempool, included event или accepted-but-unfinalized block.
По сути, это очень прикладательно объясняет finality.
Это не просто термин про производительность.
А ответ на вопрос：
С какого момента система может больше не опасаться, что этот статус будет отозван?
Сайт Dusk сейчас дает показатель finality примерно 10 секунд.
Меня волнует не только то, насколько красиво выглядит эта цифра.
А то, сможет ли в реальной нагрузке основной сети этот переход от accepted к finalized оставаться всегда четким, ясным и стабильным.
В конечном счете финансовые системы полагаются именно на это.
Недавно я продолжил разбираться с документацией по жизненному циклу транзакций для @Dusk и только тогда понял, что раньше слишком упрощал одну вещь：
Успешное выполнение транзакции не означает, что этот статус уже можно считать «фактом» для финансовой системы.
В DuskDS транзакция сначала принимается, распространяется, выполняется, а затем ей еще предстоит пройти финальное подтверждение.
Официальная документация даже отдельно напоминает：
included、accepted、confirmed нельзя напрямую трактовать как payment finality.
Причина довольно простая.
Транзакция попала в block уровня accepted — этот блок все еще может быть откат (отменен).
И только когда все доходит до finalized, это означает, что статус перешел в deterministic finality.
В Succinct Attestation от Dusk дальнейший путь выглядит так：
Proposal
→ Validation
→ Ratification
И лишь после завершения Ratification block действительно становится final.
Мне кажется, что эта деталь важнее, чем «сколько TPS».
Потому что биржи и финансовые системы больше всего боятся не того, что транзакцию увидят на несколько секунд позже.
Они боятся вот чего：
Я уже зачислил деньги пользователю на основании этого статуса, а затем выясняется, что базовый статус на самом деле изменился.
Поэтому integration-документация Dusk для бирж прямо требует не делать предварительный учет из‑за mempool, included event или accepted-but-unfinalized block.
По сути, это очень прикладательно объясняет finality.
Это не просто термин про производительность.
А ответ на вопрос：
С какого момента система может больше не опасаться, что этот статус будет отозван?
Сайт Dusk сейчас дает показатель finality примерно 10 секунд.
Меня волнует не только то, насколько красиво выглядит эта цифра.
А то, сможет ли в реальной нагрузке основной сети этот переход от accepted к finalized оставаться всегда четким, ясным и стабильным.
В конечном счете финансовые системы полагаются именно на это.