Đêm qua, tôi đã xem lại tài liệu Dusk, tập trung vào việc nắm bắt vai trò thực sự $DUSK plays trong giao thức—chức năng kỹ thuật của nó chứ không phải câu chuyện do thị trường dẫn dắt.
Điều đầu tiên tôi phải gỡ rối là hai mô hình giao dịch của DuskDS. Moonlight là lộ trình quen thuộc: tài khoản công khai, số dư hiển thị, người gửi, người nhận, số tiền. Phoenix hoạt động với các “notes” được mã hóa. Để chi tiêu một note, người dùng cung cấp một bằng chứng không kiến thức (zero-knowledge proof) chứng minh rằng quyền sở hữu và các quy tắc về số dư đều được thỏa mãn. Hãy tưởng tượng bạn đưa cho một nhân viên một phong bì được niêm phong, trong đó con dấu chứng minh rằng mọi ô cần thiết đã được kiểm tra, mà không tiết lộ nội dung bên trong. Sau đó, nullifier giúp mạng từ chối một lần chi tiêu thứ hai mà không phải xác định note nào trong cây công khai đã được dùng. Tôi đã đọc lại đoạn đó hai lần—rồi một thông báo kéo tôi ra khỏi nó—bởi vì “riêng tư” không có nghĩa là “không có gì được kiểm tra”. Nó có nghĩa là mạng kiểm tra một bằng chứng thay vì các chi tiết giao dịch bị che giấu. Các viewing key có thể được dùng để tiết lộ thông tin một cách chọn lọc.
Việc đạt đồng thuận cũng cần thêm một lượt xem. Dusk gọi đó là Succinct Attestation (Xác thực gọn nhẹ): các staker, hay provisioners, khóa DUSK; việc chọn proposer theo tỷ trọng stake và xác định trước sẽ xác định người đề xuất một block, sau đó một ủy ban sẽ xác thực và một ủy ban khác phê chuẩn. Các chữ ký gộp lại trở thành một bản attestation rằng một quorum đã đồng ý. Vì vậy $DUSK vừa là gas vừa là phần stake đứng sau sự tham gia.
Phần tôi sẽ xem tiếp theo là mức độ tập trung. Việc chọn người là không cần xin phép, nhưng trong thực tế, mức độ phân tán của các “committee credits” hiệu quả ra sao? Trong những trang tôi đọc, tôi không tìm thấy một bản tường thuật rõ ràng về việc ai thay đổi các tham số toàn cục—có thể tôi đã bỏ sót.
Những bằng chứng nào sẽ cho thấy quyền lực của ủy ban thực sự được phân tán? Các viewing keys được quản trị thế nào trong các triển khai thực tế? Ai có thể thay đổi tham số giao thức, và theo quy trình nào?
#dusk $DUSK @Dusk
Điều đầu tiên tôi phải gỡ rối là hai mô hình giao dịch của DuskDS. Moonlight là lộ trình quen thuộc: tài khoản công khai, số dư hiển thị, người gửi, người nhận, số tiền. Phoenix hoạt động với các “notes” được mã hóa. Để chi tiêu một note, người dùng cung cấp một bằng chứng không kiến thức (zero-knowledge proof) chứng minh rằng quyền sở hữu và các quy tắc về số dư đều được thỏa mãn. Hãy tưởng tượng bạn đưa cho một nhân viên một phong bì được niêm phong, trong đó con dấu chứng minh rằng mọi ô cần thiết đã được kiểm tra, mà không tiết lộ nội dung bên trong. Sau đó, nullifier giúp mạng từ chối một lần chi tiêu thứ hai mà không phải xác định note nào trong cây công khai đã được dùng. Tôi đã đọc lại đoạn đó hai lần—rồi một thông báo kéo tôi ra khỏi nó—bởi vì “riêng tư” không có nghĩa là “không có gì được kiểm tra”. Nó có nghĩa là mạng kiểm tra một bằng chứng thay vì các chi tiết giao dịch bị che giấu. Các viewing key có thể được dùng để tiết lộ thông tin một cách chọn lọc.
Việc đạt đồng thuận cũng cần thêm một lượt xem. Dusk gọi đó là Succinct Attestation (Xác thực gọn nhẹ): các staker, hay provisioners, khóa DUSK; việc chọn proposer theo tỷ trọng stake và xác định trước sẽ xác định người đề xuất một block, sau đó một ủy ban sẽ xác thực và một ủy ban khác phê chuẩn. Các chữ ký gộp lại trở thành một bản attestation rằng một quorum đã đồng ý. Vì vậy $DUSK vừa là gas vừa là phần stake đứng sau sự tham gia.
Phần tôi sẽ xem tiếp theo là mức độ tập trung. Việc chọn người là không cần xin phép, nhưng trong thực tế, mức độ phân tán của các “committee credits” hiệu quả ra sao? Trong những trang tôi đọc, tôi không tìm thấy một bản tường thuật rõ ràng về việc ai thay đổi các tham số toàn cục—có thể tôi đã bỏ sót.
Những bằng chứng nào sẽ cho thấy quyền lực của ủy ban thực sự được phân tán? Các viewing keys được quản trị thế nào trong các triển khai thực tế? Ai có thể thay đổi tham số giao thức, và theo quy trình nào?
#dusk $DUSK @Dusk
