Lợi thế thực sự của mô hình thực thi kép của Dusk không phải là khả năng tương thích EVM. Đó là một lựa chọn kiến trúc.
@Dusk tách biệt phần thanh toán (settlement) khỏi phần thực thi: DuskVM chạy trực tiếp các hợp đồng Rust/WASM trên Dusk L1, trong khi DuskEVM cung cấp khả năng thực thi tương thích EVM với phần thanh toán và tính sẵn có dữ liệu thông qua DuskDS.
Hệ quả sâu xa hơn là các nhà phát triển có thể lựa chọn nơi đặt logic ứng dụng thay vì bắt mọi khối công việc phải dồn vào chỉ một mô hình thực thi.
Nếu một hợp đồng cần truy cập trực tiếp L1 vào các mô hình giao dịch của Dusk, các khả năng về quyền riêng tư hoặc zero-knowledge, thì DuskVM là con đường gốc. Nếu ưu tiên là Solidity, các ví hiện có và công cụ hệ sinh thái Ethereum, thì DuskEVM làm giảm rào cản di chuyển. Dusk trình bày rõ ràng hai con đường như các lựa chọn dựa trên yêu cầu của ứng dụng.
Nhưng sự linh hoạt đó đặt ra một câu hỏi kiến trúc mà tôi thấy còn thú vị hơn cả khả năng tương thích:
Quy tắc bất biến (invariant) nên nằm ở đâu?
Theo quan điểm của tôi, các quy tắc chỉ gắn với một môi trường thực thi duy nhất có thể được giữ lại ngay trong môi trường đó. Những quy tắc trải qua nhiều nhánh thực thi hoặc phụ thuộc vào phần thanh toán cần có quyền sở hữu rõ ràng và ranh giới phối hợp (coordination) cụ thể.
Sự phân biệt này quan trọng vì các lớp của Dusk không thể thay thế cho nhau. DuskDS cung cấp sự đồng thuận (consensus), tính cuối cùng (finality), thanh toán (settlement) và tính sẵn có dữ liệu, trong khi DuskVM và DuskEVM cung cấp các môi trường thực thi khác nhau.
Cây cầu (bridge) làm cho ranh giới trở nên cụ thể. Trong luồng rút tiền (withdrawal) của DuskEVM Testnet đã được tài liệu hóa, lệnh rút được khởi tạo trên DuskEVM, sau đó được chứng minh và hoàn tất trên Dusk L1. Vì vậy, quy trình này vượt qua các lớp thực thi thay vì vận hành như một thao tác đơn khối.
Điểm rút ra của tôi là tính mô-đun không chỉ đơn giản là giảm độ phức tạp. Nó cho phép nhà phát triển quyết định độ phức tạp nên “sống” ở đâu.
Đối với các ứng dụng tài chính, đó có thể là một lợi thế kiến trúc đáng kể: giữ logic đặc thù cho từng môi trường thực thi ở cục bộ, đồng thời xem các quy tắc xuyên lớp (Cross-layer) như những ràng buộc kiến trúc rõ ràng.
Những quy tắc nào nên ở lại trong một môi trường thực thi, và những quy tắc nào đủ quan trọng để được thực thi xuyên suốt kiến trúc?
$DUSK #dusk
@Dusk tách biệt phần thanh toán (settlement) khỏi phần thực thi: DuskVM chạy trực tiếp các hợp đồng Rust/WASM trên Dusk L1, trong khi DuskEVM cung cấp khả năng thực thi tương thích EVM với phần thanh toán và tính sẵn có dữ liệu thông qua DuskDS.
Hệ quả sâu xa hơn là các nhà phát triển có thể lựa chọn nơi đặt logic ứng dụng thay vì bắt mọi khối công việc phải dồn vào chỉ một mô hình thực thi.
Nếu một hợp đồng cần truy cập trực tiếp L1 vào các mô hình giao dịch của Dusk, các khả năng về quyền riêng tư hoặc zero-knowledge, thì DuskVM là con đường gốc. Nếu ưu tiên là Solidity, các ví hiện có và công cụ hệ sinh thái Ethereum, thì DuskEVM làm giảm rào cản di chuyển. Dusk trình bày rõ ràng hai con đường như các lựa chọn dựa trên yêu cầu của ứng dụng.
Nhưng sự linh hoạt đó đặt ra một câu hỏi kiến trúc mà tôi thấy còn thú vị hơn cả khả năng tương thích:
Quy tắc bất biến (invariant) nên nằm ở đâu?
Theo quan điểm của tôi, các quy tắc chỉ gắn với một môi trường thực thi duy nhất có thể được giữ lại ngay trong môi trường đó. Những quy tắc trải qua nhiều nhánh thực thi hoặc phụ thuộc vào phần thanh toán cần có quyền sở hữu rõ ràng và ranh giới phối hợp (coordination) cụ thể.
Sự phân biệt này quan trọng vì các lớp của Dusk không thể thay thế cho nhau. DuskDS cung cấp sự đồng thuận (consensus), tính cuối cùng (finality), thanh toán (settlement) và tính sẵn có dữ liệu, trong khi DuskVM và DuskEVM cung cấp các môi trường thực thi khác nhau.
Cây cầu (bridge) làm cho ranh giới trở nên cụ thể. Trong luồng rút tiền (withdrawal) của DuskEVM Testnet đã được tài liệu hóa, lệnh rút được khởi tạo trên DuskEVM, sau đó được chứng minh và hoàn tất trên Dusk L1. Vì vậy, quy trình này vượt qua các lớp thực thi thay vì vận hành như một thao tác đơn khối.
Điểm rút ra của tôi là tính mô-đun không chỉ đơn giản là giảm độ phức tạp. Nó cho phép nhà phát triển quyết định độ phức tạp nên “sống” ở đâu.
Đối với các ứng dụng tài chính, đó có thể là một lợi thế kiến trúc đáng kể: giữ logic đặc thù cho từng môi trường thực thi ở cục bộ, đồng thời xem các quy tắc xuyên lớp (Cross-layer) như những ràng buộc kiến trúc rõ ràng.
Những quy tắc nào nên ở lại trong một môi trường thực thi, và những quy tắc nào đủ quan trọng để được thực thi xuyên suốt kiến trúc?
$DUSK #dusk
