Nói về quyền riêng tư, phần lớn mọi người chỉ hỏi một câu hỏi: có giấu được không. Trong bối cảnh tài chính, lại cần hỏi thêm một câu: đưa cho ai xem.
Hai câu hỏi này, whitepaper của Dusk đã đồng thời trả lời bằng một bộ thiết kế khóa.
Người dùng của giao thức Phoenix có trong tay hai bộ khóa. Một bộ là khóa riêng đầy đủ: có thể nhận tiền cũng như chi tiền; bộ còn lại gọi là khóa xem (view key), nó chỉ làm được đúng một việc: quét toàn mạng, tìm ra các giao dịch được gửi cho bạn, giải mã để biết số tiền và bên đối tác. Có thể xem sổ sách, nhưng không thể chi tiền. Quyền hạn của chiếc khóa này dừng lại ở đây.
Đừng coi nhẹ “dừng lại ở đây” — đó chính là nền tảng kỹ thuật của việc tiết lộ có chọn lọc. Whitepaper viết rõ mô hình ủy quyền: bạn có thể giao khóa xem cho bên thứ ba; bên đó thay bạn quét, xem sổ sách, nhưng không có khóa riêng đầy đủ nên không thể động đến bất kỳ đồng nào của bạn; thậm chí các tác vụ nặng như tạo bằng chứng cũng có thể ủy quyền ký ra thông qua chữ ký ủy quyền, mà tính toàn vẹn của giao dịch không bị ảnh hưởng.
Dịch ra bối cảnh tài chính: khi một tổ chức làm kiểm toán, hãy giao khóa xem cho bên kiểm toán; bên kiểm toán thấy được những gì cần thấy, nhưng không thể mang đi bất kỳ tài sản nào. Khi cơ quan quản lý cần đối chiếu lại, việc ủy quyền được cấp theo nhu cầu, và quyền được cấp chính xác đến mức “chỉ được xem”.
Trong whitepaper, cấu trúc note cũng giấu phần tinh xảo này: số tiền là một cam kết; các trường mã hóa chỉ có thể được mở bằng khóa xem của bên nhận; dữ liệu toàn mạng được xác thực là cam kết và bằng chứng, còn chi tiết chỉ được mở cho người nắm giữ khóa.
Sau đó, Dusk đã thương mại hóa logic này thành Citadel: mô hình về danh tính, chứng cứ và tiết lộ có chọn lọc — chính là hạ tầng “ai được xem gì” dành cho tổ chức.
Những khó khăn của tiết lộ có chọn lọc chưa bao giờ nằm ở việc mã hóa có đủ mạnh hay không, mà nằm ở chỗ làm thật chi tiết mức độ ủy quyền: xem sổ sách là một khóa, chi tiền là một khóa khác; còn khóa được giao cho kiểm toán thì vĩnh viễn không mở được cánh cửa tài chính.@Dusk #dusk $DUSK
Hai câu hỏi này, whitepaper của Dusk đã đồng thời trả lời bằng một bộ thiết kế khóa.
Người dùng của giao thức Phoenix có trong tay hai bộ khóa. Một bộ là khóa riêng đầy đủ: có thể nhận tiền cũng như chi tiền; bộ còn lại gọi là khóa xem (view key), nó chỉ làm được đúng một việc: quét toàn mạng, tìm ra các giao dịch được gửi cho bạn, giải mã để biết số tiền và bên đối tác. Có thể xem sổ sách, nhưng không thể chi tiền. Quyền hạn của chiếc khóa này dừng lại ở đây.
Đừng coi nhẹ “dừng lại ở đây” — đó chính là nền tảng kỹ thuật của việc tiết lộ có chọn lọc. Whitepaper viết rõ mô hình ủy quyền: bạn có thể giao khóa xem cho bên thứ ba; bên đó thay bạn quét, xem sổ sách, nhưng không có khóa riêng đầy đủ nên không thể động đến bất kỳ đồng nào của bạn; thậm chí các tác vụ nặng như tạo bằng chứng cũng có thể ủy quyền ký ra thông qua chữ ký ủy quyền, mà tính toàn vẹn của giao dịch không bị ảnh hưởng.
Dịch ra bối cảnh tài chính: khi một tổ chức làm kiểm toán, hãy giao khóa xem cho bên kiểm toán; bên kiểm toán thấy được những gì cần thấy, nhưng không thể mang đi bất kỳ tài sản nào. Khi cơ quan quản lý cần đối chiếu lại, việc ủy quyền được cấp theo nhu cầu, và quyền được cấp chính xác đến mức “chỉ được xem”.
Trong whitepaper, cấu trúc note cũng giấu phần tinh xảo này: số tiền là một cam kết; các trường mã hóa chỉ có thể được mở bằng khóa xem của bên nhận; dữ liệu toàn mạng được xác thực là cam kết và bằng chứng, còn chi tiết chỉ được mở cho người nắm giữ khóa.
Sau đó, Dusk đã thương mại hóa logic này thành Citadel: mô hình về danh tính, chứng cứ và tiết lộ có chọn lọc — chính là hạ tầng “ai được xem gì” dành cho tổ chức.
Những khó khăn của tiết lộ có chọn lọc chưa bao giờ nằm ở việc mã hóa có đủ mạnh hay không, mà nằm ở chỗ làm thật chi tiết mức độ ủy quyền: xem sổ sách là một khóa, chi tiền là một khóa khác; còn khóa được giao cho kiểm toán thì vĩnh viễn không mở được cánh cửa tài chính.@Dusk #dusk $DUSK