#dusk $DUSK @Dusk
Tôi đang xem qua những thay đổi kỹ thuật gần đây của Dusk và kỳ vọng phần thú vị sẽ là một cải tiến khác cho hệ thống chứng minh.
Nhưng rồi tôi lại quay trở lại với một điều kém “hào nhoáng” hơn nhiều: điều gì xảy ra trước khi một bản chứng minh thậm chí được xử lý.
Một thay đổi gần đây liên quan đến Plonk tập trung vào việc loại bỏ sớm dữ liệu do prover tạo ra nếu bị định dạng sai.
Ban đầu nghe có vẻ chỉ là dọn dẹp thường quy.
Nhưng càng suy nghĩ, tôi càng thấy nó quan trọng đến mức nào.
Có sự khác biệt giữa việc “phá vỡ” mật mã và việc đưa dữ liệu xấu vào hạ tầng mật mã.
Một bản chứng minh có thể hợp lệ về mặt toán học trong khi dữ liệu xung quanh nó lại bị định dạng sai, được serialize không đúng cách hoặc được cấu trúc theo một kiểu mà hệ thống không bao giờ dự kiến. Nếu các đầu vào đó được phép đi sâu hơn vào pipeline chứng minh, thì sự cố cuối cùng sẽ khó khoanh vùng hơn và có thể tốn kém hơn để xử lý.
Vì vậy, cải tiến thực sự không nhất thiết là về toán học mạnh hơn.
Đó là về việc đưa điểm bị từ chối (rejection) tiến gần hơn tới nguồn.
Điều này quan trọng về mặt vận hành.
Trong một hạ tầng chứng minh chạy trên mạng thực tế, hệ thống không hoạt động tách biệt. Nó phải xử lý việc serialize/decoder đầu vào, đường đi bộ nhớ (memory execution paths) và tất cả những trường hợp biên kỳ lạ xuất hiện khi phần mềm gặp dữ liệu ngoài đời.
Mật mã có thể vững chắc trong khi phần triển khai xung quanh vẫn có những giả định yếu.
Vì vậy, tôi thấy các thay đổi nhỏ hơn này “gợi mở” hơn những thông báo tính năng.
Chúng cho thấy nhóm kỹ thuật đang dành thời gian để giảm số lượng những thứ hệ thống sẵn sàng xử lý một cách mù quáng.
Với Dusk, tôi nghĩ đây là một hướng đi quan trọng: không chỉ chứng minh rằng dữ liệu hợp lệ hoạt động, mà còn khiến dữ liệu không hợp lệ bị thất bại sớm hơn, sạch hơn và gần nơi bắt đầu xảy ra sai sót.
Lớp kiểm tra xác thực (validation) “nhàm chán” có thể cuối cùng sẽ cho chúng ta biết nhiều hơn về mức độ sẵn sàng cho sản xuất so với bất kỳ thứ mật mã “hào nhoáng” nào.
Tôi đang xem qua những thay đổi kỹ thuật gần đây của Dusk và kỳ vọng phần thú vị sẽ là một cải tiến khác cho hệ thống chứng minh.
Nhưng rồi tôi lại quay trở lại với một điều kém “hào nhoáng” hơn nhiều: điều gì xảy ra trước khi một bản chứng minh thậm chí được xử lý.
Một thay đổi gần đây liên quan đến Plonk tập trung vào việc loại bỏ sớm dữ liệu do prover tạo ra nếu bị định dạng sai.
Ban đầu nghe có vẻ chỉ là dọn dẹp thường quy.
Nhưng càng suy nghĩ, tôi càng thấy nó quan trọng đến mức nào.
Có sự khác biệt giữa việc “phá vỡ” mật mã và việc đưa dữ liệu xấu vào hạ tầng mật mã.
Một bản chứng minh có thể hợp lệ về mặt toán học trong khi dữ liệu xung quanh nó lại bị định dạng sai, được serialize không đúng cách hoặc được cấu trúc theo một kiểu mà hệ thống không bao giờ dự kiến. Nếu các đầu vào đó được phép đi sâu hơn vào pipeline chứng minh, thì sự cố cuối cùng sẽ khó khoanh vùng hơn và có thể tốn kém hơn để xử lý.
Vì vậy, cải tiến thực sự không nhất thiết là về toán học mạnh hơn.
Đó là về việc đưa điểm bị từ chối (rejection) tiến gần hơn tới nguồn.
Điều này quan trọng về mặt vận hành.
Trong một hạ tầng chứng minh chạy trên mạng thực tế, hệ thống không hoạt động tách biệt. Nó phải xử lý việc serialize/decoder đầu vào, đường đi bộ nhớ (memory execution paths) và tất cả những trường hợp biên kỳ lạ xuất hiện khi phần mềm gặp dữ liệu ngoài đời.
Mật mã có thể vững chắc trong khi phần triển khai xung quanh vẫn có những giả định yếu.
Vì vậy, tôi thấy các thay đổi nhỏ hơn này “gợi mở” hơn những thông báo tính năng.
Chúng cho thấy nhóm kỹ thuật đang dành thời gian để giảm số lượng những thứ hệ thống sẵn sàng xử lý một cách mù quáng.
Với Dusk, tôi nghĩ đây là một hướng đi quan trọng: không chỉ chứng minh rằng dữ liệu hợp lệ hoạt động, mà còn khiến dữ liệu không hợp lệ bị thất bại sớm hơn, sạch hơn và gần nơi bắt đầu xảy ra sai sót.
Lớp kiểm tra xác thực (validation) “nhàm chán” có thể cuối cùng sẽ cho chúng ta biết nhiều hơn về mức độ sẵn sàng cho sản xuất so với bất kỳ thứ mật mã “hào nhoáng” nào.
