#dusk $DUSK @Dusk Thiết lập bảo mật của Dusk thực sự chạy trên hai luồng riêng biệt. Trên DuskDS, mô hình Phoenix biểu diễn giá trị dưới dạng các ghi chú (note) được cam kết vào một cây Merkle — việc chi tiêu một ghi chú không chỉ ra ghi chú nào đang được chi tiêu. Thay vào đó, người gửi công bố một nullifier và một bằng chứng không kiến thức (zero-knowledge) chứng minh rằng việc chi tiêu là hợp lệ, quyền sở hữu là có thật, và không có giá trị nào được tạo ra từ hư vô mà không tiết lộ ghi chú gốc. Song song với đó, Moonlight vận hành như một mô hình minh bạch dựa trên tài khoản (account-based) trên cùng một chuỗi.
Trên DuskEVM, tuy nhiên, quyền riêng tư đến từ một bộ công cụ hoàn toàn khác — một module tên là Hedger, kết hợp mã hóa đồng hình dựa trên ElGamal với các bằng chứng không kiến thức, cùng với cấu trúc kết hợp giữa UTXO và tài khoản (hybrid). Ở đây, người dùng tương tác với hợp đồng thông qua một địa chỉ EVM chuẩn, trong khi một địa chỉ Hedger riêng sẽ xử lý các số dư đã được mã hóa, với yêu cầu tuân thủ được đảm bảo thông qua danh sách cho phép (allowlisting).
Đây không phải là hai phiên bản của cùng một ý tưởng. Phoenix là một hệ thống bằng chứng dựa trên ghi chú; Hedger tính toán trực tiếp trên các số dư đã mã hóa, được xác thực thông qua các bằng chứng không kiến thức. Lý do có thể cho sự tách biệt này là quyền riêng tư dựa trên ghi chú không phù hợp một cách tự nhiên với cấu trúc EVM dựa trên tài khoản, nên cần một hướng tiếp cận khác.
Chạy song song hai ngăn xếp quyền riêng tư mật mã độc lập đồng nghĩa với bề mặt tấn công lớn hơn và chi phí kiểm toán (audit) nặng hơn. Đồng thời cũng chưa rõ cam kết về quyền riêng tư được duy trì như thế nào khi giá trị chuyển động giữa hai lớp.
Việc duy trì hai “cỗ máy” bảo mật (confidentiality engines) riêng biệt có làm chi phí kiểm toán tăng lên theo tỷ lệ, hay việc cả hai cùng dựa vào các bằng chứng không kiến thức có nghĩa là chi phí gia tăng của “engine” thứ hai thực sự thấp hơn mức trông đợi?
Trên DuskEVM, tuy nhiên, quyền riêng tư đến từ một bộ công cụ hoàn toàn khác — một module tên là Hedger, kết hợp mã hóa đồng hình dựa trên ElGamal với các bằng chứng không kiến thức, cùng với cấu trúc kết hợp giữa UTXO và tài khoản (hybrid). Ở đây, người dùng tương tác với hợp đồng thông qua một địa chỉ EVM chuẩn, trong khi một địa chỉ Hedger riêng sẽ xử lý các số dư đã được mã hóa, với yêu cầu tuân thủ được đảm bảo thông qua danh sách cho phép (allowlisting).
Đây không phải là hai phiên bản của cùng một ý tưởng. Phoenix là một hệ thống bằng chứng dựa trên ghi chú; Hedger tính toán trực tiếp trên các số dư đã mã hóa, được xác thực thông qua các bằng chứng không kiến thức. Lý do có thể cho sự tách biệt này là quyền riêng tư dựa trên ghi chú không phù hợp một cách tự nhiên với cấu trúc EVM dựa trên tài khoản, nên cần một hướng tiếp cận khác.
Chạy song song hai ngăn xếp quyền riêng tư mật mã độc lập đồng nghĩa với bề mặt tấn công lớn hơn và chi phí kiểm toán (audit) nặng hơn. Đồng thời cũng chưa rõ cam kết về quyền riêng tư được duy trì như thế nào khi giá trị chuyển động giữa hai lớp.
Việc duy trì hai “cỗ máy” bảo mật (confidentiality engines) riêng biệt có làm chi phí kiểm toán tăng lên theo tỷ lệ, hay việc cả hai cùng dựa vào các bằng chứng không kiến thức có nghĩa là chi phí gia tăng của “engine” thứ hai thực sự thấp hơn mức trông đợi?