Tôi đã đào sâu hơn vào @Dusk và hai lộ trình thực thi của nó—DuskEVM cho Solidity và DuskVM cho các hợp đồng gốc viết bằng Rust/WASM.

Thiết kế kỹ thuật có vẻ hợp lý. Nhưng điều thực sự khiến tôi dừng lại là hành vi của nhà phát triển mà nó có thể tạo ra.

Tôi không còn chỉ xem tài liệu nữa, mà bắt đầu nghĩ về điều mà các nhà phát triển thực sự sẽ chọn.

DuskEVM quen thuộc, với bộ công cụ EVM mà các nhà phát triển đã biết. DuskVM đi sâu hơn vào thời gian chạy thông qua Forge: xử lý phần soạn sẵn, các WASM exports và các data driver, trong khi trạng thái hợp đồng nằm trực tiếp trong bộ nhớ tuyến tính và được tuần tự hóa bằng rkyv.

Khoan đã—điều đó tạo ra một mâu thuẫn thú vị.

DuskVM có thể mang lại một môi trường thực thi gốc hơn và tiềm năng có độ trễ thấp hơn, nhưng DuskEVM vẫn có thể là lựa chọn hiển nhiên chỉ vì nó dễ xây dựng hơn.

Khoảng trống đó là thứ tôi thấy thú vị hơn chính bản thân kiến trúc Rust/WASM.

Tôi không nói rằng DuskVM bị lỗi ở đây. Mô hình thực thi gốc đang làm đúng chính những gì nó được thiết kế để làm.

Câu hỏi thực sự là liệu lợi thế kỹ thuật có đủ mạnh để thay đổi hành vi của nhà phát triển hay không.

Nó gợi cho tôi nhớ đến việc chọn giữa một công cụ quen thuộc giúp bạn hoàn thành công việc và một công cụ chuyên biệt hơn cho bạn quyền kiểm soát sâu hơn—nhưng lại yêu cầu bạn phải học một quy trình làm việc mới trước.

Nếu các nhà phát triển vẫn tiếp tục chọn DuskEVM, thì DuskVM có trở thành một môi trường thực thi mạnh về mặt kỹ thuật nhưng chỉ là ngách?

Hay việc triển khai bản gốc cuối cùng có thể trở thành một tín hiệu có ý nghĩa về #Dusk ’s giá trị tiện ích sâu hơn của mạng?
$DUSK $KII $AKE
#RedditToJoinSP500 #US30YBondAuctionYieldHighestSince2001 #GlobalStocksNearRecordHighs #ProCapFilesBitcoinTreasuryDiscountETF