Tôi chạy một script Python nhỏ trên laptop của mình ở Islamabad để thực hiện băm (hashing) nặng cho một dự án phụ, và một lần tôi thử chuyển nó sang một môi trường được “sandbox” (cô lập) với suy nghĩ rằng nó sẽ chạy nhanh như cũ vì logic không thay đổi. Nó chạy chậm hơn rõ rệt, và mãi đến khi tôi đọc về VM Piecrust của Dusk tôi mới thực sự hiểu vì sao điều đó xảy ra ở cấp độ kỹ thuật.

Tôi cho rằng mọi việc thực thi hợp đồng thông minh bên trong một máy ảo WASM đều chạy xấp xỉ tốc độ “native” (gần như tốc độ hệ thống), vì WASM thường được quảng cáo là hiệu năng gần native.
Điều đó không đúng đối với các thao tác mật mã (cryptographic) nói riêng. Nghiên cứu được trích dẫn trong whitepaper cho thấy việc thực thi WASM có thể chạy chậm hơn 45 đến 255 phần trăm so với mã native đối với các ứng dụng phức tạp, chủ yếu do quản lý bộ nhớ được ảo hóa và xử lý thêm các lệnh bên trong sandbox.

Chính vì thế mà Piecrust không hề chạy các tác vụ như xác minh ZK proof, hashing hay kiểm tra chữ ký bên trong sandbox WASM. Thay vào đó, nó mở ra các hàm host (hàm phía máy chủ) — các lời gọi native trực tiếp cho các thao tác như hash, verify_plonk, verify_groth16_bn254, verify_schnorr và verify_bls. Hợp đồng gọi sang mã native để thực hiện phần tính toán mật mã nặng, rồi quay trở lại WASM cho mọi thứ còn lại. Đó là một cách tách kiến trúc có chủ đích, chứ không phải một giải pháp tạm thời.

Điều whitepaper thừa nhận trực tiếp là Dusk vẫn chưa lượng hóa được mức tiết kiệm công suất thực tế từ cấu hình này. Vì vậy, tôi không thể cho bạn một con số hiệu suất thực sự, bởi chính Dusk cũng chưa công bố.

Thử nghiệm thực sự dành cho DUSK là liệu cách tiếp cận host function này có tiếp tục phát huy khi độ phức tạp của hợp đồng tăng lên trên mainnet hay không.

Có ai đã benchmark các lệnh gọi host function của Piecrust so với việc thực thi WASM thuần túy chưa?
@Dusk #dusk $DUSK