Tôi bắt đầu xem xét “private state” của DUSK theo một thước đo sai trước: tổng số ghi chú được tạo. Nghe thì có vẻ là câu chuyện lưu trữ hiển nhiên, nhưng nó chỉ vẽ ra một đường cong. @Dusk
Cây ghi chú phát triển khi các output được tạo. Tập nullifier phát triển khi các ghi chú được tiêu thụ (spent). Chúng có liên quan, nhưng không phải cùng một hành vi.
Hãy lấy 100M ghi chú Phoenix, trong đó đã có 60M được tiêu thụ. DUSK vẫn mang lịch sử của các ghi chú đã được tạo, trong khi phía nullifier đã đạt 60M mục. Nếu cuối cùng 70% được tiêu thụ, điều đó sẽ trở thành 70M nullifier. Ở mức 1B ghi chú và 750M nullifier, câu hỏi trở nên khó chịu hơn: cấu trúc nào trở thành gánh nặng trạng thái (state burden) lâu dài nặng hơn?
Một giao dịch 4-in/1-out làm điều này rõ hơn. Số ghi chú “live” giảm đi ba net, nhưng lại có bốn nullifier mới được thêm vào. Số lượng live-note giảm không đồng nghĩa với việc lịch sử state giảm.
Một mức tăng trưởng là bình thường. Hệ thống private cần cam kết (commitments) và cơ chế bảo vệ ghi chú đã spent.
Thử thách thực sự là liệu DUSK có thể giữ cho cả hai đường cong đều hiệu quả khi mức sử dụng tăng dần không. Có thể cắt tỉa (pruning), lập chỉ mục (indexing), chi phí tạo proof và chi phí đồng bộ (sync) vẫn nằm trong tầm kiểm soát không? Hay quyền riêng tư (privacy) sẽ dần trở thành một loại “thuế hạ tầng”?
Đối với hoạt động của DUSK thì thước đo khó khăn không phải là vấn đề. Kỷ luật về state mới là vấn đề.
#dusk $DUSK
Cây ghi chú phát triển khi các output được tạo. Tập nullifier phát triển khi các ghi chú được tiêu thụ (spent). Chúng có liên quan, nhưng không phải cùng một hành vi.
Hãy lấy 100M ghi chú Phoenix, trong đó đã có 60M được tiêu thụ. DUSK vẫn mang lịch sử của các ghi chú đã được tạo, trong khi phía nullifier đã đạt 60M mục. Nếu cuối cùng 70% được tiêu thụ, điều đó sẽ trở thành 70M nullifier. Ở mức 1B ghi chú và 750M nullifier, câu hỏi trở nên khó chịu hơn: cấu trúc nào trở thành gánh nặng trạng thái (state burden) lâu dài nặng hơn?
Một giao dịch 4-in/1-out làm điều này rõ hơn. Số ghi chú “live” giảm đi ba net, nhưng lại có bốn nullifier mới được thêm vào. Số lượng live-note giảm không đồng nghĩa với việc lịch sử state giảm.
Một mức tăng trưởng là bình thường. Hệ thống private cần cam kết (commitments) và cơ chế bảo vệ ghi chú đã spent.
Thử thách thực sự là liệu DUSK có thể giữ cho cả hai đường cong đều hiệu quả khi mức sử dụng tăng dần không. Có thể cắt tỉa (pruning), lập chỉ mục (indexing), chi phí tạo proof và chi phí đồng bộ (sync) vẫn nằm trong tầm kiểm soát không? Hay quyền riêng tư (privacy) sẽ dần trở thành một loại “thuế hạ tầng”?
Đối với hoạt động của DUSK thì thước đo khó khăn không phải là vấn đề. Kỷ luật về state mới là vấn đề.
#dusk $DUSK
