Sau khi xem lại Dusk, ngược lại tôi bắt đầu chú ý đến một vấn đề ít khi được thảo luận: “quyền thực thi” trên chuỗi rốt cuộc nên đặt ở đâu?
Gần đây khi nghiên cứu @Dusk , tôi nhận ra mình ngày càng ít tập trung vào một chức năng đơn lẻ, mà bắt đầu xem một blockchain công khai về tài chính thì năng lực thực thi được phân bổ như thế nào.
Hiện tại, Dusk không phải là nhét mọi thứ vào một môi trường thực thi duy nhất. DuskEVM chịu trách nhiệm cho Solidity, Vyper và các công cụ quen thuộc của EVM; còn DuskVM chạy trực tiếp trên Dusk L1, dành cho các hợp đồng Rust/WASM, và có thể tương tác với tài sản cấp giao thức, mô hình giao dịch gốc, các năng lực về quyền riêng tư và ZK; còn lớp nền DuskDS sẽ phụ trách đồng thuận, thanh toán và tính sẵn có của dữ liệu. Tài liệu chính thức viết khá rõ ràng về sự phân công này.
Tôi nghĩ có một sự khác biệt dễ bị bỏ qua ở đây: EVM tương thích giải quyết bài toán “làm sao để mời được nhà phát triển vào”, còn môi trường thực thi gốc thì giải quyết “những việc nhất định phải gắn với L1 để làm cho thật tốt”.
Với các ứng dụng DeFi thông thường, công cụ EVM là đủ tiện; nhưng nếu bản thân ứng dụng liên quan đến giao dịch riêng tư, tài sản chịu quản lý hoặc cần gọi trực tiếp năng lực gốc của Dusk, thì việc xử lý mọi thứ theo đúng khuôn mẫu EVM truyền thống có thể lại hạn chế thiết kế của giao thức.
Đây cũng là một lăng kính mới để tôi hiểu lại Dusk. Nó không chỉ đơn thuần theo đuổi “tương thích được nhiều hơn”, mà đang cố gắng đặt các vị trí thực thi khác nhau cho các kiểu ứng dụng khác nhau, đồng thời để kết quả cuối cùng quay về cùng một lớp thanh toán.
Rồi nhìn $DUSK , bản thân nó vừa đảm nhiệm vai trò Gas vừa đảm nhiệm vai trò staking, nên việc thực thi giao dịch và an toàn mạng vì thế chia sẻ cùng một tài sản kinh tế.
Tất nhiên, kiến trúc này có thể thực sự thể hiện giá trị hay không còn tùy thuộc việc nhà phát triển có sẵn sàng rời khỏi lối đi thuần EVM để đổi lấy năng lực bản địa hay không, và các ứng dụng tài chính thực sự cuối cùng sẽ chọn cách thực thi nào.
Vì vậy hiện tại, thứ tôi muốn quan sát không phải là Dusk “có EVM hay không”, mà là liệu nó có thể chứng minh được một điều: trong các bối cảnh tài chính phức tạp, bản thân môi trường thực thi cũng có thể trở thành một phần của thiết kế giao thức. #dusk $DUSK @Dusk
Gần đây khi nghiên cứu @Dusk , tôi nhận ra mình ngày càng ít tập trung vào một chức năng đơn lẻ, mà bắt đầu xem một blockchain công khai về tài chính thì năng lực thực thi được phân bổ như thế nào.
Hiện tại, Dusk không phải là nhét mọi thứ vào một môi trường thực thi duy nhất. DuskEVM chịu trách nhiệm cho Solidity, Vyper và các công cụ quen thuộc của EVM; còn DuskVM chạy trực tiếp trên Dusk L1, dành cho các hợp đồng Rust/WASM, và có thể tương tác với tài sản cấp giao thức, mô hình giao dịch gốc, các năng lực về quyền riêng tư và ZK; còn lớp nền DuskDS sẽ phụ trách đồng thuận, thanh toán và tính sẵn có của dữ liệu. Tài liệu chính thức viết khá rõ ràng về sự phân công này.
Tôi nghĩ có một sự khác biệt dễ bị bỏ qua ở đây: EVM tương thích giải quyết bài toán “làm sao để mời được nhà phát triển vào”, còn môi trường thực thi gốc thì giải quyết “những việc nhất định phải gắn với L1 để làm cho thật tốt”.
Với các ứng dụng DeFi thông thường, công cụ EVM là đủ tiện; nhưng nếu bản thân ứng dụng liên quan đến giao dịch riêng tư, tài sản chịu quản lý hoặc cần gọi trực tiếp năng lực gốc của Dusk, thì việc xử lý mọi thứ theo đúng khuôn mẫu EVM truyền thống có thể lại hạn chế thiết kế của giao thức.
Đây cũng là một lăng kính mới để tôi hiểu lại Dusk. Nó không chỉ đơn thuần theo đuổi “tương thích được nhiều hơn”, mà đang cố gắng đặt các vị trí thực thi khác nhau cho các kiểu ứng dụng khác nhau, đồng thời để kết quả cuối cùng quay về cùng một lớp thanh toán.
Rồi nhìn $DUSK , bản thân nó vừa đảm nhiệm vai trò Gas vừa đảm nhiệm vai trò staking, nên việc thực thi giao dịch và an toàn mạng vì thế chia sẻ cùng một tài sản kinh tế.
Tất nhiên, kiến trúc này có thể thực sự thể hiện giá trị hay không còn tùy thuộc việc nhà phát triển có sẵn sàng rời khỏi lối đi thuần EVM để đổi lấy năng lực bản địa hay không, và các ứng dụng tài chính thực sự cuối cùng sẽ chọn cách thực thi nào.
Vì vậy hiện tại, thứ tôi muốn quan sát không phải là Dusk “có EVM hay không”, mà là liệu nó có thể chứng minh được một điều: trong các bối cảnh tài chính phức tạp, bản thân môi trường thực thi cũng có thể trở thành một phần của thiết kế giao thức. #dusk $DUSK @Dusk