#dusk $DUSK @Dusk Hôm nay mình đã đi tìm hiểu xem rốt cuộc vì sao lúc chạng vạng (dusk) lại phải chạy hai môi trường thực thi riêng biệt thay vì chỉ chọn một, và thành thật mà nói? 😂 Câu trả lời hoá ra lại là một sự đánh đổi thực sự hơn là một “flex” kỹ thuật.
Vậy thì, duskvm là một môi trường wasm được xây dựng quanh wasmtime, và nó thực thi trực tiếp trên chính dusk L1, không cần bước “settlement hop” như duskevm phải làm thông qua duskds—mình đã viết về điều đó từ trước. Nó được thiết kế cho các hợp đồng Rust muốn tích hợp chặt chẽ với các mô hình giao dịch riêng của dusk, các tài sản ở cấp giao thức, và các khả năng về quyền riêng tư hoặc zk một cách đặc thù. Còn duskevm thì tồn tại thuần tuý cho Solidity và bộ công cụ EVM tiêu chuẩn: foundry, hardhat, các ví hiện có, toàn bộ hệ sinh thái Ethereum mà mọi người đã quen.
Bài viết nội bộ của dusk thì lại đưa ra các con số thực cho thấy vì sao sự tách đôi này lại quan trọng. Theo đó, một tích hợp L1 tuỳ biến, “may đo” có thể mất từ 6 đến 12 tháng và tốn khoảng gấp 50 lần so với một triển khai EVM tương đương. Và họ nêu ví dụ cụ thể: các sàn giao dịch phải mất nhiều tháng để điều chỉnh với dusk native, trong khi tích hợp EVM thì chỉ mất vài tuần.
Điều mình cứ quay lại mãi sau khi đọc các con số đó là liệu “khoảng chênh chi phí” này có âm thầm đẩy gần như toàn bộ dự án đi theo duskevm mặc định, kể cả những dự án về mặt kỹ thuật đáng lẽ sẽ hưởng lợi nhiều hơn từ duskvm với phần tích hợp quyền riêng tư native chặt chẽ hơn. Nếu con đường ít cản trở nhất lại rẻ và nhanh đến vậy, thì lựa chọn khó hơn nhưng được thiết kế đúng mục đích cuối cùng có bị dùng ít đi, bất kể mức độ phù hợp? Mình chưa thấy ai giải quyết trực tiếp sự giằng co này.
Dù sao đi nữa, việc cho các builder hai lối đi thật sự thay vì bắt tất cả mọi người phải đánh đổi theo một mô hình duy nhất lại là một phản hồi hợp lý trước nhu cầu khác nhau một cách thực chất—không chỉ là thêm độ phức tạp vì sự phức tạp.
Thật lòng mình không biết liệu khoảng chênh chi phí đó có thực sự hướng đa số dự án nghiêm túc về duskevm, hay duskvm lại giữ thế chủ động cho đúng những use case cần nó??
🤔
#dusk @Dusk $DUSK
Vậy thì, duskvm là một môi trường wasm được xây dựng quanh wasmtime, và nó thực thi trực tiếp trên chính dusk L1, không cần bước “settlement hop” như duskevm phải làm thông qua duskds—mình đã viết về điều đó từ trước. Nó được thiết kế cho các hợp đồng Rust muốn tích hợp chặt chẽ với các mô hình giao dịch riêng của dusk, các tài sản ở cấp giao thức, và các khả năng về quyền riêng tư hoặc zk một cách đặc thù. Còn duskevm thì tồn tại thuần tuý cho Solidity và bộ công cụ EVM tiêu chuẩn: foundry, hardhat, các ví hiện có, toàn bộ hệ sinh thái Ethereum mà mọi người đã quen.
Bài viết nội bộ của dusk thì lại đưa ra các con số thực cho thấy vì sao sự tách đôi này lại quan trọng. Theo đó, một tích hợp L1 tuỳ biến, “may đo” có thể mất từ 6 đến 12 tháng và tốn khoảng gấp 50 lần so với một triển khai EVM tương đương. Và họ nêu ví dụ cụ thể: các sàn giao dịch phải mất nhiều tháng để điều chỉnh với dusk native, trong khi tích hợp EVM thì chỉ mất vài tuần.
Điều mình cứ quay lại mãi sau khi đọc các con số đó là liệu “khoảng chênh chi phí” này có âm thầm đẩy gần như toàn bộ dự án đi theo duskevm mặc định, kể cả những dự án về mặt kỹ thuật đáng lẽ sẽ hưởng lợi nhiều hơn từ duskvm với phần tích hợp quyền riêng tư native chặt chẽ hơn. Nếu con đường ít cản trở nhất lại rẻ và nhanh đến vậy, thì lựa chọn khó hơn nhưng được thiết kế đúng mục đích cuối cùng có bị dùng ít đi, bất kể mức độ phù hợp? Mình chưa thấy ai giải quyết trực tiếp sự giằng co này.
Dù sao đi nữa, việc cho các builder hai lối đi thật sự thay vì bắt tất cả mọi người phải đánh đổi theo một mô hình duy nhất lại là một phản hồi hợp lý trước nhu cầu khác nhau một cách thực chất—không chỉ là thêm độ phức tạp vì sự phức tạp.
Thật lòng mình không biết liệu khoảng chênh chi phí đó có thực sự hướng đa số dự án nghiêm túc về duskevm, hay duskvm lại giữ thế chủ động cho đúng những use case cần nó??
🤔
#dusk @Dusk $DUSK