Tôi đang xem qua các công việc kỹ thuật gần đây của Dusk và mong phần thú vị sẽ là một cải tiến khác cho hệ thống chứng minh.
Thay vào đó tôi lại mắc kẹt với một thứ kém hấp dẫn hơn nhiều:
làm thế nào hệ thống xử lý dữ liệu chứng minh kém (bad prover data) trước khi đi sâu hơn vào pipeline..
Một thay đổi gần đây liên quan đến Plonk tập trung vào việc từ chối dữ liệu chứng minh bị định dạng sai sớm hơn.
Nhìn bề ngoài thì nghe có vẻ như một công việc kỹ thuật thường ngày.
Nhưng ở đây có một điểm khác biệt quan trọng.
Một bằng chứng mật mã có thể hoàn toàn đúng về mặt toán học, trong khi dữ liệu mang theo hoặc bao quanh bằng chứng đó lại bị sai định dạng một cách không đúng—hoặc đơn giản là nằm ngoài những gì mà phần triển khai mong đợi.
Nếu dữ liệu đó đi quá xa vào pipeline tạo chứng minh thì việc xảy ra lỗi 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 này không nhất thiết nhằm làm cho mật mã mạnh hơn.
Nó là để hệ thống ít sẵn sàng tin tưởng dữ liệu đầu vào một cách mù quáng hơn.
Điều này quan trọng hơn rất nhiều khi một hệ thống chứng minh được chạy như hạ tầng sản xuất, thay vì chỉ là chứng minh rằng phần toán học nền tảng hoạt động.
Các hệ thống thực tế phải xử lý việc tuần tự hoá/giải mã (serialization decoding), quản lý bộ nhớ, các nhánh thực thi (execution paths) và các đầu vào bất ngờ.
Toán học có thể đúng, nhưng phần mềm xung quanh vẫn có thể dựa trên các giả định yếu.
Đó là lý do những thay đổi kỹ thuật nhỏ hơn này thu hút sự chú ý của tôi.
Các thông báo tính năng cho thấy đội ngũ muốn xây dựng gì…
Những thay đổi như thế này cho thấy nhóm đang học được điều gì có thể thực sự đi sai.
Với Dusk, việc đẩy dữ liệu không hợp lệ ra sớm có vẻ như là một thay đổi nhỏ nhưng lại mang ý nghĩa lớn hơn nhiều:
hạ tầng ZK cấp production không chỉ là đảm bảo chứng minh đúng những điều hợp lệ.
Nó còn là làm cho những điều không hợp lệ thất bại một cách an toàn, có thể dự đoán, và càng sớm càng tốt.
#dusk @Dusk $DUSK
$TUT
$UAI
Thay vào đó tôi lại mắc kẹt với một thứ kém hấp dẫn hơn nhiều:
làm thế nào hệ thống xử lý dữ liệu chứng minh kém (bad prover data) trước khi đi sâu hơn vào pipeline..
Một thay đổi gần đây liên quan đến Plonk tập trung vào việc từ chối dữ liệu chứng minh bị định dạng sai sớm hơn.
Nhìn bề ngoài thì nghe có vẻ như một công việc kỹ thuật thường ngày.
Nhưng ở đây có một điểm khác biệt quan trọng.
Một bằng chứng mật mã có thể hoàn toàn đúng về mặt toán học, trong khi dữ liệu mang theo hoặc bao quanh bằng chứng đó lại bị sai định dạng một cách không đúng—hoặc đơn giản là nằm ngoài những gì mà phần triển khai mong đợi.
Nếu dữ liệu đó đi quá xa vào pipeline tạo chứng minh thì việc xảy ra lỗi 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 này không nhất thiết nhằm làm cho mật mã mạnh hơn.
Nó là để hệ thống ít sẵn sàng tin tưởng dữ liệu đầu vào một cách mù quáng hơn.
Điều này quan trọng hơn rất nhiều khi một hệ thống chứng minh được chạy như hạ tầng sản xuất, thay vì chỉ là chứng minh rằng phần toán học nền tảng hoạt động.
Các hệ thống thực tế phải xử lý việc tuần tự hoá/giải mã (serialization decoding), quản lý bộ nhớ, các nhánh thực thi (execution paths) và các đầu vào bất ngờ.
Toán học có thể đúng, nhưng phần mềm xung quanh vẫn có thể dựa trên các giả định yếu.
Đó là lý do những thay đổi kỹ thuật nhỏ hơn này thu hút sự chú ý của tôi.
Các thông báo tính năng cho thấy đội ngũ muốn xây dựng gì…
Những thay đổi như thế này cho thấy nhóm đang học được điều gì có thể thực sự đi sai.
Với Dusk, việc đẩy dữ liệu không hợp lệ ra sớm có vẻ như là một thay đổi nhỏ nhưng lại mang ý nghĩa lớn hơn nhiều:
hạ tầng ZK cấp production không chỉ là đảm bảo chứng minh đúng những điều hợp lệ.
Nó còn là làm cho những điều không hợp lệ thất bại một cách an toàn, có thể dự đoán, và càng sớm càng tốt.
#dusk @Dusk $DUSK
$TUT
$UAI