#dusk $DUSK
Trong vài ngày qua, tôi lại xem lại tài liệu kiến trúc của @Dusk lần nữa, và hóa ra có một vấn đề trước đó tôi đã nghĩ đơn giản hơn mức cần thiết.
Cuối cùng DuskEVM cũng sẽ quay về settlement của DuskDS, vậy tại sao vẫn phải giữ riêng DuskVM?
Ban đầu tôi tưởng là do khác ngôn ngữ phát triển: một là Solidity, một là Rust/WASM.
Nhưng đọc tiếp thì khác biệt thực ra nằm ở đường đi khi thực thi.
DuskVM chạy trực tiếp trên L1.
Còn DuskEVM thì không. Giao dịch đi qua sequencer trước, sau đó thực thi ở lớp EVM; tiếp theo còn có batch, state commitment, rồi mới kết nối lại với DuskDS.
Vì vậy, dù cuối cùng có rơi vào cùng một settlement layer, thì những thứ diễn ra ở giữa hoàn toàn khác nhau.
Tôi nghĩ sự khác biệt này rất quan trọng.
Nếu đã có sẵn một sản phẩm dùng Solidity, và muốn chuyển sang ít phải sửa code nhất có thể, thì DuskEVM là hợp lý. Công cụ và thói quen phát triển cơ bản đều đã quen.
Nhưng nếu bản thân ứng dụng vốn đã cần đụng trực tiếp tới L1, hoặc cần dùng khả năng thực thi native của Dusk và logic ở cấp độ giao thức, thì việc cố gắng “vòng” qua lớp EVM có thể không thực sự cần thiết.
Thế nên hiện tại tôi đã không còn quá băn khoăn DuskEVM và DuskVM cái nào “cao cấp hơn”.
Nó giống như hai con đường.
Một con đường dành cho những nhà phát triển EVM hiện có, để họ dễ bước vào.
Con đường còn lại dành cho những người ngay từ đầu đã muốn dùng trực tiếp năng lực Dusk-native.
Cuối cùng chúng đều có thể kết nối tới DuskDS, nhưng execution path thì không giống nhau.
Đây cũng là điều tôi thấy kiến trúc của Dusk đáng được nghiên cứu hơn so với “một L1 khác tương thích với EVM”.
Trong vài ngày qua, tôi lại xem lại tài liệu kiến trúc của @Dusk lần nữa, và hóa ra có một vấn đề trước đó tôi đã nghĩ đơn giản hơn mức cần thiết.
Cuối cùng DuskEVM cũng sẽ quay về settlement của DuskDS, vậy tại sao vẫn phải giữ riêng DuskVM?
Ban đầu tôi tưởng là do khác ngôn ngữ phát triển: một là Solidity, một là Rust/WASM.
Nhưng đọc tiếp thì khác biệt thực ra nằm ở đường đi khi thực thi.
DuskVM chạy trực tiếp trên L1.
Còn DuskEVM thì không. Giao dịch đi qua sequencer trước, sau đó thực thi ở lớp EVM; tiếp theo còn có batch, state commitment, rồi mới kết nối lại với DuskDS.
Vì vậy, dù cuối cùng có rơi vào cùng một settlement layer, thì những thứ diễn ra ở giữa hoàn toàn khác nhau.
Tôi nghĩ sự khác biệt này rất quan trọng.
Nếu đã có sẵn một sản phẩm dùng Solidity, và muốn chuyển sang ít phải sửa code nhất có thể, thì DuskEVM là hợp lý. Công cụ và thói quen phát triển cơ bản đều đã quen.
Nhưng nếu bản thân ứng dụng vốn đã cần đụng trực tiếp tới L1, hoặc cần dùng khả năng thực thi native của Dusk và logic ở cấp độ giao thức, thì việc cố gắng “vòng” qua lớp EVM có thể không thực sự cần thiết.
Thế nên hiện tại tôi đã không còn quá băn khoăn DuskEVM và DuskVM cái nào “cao cấp hơn”.
Nó giống như hai con đường.
Một con đường dành cho những nhà phát triển EVM hiện có, để họ dễ bước vào.
Con đường còn lại dành cho những người ngay từ đầu đã muốn dùng trực tiếp năng lực Dusk-native.
Cuối cùng chúng đều có thể kết nối tới DuskDS, nhưng execution path thì không giống nhau.
Đây cũng là điều tôi thấy kiến trúc của Dusk đáng được nghiên cứu hơn so với “một L1 khác tương thích với EVM”.