Раньше я думал, что подтверждение блоков — это очень просто: транзакция попадает в блок, потом считаешь ещё несколько блоков — и в целом можно считать это безопасным. Но сегодня вечером, когда я читал документацию по жизненному циклу транзакции @Dusk , одна фраза меня буквально остановила: «accepted blocks can still be reverted». Если блок уже accepted, почему его всё ещё можно откатить?
Потом я разобрался, когда прочитал 2024 Whitepaper. В раунде консенсуса Dusk происходит несколько iteration; в рамках одного round могут возникать конкурирующие блоки. Блоки с более высокой iteration, даже если они уже accepted, всё равно могут вызвать fallback, если блок-конкурент с более низкой iteration удовлетворяет условиям.
«Увидеть, что оно попало в блокчейн», — не значит, что это уже невозможно заменить.
Rolling Finality неожиданнее, чем кажется. В whitepaper n — это количество iteration, которые надо пройти, чтобы надёжно подтвердить не завершённые ещё attestation. Блок accepted должен дождаться 2×n следующих подряд блоков с attestation или confirmed, прежде чем он перейдёт в confirmed. Если n=3, нужно понаблюдать за последующими 6 блоками, которые удовлетворяют условиям.
И вот здесь я понял: «число подтверждений» — это не единая линейка. Даже когда транзакция уже on-chain, из-за различий в истории консенсуса стабильность может быть разной.
Советы в текущей документации звучат ещё более прямо: included, accepted и даже confirmed нельзя воспринимать как сигнал о том, что средства уже зачислены; нужно дождаться именно finalized.
Для небольших переводов разница может быть всего в несколько секунд; но если перенести это в DvP-расчёты больших OTC-сделок или RWA, то «увидеть транзакцию» и «необратимое расчётное исполнение» — это совершенно разные вещи. В следующий раз, глядя на крупные транзакции Dusk, спрашивай только одно: она finalized?
#dusk $DUSK @Dusk
Потом я разобрался, когда прочитал 2024 Whitepaper. В раунде консенсуса Dusk происходит несколько iteration; в рамках одного round могут возникать конкурирующие блоки. Блоки с более высокой iteration, даже если они уже accepted, всё равно могут вызвать fallback, если блок-конкурент с более низкой iteration удовлетворяет условиям.
«Увидеть, что оно попало в блокчейн», — не значит, что это уже невозможно заменить.
Rolling Finality неожиданнее, чем кажется. В whitepaper n — это количество iteration, которые надо пройти, чтобы надёжно подтвердить не завершённые ещё attestation. Блок accepted должен дождаться 2×n следующих подряд блоков с attestation или confirmed, прежде чем он перейдёт в confirmed. Если n=3, нужно понаблюдать за последующими 6 блоками, которые удовлетворяют условиям.
И вот здесь я понял: «число подтверждений» — это не единая линейка. Даже когда транзакция уже on-chain, из-за различий в истории консенсуса стабильность может быть разной.
Советы в текущей документации звучат ещё более прямо: included, accepted и даже confirmed нельзя воспринимать как сигнал о том, что средства уже зачислены; нужно дождаться именно finalized.
Для небольших переводов разница может быть всего в несколько секунд; но если перенести это в DvP-расчёты больших OTC-сделок или RWA, то «увидеть транзакцию» и «необратимое расчётное исполнение» — это совершенно разные вещи. В следующий раз, глядя на крупные транзакции Dusk, спрашивай только одно: она finalized?
#dusk $DUSK @Dusk
