Читал документацию Dusk по рыночной инфраструктуре и постоянно застревал на части про расчёты. Перевести актив само по себе несложно — его легко представить. Самое «грязное» начинается там, где платёж должен совпасть с этим переводом.
Dusk рассматривает Delivery-versus-Payment (поставка против платежа) как задачу оркестрации процесса, а не просто как ещё один перевод токенов. Модули поставки активов и платежа можно согласовать через исполняющие пути Dusk, а DuskDS обеспечивает расчёт и детерминированную окончательность в основе. Это означает, что интересная часть — не столько в том, чтобы оба актива оказались в одной цепочке. Интереснее — добиться предсказуемого урегулирования, синхронизировав оба изменения состояния.
Мне нравится эта идея, но я также думаю, что здесь легко переоценить то, что делает протокол.
Dusk даёт строительные блоки для такой координации. При этом реальному приложению всё равно нужно определить, как именно связываются условия по активу, платежу, правомочности и расчёту. Собственная документация Dusk довольно однозначно говорит, что разные продукты могут реализовать этот workflow по-разному.
Это важно, потому что DvP снаружи может выглядеть обманчиво простым. Вы переносите ценную бумагу, переносите платёж, и считаете это «урегулированием». В реальном регулируемом процессе вокруг этих двух «ветвей» существует ещё множество условий.
Так что я бы не сказал, что Dusk каким-то образом устранил проблему координации. Он просто перенёс координацию на общую основу расчётов с детерминированной окончательностью.
То, что я всё равно хотел бы проверить в реальном развёртывании, довольно узкое: когда одна из ветвей не проходит условия приложения, какое именно состояние сохраняет другая ветвь и насколько быстро workflow может безопасно размотаться (unwind)?
#dusk $DUSK @Dusk $ACE
Dusk рассматривает Delivery-versus-Payment (поставка против платежа) как задачу оркестрации процесса, а не просто как ещё один перевод токенов. Модули поставки активов и платежа можно согласовать через исполняющие пути Dusk, а DuskDS обеспечивает расчёт и детерминированную окончательность в основе. Это означает, что интересная часть — не столько в том, чтобы оба актива оказались в одной цепочке. Интереснее — добиться предсказуемого урегулирования, синхронизировав оба изменения состояния.
Мне нравится эта идея, но я также думаю, что здесь легко переоценить то, что делает протокол.
Dusk даёт строительные блоки для такой координации. При этом реальному приложению всё равно нужно определить, как именно связываются условия по активу, платежу, правомочности и расчёту. Собственная документация Dusk довольно однозначно говорит, что разные продукты могут реализовать этот workflow по-разному.
Это важно, потому что DvP снаружи может выглядеть обманчиво простым. Вы переносите ценную бумагу, переносите платёж, и считаете это «урегулированием». В реальном регулируемом процессе вокруг этих двух «ветвей» существует ещё множество условий.
Так что я бы не сказал, что Dusk каким-то образом устранил проблему координации. Он просто перенёс координацию на общую основу расчётов с детерминированной окончательностью.
То, что я всё равно хотел бы проверить в реальном развёртывании, довольно узкое: когда одна из ветвей не проходит условия приложения, какое именно состояние сохраняет другая ветвь и насколько быстро workflow может безопасно размотаться (unwind)?
#dusk $DUSK @Dusk $ACE