Chứng minh không kiến thức (zero knowledge proof) thường có nghĩa là ai đó đã xây một mạch rất cụ thể cho đúng một việc rất cụ thể. Chứng minh số dư nằm trên một con số. Chứng minh việc một lá phiếu đã được đếm đúng. Một nhiệm vụ hẹp, một mạch tùy chỉnh được làm riêng cho nhiệm vụ đó, và nếu bạn muốn chứng minh thứ khác thì về cơ bản bạn phải làm lại từ đầu.
Hệ thống tranh chấp của Newton không hoạt động như vậy, và tôi đã mất một phút mới hiểu được vì sao. Thay vì xây một mạch mới cho mọi chính sách mà ai đó viết, họ đã lấy toàn bộ công cụ máy thực thi Rego—chính là bộ thông dịch thực sự chạy các quy tắc tuân thủ—rồi biên dịch toàn bộ thành một zkvm đa dụng. Vì vậy, bất kỳ chính sách nào viết bằng Rego—kiểm tra lệnh trừng phạt, giới hạn tốc độ, một quy tắc đủ điều kiện nhiều bước, bất cứ là gì—tự động trở thành thứ có thể chứng minh được. Không cần phải làm mạch mới cho từng chính sách. Thứ được làm cho có thể chứng minh chính là bản thân động cơ, chứ không phải từng quy tắc riêng lẻ.
Điều này chỉ hoạt động được vì có một điều gì đó khá “nhàm” về Rego. Nó mang tính xác định (deterministic). Cùng một chính sách, cùng các đầu vào, cùng một đầu ra, mỗi lần, không có tác dụng phụ và không có bất kỳ sự ngẫu nhiên nào len lỏi vào. Sự xác định đó chính là lý do cốt lõi khiến cách tiếp cận này có thể gắn kết lại được. Nếu ngôn ngữ chính sách cho phép bất kỳ trạng thái bên ngoài nào hoặc bất kỳ sự ngẫu nhiên nào, bạn sẽ không thể biên dịch nó thành một mạch (circuit) và mong rằng bằng chứng sẽ có ý nghĩa một cách nhất quán.
Vậy nên đây là thứ thực sự mà nó mang lại. Khi ai đó thách thức một chứng thực (attestation), cụ thể là kết quả được ký của người vận hành (operator) cho một lần đánh giá chính sách (policy evaluation), họ không yêu cầu ai đó chỉ “tin” phiên bản của mình về chuyện đáng lẽ phải xảy ra gì. Họ tự chạy lại cùng chính sách đó qua zkvm và nhận được một bằng chứng toán học thực sự, không phải ý kiến, không phải cách diễn giải khác nhau—một bằng chứng cho thấy kết quả ban đầu là sai. Smart contract kiểm tra bằng chứng đó, kiểm tra cửa sổ thách thức (challenge window), và đưa ra quyết định. Không bỏ phiếu. Không hội đồng. Không ai cân nhắc xem ai đáng tin hơn. Chỉ có việc smart contract kiểm tra phép toán và trừng phạt (slash) các operator nếu bằng chứng xác nhận họ đã làm sai.
Điều này quay lại với ý tưởng tổng thể rằng Newton trả về một chứng thực pass/fail đã được ký trước khi một giao dịch được chốt. Việc chứng thực đó bị sai không chỉ là một báo cáo lỗi chờ được đem ra để tranh luận vào lúc sau. Đó là thứ có thể bị bất kỳ ai chịu khó kiểm tra chứng minh là sai về mặt toán học—một đảm bảo rất khác so với phần lớn các hệ thống hiện nay.
Điều tôi bị mắc ở đây là hình dung xem điều này trông sẽ như thế nào với mức độ phức tạp thực tế. Ví dụ trong whitepaper chỉ là một bài kiểm tra cấm vận khá đơn giản, gồm vài quy tắc, dữ liệu đầu vào sạch sẽ, và đương nhiên mọi thứ chứng minh “sạch” thông qua zkVM mà không gặp nhiều rắc rối. Nhưng logic tuân thủ (compliance) thực tế lại nhanh chóng trở nên rối hơn. Nhiều nguồn dữ liệu đối chiếu lẫn nhau, các điều kiện lồng nhau, những chính sách lấy từ nhiều luồng dữ liệu khác nhau cùng lúc và kết hợp chúng theo những cách không “gọn gàng” như một quy tắc thẳng tuột duy nhất. Tôi chưa biết liệu thời gian tạo bằng chứng có còn giữ được khi các chính sách không còn giống những ví dụ 3 dòng nữa mà bắt đầu giống chính các logic cấm vận và đủ điều kiện mà các tổ chức thực sự muốn vận hành.
Magic Labs là đội ngũ đứng sau tất cả điều này—cùng nhóm đã xây dựng hạ tầng ví chạy dưới những thứ như Polymarket—vì vậy phần triển khai (execution side) rõ ràng biết mình đang làm gì ở quy mô lớn. Nhưng liệu sự tự tin đó có còn giữ nguyên khi các chính sách trở nên thực sự phức tạp hơn, thời gian tạo bằng chứng, kích thước mạch (circuit size), và tất cả những thứ đó… là điều tôi chưa thấy được đề cập ở đâu cho tới bây giờ.
Không biết ai đã thực sự thử nghiệm điều này với một thứ gần với độ phức tạp của thế giới thực hơn là ví dụ sách giáo khoa “gọn gàng” chưa.