Once DuskEVM existed, Dusk Network could have made a simpler pitch: one execution environment, Solidity for everyone, done. Instead the documentation is explicit that native Dusk development, meaning Rust contracts compiled to WASM and executed by DuskVM, remains the recommended path whenever an application needs protocol-level control, custom transaction models, or zero-knowledge capabilities that sit close to the base layer. I find that an interesting decision to defend, because maintaining two execution paths is more expensive to build and to explain than maintaining one.

Logic có vẻ là DuskEVM và DuskVM được tối ưu cho những nhóm khách hàng khác nhau thay vì cạnh tranh cùng một nhóm. Một nhóm chuyển một giao thức DeFi Ethereum hiện có muốn có công cụ quen thuộc, các bản kiểm toán sẵn có, và các ví đã hoạt động—đó là điều mà DuskEVM được tạo ra. Một nhóm xây dựng logic thanh toán chứng khoán với các giao dịch bị giới hạn chuyển nhượng, phân phối cổ tức hoặc các quy tắc tuân thủ được nhúng trực tiếp vào một hợp đồng lại gần với những gì Zedger và các hợp đồng native DuskVM được thiết kế ngay từ đầu, vì mô hình giao dịch lai này đã được tạo riêng cho đúng kiểu sổ sách token chứng khoán như vậy thay vì được “chắp vá” từ một khuôn mẫu chung rồi mới điều chỉnh sau.

Tôi chưa thật sự thuyết phục rằng cách tiếp cận hai nhánh này có thể tránh được việc làm phân mảnh nền tảng nhà phát triển và nỗ lực tài liệu của Dusk Network của chính họ giữa hai đối tượng thay vì tập trung phía sau một hướng. Hai môi trường thực thi đồng nghĩa với hai bộ công cụ cần duy trì, hai mô hình tư duy cho người đóng góp mới, và hai câu trả lời cho câu hỏi đơn giản về việc ứng dụng mới thực sự nên được xây dựng ở đâu. Tôi hiểu canh bạc này, vì nếu chỉ chọn một hướng ngay từ sớm thì sẽ âm thầm loại bỏ đối tượng nào đó bị rơi ra ngoài. Liệu Dusk Network có đủ lớn để hỗ trợ đúng cách cả hai hướng trong vài năm tới hay không là điều đáng theo dõi.

#dusk $DUSK @Dusk