Trong mấy ngày nay lại lần nữa lần theo cấu trúc giao dịch của Phoenix. Lần này thì mình tách hẳn một giao dịch ra, xem rốt cuộc những thứ nào có thể nhìn thấy trên chuỗi, và những thứ nào thì không thể nhìn thấy
━━━━━━━━━━━━━━
▎note trong đó rốt cuộc chứa gì
Phoenix là mô hình UTXO, mỗi đơn vị tài sản trên chuỗi được gọi là một “note”. Một note gói ba thứ: một cam kết về số tiền (không phải con số hiển thị rõ ràng, mà là giá trị cam kết đã được mã hoá), một hệ số làm mù (nói thẳng là một “muối” ngẫu nhiên được cộng vào để ngăn ai đó suy đoán số tiền dựa trên va chạm), và một số ngẫu nhiên dùng một lần để đảm bảo mỗi note là duy nhất, không trùng với bất kỳ note nào khác
Ba thứ này ghép lại với nhau, thì trên chuỗi người ta chỉ thấy một mớ dữ liệu mã hoá; cụ thể đã chuyển bao nhiêu tiền, và note này rốt cuộc trị giá bao nhiêu, người ngoài hoàn toàn không thể biết. Nhưng mạng vẫn có thể kiểm chứng rằng các cam kết cộng lại cân bằng thu chi, không cần giải mã bất kỳ con số cụ thể nào
━━━━━━━━━━━━━━
▎Chống double-spend dựa trên nullifier
Một điểm mình thấy khá hay ở thiết kế này là: nó không dựa vào việc “xoá các note cũ” để ngăn chi tiêu lặp lại, mà dựa vào việc công khai một chứng từ tiêu dùng không thể liên kết trở lại note gốc
Khi tiêu hết một note, sẽ tạo ra một nullifier tương ứng. Thứ này được tính ra theo cách xác định (deterministic), nhưng người ngoài nhìn vào nó thì hoàn toàn không thể suy ngược nullifier đó thuộc note nào. Mạng chỉ cần theo dõi “nullifier này đã từng xuất hiện chưa”; nếu đã xuất hiện thì nghĩa là note tương ứng đã bị tiêu rồi. Nếu cùng một note muốn chi tiêu lần thứ hai, nó sẽ tạo ra cùng một nullifier, dẫn tới va chạm với bản ghi đã có—hệ thống lập tức từ chối
Toàn bộ quá trình không hề lộ “ai đã chi tiêu cái gì”; chỉ cần kiểm tra va chạm là xong
━━━━━━━━━━━━━━
▎Băm Poseidon, làm nền cho toàn bộ trạng thái riêng tư
Trạng thái riêng tư phải được lưu trong một cây Merkle để dùng cho bằng chứng thành viên (chứng minh “note này thực sự tồn tại trong cây trạng thái”)
Đưa hàm băm thông thường vào mạch zk để tính sẽ tốn kém rất lớn. Poseidon là thuật toán băm được thiết kế riêng cho zk; cấu trúc của nó khớp hơn với hệ thống chứng minh, nhờ đó giảm đáng kể chi phí tính băm trong mạch. Nếu không có loại băm thân thiện với zk này, việc tạo bằng chứng cho cây trạng thái riêng tư sẽ chậm đến mức không thể dùng
@Dusk_Foundation $DUSK #dusk
Trong giao dịch Phoenix, cơ chế nào có thể ngăn tài sản ẩn bị double-spend?