#dusk $DUSK @Dusk
Tôi đang chạy tạo bằng chứng cục bộ để benchmark hiệu năng mạch thì nhận ra một điều khiến tôi quay lại đọc các bản ghi kỹ thuật (writeups) chính từ nhóm mật mã, thay vì chỉ xem các trang marketing.
Các con số thực tế của PLONK mới là thứ làm cho lập luận tuân thủ (compliance) hoạt động, chứ không chỉ góc nhìn về quyền riêng tư. Thời gian xác minh duy trì quanh 6-9 mili giây bất kể kích thước mạch — còn thời gian tạo chứng minh thì tăng theo độ phức tạp mạch (xấp xỉ 5,46 giây cho một mạch 2^16 cổng trên phần cứng phổ thông), nhưng phía bộ xác minh vẫn nhanh và gần như hằng số. Sự bất đối xứng này quan trọng hơn nhiều đối với tài chính được quản lý (regulated finance) so với những gì người ta thường đánh giá: một kiểm toán viên hay đối tác kiểm tra một chứng minh không phải tiêu tốn tính toán đáng kể mỗi lần, ngay cả khi logic của giao dịch bên dưới ngày càng phức tạp.
Điều tôi không ngờ là bản thân PLONK lại có một lỗ hổng đã được công bố một cách thực sự, không chỉ là rủi ro mang tính lý thuyết. Nhóm nghiên cứu của Dusk đã phát hiện một vấn đề nghiêm trọng trong cách triển khai phép biến đổi Fiat-Shamir — phần dùng hashing để biến một giao thức tương tác thành phi tương tác bằng cách lấy thách thức từ việc băm thay vì việc một bộ xác minh trực tiếp gửi chúng. Cách triển khai ban đầu không băm các đầu vào công khai đủ sớm, làm suy yếu cam kết về độ đúng đắn (soundness). Trail of Bits đã phối hợp công bố, Dusk vá lỗi trước khi lên mainnet, và đưa bản sửa lỗi ra công khai thay vì âm thầm giữ lại.
Chi tiết đó là điều tôi cứ suy nghĩ mãi — một chuỗi hướng tới tuân thủ dựa trên hệ thống bằng chứng mật mã mà trong code vận hành gần với môi trường thực tế lại từng tồn tại một lỗi về soundness: được phát hiện và sửa trước khi nó thực sự kịp gây ảnh hưởng. Tôi không biết có bao nhiêu triển khai khác dùng PLONK ở nơi nào đó vẫn còn dễ tổn thương khi thông tin này trở nên công khai, hoặc khoảng thời gian trôi giữa lúc công bố và các dự án khác tự vá các fork của họ.
Tôi đang chạy tạo bằng chứng cục bộ để benchmark hiệu năng mạch thì nhận ra một điều khiến tôi quay lại đọc các bản ghi kỹ thuật (writeups) chính từ nhóm mật mã, thay vì chỉ xem các trang marketing.
Các con số thực tế của PLONK mới là thứ làm cho lập luận tuân thủ (compliance) hoạt động, chứ không chỉ góc nhìn về quyền riêng tư. Thời gian xác minh duy trì quanh 6-9 mili giây bất kể kích thước mạch — còn thời gian tạo chứng minh thì tăng theo độ phức tạp mạch (xấp xỉ 5,46 giây cho một mạch 2^16 cổng trên phần cứng phổ thông), nhưng phía bộ xác minh vẫn nhanh và gần như hằng số. Sự bất đối xứng này quan trọng hơn nhiều đối với tài chính được quản lý (regulated finance) so với những gì người ta thường đánh giá: một kiểm toán viên hay đối tác kiểm tra một chứng minh không phải tiêu tốn tính toán đáng kể mỗi lần, ngay cả khi logic của giao dịch bên dưới ngày càng phức tạp.
Điều tôi không ngờ là bản thân PLONK lại có một lỗ hổng đã được công bố một cách thực sự, không chỉ là rủi ro mang tính lý thuyết. Nhóm nghiên cứu của Dusk đã phát hiện một vấn đề nghiêm trọng trong cách triển khai phép biến đổi Fiat-Shamir — phần dùng hashing để biến một giao thức tương tác thành phi tương tác bằng cách lấy thách thức từ việc băm thay vì việc một bộ xác minh trực tiếp gửi chúng. Cách triển khai ban đầu không băm các đầu vào công khai đủ sớm, làm suy yếu cam kết về độ đúng đắn (soundness). Trail of Bits đã phối hợp công bố, Dusk vá lỗi trước khi lên mainnet, và đưa bản sửa lỗi ra công khai thay vì âm thầm giữ lại.
Chi tiết đó là điều tôi cứ suy nghĩ mãi — một chuỗi hướng tới tuân thủ dựa trên hệ thống bằng chứng mật mã mà trong code vận hành gần với môi trường thực tế lại từng tồn tại một lỗi về soundness: được phát hiện và sửa trước khi nó thực sự kịp gây ảnh hưởng. Tôi không biết có bao nhiêu triển khai khác dùng PLONK ở nơi nào đó vẫn còn dễ tổn thương khi thông tin này trở nên công khai, hoặc khoảng thời gian trôi giữa lúc công bố và các dự án khác tự vá các fork của họ.