#dusk $DUSK @Dusk
‎
‎Đã đối chiếu đường dẫn xác minh mật mã của Dusk với những gì một lựa chọn thay thế được “sandbox” hoàn toàn sẽ yêu cầu, vì câu “moved outside WASM” (đưa ra ngoài WASM) được nêu ra ở nhiều nơi mà thiếu sự định lượng bằng số cụ thể mà tôi đọc được.
‎
‎Tài liệu riêng của Dusk xác nhận Piecrust cung cấp các hàm băm (hashing), xác minh PLONK (PLONK-verification), xác minh Groth16 (Groth16-verification) và kiểm tra chữ ký (signature-checks) dưới dạng host-function — tức là mã gốc mà runtime gọi trực tiếp, bỏ qua hoàn toàn máy ảo WASM cho những thao tác cụ thể này. Ngoài ra, tôi phát hiện Phoenix đặc biệt sử dụng một biến thể chữ ký Schnorr kép, được mô tả trong chính repository của Dusk như một phần giới thiệu mới, trong đó ủy quyền việc tính toán proof mà không làm lộ khóa bí mật của người ký — nghĩa là ngay cả lớp chữ ký, chứ không chỉ lớp ZK-proof, cũng được thiết kế để chạy theo đường dẫn native này.
‎
‎Tính toán xem phần nào vẫn nằm trong WASM và phần nào không. Toàn bộ logic hợp đồng nói chung — thay đổi trạng thái, quy tắc nghiệp vụ — chạy trong sandbox. Mọi primitive mật mã mà một giao dịch Phoenix thực sự phụ thuộc vào đều chạy native thay vì WASM.
‎
‎Vẫn có thể coi đây là một giả thuyết đáng nêu một cách thật chính xác: tôi chưa tìm thấy một benchmark đã công bố theo tỷ lệ phần trăm cụ thể để định lượng xem việc xác minh Phoenix sẽ chậm hơn bao nhiêu nếu các kiểm tra này được giữ lại trong WASM so với việc chạy dưới dạng host-functions trong thiết lập hiện tại của Dusk.
‎
‎Điểm thay đổi trong cách đọc của tôi: tôi đã giả định đây chỉ là lựa chọn tối ưu hóa. Nhưng đó cũng là lựa chọn về ranh giới bảo mật — mã native mang những thuộc tính bề mặt tấn công khác so với mã WASM được sandbox, và phần “đóng khung hiệu năng” đơn thuần không phản ánh được điều đó.
‎