Kết quả nguy hiểm nhất không nhất thiết là các node “đánh nhau” với nhau, mà là tất cả các node đều gọi cùng một bộ mã kiểm chứng, rồi kiểm chứng sai một cách ngay ngắn, trật tự.
Tôi đã đối chiếu whitepaper lịch sử của @Dusk với tài liệu hiện hành. Tài liệu cũ gọi bộ runtime Rust/WASM này là Piecrust, còn tài liệu hiện tại thì dùng DuskVM. Tên gọi có thể thay đổi, nhưng thiết kế cốt lõi không đổi: hợp đồng có thể giao các phép xác thực mật mã như PLONK, Groth16, BLS… cho tầng host với các cổng vào công cộng, không cần tự tự hiện thực từng thứ.
Lợi ích thì rất thực tế. Lập trình viên ít phải viết một bộ mã mật mã “dễ sai” hơn; các node cũng không cần lặp lại các phép tính nền trong sandbox WASM, nên ứng dụng nhẹ hơn và quy tắc xác thực dễ được thống nhất hơn.
Chi phí cũng tập trung. Hợp đồng ứng dụng viết sai thường sẽ trước hết gây hại cho chính nó; nhưng nếu bộ xác thực dùng chung sai ở việc phân tích đầu vào, lựa chọn phiên bản hoặc các điều kiện biên, thì tất cả các hợp đồng phụ thuộc có thể đều bị ảnh hưởng. Toàn mạng phải nhất quán—chỉ có thể chứng minh rằng mọi người đã thực thi cùng một quy tắc.
Trong bản nâng cấp Aegis của Dusk vào tháng 3/2026, Dusk đã bật PLONK V3 và các hành vi BLS mới, và truy vấn host BLS mà hợp đồng dùng cũng chuyển theo chiều cao khối. Khối lịch sử gọi bộ xác thực cũ, còn dữ liệu mới dùng phiên bản mới; nếu chọn sai chiều cao thì có thể dẫn đến những kết luận khác nhau về tính hợp lệ của giao dịch.
Vì vậy, tôi sẽ không chỉ đếm và xem xét các báo cáo audit; tôi còn theo dõi phiên bản của bộ xác thực, chiều cao nâng cấp, vector kiểm thử, vấn đề mất hiệu lực cache và các bài diễn tập rollback. $DUSK đảm nhiệm Gas và an toàn đồng thuận, nhưng để giữ cho các ứng dụng tài chính vận hành còn có những cổng xác thực công cộng này. Tốc độ quyết định hệ thống chạy nhanh đến đâu; còn bộ xác thực quyết định liệu nó có làm cho cả “lỗi” cũng chạy nhanh hơn không.
#dusk
Tôi đã đối chiếu whitepaper lịch sử của @Dusk với tài liệu hiện hành. Tài liệu cũ gọi bộ runtime Rust/WASM này là Piecrust, còn tài liệu hiện tại thì dùng DuskVM. Tên gọi có thể thay đổi, nhưng thiết kế cốt lõi không đổi: hợp đồng có thể giao các phép xác thực mật mã như PLONK, Groth16, BLS… cho tầng host với các cổng vào công cộng, không cần tự tự hiện thực từng thứ.
Lợi ích thì rất thực tế. Lập trình viên ít phải viết một bộ mã mật mã “dễ sai” hơn; các node cũng không cần lặp lại các phép tính nền trong sandbox WASM, nên ứng dụng nhẹ hơn và quy tắc xác thực dễ được thống nhất hơn.
Chi phí cũng tập trung. Hợp đồng ứng dụng viết sai thường sẽ trước hết gây hại cho chính nó; nhưng nếu bộ xác thực dùng chung sai ở việc phân tích đầu vào, lựa chọn phiên bản hoặc các điều kiện biên, thì tất cả các hợp đồng phụ thuộc có thể đều bị ảnh hưởng. Toàn mạng phải nhất quán—chỉ có thể chứng minh rằng mọi người đã thực thi cùng một quy tắc.
Trong bản nâng cấp Aegis của Dusk vào tháng 3/2026, Dusk đã bật PLONK V3 và các hành vi BLS mới, và truy vấn host BLS mà hợp đồng dùng cũng chuyển theo chiều cao khối. Khối lịch sử gọi bộ xác thực cũ, còn dữ liệu mới dùng phiên bản mới; nếu chọn sai chiều cao thì có thể dẫn đến những kết luận khác nhau về tính hợp lệ của giao dịch.
Vì vậy, tôi sẽ không chỉ đếm và xem xét các báo cáo audit; tôi còn theo dõi phiên bản của bộ xác thực, chiều cao nâng cấp, vector kiểm thử, vấn đề mất hiệu lực cache và các bài diễn tập rollback. $DUSK đảm nhiệm Gas và an toàn đồng thuận, nhưng để giữ cho các ứng dụng tài chính vận hành còn có những cổng xác thực công cộng này. Tốc độ quyết định hệ thống chạy nhanh đến đâu; còn bộ xác thực quyết định liệu nó có làm cho cả “lỗi” cũng chạy nhanh hơn không.
#dusk
