Khi tôi xem lại @Dusk lần này, điều thực sự khiến tôi dừng lại không phải là công nghệ bảo mật riêng tư, mà là một vấn đề thực tế hơn: sau khi những tài sản như chứng khoán được đưa lên chuỗi, các điều kiện tư cách nhà đầu tư, các hạn chế chuyển nhượng và việc công bố thông tin—liệu chúng có thể được chuyển trực tiếp thành các quy tắc trên chuỗi không?
Mô hình Phoenix của Dusk cho tôi một câu trả lời khá thú vị. Giao dịch có thể ẩn các bên tham gia và số tiền, đồng thời thực hiện công bố có định hướng thông qua viewing key. Với tài sản tài chính, điều này thực dụng hơn nhiều so với việc chỉ theo đuổi kiểu “ai cũng không xem được”, vì cơ quan quản lý thường không cần toàn bộ dữ liệu, mà cần xác minh một dữ liệu cụ thể trong các điều kiện nhất định. Moonlight thì vẫn giữ mô hình tài khoản công khai, còn DuskDS phụ trách thanh toán lớp nền. Hai mô hình này có thể phục vụ các nhu cầu nghiệp vụ khác nhau.
Nhưng tôi cũng nghĩ rằng, ưu điểm lớn nhất của thiết kế này—đồng thời có thể trở thành rào cản hệ sinh thái. DuskVM hướng tới Rust và WASM, phù hợp với các ứng dụng quyền riêng tư gốc và zero-knowledge. DuskEVM lại tương thích với Solidity và các công cụ EVM hiện có. Việc có thêm lựa chọn không nhất thiết đồng nghĩa với việc phát triển sẽ dễ hơn; nếu cuối cùng đội ngũ chủ yếu dùng EVM, thì khác biệt kỹ thuật của bản thân Dusk có thể bị suy giảm. Vấn đề thực tế hơn là chi phí tính toán của bằng chứng zero-knowledge, cũng như yêu cầu của Prover đối với tài nguyên phần cứng, sẽ là bài toán kỹ thuật cần giải quyết để mở rộng ứng dụng ở quy mô lớn.
Ở lớp token, tôi quan tâm nhiều hơn đến nhu cầu sử dụng thực tế của $DUSK , thay vì chỉ nhìn riêng lượng cung. Là một tài sản gốc của mạng, DUSK gắn trực tiếp với các chức năng của mạng như phí giao dịch, thế chấp, v.v. Điều này có nghĩa là cuối cùng nó có thể “gánh” được bao nhiêu giá trị, phần lớn vẫn phụ thuộc vào việc mạng có tiếp tục tăng thêm hoạt động thực sự hay không. Thiết kế cung chính thức áp dụng cơ chế phát hành dài hạn, với giới hạn tổng cung là 1 tỷ token. Với tôi, bản thân bộ số liệu này không phải trọng điểm; điều đáng theo dõi thực sự là liệu lượng sử dụng mạng trong tương lai có khớp được với nhu cầu chức năng mà token cung cấp hay không.
Bây giờ nhìn lại Dusk, điều tôi quan tâm hơn là liệu nó có thể đưa quyền riêng tư, danh tính và các quy tắc đối với tài sản vào đúng quy trình vận hành hằng ngày của nghiệp vụ tài chính hay không. Năng lực kỹ thuật giải quyết câu hỏi “có làm được không”; còn việc ứng dụng thực sự giải quyết “có cần phải làm không”. Với Dusk, điều đáng quan sát nhất phía sau có lẽ không phải là thêm bao nhiêu module kỹ thuật nữa, mà là liệu ngày càng nhiều tài sản thực sự có sẵn sàng ở lại hay không. #dusk
Mô hình Phoenix của Dusk cho tôi một câu trả lời khá thú vị. Giao dịch có thể ẩn các bên tham gia và số tiền, đồng thời thực hiện công bố có định hướng thông qua viewing key. Với tài sản tài chính, điều này thực dụng hơn nhiều so với việc chỉ theo đuổi kiểu “ai cũng không xem được”, vì cơ quan quản lý thường không cần toàn bộ dữ liệu, mà cần xác minh một dữ liệu cụ thể trong các điều kiện nhất định. Moonlight thì vẫn giữ mô hình tài khoản công khai, còn DuskDS phụ trách thanh toán lớp nền. Hai mô hình này có thể phục vụ các nhu cầu nghiệp vụ khác nhau.
Nhưng tôi cũng nghĩ rằng, ưu điểm lớn nhất của thiết kế này—đồng thời có thể trở thành rào cản hệ sinh thái. DuskVM hướng tới Rust và WASM, phù hợp với các ứng dụng quyền riêng tư gốc và zero-knowledge. DuskEVM lại tương thích với Solidity và các công cụ EVM hiện có. Việc có thêm lựa chọn không nhất thiết đồng nghĩa với việc phát triển sẽ dễ hơn; nếu cuối cùng đội ngũ chủ yếu dùng EVM, thì khác biệt kỹ thuật của bản thân Dusk có thể bị suy giảm. Vấn đề thực tế hơn là chi phí tính toán của bằng chứng zero-knowledge, cũng như yêu cầu của Prover đối với tài nguyên phần cứng, sẽ là bài toán kỹ thuật cần giải quyết để mở rộng ứng dụng ở quy mô lớn.
Ở lớp token, tôi quan tâm nhiều hơn đến nhu cầu sử dụng thực tế của $DUSK , thay vì chỉ nhìn riêng lượng cung. Là một tài sản gốc của mạng, DUSK gắn trực tiếp với các chức năng của mạng như phí giao dịch, thế chấp, v.v. Điều này có nghĩa là cuối cùng nó có thể “gánh” được bao nhiêu giá trị, phần lớn vẫn phụ thuộc vào việc mạng có tiếp tục tăng thêm hoạt động thực sự hay không. Thiết kế cung chính thức áp dụng cơ chế phát hành dài hạn, với giới hạn tổng cung là 1 tỷ token. Với tôi, bản thân bộ số liệu này không phải trọng điểm; điều đáng theo dõi thực sự là liệu lượng sử dụng mạng trong tương lai có khớp được với nhu cầu chức năng mà token cung cấp hay không.
Bây giờ nhìn lại Dusk, điều tôi quan tâm hơn là liệu nó có thể đưa quyền riêng tư, danh tính và các quy tắc đối với tài sản vào đúng quy trình vận hành hằng ngày của nghiệp vụ tài chính hay không. Năng lực kỹ thuật giải quyết câu hỏi “có làm được không”; còn việc ứng dụng thực sự giải quyết “có cần phải làm không”. Với Dusk, điều đáng quan sát nhất phía sau có lẽ không phải là thêm bao nhiêu module kỹ thuật nữa, mà là liệu ngày càng nhiều tài sản thực sự có sẵn sàng ở lại hay không. #dusk