Coi việc triển khai hợp đồng thành công như thể đã hoàn tất phát triển là điều rất dễ bị đánh giá nhầm trên Dusk. Nhìn tiếp theo tài liệu DuskVM của @Dusk , tôi dừng ở mục Forge: nó tạo ra ABI, schema và data driver từ mã Rust có chú thích; hai thứ sau không phải là các tệp “kèm theo”, mà là điểm vào để ứng dụng đọc trạng thái trên chuỗi. Chi tiết này khiến tôi phải đánh giá lại tiến độ phát triển: WASM chạy được chỉ chứng tỏ các quy tắc đã được ghi vào; còn nếu mô tả giao diện và driver đọc không được giao cùng phiên bản, thì frontend, script và indexer vẫn chỉ có thể “đoán” trạng thái trông như thế nào.
Những thứ dễ gây lỗi nhất là việc nâng cấp. Nhóm triển khai hợp đồng mới, nhưng data driver vẫn dùng phiên bản cũ. Giao dịch vẫn thành công bình thường, trong khi số dư, trường hoặc sự kiện hiển thị trên trang có thể đã bị tụt lại. Người dùng sẽ liên tục làm mới, kỹ sư trước tiên kiểm tra node, rồi bộ phận CS lại giải thích “chuỗi không có vấn đề”; nhưng thứ thực sự bị lệch là trạng thái hợp đồng và hợp đồng dùng để đọc. Khởi động lại dịch vụ không giải quyết được tình trạng không nhất quán phiên bản; thường phải xây dựng lại, xác minh lại và để ứng dụng chuyển sang đúng driver tương ứng.
Vì vậy, tôi không coi Forge chỉ là công cụ giúp tiết kiệm thời gian dựng khung. Nó đưa “hợp đồng có thể chạy” và “ứng dụng có thể diễn giải đúng hợp đồng” vào cùng một chuỗi bàn giao; thứ nó giảm bớt là sự suy đoán qua các vai trò, chứ không phải toàn bộ chi phí tích hợp. Với hệ sinh thái $DUSK , phần đáng xem hơn ở giai đoạn sau là liệu dự án mẫu và quy trình phát hành có thể nêu rõ mối quan hệ phiên bản giữa ABI, schema và data driver hay không; nếu bước này bị xem là tùy chọn, thì nhà phát triển vẫn có thể chỉ nhận được một hợp đồng chạy được, nhưng khó có thể dùng một cách đáng tin cậy.#dusk 👻👻👻