Trước đây tôi nghĩ rằng, trên một public chain, thêm vài môi trường thực thi nữa cùng lắm cũng chỉ là cho nhà phát triển thêm một con đường. Nhưng sau khi bóc tách kiến trúc của @Dusk , tôi nhận ra mối quan hệ giữa DuskVM và DuskEVM không hề đơn giản như vậy; chúng giống như hai bộ cửa ngõ phục vụ cho những nhu cầu khác nhau hơn.$DUSK
DuskVM chạy trực tiếp trên Dusk L1, sử dụng Rust/WASM, phù hợp để gọi tài sản nguyên sinh, quyền riêng tư và năng lực ZK; còn DuskEVM thì giống như một cây cầu di chuyển, giúp các nhà phát triển Solidity tiếp tục dùng ví, framework và công cụ kiểm thử quen thuộc. Cuối cùng, kết quả của cả hai bên đều được giao cho DuskDS phụ trách quyết toán.#dusk
Điều đó có nghĩa là vai trò của DuskEVM không chỉ là hạ thấp ngưỡng chuyển đổi. Ví dụ, một ứng dụng tài chính thông thường muốn tích hợp trước chuỗi công cụ EVM đã trưởng thành có thể bắt đầu từ DuskEVM; nhưng nếu làm chứng khoán bảo mật, chuyển nhượng tài sản có kiểm soát, hoặc cần gọi năng lực bí mật nguyên sinh của Dusk, thì không thể chỉ dừng ở lớp EVM, nhiều logic vẫn phải dựa vào DuskVM.
Vấn đề cũng vì thế mà xuất hiện. Giả sử một ứng dụng vừa cần hợp đồng Solidity, vừa cần xử lý tài sản riêng tư nguyên sinh của Dusk, thì trạng thái cốt lõi nên đặt ở đâu? Hai môi trường này đồng bộ với nhau như thế nào? Ai sẽ xác thực các lời gọi xuyên lớp? Một khi xảy ra lỗi, nhà phát triển cần truy vết là lỗi hợp đồng, lỗi môi trường thực thi hay lỗi lớp quyết toán?$BTC
Vì vậy, hiện giờ khi nhìn vào đa môi trường thực thi của Dusk, tôi sẽ không chỉ hiểu nó là một ưu thế về khả năng tương thích. Một mặt, nó giúp nhiều nhà phát triển có thể đi vào hệ sinh thái; mặt khác, nó cũng đẩy bài toán thiết kế hệ thống về phía đội ngũ phát triển. Điều thực sự đáng quan sát không phải là Dusk cung cấp bao nhiêu kiểu thực thi, mà là các môi trường đó có thể tạo ra ranh giới rõ ràng hay không, để nhà phát triển bớt phải đánh đổi vô ích, thay vì vì muốn đồng thời gọi nhiều năng lực khác nhau mà khiến kiến trúc ứng dụng ngày càng chồng chất phức tạp.$ETH
DuskVM chạy trực tiếp trên Dusk L1, sử dụng Rust/WASM, phù hợp để gọi tài sản nguyên sinh, quyền riêng tư và năng lực ZK; còn DuskEVM thì giống như một cây cầu di chuyển, giúp các nhà phát triển Solidity tiếp tục dùng ví, framework và công cụ kiểm thử quen thuộc. Cuối cùng, kết quả của cả hai bên đều được giao cho DuskDS phụ trách quyết toán.#dusk
Điều đó có nghĩa là vai trò của DuskEVM không chỉ là hạ thấp ngưỡng chuyển đổi. Ví dụ, một ứng dụng tài chính thông thường muốn tích hợp trước chuỗi công cụ EVM đã trưởng thành có thể bắt đầu từ DuskEVM; nhưng nếu làm chứng khoán bảo mật, chuyển nhượng tài sản có kiểm soát, hoặc cần gọi năng lực bí mật nguyên sinh của Dusk, thì không thể chỉ dừng ở lớp EVM, nhiều logic vẫn phải dựa vào DuskVM.
Vấn đề cũng vì thế mà xuất hiện. Giả sử một ứng dụng vừa cần hợp đồng Solidity, vừa cần xử lý tài sản riêng tư nguyên sinh của Dusk, thì trạng thái cốt lõi nên đặt ở đâu? Hai môi trường này đồng bộ với nhau như thế nào? Ai sẽ xác thực các lời gọi xuyên lớp? Một khi xảy ra lỗi, nhà phát triển cần truy vết là lỗi hợp đồng, lỗi môi trường thực thi hay lỗi lớp quyết toán?$BTC
Vì vậy, hiện giờ khi nhìn vào đa môi trường thực thi của Dusk, tôi sẽ không chỉ hiểu nó là một ưu thế về khả năng tương thích. Một mặt, nó giúp nhiều nhà phát triển có thể đi vào hệ sinh thái; mặt khác, nó cũng đẩy bài toán thiết kế hệ thống về phía đội ngũ phát triển. Điều thực sự đáng quan sát không phải là Dusk cung cấp bao nhiêu kiểu thực thi, mà là các môi trường đó có thể tạo ra ranh giới rõ ràng hay không, để nhà phát triển bớt phải đánh đổi vô ích, thay vì vì muốn đồng thời gọi nhiều năng lực khác nhau mà khiến kiến trúc ứng dụng ngày càng chồng chất phức tạp.$ETH