#dusk $DUSK @Dusk Khi đọc sách trắng Dusk, tôi nhận thấy một chi tiết dễ bị bỏ qua: phần mô tả của các hợp đồng khác nhau sử dụng các thì khác nhau.
Mục 6.2 khi mô tả Genesis, Transfer và Stake Contracts chủ yếu đang trình bày các chức năng hiện tại mà chúng đảm nhiệm: chuyển khoản, khấu trừ Gas, staking, v.v. Đây là những phần hạ tầng cần thiết cho việc vận hành mạng Dusk.
Trong khi đó, Mục 6.3 khi giới thiệu Zedger và Citadel lại xuất hiện nhiều cách diễn đạt hướng về tương lai hơn, chẳng hạn như “designed to be deployed” và “will allow”.
Chỉ dựa vào thì ngữ pháp, dĩ nhiên không thể chứng minh rằng một chức năng nào đó “vẫn chưa được triển khai”. Nhưng với tư cách là tín hiệu của tài liệu kỹ thuật, điều đó ít nhất nhắc chúng ta rằng: thiết kế kiến trúc trong sách trắng, các giao thức đã được triển khai, và năng lực sản phẩm hiện có thể sử dụng thực tế không phải là cùng một khái niệm.
Nhìn lại trang web chính thức của Dusk, trạng thái của các sản phẩm khác nhau đã được gắn nhãn là Live, Building và Testnet. Điều này lại cung cấp cho chúng ta một hệ quy chiếu cụ thể hơn: khi thảo luận về một năng lực nào đó, liệu chúng ta có nên phân biệt nó là đã được thiết kế, đã được triển khai, hay đã có thể được xác minh và sử dụng trong thực tế hay không?
Ngày nay, các thảo luận của Dusk về tài chính on-chain có quản lý ngày càng tập trung vào các quy trình đầy đủ như tiếp cận nhà đầu tư, chuyển nhượng có kiểm soát, công bố quyền riêng tư và thanh toán bù trừ.
Vậy vấn đề trở nên cụ thể hơn:
Hiện tại các năng lực như Zedger, XSC, Citadel đang ở giai đoạn nào trong ba giai đoạn “thiết kế, triển khai, sử dụng có thể xác minh”?
Nếu mục tiêu của Dusk là hỗ trợ một thị trường tài chính on-chain có quản lý trong thực tế, thì từ thiết kế trong sách trắng đi đến việc sử dụng trên thị trường thật, đâu là mắt xích then chốt hiện cần được bên ngoài xác minh nhất?#dusk $DUSK @Dusk
Mục 6.2 khi mô tả Genesis, Transfer và Stake Contracts chủ yếu đang trình bày các chức năng hiện tại mà chúng đảm nhiệm: chuyển khoản, khấu trừ Gas, staking, v.v. Đây là những phần hạ tầng cần thiết cho việc vận hành mạng Dusk.
Trong khi đó, Mục 6.3 khi giới thiệu Zedger và Citadel lại xuất hiện nhiều cách diễn đạt hướng về tương lai hơn, chẳng hạn như “designed to be deployed” và “will allow”.
Chỉ dựa vào thì ngữ pháp, dĩ nhiên không thể chứng minh rằng một chức năng nào đó “vẫn chưa được triển khai”. Nhưng với tư cách là tín hiệu của tài liệu kỹ thuật, điều đó ít nhất nhắc chúng ta rằng: thiết kế kiến trúc trong sách trắng, các giao thức đã được triển khai, và năng lực sản phẩm hiện có thể sử dụng thực tế không phải là cùng một khái niệm.
Nhìn lại trang web chính thức của Dusk, trạng thái của các sản phẩm khác nhau đã được gắn nhãn là Live, Building và Testnet. Điều này lại cung cấp cho chúng ta một hệ quy chiếu cụ thể hơn: khi thảo luận về một năng lực nào đó, liệu chúng ta có nên phân biệt nó là đã được thiết kế, đã được triển khai, hay đã có thể được xác minh và sử dụng trong thực tế hay không?
Ngày nay, các thảo luận của Dusk về tài chính on-chain có quản lý ngày càng tập trung vào các quy trình đầy đủ như tiếp cận nhà đầu tư, chuyển nhượng có kiểm soát, công bố quyền riêng tư và thanh toán bù trừ.
Vậy vấn đề trở nên cụ thể hơn:
Hiện tại các năng lực như Zedger, XSC, Citadel đang ở giai đoạn nào trong ba giai đoạn “thiết kế, triển khai, sử dụng có thể xác minh”?
Nếu mục tiêu của Dusk là hỗ trợ một thị trường tài chính on-chain có quản lý trong thực tế, thì từ thiết kế trong sách trắng đi đến việc sử dụng trên thị trường thật, đâu là mắt xích then chốt hiện cần được bên ngoài xác minh nhất?#dusk $DUSK @Dusk
