Tôi bắt đầu nghi ngờ câu chuyện về số cổng của DUSK khi một phép XOR 8-bit mô phỏng giảm từ 31 cổng xuống còn một tra cứu PlonKup duy nhất. Sự nén này trông có vẻ ấn tượng 96,8%. Nhưng điều đó phản ánh toán học của mạch chứ không phải tốc độ proving thực tế.
Tra cứu vẫn kéo theo việc xử lý bảng, sắp xếp commitments và áp lực lên bộ nhớ. Vì vậy, giảm 31× số cổng không đồng nghĩa với việc proving nhanh hơn 31×. Chi phí có thể đơn giản là chuyển sang RAM.
Điều này quan trọng vì hướng dẫn dành cho operator của DUSK dự trù khoảng 1 GB cho mỗi worker tạo proof và 8 GB cho một server tối thiểu. Đây là các con số ước lượng kích thước, không phải bộ nhớ đỉnh đo được. Chỉ số còn thiếu là số proof trên mỗi GB ở mức tải P50 và P99, đặc biệt khi có nhiều worker chạy đồng thời.
Rồi đến khả năng tiếp cận. Điều gì xảy ra trên một điện thoại tầm trung sau thời gian nóng lên, các ứng dụng chạy nền và những lần proving lặp lại? Nếu P50 là chấp nhận được nhưng P99 bị treo thì việc riêng tư trở thành rào cản đối với người dùng, không chỉ là một “chiến thắng” về mật mã.
Tôi cũng đang theo dõi các proof bị sai định dạng. Một đầu vào không hợp lệ có thể tiêu tốn CPU bao nhiêu trước khi bị từ chối, và bộ lọc sớm tiết kiệm được bao nhiêu? Một chút overhead là bình thường. Còn việc khuếch đại không giới hạn thì không.
DUSK có thể thành công nếu việc nén bằng tra cứu cải thiện được thông lượng thực sự mà không tập trung việc proving vào phần cứng RAM cao. Cho đến khi DUSK công bố các benchmark về thời gian proof, mức sử dụng đỉnh RAM, năng lượng và việc từ chối proof không hợp lệ, thì vẫn chưa thể đánh giá đầy đủ.
#dusk $DUSK @Dusk
Tra cứu vẫn kéo theo việc xử lý bảng, sắp xếp commitments và áp lực lên bộ nhớ. Vì vậy, giảm 31× số cổng không đồng nghĩa với việc proving nhanh hơn 31×. Chi phí có thể đơn giản là chuyển sang RAM.
Điều này quan trọng vì hướng dẫn dành cho operator của DUSK dự trù khoảng 1 GB cho mỗi worker tạo proof và 8 GB cho một server tối thiểu. Đây là các con số ước lượng kích thước, không phải bộ nhớ đỉnh đo được. Chỉ số còn thiếu là số proof trên mỗi GB ở mức tải P50 và P99, đặc biệt khi có nhiều worker chạy đồng thời.
Rồi đến khả năng tiếp cận. Điều gì xảy ra trên một điện thoại tầm trung sau thời gian nóng lên, các ứng dụng chạy nền và những lần proving lặp lại? Nếu P50 là chấp nhận được nhưng P99 bị treo thì việc riêng tư trở thành rào cản đối với người dùng, không chỉ là một “chiến thắng” về mật mã.
Tôi cũng đang theo dõi các proof bị sai định dạng. Một đầu vào không hợp lệ có thể tiêu tốn CPU bao nhiêu trước khi bị từ chối, và bộ lọc sớm tiết kiệm được bao nhiêu? Một chút overhead là bình thường. Còn việc khuếch đại không giới hạn thì không.
DUSK có thể thành công nếu việc nén bằng tra cứu cải thiện được thông lượng thực sự mà không tập trung việc proving vào phần cứng RAM cao. Cho đến khi DUSK công bố các benchmark về thời gian proof, mức sử dụng đỉnh RAM, năng lượng và việc từ chối proof không hợp lệ, thì vẫn chưa thể đánh giá đầy đủ.
#dusk $DUSK @Dusk