Em họ tôi điều hành hai xưởng riêng phía sau nhà — một xưởng làm đồ gỗ, một xưởng hàn. Tôi từng hỏi sao anh ấy không xây một cái nhà xưởng chung rồi dùng cho tất cả. Anh ấy nói rằng ngay khi bạn cố gắng làm một không gian có thể xử lý tốt cả hai việc, bạn sẽ phải thỏa hiệp cho cả hai.
Tôi nghĩ lớp triển khai của Dusk sẽ hoạt động giống như đa số các chuỗi mà tôi đã xem — chọn EVM, triển khai là xong. Nhưng giả định đó sụp đổ khi tôi lần ra DuskVM thực sự là gì.
DuskVM chạy trên Wasmtime, thực thi trực tiếp các hợp đồng Rust/WASM trên L1 của Dusk — đây là một môi trường hoàn toàn tách biệt với DuskEVM, không phải một lớp được gắn thêm lên nó. DuskVM tồn tại đặc biệt cho các hợp đồng cần truy cập trực tiếp vào các mô hình giao dịch gốc của Dusk, các tính năng riêng tư và khả năng zero-knowledge — đúng là những thứ mà mô hình thực thi của EVM chưa bao giờ được thiết kế để bộc lộ một cách tự nhiên.
Piecrust, động cơ nằm bên dưới, đã thay thế RuskVM nguyên bản của Dusk — cụ thể là vì RuskVM gặp các giới hạn về tăng trưởng trạng thái và hiệu năng mà Dusk cần được giải quyết trước khi mở rộng việc token hóa các tài sản do quy định quản lý. Các ghi chú kỹ thuật của chính Dusk nêu rằng Piecrust vượt trội RuskVM hơn mười lần — không phải một ước tính, mà là một so sánh trực tiếp, đã được công bố — với các host-function như PLONK, Groth16 và BLS được tích hợp trực tiếp vào runtime.
DuskEVM đảm nhiệm phần còn lại — tương đương EVM đầy đủ, công cụ Solidity tiêu chuẩn, và cơ chế quyết toán thông qua DuskDS cho các nhà phát triển muốn có quy trình quen thuộc mà không cần các nguyên thủ riêng tư “native”.
Thử nghiệm thực sự dành cho DUSK là liệu việc giữ hai môi trường này tách biệt một cách thực sự — thay vì ép các hợp đồng gốc riêng tư qua một mô hình thực thi được xây dựng cho thứ khác — có thực sự mang lại lợi ích khi mức độ áp dụng tăng lên ở cả hai phía hay không.
Việc vận hành hai môi trường chuyên biệt có tốt hơn một môi trường bị thỏa hiệp, hay nó chỉ có nghĩa là gấp đôi công sức bảo trì cho một mức độ rõ ràng chỉ bằng một nửa?
#dusk $DUSK @Dusk
Tôi nghĩ lớp triển khai của Dusk sẽ hoạt động giống như đa số các chuỗi mà tôi đã xem — chọn EVM, triển khai là xong. Nhưng giả định đó sụp đổ khi tôi lần ra DuskVM thực sự là gì.
DuskVM chạy trên Wasmtime, thực thi trực tiếp các hợp đồng Rust/WASM trên L1 của Dusk — đây là một môi trường hoàn toàn tách biệt với DuskEVM, không phải một lớp được gắn thêm lên nó. DuskVM tồn tại đặc biệt cho các hợp đồng cần truy cập trực tiếp vào các mô hình giao dịch gốc của Dusk, các tính năng riêng tư và khả năng zero-knowledge — đúng là những thứ mà mô hình thực thi của EVM chưa bao giờ được thiết kế để bộc lộ một cách tự nhiên.
Piecrust, động cơ nằm bên dưới, đã thay thế RuskVM nguyên bản của Dusk — cụ thể là vì RuskVM gặp các giới hạn về tăng trưởng trạng thái và hiệu năng mà Dusk cần được giải quyết trước khi mở rộng việc token hóa các tài sản do quy định quản lý. Các ghi chú kỹ thuật của chính Dusk nêu rằng Piecrust vượt trội RuskVM hơn mười lần — không phải một ước tính, mà là một so sánh trực tiếp, đã được công bố — với các host-function như PLONK, Groth16 và BLS được tích hợp trực tiếp vào runtime.
DuskEVM đảm nhiệm phần còn lại — tương đương EVM đầy đủ, công cụ Solidity tiêu chuẩn, và cơ chế quyết toán thông qua DuskDS cho các nhà phát triển muốn có quy trình quen thuộc mà không cần các nguyên thủ riêng tư “native”.
Thử nghiệm thực sự dành cho DUSK là liệu việc giữ hai môi trường này tách biệt một cách thực sự — thay vì ép các hợp đồng gốc riêng tư qua một mô hình thực thi được xây dựng cho thứ khác — có thực sự mang lại lợi ích khi mức độ áp dụng tăng lên ở cả hai phía hay không.
Việc vận hành hai môi trường chuyên biệt có tốt hơn một môi trường bị thỏa hiệp, hay nó chỉ có nghĩa là gấp đôi công sức bảo trì cho một mức độ rõ ràng chỉ bằng một nửa?
#dusk $DUSK @Dusk