Trước đây, tôi chỉ đơn giản chấp nhận rằng một hệ thống thực hiện công việc cũng đồng thời là hệ thống quyết định khi nào công việc được hoàn tất.

Một giao dịch được chạy. Trạng thái thay đổi. Mọi người tiếp tục.
Sau đó tôi dành một khoảng thời gian để xem kiến trúc của Dusk, và tôi buộc phải tách bạch hai ý này.

Dusk có DuskVM và DuskEVM để thực thi. DuskVM chạy trực tiếp các hợp đồng Rust/WASM trên L1, trong khi DuskEVM cung cấp cho ứng dụng một môi trường thực thi EVM. DuskDS nằm phía dưới với cơ chế đồng thuận, tính cuối cùng và khả năng sẵn sàng dữ liệu.

Ban đầu tôi nghĩ rằng điều này chủ yếu để cung cấp cho nhà phát triển hai cách xây dựng.

Nhưng chưa đúng.

Môi trường thực thi có thể xử lý những gì ứng dụng đang cố gắng thực hiện. DuskDS là phần quyết định mạng thực sự sẽ kết toán lên trạng thái nào. Tài liệu của Dusk thể hiện sự tách bạch đó khá rõ ràng, và DuskEVM dù sao vẫn được “kết toán” thông qua DuskDS.

Sự khác biệt này có vẻ hữu ích hơn nhiều khi thứ được chuyển đi là một tài sản được quản lý/quy định chặt chẽ.

Hãy tưởng tượng một giao dịch mua bán tài sản: logic hợp đồng thực thi đúng, nhưng bạn vẫn đang chờ mạng đồng thuận về trạng thái kết quả. Với một trò chơi, điều đó có thể gây khó chịu. Còn với một thị trường tài chính, câu trả lời cho “này đã cuối cùng chưa?” có thể ảnh hưởng đến việc ai là chủ sở hữu tài sản, liệu việc thanh toán đã hoàn tất hay chưa, và người tham gia tiếp theo được phép làm gì.

Vì vậy tôi ngừng nghĩ về sự tách lớp này như một tiện lợi dành cho nhà phát triển.
Nó giống hơn với cách giữ ý nghĩa của “đã được kết toán” nằm ở tầng phía dưới ứng dụng đã tạo ra giao dịch.

Tuy nhiên, sự đánh đổi khá rõ ràng. Việc thực thi có thể vẫn linh hoạt, trong khi tầng kết toán chung đó phải luôn đáng tin cậy cho mọi quy trình được xây dựng trên nền tảng đó. Đây là một điều khó sai hơn rất nhiều.

#dusk $DUSK @Dusk