#dusk $DUSK
Tuần này tôi đã xem qua cấu trúc khóa của Phoenix vì muốn hiểu chính xác khóa xem (view key) thực sự mang lại cho ai đó điều gì — và nó khác gì so với việc chỉ đơn thuần trao quyền truy cập.
Khóa xem của Phoenix: tài liệu whitepaper định nghĩa khóa xem là (a, B) — một bí mật cục bộ cho phép bên thứ ba quét mạng để xác định những giao dịch nào được gửi đến bạn. Họ có thể thấy các giao dịch đang đến. Họ không thể tính ra khóa bí mật của note, nên họ không thể chi tiêu bất cứ thứ gì. Quét mà không chi tiêu.
Việc tạo bằng chứng ZK có thể được ủy quyền riêng biệt. Một giao dịch yêu cầu một bằng chứng không kiến thức (zero-knowledge proof). Việc tạo bằng chứng này tốn tính toán, có thể ủy quyền cho một bên đáng tin cậy thông qua chữ ký, mà không cần cấp cho họ quyền truy cập vào toàn bộ khóa riêng của bạn. Tính toàn vẹn của giao dịch không bị ảnh hưởng vì chữ ký ràng buộc giao dịch với khóa của bạn ngay cả khi bằng chứng được tạo ở nơi khác.
Phần đó vững chắc. Có hai mức ủy quyền, tách bạch rõ ràng: một cho kiểu truy cập để kiểm toán, một cho việc chuyển tải tính toán.
Điều khó để suy luận hơn là chi phí riêng tư của từng mức. Bên được ủy quyền khóa xem biết giao dịch nào là của bạn. "Không thể chi tiêu" không có nghĩa là "không biết gì" — mà có nghĩa họ có thể dựng nên bức tranh về toàn bộ lịch sử nhận của bạn. Với một tình huống tuân thủ (compliance), có thể chính xác đó là điều cần thiết. Với người dùng cá nhân, việc giao khóa xem cho một dịch vụ là sự tiết lộ đáng kể, ngay cả khi không có tiền nào được chuyển đi.
Tôi thật sự nghĩ rằng việc ủy quyền tạo bằng chứng sạch hơn về mặt riêng tư — bên tạo bằng chứng sẽ không biết gì về nội dung giao dịch nếu giao thức được cấu trúc đúng. Khóa xem mới là thứ mang thông tin thật sự.
Điều tôi chưa xác định được là các use case kiểm toán của Phoenix có sử dụng trực tiếp khóa xem hay không, hay tồn tại cơ chế tiết lộ có chọn lọc để chỉ những giao dịch cụ thể được tiết lộ thay vì toàn bộ lịch sử nhận. @Dusk
$DUSK #dusk
Tuần này tôi đã xem qua cấu trúc khóa của Phoenix vì muốn hiểu chính xác khóa xem (view key) thực sự mang lại cho ai đó điều gì — và nó khác gì so với việc chỉ đơn thuần trao quyền truy cập.
Khóa xem của Phoenix: tài liệu whitepaper định nghĩa khóa xem là (a, B) — một bí mật cục bộ cho phép bên thứ ba quét mạng để xác định những giao dịch nào được gửi đến bạn. Họ có thể thấy các giao dịch đang đến. Họ không thể tính ra khóa bí mật của note, nên họ không thể chi tiêu bất cứ thứ gì. Quét mà không chi tiêu.
Việc tạo bằng chứng ZK có thể được ủy quyền riêng biệt. Một giao dịch yêu cầu một bằng chứng không kiến thức (zero-knowledge proof). Việc tạo bằng chứng này tốn tính toán, có thể ủy quyền cho một bên đáng tin cậy thông qua chữ ký, mà không cần cấp cho họ quyền truy cập vào toàn bộ khóa riêng của bạn. Tính toàn vẹn của giao dịch không bị ảnh hưởng vì chữ ký ràng buộc giao dịch với khóa của bạn ngay cả khi bằng chứng được tạo ở nơi khác.
Phần đó vững chắc. Có hai mức ủy quyền, tách bạch rõ ràng: một cho kiểu truy cập để kiểm toán, một cho việc chuyển tải tính toán.
Điều khó để suy luận hơn là chi phí riêng tư của từng mức. Bên được ủy quyền khóa xem biết giao dịch nào là của bạn. "Không thể chi tiêu" không có nghĩa là "không biết gì" — mà có nghĩa họ có thể dựng nên bức tranh về toàn bộ lịch sử nhận của bạn. Với một tình huống tuân thủ (compliance), có thể chính xác đó là điều cần thiết. Với người dùng cá nhân, việc giao khóa xem cho một dịch vụ là sự tiết lộ đáng kể, ngay cả khi không có tiền nào được chuyển đi.
Tôi thật sự nghĩ rằng việc ủy quyền tạo bằng chứng sạch hơn về mặt riêng tư — bên tạo bằng chứng sẽ không biết gì về nội dung giao dịch nếu giao thức được cấu trúc đúng. Khóa xem mới là thứ mang thông tin thật sự.
Điều tôi chưa xác định được là các use case kiểm toán của Phoenix có sử dụng trực tiếp khóa xem hay không, hay tồn tại cơ chế tiết lộ có chọn lọc để chỉ những giao dịch cụ thể được tiết lộ thay vì toàn bộ lịch sử nhận. @Dusk
$DUSK #dusk