Lỗ hổng PLONK của Dusk, lớp quyền riêng tư với vốn hóa 600.000 USD suýt bị một kẻ giả mạo bằng chứng đánh bại
Sau khi tôi đọc xong bản báo cáo an ninh mà OtterSec công bố vào ngày 30/04/2026, tôi đã ngẩn ra khoảng năm phút. Bộ xác minh của dusk-plonk chưa từng xác minh bốn cam kết đa thức mà người chứng đưa ra. Nói đơn giản, kẻ tấn công có thể giả mạo một bằng chứng zero-knowledge giả để đúc token DUSK mà không cần bất kỳ tài sản thực nào và chuyển các khoản thu nhập bất hợp pháp. Một giao thức quyền riêng tư được thiết kế cho thị trường tài chính được quản lý, nhưng lõi mật mã của nó lại có lỗ hổng cho phép kẻ tấn công tạo token “từ hư không”. Một hạ tầng được gắn mác là khiến các tổ chức yên tâm đưa lên chuỗi, lại tồn tại một khiếm khuyết mang tính nền tảng ở lớp quyền riêng tư.
Câu chuyện về tuân thủ trên whitepaper thì rất đẹp, nhưng trong mã thì suýt có một “cửa hậu” để đúc vô hạn. Bạn có thể nói lỗ hổng đã được khắc phục. Nhưng lỗ hổng xuất hiện ở phần xác minh trong lớp quyền riêng tư, bản thân nó đã là một cái tát vào định vị “ưu tiên quyền riêng tư”. Một dự án kiếm cơm nhờ ZK, mà hiện thực ZK lại gặp vấn đề. Sau khi đọc báo cáo, câu hỏi đầu tiên xuất hiện trong đầu tôi là—một chuỗi quyền riêng tư dựa vào ZK, nếu hiện thực ZK có thể mắc kiểu lỗ hổng như vậy, thì còn điều gì có thể không bị lỗi? Dusk đã giảm khá nhiều so với đỉnh; quy đổi 600.000 USD theo giá lúc đó, nếu kẻ tấn công dùng lỗ hổng này để đúc một lượng lớn token, giá có thể bị đập thẳng xuống. @Dusk
Tôi tìm được một báo cáo kiểm toán của Dusk và lướt qua. Đơn vị kiểm toán là Dust Labs, phạm vi kiểm toán chỉ bao phủ một số module nhất định, vậy logic xác minh của dusk-plonk có nằm trong phạm vi kiểm toán không? Tôi không tìm thấy mô tả rõ ràng. Nếu mã nguồn lớp quyền riêng tư cốt lõi của một dự án bị bỏ sót trong đợt kiểm toán, hoặc bản thân phạm vi kiểm toán không bao phủ đến, thì giá trị của báo cáo kiểm toán đó cần phải được đánh giá lại. Kiểm toán không phải làm một lần là xong.
Tôi không nói rằng Dusk không đáng tin, nhưng một dự án viết chữ “quyền riêng tư” ngay trong tên gọi, mà ở lớp xác minh ZK cốt lõi lại tồn tại lỗ hổng nền tảng như vậy, thì tôi rất khó thuyết phục bản thân tiếp tục nắm giữ. Hãy chờ sau khi lõi mật mã được xác thực qua thêm vài vòng. Tạm thời tôi sẽ đưa nó trở lại danh sách theo dõi, xem liệu sau đó có còn công bố thêm lỗ hổng mới không. Nếu cùng một module lại tiếp tục gặp vấn đề lần nữa, thì không chỉ là vấn đề kỹ thuật nữa—mà là vấn đề quy trình.
#dusk $DUSK
Sau khi tôi đọc xong bản báo cáo an ninh mà OtterSec công bố vào ngày 30/04/2026, tôi đã ngẩn ra khoảng năm phút. Bộ xác minh của dusk-plonk chưa từng xác minh bốn cam kết đa thức mà người chứng đưa ra. Nói đơn giản, kẻ tấn công có thể giả mạo một bằng chứng zero-knowledge giả để đúc token DUSK mà không cần bất kỳ tài sản thực nào và chuyển các khoản thu nhập bất hợp pháp. Một giao thức quyền riêng tư được thiết kế cho thị trường tài chính được quản lý, nhưng lõi mật mã của nó lại có lỗ hổng cho phép kẻ tấn công tạo token “từ hư không”. Một hạ tầng được gắn mác là khiến các tổ chức yên tâm đưa lên chuỗi, lại tồn tại một khiếm khuyết mang tính nền tảng ở lớp quyền riêng tư.
Câu chuyện về tuân thủ trên whitepaper thì rất đẹp, nhưng trong mã thì suýt có một “cửa hậu” để đúc vô hạn. Bạn có thể nói lỗ hổng đã được khắc phục. Nhưng lỗ hổng xuất hiện ở phần xác minh trong lớp quyền riêng tư, bản thân nó đã là một cái tát vào định vị “ưu tiên quyền riêng tư”. Một dự án kiếm cơm nhờ ZK, mà hiện thực ZK lại gặp vấn đề. Sau khi đọc báo cáo, câu hỏi đầu tiên xuất hiện trong đầu tôi là—một chuỗi quyền riêng tư dựa vào ZK, nếu hiện thực ZK có thể mắc kiểu lỗ hổng như vậy, thì còn điều gì có thể không bị lỗi? Dusk đã giảm khá nhiều so với đỉnh; quy đổi 600.000 USD theo giá lúc đó, nếu kẻ tấn công dùng lỗ hổng này để đúc một lượng lớn token, giá có thể bị đập thẳng xuống. @Dusk
Tôi tìm được một báo cáo kiểm toán của Dusk và lướt qua. Đơn vị kiểm toán là Dust Labs, phạm vi kiểm toán chỉ bao phủ một số module nhất định, vậy logic xác minh của dusk-plonk có nằm trong phạm vi kiểm toán không? Tôi không tìm thấy mô tả rõ ràng. Nếu mã nguồn lớp quyền riêng tư cốt lõi của một dự án bị bỏ sót trong đợt kiểm toán, hoặc bản thân phạm vi kiểm toán không bao phủ đến, thì giá trị của báo cáo kiểm toán đó cần phải được đánh giá lại. Kiểm toán không phải làm một lần là xong.
Tôi không nói rằng Dusk không đáng tin, nhưng một dự án viết chữ “quyền riêng tư” ngay trong tên gọi, mà ở lớp xác minh ZK cốt lõi lại tồn tại lỗ hổng nền tảng như vậy, thì tôi rất khó thuyết phục bản thân tiếp tục nắm giữ. Hãy chờ sau khi lõi mật mã được xác thực qua thêm vài vòng. Tạm thời tôi sẽ đưa nó trở lại danh sách theo dõi, xem liệu sau đó có còn công bố thêm lỗ hổng mới không. Nếu cùng một module lại tiếp tục gặp vấn đề lần nữa, thì không chỉ là vấn đề kỹ thuật nữa—mà là vấn đề quy trình.
#dusk $DUSK
