#dusk $DUSK @Dusk #dusk $DUSK @Dusk
Dưới đây là một quyết định thiết kế trên Dusk mà tôi chưa từng thấy được diễn đạt đúng cách ở bất kỳ đâu.
DuskVM chạy các hợp đồng Rust/WASM trên Wasmtime, trực tiếp trên L1. Đó là một lựa chọn về ngăn xếp. Phần tôi thấy thú vị hơn nằm ở việc node sẽ “bộc lộ” gì cho những hợp đồng đó.
Việc xác minh một bằng chứng zero-knowledge trong một hợp đồng, từng lệnh một, cực kỳ tốn kém. Vì vậy Dusk đã đẩy việc đó xuống một tầng: rusk-abi cung cấp cho hợp đồng các hàm host để xác minh bằng chứng, bao gồm verify_groth16. Hiện tại host hỗ trợ hai hệ thống bằng chứng — Groth16 và PLONK.
Đó là một năng lực thật sự. Nó có nghĩa là một hợp đồng trên Dusk có thể nhận một bằng chứng ZK như một đầu vào và kiểm tra với chi phí gần như bản địa. Trên hầu hết các chuỗi, điều này hoặc là không thể, hoặc là gây “phá sản” về chi phí.
Nhưng hãy để ý ý nghĩa của việc đó. Tập các hệ thống bằng chứng mà bạn có thể sử dụng với vai trò một nhà xây dựng là cố định ở lớp giao thức, không phải thứ được ứng dụng của bạn chọn. Muốn một cơ chế khác vì mạch của bạn phù hợp hơn với nó? Lúc đó bạn đang yêu cầu một thay đổi ở cấp giao thức, chứ không chỉ là “import” một thư viện.
Chỉ trong một câu: xác minh ở cấp host giúp bạn tối ưu chi phí, nhưng đánh đổi bằng tính linh hoạt tùy chọn.
Với một chuỗi hướng tới tài chính được quản lý, tôi thực sự nghĩ đây là phía đúng của phép đánh đổi. Phần mềm của các tổ chức cần một tập nhỏ các primitive—đã được kiểm toán, ổn định—chứ không phải năm mươi “phương ngữ” mật mã. Nhưng điều đó cũng đồng nghĩa là nhóm phát triển giao thức, chứ không phải thị trường, sẽ quyết định hệ mật mã mà hệ sinh thái được xây dựng trên, và quyết định đó sẽ “cộng dồn” qua nhiều năm.
Cũng đáng nhớ rằng chính VM bản thân nó có lịch sử kiểm toán riêng—Piecrust đã được rà soát vào tháng 7/2024, trước khi phần lớn kiến trúc hiện tại tồn tại.
Liệu các hệ thống bằng chứng có nên là primitive ở cấp giao thức mà ai cũng dùng chung, hay là các lựa chọn ở cấp ứng dụng mà từng đội tự quyết cho mình?
Dưới đây là một quyết định thiết kế trên Dusk mà tôi chưa từng thấy được diễn đạt đúng cách ở bất kỳ đâu.
DuskVM chạy các hợp đồng Rust/WASM trên Wasmtime, trực tiếp trên L1. Đó là một lựa chọn về ngăn xếp. Phần tôi thấy thú vị hơn nằm ở việc node sẽ “bộc lộ” gì cho những hợp đồng đó.
Việc xác minh một bằng chứng zero-knowledge trong một hợp đồng, từng lệnh một, cực kỳ tốn kém. Vì vậy Dusk đã đẩy việc đó xuống một tầng: rusk-abi cung cấp cho hợp đồng các hàm host để xác minh bằng chứng, bao gồm verify_groth16. Hiện tại host hỗ trợ hai hệ thống bằng chứng — Groth16 và PLONK.
Đó là một năng lực thật sự. Nó có nghĩa là một hợp đồng trên Dusk có thể nhận một bằng chứng ZK như một đầu vào và kiểm tra với chi phí gần như bản địa. Trên hầu hết các chuỗi, điều này hoặc là không thể, hoặc là gây “phá sản” về chi phí.
Nhưng hãy để ý ý nghĩa của việc đó. Tập các hệ thống bằng chứng mà bạn có thể sử dụng với vai trò một nhà xây dựng là cố định ở lớp giao thức, không phải thứ được ứng dụng của bạn chọn. Muốn một cơ chế khác vì mạch của bạn phù hợp hơn với nó? Lúc đó bạn đang yêu cầu một thay đổi ở cấp giao thức, chứ không chỉ là “import” một thư viện.
Chỉ trong một câu: xác minh ở cấp host giúp bạn tối ưu chi phí, nhưng đánh đổi bằng tính linh hoạt tùy chọn.
Với một chuỗi hướng tới tài chính được quản lý, tôi thực sự nghĩ đây là phía đúng của phép đánh đổi. Phần mềm của các tổ chức cần một tập nhỏ các primitive—đã được kiểm toán, ổn định—chứ không phải năm mươi “phương ngữ” mật mã. Nhưng điều đó cũng đồng nghĩa là nhóm phát triển giao thức, chứ không phải thị trường, sẽ quyết định hệ mật mã mà hệ sinh thái được xây dựng trên, và quyết định đó sẽ “cộng dồn” qua nhiều năm.
Cũng đáng nhớ rằng chính VM bản thân nó có lịch sử kiểm toán riêng—Piecrust đã được rà soát vào tháng 7/2024, trước khi phần lớn kiến trúc hiện tại tồn tại.
Liệu các hệ thống bằng chứng có nên là primitive ở cấp giao thức mà ai cũng dùng chung, hay là các lựa chọn ở cấp ứng dụng mà từng đội tự quyết cho mình?