Mình từng nghĩ revocation là phần dễ nhất của Sign Protocol: chỉ cần revoke on-chain là xong. Issuance mới là thứ phức tạp: phải verify danh tính, thiết kế schema, build trust.
Nhưng đó là hiểu nhầm nguy hiểm nhất.
Khi một credential bị revoke trên Sign, issuer chỉ làm một việc: ghi một record on-chain rằng credential này không còn hợp lệ. Record đó là immutable, ai cũng đọc được, không thể sửa.
Về mặt kỹ thuật, mọi thứ đều đúng.
Vấn đề nằm ở phần còn lại của hệ thống.
Có bao nhiêu verifier đã kiểm tra credential đó trước khi nó bị revoke? Bao nhiêu trong số đó lưu lại kết quả verification thay vì query lại mỗi lần? Bao nhiêu hệ thống sẽ tự động biết rằng trạng thái đã thay đổi?
Sign không push thông tin này đi. Revocation không phải broadcast. Nó là một pull-based truth — ai muốn biết trạng thái mới nhất thì phải tự đi query, không có ai chủ động thông báo.
Đó là revocation propagation gap: khoảng cách giữa thời điểm credential bị revoke on-chain và thời điểm toàn bộ hệ thống ngừng chấp nhận nó.
Khoảng cách đó không phải lý thuyết.
Hãy hình dung một user đang dùng credential để truy cập hệ thống thanh toán. Credential bị revoke vì fraud, và on-chain record cập nhật ngay lập tức. Nhưng merchant terminal, banking app, hoặc service portal vẫn đang dùng kết quả verification từ trước đó — cache 1 giờ, 1 ngày, hoặc thậm chí vĩnh viễn.
Trong toàn bộ khoảng thời gian đó, hệ thống vẫn vận hành dựa trên một credential đã không còn hợp lệ.
Revocation đã xảy ra trên chain. Nhưng chưa xảy ra trong thực tế.
Đây không phải lỗi của Sign. Đây là giới hạn cấu trúc của mọi hệ thống decentralized: không có central authority để push trạng thái đến tất cả verifier, nên mọi thứ phụ thuộc vào việc verifier có chủ động check lại hay không.
Và nếu không có gì buộc họ phải check, họ sẽ không check.
Hệ thống certificate của internet đã gặp chính vấn đề này. Trình duyệt không chỉ verify một lần rồi tin mãi mãi mà buộc phải check lại trạng thái chứng chỉ trong mỗi kết nối. Không hoàn hảo, nhưng nó thừa nhận một điều quan trọng: revocation chỉ có ý nghĩa khi verifier biết về nó.
Sign hiện chưa có cơ chế tương đương ở tầng protocol. Không có revocation notification. Không có tiêu chuẩn bắt buộc re-verification. Không có gì ngăn một hệ thống cache kết quả verification vô thời hạn.
Với use case nhỏ, đây là inconvenience.
Với sovereign infrastructure như CBDC và national ID, đây là rủi ro hệ thống.
Trong môi trường đó, revocation không phải edge case. Nó là core function: fraud, compliance, policy change đều phụ thuộc vào việc revoke credential đúng lúc và được toàn bộ hệ thống phản ứng đúng lúc.
Nếu propagation không xảy ra kịp thời, hệ thống đang vận hành với thông tin sai — ở quy mô hàng triệu transaction.
Risk control không nằm ở Sign. Nó nằm ở người build trên Sign.
Bất kỳ production system nào có yêu cầu revocation nghiêm ngặt cần tự thiết kế re-verification layer: query lại trạng thái credential trước mỗi hành động quan trọng, đặt thời hạn hiệu lực của kết quả verification rõ ràng cho mọi kết quả verification, và không bao giờ coi một kết quả verify cũ là có hiệu lực vô thời hạn.
Nếu không, bạn đã vô tình biến một credential có thể bị revoke thành credential vĩnh viễn — chỉ vì bạn không kiểm tra lại.
Đó là lý do mình theo dõi Sign không phải qua tốc độ revocation on-chain, mà qua việc liệu họ có build được cơ chế giảm revocation propagation gap hay không.
Revocation on-chain là declaration.
Revocation thật sự là hành vi của verifier.