Trước đây tôi cứ trộn Dusk Trade, DuskEVM và DuskDS lại để xem, nên lúc nào cũng thấy có quá nhiều thuật ngữ. Sau khi tách ra lại, logic ngược lại trở nên rất rõ ràng.
DuskDS chịu trách nhiệm về đồng thuận, tính kết cuối tất định (deterministic finality), tính khả dụng dữ liệu và mô hình giao dịch Moonlight, Phoenix; DuskVM cho phép hợp đồng Rust/WASM chạy trực tiếp trên lớp L1 gốc; DuskEVM cung cấp môi trường ứng dụng cho Solidity; còn Dusk Trade lại đóng gói việc kiểm soát truy cập, mua bán và thanh toán thành một sản phẩm mà người dùng có thể thao tác.
Nó giống như một thị trường chứng khoán: DuskDS là sổ cái và trung tâm thanh toán, DuskVM và DuskEVM là hai tuyến phát triển nghiệp vụ, còn Dusk Trade là quầy giao dịch hướng tới nhà đầu tư.
Quầy có thể thay phiên bản, nhưng sổ cái ở tầng dưới cùng phải ổn định.
Cách phân tầng này giúp tôi hiểu vì sao Dusk liên tục nhấn mạnh deterministic settlement.
Tài sản chịu quản lý không thể chấp nhận kiểu “xác suất là không bị rollback (quay lui)”, thị trường cần một trạng thái cuối cùng thật sự rõ ràng.
Và câu hỏi của tôi cũng chuyển sang hướng khác: liệu kiến trúc nhiều lớp có biến rủi ro từ hiệu năng của một chuỗi đơn lẻ thành rủi ro do tin nhắn liên tầng, độ phức tạp của cầu nối (bridge) và công tác vận hành không? Kết cuối tầng dưới nhanh là một lợi thế, nhưng chỉ khi tầng trên kế thừa đúng cách thì người dùng mới thật sự nhận được một cơ chế thanh toán sạch hơn.
#dusk $DUSK @Dusk
DuskDS chịu trách nhiệm về đồng thuận, tính kết cuối tất định (deterministic finality), tính khả dụng dữ liệu và mô hình giao dịch Moonlight, Phoenix; DuskVM cho phép hợp đồng Rust/WASM chạy trực tiếp trên lớp L1 gốc; DuskEVM cung cấp môi trường ứng dụng cho Solidity; còn Dusk Trade lại đóng gói việc kiểm soát truy cập, mua bán và thanh toán thành một sản phẩm mà người dùng có thể thao tác.
Nó giống như một thị trường chứng khoán: DuskDS là sổ cái và trung tâm thanh toán, DuskVM và DuskEVM là hai tuyến phát triển nghiệp vụ, còn Dusk Trade là quầy giao dịch hướng tới nhà đầu tư.
Quầy có thể thay phiên bản, nhưng sổ cái ở tầng dưới cùng phải ổn định.
Cách phân tầng này giúp tôi hiểu vì sao Dusk liên tục nhấn mạnh deterministic settlement.
Tài sản chịu quản lý không thể chấp nhận kiểu “xác suất là không bị rollback (quay lui)”, thị trường cần một trạng thái cuối cùng thật sự rõ ràng.
Và câu hỏi của tôi cũng chuyển sang hướng khác: liệu kiến trúc nhiều lớp có biến rủi ro từ hiệu năng của một chuỗi đơn lẻ thành rủi ro do tin nhắn liên tầng, độ phức tạp của cầu nối (bridge) và công tác vận hành không? Kết cuối tầng dưới nhanh là một lợi thế, nhưng chỉ khi tầng trên kế thừa đúng cách thì người dùng mới thật sự nhận được một cơ chế thanh toán sạch hơn.
#dusk $DUSK @Dusk