Tôi lại đọc kiến trúc của Dusk và bị mắc kẹt ở chỗ vì sao “settlement” (thanh toán/quyết toán) lại được xem như một công việc tách biệt với “execution” (thực thi).

DuskDS là lớp settlement và nền tảng khả dụng dữ liệu của L1. Nó xử lý đồng thuận và tính cuối cùng, trong khi DuskVM chạy trực tiếp các hợp đồng Rust/WASM trên L1. DuskEVM đi theo hướng khác: cung cấp công cụ Solidity và EVM, nhưng vẫn sử dụng DuskDS cho settlement và khả dụng dữ liệu.

Sự tách bạch đó trở nên hợp lý hơn khi tôi ngừng coi “execution” là toàn bộ giao dịch.

Một hợp đồng có thể tính toán điều gì cần phải xảy ra. Nhưng vẫn phải có ai đó thiết lập rằng trạng thái kết quả bây giờ đã là một phần của chuỗi dùng chung và đã đạt tới tính cuối cùng. Dusk giữ cho những trách nhiệm đó tách biệt, nhưng không biến chúng thành các hệ thống độc lập lơ lửng riêng rẽ.

Điều này đặc biệt liên quan đến hạ tầng tài chính. Một ứng dụng có thể cần môi trường thực thi EVM quen thuộc, nhưng lớp settlement bên dưới vẫn phải cung cấp đồng thuận và tính cuối cùng mà quy trình đó dựa vào. DuskEVM có thể thay đổi môi trường thực thi mà không làm thay đổi nơi xuất phát của lớp settlement đó.

Tuy vậy, vẫn có một phần mà tôi chưa thực sự thấy thoải mái. Sự tách bạch nghe có vẻ gọn gàng về mặt kiến trúc, nhưng đường thực thi và DuskDS vẫn phải vận hành như một hệ thống thống nhất. Thêm mô-đun hơn không đồng nghĩa với việc cần ít phối hợp hơn.

Và tôi vẫn chưa thấy đủ dữ liệu benchmark công khai để nói rằng ràng buộc thực tế xuất hiện đầu tiên ở đâu khi tải được duy trì ở mức cao.

Tôi muốn đo lường một điều trước khi đưa ra các khẳng định lớn hơn: khi việc thực thi của DuskEVM bị đẩy mạnh, thì khối lượng công việc đó thực sự ảnh hưởng như thế nào đến độ trễ settlement và tính cuối cùng trên DuskDS?

#dusk $DUSK @Dusk $PORTAL $GPS