Saya sedang membaca dokumen infrastruktur pasar Dusk dan terus tersangkut di bagian payment-nya. Transfer aset itu sendiri cukup mudah dibayangkan. Bagian yang rumit dimulai ketika pembayaran harus selaras dengannya.
Dusk memandang Delivery-versus-Payment sebagai masalah alur kerja (workflow), bukan sekadar transfer token lain. Jalur aset dan jalur pembayaran dapat dikoordinasikan melalui path eksekusi milik Dusk, sementara DuskDS menyediakan settlement serta finalitas deterministik di bawahnya. Itu berarti bagian yang menarik bukan benar-benar menempatkan kedua aset pada rantai yang sama. Yang penting adalah membuat kedua perubahan status itu terselesaikan secara prediktabel.
Saya suka idenya, tapi saya juga merasa mudah untuk melebih-lebihkan apa yang dilakukan protokol di sini.
Dusk menyediakan komponen-komponen untuk koordinasi ini. Aplikasi yang sebenarnya tetap harus menentukan bagaimana kondisi aset, pembayaran, eligibility, dan settlement saling terhubung. Dokumentasi Dusk sendiri cukup tegas bahwa produk yang berbeda dapat mengimplementasikan workflow ini dengan cara yang berbeda.
Hal ini penting karena DvP bisa terlihat seolah-olah sederhana dari luar. Anda memindahkan sekuritas, memindahkan pembayaran, sebut saja sudah settled. Dalam sebuah workflow yang benar-benar teregulasi, ada lebih banyak kondisi yang mengelilingi dua bagian tersebut.
Jadi saya tidak akan mengatakan bahwa Dusk entah bagaimana telah menghilangkan masalah koordinasi. Ia hanya memindahkan koordinasi ke fondasi settlement yang sama dengan deterministic finality.
Hal yang masih ingin saya periksa dalam penerapan nyata itu cukup spesifik: ketika satu leg gagal karena kondisi-level aplikasi, status persis apa yang tersisa pada leg yang lain, dan seberapa cepat workflow bisa di-unwind dengan aman?
#dusk $DUSK @Dusk $ACE
Dusk memandang Delivery-versus-Payment sebagai masalah alur kerja (workflow), bukan sekadar transfer token lain. Jalur aset dan jalur pembayaran dapat dikoordinasikan melalui path eksekusi milik Dusk, sementara DuskDS menyediakan settlement serta finalitas deterministik di bawahnya. Itu berarti bagian yang menarik bukan benar-benar menempatkan kedua aset pada rantai yang sama. Yang penting adalah membuat kedua perubahan status itu terselesaikan secara prediktabel.
Saya suka idenya, tapi saya juga merasa mudah untuk melebih-lebihkan apa yang dilakukan protokol di sini.
Dusk menyediakan komponen-komponen untuk koordinasi ini. Aplikasi yang sebenarnya tetap harus menentukan bagaimana kondisi aset, pembayaran, eligibility, dan settlement saling terhubung. Dokumentasi Dusk sendiri cukup tegas bahwa produk yang berbeda dapat mengimplementasikan workflow ini dengan cara yang berbeda.
Hal ini penting karena DvP bisa terlihat seolah-olah sederhana dari luar. Anda memindahkan sekuritas, memindahkan pembayaran, sebut saja sudah settled. Dalam sebuah workflow yang benar-benar teregulasi, ada lebih banyak kondisi yang mengelilingi dua bagian tersebut.
Jadi saya tidak akan mengatakan bahwa Dusk entah bagaimana telah menghilangkan masalah koordinasi. Ia hanya memindahkan koordinasi ke fondasi settlement yang sama dengan deterministic finality.
Hal yang masih ingin saya periksa dalam penerapan nyata itu cukup spesifik: ketika satu leg gagal karena kondisi-level aplikasi, status persis apa yang tersisa pada leg yang lain, dan seberapa cepat workflow bisa di-unwind dengan aman?
#dusk $DUSK @Dusk $ACE