#dusk $DUSK @Dusk Trước đây, tôi cứ nghĩ rằng một giao dịch blockchain chỉ có hai khả năng: thành công hoặc thất bại. Thành công nghĩa là giá trị được chuyển. Thất bại nghĩa là có gì đó đã hỏng. Nhưng khi tôi tìm hiểu sâu hơn về cách Dusk mô tả việc chuyển tài sản được quản lý theo quy định, tôi nhận ra mô hình đó quá thô sơ đối với các thị trường tài chính.
Trên một chuỗi thông thường, một giao dịch bị từ chối cho bạn biết rất ít. Gas cạn, một câu lệnh require bị kích hoạt, trạng thái thay đổi ngay dưới chân bạn. Bạn buộc phải đoán xem điều gì đã xảy ra.
Với một tài sản được quản lý theo quy định, sự mơ hồ đó là không thể chấp nhận. Tài liệu của Dusk mô tả các kiểm tra chuyển giao mà có thể thất bại kèm lý do rõ ràng, và — phần khiến tôi thấy đặc biệt thú vị — các kiểm tra có thể được mô phỏng trước khi giao dịch được gửi đi.
Điều tôi thấy đáng chú ý nhất là hàm ý của điểm thứ hai. Nó có nghĩa là tính đủ điều kiện không phải thứ bạn “phát hiện” bằng cách thử thực hiện một lần chuyển rồi để nó vỡ. Bạn có thể đặt câu hỏi trước và nhận câu trả lời, mà không cần đụng chạm tới sổ cái.
Điều này giống với cách phía truyền thống đã vận hành. Một công ty môi giới không gửi một lệnh rồi hy vọng hệ thống tuân thủ sẽ cho phép. Việc kiểm tra diễn ra trước, và khi một giao dịch bị từ chối, ai đó có thể giải thích thật chính xác lý do — bên đối tác không được cấp phép, thời gian nắm giữ chưa đủ, hoặc phạm vi pháp lý bị hạn chế. "Bị từ chối" mà không có lý do không phải là câu trả lời có thể sử dụng trong một quy trình được quản lý.
Sự thất bại trở thành thông tin thay vì một tai nạn. Và một lần từ chối kèm theo lý do có lẽ còn hữu ích hơn một lần thành công mà không có lý do.
Tôi vẫn chưa thể đánh giá mức độ chi tiết của các lý do đó trong thực tế, hoặc mức độ các thông tin này sẵn có cho một ứng dụng ngày hôm nay, thay vì chỉ được mô tả như một mục tiêu thiết kế.
Từ đây, tôi bắt đầu nhìn thiết kế theo cách khác. Tuân thủ “on-chain” có lẽ không chỉ nhằm chặn các giao dịch xấu. Nó có thể là để làm cho kết quả trở nên dự đoán được trước khi bất kỳ ai cam kết vào nó.
Trên một chuỗi thông thường, một giao dịch bị từ chối cho bạn biết rất ít. Gas cạn, một câu lệnh require bị kích hoạt, trạng thái thay đổi ngay dưới chân bạn. Bạn buộc phải đoán xem điều gì đã xảy ra.
Với một tài sản được quản lý theo quy định, sự mơ hồ đó là không thể chấp nhận. Tài liệu của Dusk mô tả các kiểm tra chuyển giao mà có thể thất bại kèm lý do rõ ràng, và — phần khiến tôi thấy đặc biệt thú vị — các kiểm tra có thể được mô phỏng trước khi giao dịch được gửi đi.
Điều tôi thấy đáng chú ý nhất là hàm ý của điểm thứ hai. Nó có nghĩa là tính đủ điều kiện không phải thứ bạn “phát hiện” bằng cách thử thực hiện một lần chuyển rồi để nó vỡ. Bạn có thể đặt câu hỏi trước và nhận câu trả lời, mà không cần đụng chạm tới sổ cái.
Điều này giống với cách phía truyền thống đã vận hành. Một công ty môi giới không gửi một lệnh rồi hy vọng hệ thống tuân thủ sẽ cho phép. Việc kiểm tra diễn ra trước, và khi một giao dịch bị từ chối, ai đó có thể giải thích thật chính xác lý do — bên đối tác không được cấp phép, thời gian nắm giữ chưa đủ, hoặc phạm vi pháp lý bị hạn chế. "Bị từ chối" mà không có lý do không phải là câu trả lời có thể sử dụng trong một quy trình được quản lý.
Sự thất bại trở thành thông tin thay vì một tai nạn. Và một lần từ chối kèm theo lý do có lẽ còn hữu ích hơn một lần thành công mà không có lý do.
Tôi vẫn chưa thể đánh giá mức độ chi tiết của các lý do đó trong thực tế, hoặc mức độ các thông tin này sẵn có cho một ứng dụng ngày hôm nay, thay vì chỉ được mô tả như một mục tiêu thiết kế.
Từ đây, tôi bắt đầu nhìn thiết kế theo cách khác. Tuân thủ “on-chain” có lẽ không chỉ nhằm chặn các giao dịch xấu. Nó có thể là để làm cho kết quả trở nên dự đoán được trước khi bất kỳ ai cam kết vào nó.