Tối qua tôi xem lại tài liệu về Dusk và nhận ra mình quan tâm nhiều hơn đến các câu hỏi thiết kế hơn là các tuyên bố kỹ thuật.

Điều đầu tiên khiến tôi chú ý là sự tách biệt giữa Moonlight và Phoenix. Moonlight dựa trên tài khoản, với khóa công khai, nonce và số dư, trong khi Phoenix sử dụng UTXO như “ghi chú” (notes) bên trong một cây Merkle. Các trường giao dịch của Moonlight bao gồm from, to, value, nonce, deposit, data, gas_limit, gas_price và signature, với lượng gas tối đa được tính là gas_limit × gas_price.

Phoenix mới thật sự thú vị. Nó dùng đường cong Jubjub, với khóa công khai (A,B), khóa bí mật (a,b) và khóa xem (a,B). Cấu trúc ghi chú bao gồm type, com, enc, npk, R và encsender. Khóa ghi chú dùng một lần được suy ra như npk = H(rA)G + B, còn khóa chi tiêu là nsk = H(aR) + b.

Tôi vẫn đang cố gắng hiểu ranh giới tin cậy xung quanh việc tạo bằng chứng ZK và quét được ủy quyền (delegated scanning). Tài liệu nói rằng bên thứ ba có thể tạo bằng chứng hoặc quét bằng view keys mà không cần có quyền chi tiêu, nhưng các điểm thất bại nằm ở đâu?

Và với nullifiers, các Merkle roots gần đây, cùng việc gas được xử lý bên trong bằng chứng, cơ chế này vận hành ra sao khi mạng gặp điều kiện đối kháng? Những phần nào được phi tập trung, và người dùng nên soi xét những giả định nào?

#dusk $DUSK @Dusk