@Dusk Я смотрю на дизайн расчётного решения Dusk не столько как на проблему скорости, сколько как на проблему координации.
Быстрый слой финальности полезен, но регулируемые расчёты вовлекают несколько сторон, чьи системы не обязательно движутся с одинаковой скоростью. Слой DuskDS в Dusk может обеспечивать детерминированную финальность и координировать состояние расчётов, однако финансовая “товарная” часть (asset leg), платёжный канал, кастодиан и проверки комплаенса всё равно способны вносить различия во времени.
Это меняет метрику, о которой я думаю.
«Качество расчётов измеряется, когда системы расходятся во мнениях.»
Если DvP-транзакция (поставка против платежа) сталкивается с задержкой или рассогласованием, ключевой вопрос — что протокол и окружающая инфраструктура делают дальше. Может ли актив оставаться надёжно заблокированным? Можно ли на стороне платежа выполнить сверку без создания новой контрагентской экспозиции? Могут ли уполномоченные участники проверить соответствующее состояние, не раскрывая информацию, которую им не следует видеть?
Именно здесь конфиденциальное исполнеие Dusk становится для меня интереснее, чем “сырая” пропускная способность. Система должна сохранять и корректность транзакций, и контролируемый поток информации, когда что-то идёт не так.
Слабость в том, что Dusk не может устранить зависимости вне цепочки. Даже идеально детерминированный слой расчётов всё равно наследует операционные риски от кастодианов, платёжных провайдеров и внешних источников данных.
Поэтому я бы следил за обработкой неудачных расчётов, временем на сверку и повторным институциональным использованием. Успешные транзакции показывают, что система работает; сложные транзакции — насколько ей можно доверять.
#dusk @Dusk $DUSK $BTR $BMT
Быстрый слой финальности полезен, но регулируемые расчёты вовлекают несколько сторон, чьи системы не обязательно движутся с одинаковой скоростью. Слой DuskDS в Dusk может обеспечивать детерминированную финальность и координировать состояние расчётов, однако финансовая “товарная” часть (asset leg), платёжный канал, кастодиан и проверки комплаенса всё равно способны вносить различия во времени.
Это меняет метрику, о которой я думаю.
«Качество расчётов измеряется, когда системы расходятся во мнениях.»
Если DvP-транзакция (поставка против платежа) сталкивается с задержкой или рассогласованием, ключевой вопрос — что протокол и окружающая инфраструктура делают дальше. Может ли актив оставаться надёжно заблокированным? Можно ли на стороне платежа выполнить сверку без создания новой контрагентской экспозиции? Могут ли уполномоченные участники проверить соответствующее состояние, не раскрывая информацию, которую им не следует видеть?
Именно здесь конфиденциальное исполнеие Dusk становится для меня интереснее, чем “сырая” пропускная способность. Система должна сохранять и корректность транзакций, и контролируемый поток информации, когда что-то идёт не так.
Слабость в том, что Dusk не может устранить зависимости вне цепочки. Даже идеально детерминированный слой расчётов всё равно наследует операционные риски от кастодианов, платёжных провайдеров и внешних источников данных.
Поэтому я бы следил за обработкой неудачных расчётов, временем на сверку и повторным институциональным использованием. Успешные транзакции показывают, что система работает; сложные транзакции — насколько ей можно доверять.
#dusk @Dusk $DUSK $BTR $BMT