Tối qua khi lật tài liệu Dusk, tôi mới phát hiện ra mình vẫn cứ hiểu “hỗ trợ EVM” một cách quá đơn giản. Dusk không nhét toàn bộ hợp đồng vào một máy ảo: các ứng dụng quen thuộc với Solidity và Foundry có thể đi theo DuskEVM, thanh toán Gas bằng <@Dusk DUSK>, còn dữ liệu theo lô và cam kết trạng thái thì giao cho DuskDS để quyết toán; nếu cần quyền riêng tư gốc và năng lực zero-knowledge, hoặc các hợp đồng có khả năng kiểm soát tài sản ở cấp giao thức, thì chạy trực tiếp bằng Rust/WASM trên DuskVM.

Tôi đã hiểu nó như hai bàn thao tác do cùng một tổ chức giao dịch mở. Một bàn giữ các nút quen thuộc, giúp di chuyển nhanh hơn; bàn còn lại bám sát tầng kho tiền phía dưới, có thể gọi các quy tắc nguyên bản hơn, và cuối cùng cả hai đều quay về cùng một lớp nền quyết toán để xác nhận sổ cái. Sự cân nhắc này quan trọng hơn bốn chữ “tương thích EVM”, vì nó tách hiệu quả phát triển với năng lực nguyên bản.

Nhưng việc đi theo hai hướng cũng làm tăng độ phức tạp của cầu nối và tương tác xuyên lớp, đồng thời còn phải đánh giá chính xác trạng thái. Tài liệu chính thức nêu rõ ràng rằng việc đóng gói nhanh của DuskEVM không đồng nghĩa với việc đã hoàn tất quyết toán trên DuskDS; tôi sẽ không chỉ dựa vào việc hiển thị thành công trên trang mà cho rằng rốt cuộc đã xong. Sau này còn phải xem trải nghiệm xuyên lớp có mượt không, công cụ đã trưởng thành chưa, và khối lượng hợp đồng thực tế có tăng hay không. Kiến trúc đưa ra lựa chọn—còn việc áp dụng mới cho ra câu trả lời.

#dusk $DUSK