#dusk $DUSK @Dusk
Chỉ mất bốn con số. Đường đi có “lá chắn” của Phoenix trong dusk — phần mang toàn bộ nội dung quảng bá về quyền riêng tư của nó — đã xác minh các bằng chứng chỉ qua một lần gọi, và lần gọi đó không hề kiểm tra bốn giá trị selector so với các cam kết nằm ngay trong khóa xác minh. $DUSK #dusk @Dusk đã vượt qua ba đợt kiểm toán riêng lẻ trước khi sự việc này được phát hiện vào tháng Hai.
Điều khiến tôi chú ý là hình dạng của “lỗ hổng” (miss). Trong PLONK chuẩn, selector được cho là công khai, cố định, và là dữ liệu phía trình xác minh. Còn widget tùy chỉnh của dusk-plonk đã buộc chúng trở thành những con số do người tạo chứng minh (prover) cung cấp, và không ai cập nhật mô hình tư duy quyết định điều gì cần có sự ràng buộc mật mã. Logic của mạch nhìn chung ổn từ đầu đến cuối — khoảng trống nằm thấp hơn một lớp, trong hệ thống dây dẫn (wiring) phục vụ xác minh.
Điểm thay đổi với tôi là nhận ra “đã được kiểm toán ba lần” không giống với “đã được kiểm toán theo đúng mô hình đe dọa (threat model)”. Một người rà soát logic ràng buộc có thể bước qua một giả định mang tính cấu trúc, giả định đó âm thầm không còn giữ nữa. Điều này khó bắt hơn một lỗi code thông thường, và nó không chỉ xảy ra ở Dusk — cùng một kiểu mẫu cũng được phát hiện độc lập trong Jellyfish của Espresso.
Bước tiếp theo tôi sẽ kiểm tra: liệu nỗ lực của Dusk nhằm thúc đẩy một đặc tả chuẩn cho việc xác minh PLONK có thực sự được phát hành hay chỉ dừng lại ở một luồng thảo luận.
Chỉ mất bốn con số. Đường đi có “lá chắn” của Phoenix trong dusk — phần mang toàn bộ nội dung quảng bá về quyền riêng tư của nó — đã xác minh các bằng chứng chỉ qua một lần gọi, và lần gọi đó không hề kiểm tra bốn giá trị selector so với các cam kết nằm ngay trong khóa xác minh. $DUSK #dusk @Dusk đã vượt qua ba đợt kiểm toán riêng lẻ trước khi sự việc này được phát hiện vào tháng Hai.
Điều khiến tôi chú ý là hình dạng của “lỗ hổng” (miss). Trong PLONK chuẩn, selector được cho là công khai, cố định, và là dữ liệu phía trình xác minh. Còn widget tùy chỉnh của dusk-plonk đã buộc chúng trở thành những con số do người tạo chứng minh (prover) cung cấp, và không ai cập nhật mô hình tư duy quyết định điều gì cần có sự ràng buộc mật mã. Logic của mạch nhìn chung ổn từ đầu đến cuối — khoảng trống nằm thấp hơn một lớp, trong hệ thống dây dẫn (wiring) phục vụ xác minh.
Điểm thay đổi với tôi là nhận ra “đã được kiểm toán ba lần” không giống với “đã được kiểm toán theo đúng mô hình đe dọa (threat model)”. Một người rà soát logic ràng buộc có thể bước qua một giả định mang tính cấu trúc, giả định đó âm thầm không còn giữ nữa. Điều này khó bắt hơn một lỗi code thông thường, và nó không chỉ xảy ra ở Dusk — cùng một kiểu mẫu cũng được phát hiện độc lập trong Jellyfish của Espresso.
Bước tiếp theo tôi sẽ kiểm tra: liệu nỗ lực của Dusk nhằm thúc đẩy một đặc tả chuẩn cho việc xác minh PLONK có thực sự được phát hành hay chỉ dừng lại ở một luồng thảo luận.
