Ban đầu tôi tưởng Dusk chỉ là một “chuỗi quyền riêng tư” như thường thấy, mô hình tài khoản khá giống các coin quyền riêng tư khác, đơn giản là mặc định đã được mã hóa. Mãi đến khi lật xong tài liệu, tôi mới nhận ra mình nghĩ quá đơn giản—thực ra Dusk vận hành song song hai hệ thống tài khoản, đây là một thiết kế trước đó tôi chưa từng thấy ở dự án nào.

Phoenix là mô hình UTXO, đi theo giao dịch bí mật dùng bằng chứng không tri thức (zero-knowledge). Cả số tiền lẫn các bên tham gia mặc định đều không thể nhìn thấy, tinh thần khá tương đồng với phần lớn các dự án làm về quyền riêng tư. Nhưng Dusk vẫn chạy song song Moonlight, đó là mô hình tài khoản, giống hệt bộ cơ chế của Ethereum—minh bạch và có thể tra cứu được. Trên cùng một chuỗi, bạn có thể chọn bộ tài khoản để nhận/gửi tài sản; và giữa hai hệ thống còn có thể chuyển đổi qua lại.

Nhìn thoáng qua thì thiết kế này có vẻ như hơi “bị phân mảnh” không? Ban đầu tôi cũng nghĩ vậy, cho đến khi hiểu ra một điều: các tổ chức làm giao dịch tuân thủ (compliance) thật sự cần khả năng chuyển đổi giữa “giữ riêng tư khi cần” và “minh bạch khi phải”, chứ không phải bị khóa cứng vào chỉ một mô hình. Ví dụ: điều chuyển tài sản nội bộ cần được bảo mật, nhưng các chứng khoán phát hành ra bên ngoài lại bắt buộc phải để cơ quan quản lý tra cứu bất cứ lúc nào—dùng cùng một logic tài khoản để “gánh” cả hai phía thì rất khó làm trọn vẹn. Tách thành hai hệ thống chạy song song lại là cách trung thực hơn; đó là việc không giả vờ rằng một mô hình duy nhất có thể giải quyết mọi tình huống.

Cái giá cũng rất rõ ràng: có hai hệ thống tài khoản đồng nghĩa với hai logic quản lý trạng thái, và nhà phát triển phải hiểu đồng thời hai “paradigm” lập trình—UTXO và mô hình tài khoản. Mức độ phức tạp khi gọi cũng cao hơn đáng kể so với một chuỗi chỉ dùng một mô hình. Tôi xem qua diễn đàn dành cho nhà phát triển thì thấy có khá nhiều bài thảo luận về việc chuyển đổi giữa Phoenix/Moonlight, cho thấy đường cong học tập này là có thật, không phải chỉ mình tôi thấy vòng vo.

Sự phức tạp đổi lại cho bạn là tính linh hoạt: liệu có đáng hay không thì phải xem cuối cùng có kịch bản thực sự nào cần đến khả năng chuyển đổi này hay không, chứ không nên dừng ở mức “thiết kế thật khéo” thôi.
Các bạn nghĩ sao: thiết kế chế độ kép kiểu “vừa cần cái này lại vừa cần cái kia”, là một lựa chọn thông minh hay chỉ làm tăng thêm sự phức tạp không cần thiết cho nhà phát triển?
@Dusk_Foundation #dusk $DUSK