#dusk $DUSK Khi dịch tài liệu kiến trúc của @Dusk , tôi phát hiện một lựa chọn thiết kế dễ bị lướt qua trong một câu: DuskDS làm khâu quyết toán và tính sẵn dữ liệu, còn DuskEVM làm khâu thực thi. Tách riêng quyết toán và thực thi không phải là muốn tách là tách tùy tiện; phía sau là cả một hệ thống các đánh đổi về “nhanh” và “an toàn”.
Đặt thiết kế này vào ngữ cảnh của OP Stack thì sẽ thấy rõ. DuskEVM là môi trường thực thi; hợp đồng Solidity chạy ở phía EVM, còn mọi tiêu hao Gas trong tương tác của người dùng và các thay đổi trạng thái đều diễn ra ở lớp này. Nhưng DuskDS mới là lớp quyết toán thực sự—đầu ra phía EVM cần được gửi lên L1, qua xác thực, chờ proof maturity và cửa sổ dispute-game, cuối cùng mới đạt được tính cuối cùng theo nghĩa của giao thức. Thực thi nhanh thì quy về EVM, còn an toàn cuối cùng thì quy về L1.
Chi phí của kiến trúc này cũng rất trực quan: thao tác xuyên lớp cần phải chờ. Việc rút/tách vốn phải trải qua ba bước: đề xuất đầu ra (output proposal), nộp bằng chứng (proof submission) và finalize; mỗi bước đều có cửa sổ thời gian, không phải là “một cú là xong”. Hiện tại, kiến trúc này vẫn đang chạy trên mạng testnet, sử dụng loại token thử nghiệm không có giá trị thực. Việc quy trình chạy thông suốt chỉ chứng minh đường đi của giao thức là khả thi; không suy ra được ngày ra mắt mainnet, cũng không suy ra được độ ổn định của output proposal và finalize trong điều kiện tải cao.
Vì vậy, tôi giữ thái độ thận trọng với nhãn “tương thích EVM”. Thứ đáng được kiểm chứng thực sự không phải là Solidity có chạy được hay không, mà là thời gian thực tế cho việc thoát/thoát vốn qua các lớp, đường đi khôi phục sau khi thất bại, và hiệu năng của kiến trúc tách lớp này dưới tải cao sau khi các tham số mainnet được công bố. Việc tách lớp thực thi và lớp quyết toán về mặt lời nói là mô-đun hóa, nhưng khoản “trải nghiệm người dùng” cuối cùng sẽ do sản phẩm phải gánh. #dusk @Dusk