Материалы Dusk описывают "детерминированное урегулирование\n\n как ключевую особенность — после завершения транзакции\n\n она считается окончательной, и нет риска\n\n вероятностного реорганизования. \n\n Это подается как однозначное преимущество\n\n по сравнению с цепочками с вероятностной финальностью. \n\n Я думаю, что компромисс, лежащий в основе этого, пропускают.\n\n Детерминированная финальность ценна именно потому, что\n\n убирает период "подождать и посмотреть, не будет ли\n\n эта транзакция реорганизована". \n\n Но если убрать это окно, то исчезает и естественный\n\n механизм корректировки, который есть у цепочек\n\n с вероятностной финальностью, когда что-то идет не так —\n\n плохая\n\n транзакция, скомпрометированный ключ, использованный\n\n уязвимый контракт.\n\n На вероятностной цепочке есть хотя бы краткое\n\n окно, когда очевидно мошеннические действия могут\n\n теоретически быть оспорены до глубокой\n\n подтверждающей стадии.\n\n Детерминированное урегулирование означает, что как только\n\n оно становится окончательным,\n\n протокольного отмена не предусмотрено — по замыслу.\n\nДля регулируемых финансовых сфер это часто правильный\n\n компромисс —\n\n учреждения хотят определенности вместо обратимости,\n\n и для реальных споров существует правовая защита вне\n\n цепочки. \n\n Но это также значит, что весь вес "не допустить, чтобы\n\n плохая\n\n транзакция вообще стала окончательной"\n\n перекладывается на то, что проверяет транзакции до\n\n финальности —\n\n на тот же операционный уровень,\n\n где собственный инцидент моста Dusk показал,\n\n что это может быть слабое место, отдельное от\n\n протокольного ядра.\n\nДетерминированное урегулирование — реальное институциональное требование.\n\n Это также дизайн, который не допускает\n\n ни капли терпимости к той конкретной категории\n\n операционного сбоя, с которой Dusk уже однажды столкнулся,\n\n — на уровне вокруг него, а не внутри него.\n\n@Dusk #dusk $DUSK