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