#dusk $DUSK @Dusk

‎‎Cha tôi đã vận hành hai sổ riêng cho cửa hàng nhỏ của ông trong nhiều năm: một sổ cho các giao dịch bán bằng tiền mặt, và một sổ cho các tài khoản bán chịu. Tôi từng hỏi ông sao không gộp chúng lại. Ông nói tiền mặt cần phải đơn giản và tức thời, còn tín dụng cần theo dõi điều khoản và các lần theo dõi; và việc ép một hệ thống phải làm cả hai sẽ khiến mọi việc ở cả hai mảng đều tệ hơn.
‎
‎Tôi cho rằng Dusk cuối cùng sẽ hội tụ về một mô hình giao dịch duy nhất, như cách hầu hết các chuỗi thường chọn một phương án. Nhưng giả định đó đã sụp đổ khi tôi thực sự lần ra vì sao Moonlight và Phoenix cùng tồn tại.
‎
‎Moonlight là mô hình dựa trên tài khoản, công khai và rõ ràng—tài liệu của Dusk mô tả nó như mô hình cho số dư và logic ứng dụng mà không cần phải che chắn. Phoenix áp dụng cách tiếp cận UTXO, và nó tồn tại đặc biệt để hỗ trợ các luồng hướng đến quyền riêng tư: chuyển tiền được che chắn, tiết lộ chọn lọc—những mảnh ghép mà tài chính theo kiểu “được quản lý” thực sự cần khi không chấp nhận tính minh bạch hoàn toàn.
‎
‎Việc gộp hai thứ đó thành một mô hình duy nhất sẽ đồng nghĩa với việc hoặc ép mọi giao dịch phải đi qua một lớp “quyền riêng tư” không cần thiết, hoặc tước bỏ các tùy chọn che chắn khỏi những người cần chúng.
‎
‎Thử nghiệm thực sự dành cho DUSK là việc giữ cả hai mô hình có thực sự phục vụ các nhà xây dựng cần các cam kết khác nhau cho các luồng khác nhau hay không—chứ không phải chỉ là thêm gánh nặng khái niệm mà đa số người dùng chưa từng chạm tới.
‎
‎Điều tôi chưa tìm thấy được tài liệu nào nói rõ ở đâu là: thực tế, một ứng dụng đơn lẻ cần đồng thời cả hai mô hình này bao lâu một lần.
‎