#dusk $DUSK @Dusk

Vì sao xác minh bằng chứng đã rời “sandbox” để tăng tốc
‎
‎
‎Tôi đã đối chiếu đường dẫn xác minh mật mã của Dusk với những gì một phương án thay thế được sandbox hoàn toàn sẽ yêu cầu, kể từ khi cụm “moved outside WASM” (được đưa ra ngoài WASM) thường được nói đến mà không có nhiều căn cứ định lượng trong hầu hết các bài tôi đã đọc.
‎
Tài liệu riêng của Dusk xác nhận rằng Piecrust cung cấp các thao tác 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 hàm host — tức là code gốc mà runtime gọi trực tiếp, bỏ qua hoàn toàn máy ảo WASM cho các thao tác cụ thể này. Riêng phần Phoenix, tôi cũng phát hiện Phoenix sử dụng một biến thể chữ ký Schnorr kép (double-Schnorr-signature) — được mô tả trong chính kho mã của Dusk như một giới thiệu mới, trong đó ủy nhiệm việc tính toán bằng chứng 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ý, không chỉ lớp bằng chứng ZK, cũng được thiết kế để chạy theo đường dẫn native này.
‎
Hãy tính toán xem phần nào nằm trong WASM và phần nào không. Logic hợp đồng chung — thay đổi trạng thái (state-changes), quy tắc nghiệp vụ (business-rules) — được 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 thì lại chạy native.
‎
Đây vẫn là một giả thuyết đáng nêu một cách chính xác: tôi chưa tìm thấy một benchmark được công bố theo tỷ lệ phần trăm cụ thể để định lượng Phoenix-verification sẽ chạy chậm hơn bao nhiêu nếu các kiểm tra này được giữ bên trong WASM, thay vì chạy dưới dạng hàm host trên thiết lập hiện tại của Dusk.
‎
Điểm thay đổi trong cách tôi đọc: lúc đầu tôi cho rằng đây chỉ là một lựa chọn tối ưu hóa. Nhưng nó cũng là một lựa chọn về ranh giới an ninh — code native mang những đặc tính bề mặt tấn công khác so với code WASM đã được sandbox, điều mà chỉ nhìn theo khía cạnh đóng khung hiệu năng (performance-framing) thì không thể nắm bắt được.