Mình từng tư vấn cho một startup ở Đức muốn dùng Sign Protocol để lưu attestation KYC — bản ghi xác minh danh tính được lưu trên blockchain. Câu hỏi đầu tiên của luật sư họ khiến mình dừng lại khá lâu: nếu người dùng yêu cầu xóa dữ liệu theo GDPR, Sign có thể đáp ứng không? Mình không có câu trả lời.

Năm 2014, Mario Costeja González thắng kiện Google tại Tòa án Công lý Châu Âu. Google buộc phải xóa thông tin về ông khỏi kết quả tìm kiếm. Kể từ đó, right to be forgotten trở thành luật thực thi ở EU. GDPR Article 17 mở rộng quyền này: bất kỳ ai cũng có thể yêu cầu xóa dữ liệu cá nhân nếu dữ liệu không còn cần thiết cho mục đích ban đầu.

Sign Protocol đang build một thứ trực tiếp đối lập với nguyên tắc đó. Không phải vì Sign thiếu suy nghĩ. Mà vì bất biến là tính năng cốt lõi của kiến trúc. Một attestation được ghi lên chain là không thể xóa. Đây chính xác là thứ khách hàng Sign trả tiền để có.

Vấn đề bắt đầu khi Sign ký hợp đồng với các tổ chức trong jurisdiction có GDPR. Họ đang build hạ tầng mà về mặt kỹ thuật không thể tuân thủ một yêu cầu pháp lý có thể xuất hiện bất cứ lúc nào.

Đây là "erasure immunity conflict". Hệ thống được thiết kế để không thể xóa đang hoạt động trong môi trường pháp lý bắt buộc phải xóa thông tin.

Sign có một số giải pháp kỹ thuật. ZK selective disclosure cho phép người dùng chứng minh một thuộc tính mà không lộ dữ liệu gốc. Nếu dữ liệu nhạy cảm chỉ ghi hash hoặc commitment thì về lý thuyết không có gì để xóa cả.

Nhưng vấn đề không nằm ở lý thuyết. Khi developer vô tình ghi trực tiếp dữ liệu cá nhân lên chain — điều này đã xảy ra, không phải giả thuyết — không ai có cơ chế xóa record đó. Sign không thể xóa. Developer không thể xóa. Người dùng bị ảnh hưởng vẫn có quyền yêu cầu xóa theo GDPR.

Ai chịu trách nhiệm pháp lý? Theo GDPR, data controller — tổ chức quyết định mục đích và cách xử lý dữ liệu — phải chịu trách nhiệm tuân thủ right to erasure. Nếu một startup dùng Sign lưu attestation chứa dữ liệu cá nhân của người dùng EU, startup đó là data controller. Nhưng họ đang dùng một hệ thống mà về cấu trúc không thể xóa dữ liệu.

Khi phải chọn giữa tuân thủ GDPR và giữ nguyên tính toàn vẹn blockchain, một trong hai phải thua. 

Đây không phải lỗi của Sign. Đây là collision giữa hai hệ thống được thiết kế với giả định căn bản trái ngược nhau. Blockchain assume dữ liệu phải tồn tại mãi mãi để đáng tin, trong khi luật bảo vệ dữ liệu assume ngược lại: dữ liệu phải có thể xóa để hợp pháp. Sign đang build ở giao điểm đó mà chưa có câu trả lời công khai cho erasure immunity conflict này.

Điều này không ngăn Sign triển khai ở các jurisdiction không có GDPR. Kyrgyzstan, Sierra Leone, UAE đều nằm ngoài phạm vi áp dụng trực tiếp. Nhưng khi Sign mở rộng sang EU, hoặc khi các dự án build trên Sign phục vụ người dùng EU, erasure immunity conflict trở thành vấn đề pháp lý thật.

Ai build trên Sign cho EU users cần đảm bảo một điều trước khi có bất kỳ dispute nào: không ghi dữ liệu cá nhân trực tiếp on-chain, chỉ ghi hash hoặc commitment, và document rõ ràng trong kiến trúc hệ thống. Đây không phải best practice. Đây là điều kiện tối thiểu để không rơi vào erasure immunity conflict với tư cách data controller vi phạm GDPR.

Đó cũng là lý do mình theo dõi Sign không chỉ qua số lượng deployment, mà qua cách họ address erasure immunity conflict trong các jurisdiction có right to erasure.

Bất biến là tính năng. Cho đến khi luật yêu cầu nó không được là tính năng nữa.

@SignOfficial $SIGN #SignDigitalSovereignInfra