Muốn chứng minh mình trong sạch nhưng lại không muốn giao danh sách khách hàng — có cách giải quyết
Điều khó xử nhất khi một tổ chức tham gia cuộc chơi là họ muốn chứng minh mình trong sạch, nhưng lại không muốn giao danh sách khách hàng. Hiện nay về cơ bản có hai cách: một là đưa địa chỉ và lịch sử giao dịch cho công ty phân tích on-chain chấm điểm, chẳng khác nào ngửa hết bài cho bên thứ ba; hai là dùng danh sách trắng Merkle, chỉ có thể chứng minh một địa chỉ nào đó nằm trong tập hợp, chứ không chứng minh được bản thân tập hợp đó trong sạch. Tôi đã thử cách thứ ba trên đường dẫn dữ liệu riêng tư của SXT: đưa danh sách nội bộ và danh sách địa chỉ bị hạn chế công khai vào cùng một bảng, để truy vấn trả về một giá trị Boolean kèm bằng chứng. Bên ngoài chỉ tiết lộ kết luận đó, không tiết lộ bất kỳ bản ghi nào. Cách dùng này có tiềm năng lớn hơn nhiều người nghĩ: có thể áp dụng cho bằng chứng dự trữ, sàng lọc trừng phạt, thậm chí xác minh tài sản của khách hàng có đạt một ngưỡng nào đó hay không — tất cả chỉ đưa ra kết luận có hoặc không. Về mặt kỹ thuật, điều thực sự khó là tính cập nhật: danh sách thay đổi mỗi ngày, nên bằng chứng cũng phải được tạo lại theo, nếu không thì bạn đang chứng minh mình trong sạch từ tuần trước. Tôi từng vấp phải chuyện này một lần: lấy bằng chứng cũ để xác minh danh sách mới, kết quả hợp đồng báo mọi thứ đều ổn. Lúc đó tôi thấy lạnh sống lưng. Sau này tôi học được cách đưa hàm băm phiên bản dữ liệu vào bằng chứng; nếu phiên bản không khớp thì từ chối ngay. Nút thắt không nằm ở mật mã học, mà ở chính danh sách. Ai duy trì danh sách này, cập nhật bao lâu một lần, lịch sử cập nhật có thể được kiểm toán hay không — đó là những vấn đề vận hành; làm sai một loạt thì mọi thứ cũng công cốc. Hơn nữa, hiện vẫn chưa rõ pháp luật có công nhận bằng chứng mật mã hay không; cán bộ tuân thủ thường muốn xem một báo cáo có đóng dấu hơn. So với bằng chứng dự trữ của Chainlink, cách này linh hoạt hơn, có thể chạy SQL tùy ý chứ không chỉ cộng tổng số dư, nhưng đổi lại bạn phải tự gánh khối lượng công việc kỹ thuật để tạo bằng chứng. Tôi cho rằng RWA và các tổ chức lưu ký sẽ là những bên đầu tiên áp dụng con đường này, vì thứ họ thiếu nhất chính là lớp màn che cho phép vừa tự chứng minh vừa không tiết lộ thông tin. Muốn làm sâu hơn thì còn phải kết hợp bằng chứng phạm vi và bằng chứng tổng hợp, chẳng hạn vừa chứng minh tổng mức phơi nhiễm thấp hơn giới hạn, vừa chứng minh không có một đối tác nào vượt giới hạn. Hiện chưa có công cụ sẵn có cho những việc như vậy, nên phải tự ghép lại. Khi lớp này vận hành trơn tru, cách các tổ chức chào bán dịch vụ cũng sẽ thay đổi: từ “chúng tôi kiểm soát rủi ro rất nghiêm ngặt” thành “bạn có thể tự mình xác minh”.#sxt $SXT @SpaceandTime
Điều khó xử nhất khi một tổ chức tham gia cuộc chơi là họ muốn chứng minh mình trong sạch, nhưng lại không muốn giao danh sách khách hàng. Hiện nay về cơ bản có hai cách: một là đưa địa chỉ và lịch sử giao dịch cho công ty phân tích on-chain chấm điểm, chẳng khác nào ngửa hết bài cho bên thứ ba; hai là dùng danh sách trắng Merkle, chỉ có thể chứng minh một địa chỉ nào đó nằm trong tập hợp, chứ không chứng minh được bản thân tập hợp đó trong sạch. Tôi đã thử cách thứ ba trên đường dẫn dữ liệu riêng tư của SXT: đưa danh sách nội bộ và danh sách địa chỉ bị hạn chế công khai vào cùng một bảng, để truy vấn trả về một giá trị Boolean kèm bằng chứng. Bên ngoài chỉ tiết lộ kết luận đó, không tiết lộ bất kỳ bản ghi nào. Cách dùng này có tiềm năng lớn hơn nhiều người nghĩ: có thể áp dụng cho bằng chứng dự trữ, sàng lọc trừng phạt, thậm chí xác minh tài sản của khách hàng có đạt một ngưỡng nào đó hay không — tất cả chỉ đưa ra kết luận có hoặc không. Về mặt kỹ thuật, điều thực sự khó là tính cập nhật: danh sách thay đổi mỗi ngày, nên bằng chứng cũng phải được tạo lại theo, nếu không thì bạn đang chứng minh mình trong sạch từ tuần trước. Tôi từng vấp phải chuyện này một lần: lấy bằng chứng cũ để xác minh danh sách mới, kết quả hợp đồng báo mọi thứ đều ổn. Lúc đó tôi thấy lạnh sống lưng. Sau này tôi học được cách đưa hàm băm phiên bản dữ liệu vào bằng chứng; nếu phiên bản không khớp thì từ chối ngay. Nút thắt không nằm ở mật mã học, mà ở chính danh sách. Ai duy trì danh sách này, cập nhật bao lâu một lần, lịch sử cập nhật có thể được kiểm toán hay không — đó là những vấn đề vận hành; làm sai một loạt thì mọi thứ cũng công cốc. Hơn nữa, hiện vẫn chưa rõ pháp luật có công nhận bằng chứng mật mã hay không; cán bộ tuân thủ thường muốn xem một báo cáo có đóng dấu hơn. So với bằng chứng dự trữ của Chainlink, cách này linh hoạt hơn, có thể chạy SQL tùy ý chứ không chỉ cộng tổng số dư, nhưng đổi lại bạn phải tự gánh khối lượng công việc kỹ thuật để tạo bằng chứng. Tôi cho rằng RWA và các tổ chức lưu ký sẽ là những bên đầu tiên áp dụng con đường này, vì thứ họ thiếu nhất chính là lớp màn che cho phép vừa tự chứng minh vừa không tiết lộ thông tin. Muốn làm sâu hơn thì còn phải kết hợp bằng chứng phạm vi và bằng chứng tổng hợp, chẳng hạn vừa chứng minh tổng mức phơi nhiễm thấp hơn giới hạn, vừa chứng minh không có một đối tác nào vượt giới hạn. Hiện chưa có công cụ sẵn có cho những việc như vậy, nên phải tự ghép lại. Khi lớp này vận hành trơn tru, cách các tổ chức chào bán dịch vụ cũng sẽ thay đổi: từ “chúng tôi kiểm soát rủi ro rất nghiêm ngặt” thành “bạn có thể tự mình xác minh”.#sxt $SXT @SpaceandTime
