Khi tôi đối chiếu tài liệu phát triển mới nhất của @Dusk , tôi mới tách ra một hiểu lầm phổ biến: DuskEVM và DuskVM không phải là cùng một máy ảo nhưng đổi tên, cũng không phải là “EVM mới làm phế bỏ chuỗi gốc”. Tài liệu dành cho nhà phát triển đưa ra hai lối thực thi—những ứng dụng quen thuộc với Solidity, Foundry, Hardhat đi theo DuskEVM; còn những logic cần trực tiếp chạm vào tài sản L1, Phoenix/Moonlight, Rust/WASM hoặc năng lực về zero-knowledge thì đi theo DuskVM.

DuskEVM là lộ trình OP Stack: việc thực thi và công cụ cố gắng bám sát hệ sinh thái Ethereum, sau đó chuyển phần quyết toán và công bố dữ liệu cho DuskDS, còn $DUSK vẫn tiếp tục đóng vai trò như gas. DuskVM thì chạy trực tiếp hợp đồng WASM trên L1, gần hơn với mô hình giao dịch gốc và năng lực giao thức. Cái trước là để giảm chi phí di chuyển; cái sau là để giữ khả năng khác biệt—một cái giải bài toán “nhà phát triển có đến hay không”, cái còn lại giải bài toán “đến rồi có thể làm được những việc mà EVM thông thường làm không sạch hay không”.

Nhưng hai lối đi cũng tạo ra những chi phí mới. Việc tài sản bắc qua các lớp thế nào, cùng một nghiệp vụ thì đặt trạng thái ở bên nào, và ứng dụng EVM kết nối ra sao với quy trình mật của Hedger—tất cả đều không tự động hoàn thành chỉ vì ghi “modular”. Hướng dẫn cầu bắc lớp chéo của DuskEVM hiện tại từ phía chính thức mới thể hiện rõ quy trình của testnet; phần rút tiền còn phải trải qua ba lần hành động on-chain: khởi tạo, chứng minh và xác nhận cuối cùng—không thể vẽ kiến trúc thành trải nghiệm mainnet “không ma sát” từ trước.

Nếu chấm điểm theo lộ trình nhiều lớp của #dusk , tôi sẽ không chỉ đếm xem có bao nhiêu ngôn ngữ được hỗ trợ, mà sẽ theo sát việc ứng dụng thực sự rơi vào lớp nào, cách khôi phục khi lỗi xảy ra ở nhịp cross-layer, và tính năng bảo mật liệu có thể được nhà phát triển gọi trực tiếp hay không. Chuỗi mới nên bắt đầu bằng việc dùng EVM để đổi lấy tốc độ hệ sinh thái, hay nên trước tiên giữ trọn vẹn tính toàn vẹn của công nghệ gốc?