Tuần trước, tôi cứ mắc ở một câu hỏi nhỏ về proof trong crypto.
Trước khi hỏi proof có verify được không, làm sao biết đó vẫn là đúng proof ban đầu?
Vài ngày sau, đọc phần zkTLS Twitter/X Example trong docs của Newton Protocol, tôi dừng lại ở chi tiết proofCid.
Ban đầu, tôi nghĩ CID chỉ là một địa chỉ lưu proof.
Một zkTLS proof được tạo ra. Client store proof đó. Gateway trả về proofCid. Sau đó task dùng CID này để operators biết phải lấy proof nào khi chạy policy evaluation.
Nhìn qua thì giống một bước lưu file khá bình thường.
Nhưng càng đọc kỹ, tôi càng thấy @NewtonProtocol không chỉ đang hỏi proof nằm ở đâu.
Nó đang hỏi nội dung phía sau địa chỉ đó có đúng là proof mà client đã tạo ra hay không.
Đó là điểm làm CID khác một URL thông thường.
URL thường nói nội dung có thể được tìm ở đâu.
CID nói một điều mạnh hơn: nội dung này có hash như thế nào.
Nếu nội dung đổi, CID cũng phải đổi. Vì vậy, một proofCid không chỉ là pointer. Nó là một cam kết về bytes phía sau pointer đó.
Nhưng trong authorization flow, chỉ nhận một CID từ Gateway rồi tin luôn vẫn chưa đủ.
Newton’s example không dừng ở việc nhận proofCid. Khi retrieve proof bytes, client verify rằng bytes trả về khớp với CID multihash. Sau khi store(), SDK còn re-derive CID từ chính bytes đã gửi và reject nếu Gateway response không match.
Chi tiết này nhỏ, nhưng nó mở ra một boundary rất quan trọng.
Newton không để proofCid trở thành một lời hứa từ Gateway.
Nó bắt lời hứa đó quay lại đối chiếu với bytes thật.
Client vì vậy không outsource hoàn toàn niềm tin vào Gateway hay storage layer khi evidence được đưa vào authorization path. Nó kiểm tra lại, không phải bằng cảm giác tin tưởng, mà bằng việc đối chiếu CID với chính nội dung.
Đây là phần tôi thấy hay.
Một zkTLS proof có thể đúng. Một policy có thể được viết đúng. Một task có thể nhìn hợp lệ. Nhưng nếu handoff giữa proof creation và policy evaluation bị lệch, nếu proofCid trỏ tới bytes khác với proof ban đầu, thì hệ thống đang evaluate trên sai evidence.
Lỗi lúc đó không nằm ở cryptography của proof.
Nó nằm ở ranh giới lưu trữ evidence.
Newton Protocol dường như đang cố chặn lỗi đó ngay ở client boundary. Trước khi proof được đưa vào task, trước khi operators dùng nó, trước khi policy dựa vào nó, client phải chắc rằng địa chỉ và nội dung thật sự khớp nhau.
Nhìn theo góc đó, CID Integrity Boundary không phải là chuyện lưu proof cho tiện.
Nó là cách giữ cho evidence không bị tráo trong đoạn đường từ lúc được tạo ra tới lúc được dùng để authorize.
Tất nhiên, CID integrity không giải quyết mọi thứ.
Nó không chứng minh claim trong proof là tốt. Nó không thay thế policy. Nó cũng không đảm bảo data source bên ngoài luôn đáng tin.
Nhưng nó bảo vệ một đoạn rất cụ thể: proof được lưu, lấy lại, và truyền vào task mà không bị đổi nội dung phía sau địa chỉ.
Với tôi, đây là một chi tiết nhỏ nhưng đáng chú ý trong Newton.
Authorization không chỉ cần đúng rule.
Nó còn cần đúng evidence.
Và trước khi evidence được tin, hệ thống phải chắc rằng evidence đó thật sự là thứ user/client đã tạo ra.
Có lẽ proofCid không nên được xem như một link tới proof.
Nó nên được xem như lời hứa rằng proof phía sau link đó chưa bị tráo.