Tôi đang đọc tài liệu hạ tầng thị trường của Dusk và cứ bị kẹt ở phần “chân” thanh toán. Tự thân việc chuyển tài sản thì khá dễ hình dung. Phần rối bắt đầu khi khoản thanh toán phải khớp với nó.
Dusk coi Delivery-versus-Payment (Giao hàng đối ứng thanh toán) như một bài toán quy trình (workflow) chứ không chỉ là một kiểu chuyển token khác. Chân tài sản và chân thanh toán có thể được phối hợp thông qua các đường thực thi của Dusk, trong khi DuskDS cung cấp cơ chế thanh toán (settlement) và tính tất định về tính cuối cùng (deterministic finality) bên dưới. Điều đó có nghĩa là phần “đáng thú vị” không thực sự nằm ở việc đưa cả hai tài sản lên cùng một chuỗi. Thứ cần làm là đưa cả hai thay đổi trạng thái để được thanh toán một cách có thể dự đoán.
Tôi thích ý tưởng này, nhưng tôi cũng nghĩ thật dễ để đánh giá quá cao mức độ mà giao thức đang làm ở đây.
Dusk cung cấp các khối xây dựng cho việc phối hợp này. Ứng dụng thực tế vẫn phải xác định cách các điều kiện về tài sản, thanh toán, tính đủ điều kiện (eligibility) và thanh toán (settlement) ghép lại với nhau. Các tài liệu chính thức của Dusk cũng rất rõ ràng rằng các sản phẩm khác nhau có thể triển khai workflow theo những cách khác nhau.
Điều này quan trọng vì DvP có thể trông khá đơn giản từ bên ngoài. Bạn chuyển bảo mật, chuyển khoản thanh toán, gọi là đã được thanh toán. Trong một workflow được điều tiết thực tế, sẽ có nhiều điều kiện hơn nằm quanh hai “chân” đó.
Vì vậy, tôi sẽ không nói rằng Dusk đã xóa bỏ một cách nào đó bài toán phối hợp. Nó chỉ chuyển việc phối hợp sang một nền tảng thanh toán chung với tính cuối cùng tất định.
Thứ tôi vẫn muốn kiểm tra trong một triển khai thực tế thì khá hẹp: khi một “chân” thất bại do các điều kiện ở cấp ứng dụng, thì “chân” còn lại sẽ ở trạng thái chính xác nào, và quy trình có thể được tháo gỡ an toàn (unwind) nhanh đến mức nào?
#dusk $DUSK @Dusk $ACE
Dusk coi Delivery-versus-Payment (Giao hàng đối ứng thanh toán) như một bài toán quy trình (workflow) chứ không chỉ là một kiểu chuyển token khác. Chân tài sản và chân thanh toán có thể được phối hợp thông qua các đường thực thi của Dusk, trong khi DuskDS cung cấp cơ chế thanh toán (settlement) và tính tất định về tính cuối cùng (deterministic finality) bên dưới. Điều đó có nghĩa là phần “đáng thú vị” không thực sự nằm ở việc đưa cả hai tài sản lên cùng một chuỗi. Thứ cần làm là đưa cả hai thay đổi trạng thái để được thanh toán một cách có thể dự đoán.
Tôi thích ý tưởng này, nhưng tôi cũng nghĩ thật dễ để đánh giá quá cao mức độ mà giao thức đang làm ở đây.
Dusk cung cấp các khối xây dựng cho việc phối hợp này. Ứng dụng thực tế vẫn phải xác định cách các điều kiện về tài sản, thanh toán, tính đủ điều kiện (eligibility) và thanh toán (settlement) ghép lại với nhau. Các tài liệu chính thức của Dusk cũng rất rõ ràng rằng các sản phẩm khác nhau có thể triển khai workflow theo những cách khác nhau.
Điều này quan trọng vì DvP có thể trông khá đơn giản từ bên ngoài. Bạn chuyển bảo mật, chuyển khoản thanh toán, gọi là đã được thanh toán. Trong một workflow được điều tiết thực tế, sẽ có nhiều điều kiện hơn nằm quanh hai “chân” đó.
Vì vậy, tôi sẽ không nói rằng Dusk đã xóa bỏ một cách nào đó bài toán phối hợp. Nó chỉ chuyển việc phối hợp sang một nền tảng thanh toán chung với tính cuối cùng tất định.
Thứ tôi vẫn muốn kiểm tra trong một triển khai thực tế thì khá hẹp: khi một “chân” thất bại do các điều kiện ở cấp ứng dụng, thì “chân” còn lại sẽ ở trạng thái chính xác nào, và quy trình có thể được tháo gỡ an toàn (unwind) nhanh đến mức nào?
#dusk $DUSK @Dusk $ACE