Mình đã xem trực tiếp gói khóa thực sự cho mô hình Phoenix của Dusk, thay vì chỉ đọc các phần giải thích, và có một đoạn struct dừng mình lại: khoan đã — ViewKey không phải là phiên bản nhỏ hơn của spend key. Nó được tạo từ những phần hoàn toàn khác nhau.
Trong code, một SecretKey gồm hai scalar. Một ViewKey gồm một scalar và một point — một cặp cố ý không đầy đủ. Nó không phải là một cờ quyền truy cập được gắn thêm lên cùng bí mật; mà là thiếu đúng thành phần cần thiết để tạo ra một chữ ký spend hợp lệ. $DUSK #dusk @Dusk
Điều thay đổi với mình là nhận ra “quyền truy cập dạng view” ở đây không phải là một cam kết được thực thi bằng chính sách. Nó được thực thi bởi thứ mà khóa chứa về mặt toán học. Đưa cho ai đó một ViewKey thì không thể rò rỉ quyền spend, vì scalar bị thiếu vốn dĩ không hề có trong đó ngay từ đầu. Đó là một ranh giới phơi bày hẹp hơn nhiều so với các tuyên bố “chỉ đọc” trong lĩnh vực này, vốn thường chỉ có nghĩa là “xin đừng”.
Vẫn còn bỏ ngỏ: điều này xác nhận chính kiểu khóa, chứ không phải người cuối cùng cầm nó. Tài liệu mô tả ViewKeys cho phép tiết lộ cho kiểm toán viên và cơ quan quản lý — nhưng ở cấp độ kiểu dữ liệu thì không có gì nói liệu đó có phải là cùng một key mà chủ sở hữu note dùng để quét số dư của chính mình, hay là một đường ủy nhiệm tách biệt được xây dựng riêng cho bên thứ ba. Đáng kiểm tra xem quá trình bàn giao đó thực sự vận hành ra sao.
---