KHÔNG CỨ “TƯƠNG THÍCH EVM” LÀ CÓ NGHĨA “GIÁM SÁT EVM” LÀ ĐỦ.
Một chi tiết trong luồng cầu (bridge flow) của @Dusk đã khiến tôi suy nghĩ lại “tương thích EVM” thực sự đảm bảo điều gì.
Một lệnh rút bắt đầu trên DuskEVM.
Nhưng nó không kết thúc ở đó.
Người dùng khởi tạo ở phía EVM, sau đó lệnh rút phải được chứng minh và hoàn tất trên Dusk L1. Sự sẵn sàng phụ thuộc vào trạng thái đã được công bố, độ trưởng thành của bằng chứng và các kiểm tra tranh chấp — không chỉ đơn thuần vào việc đã trôi qua bao nhiêu thời gian.
Điều đó tạo ra một vấn đề mà tôi thấy thú vị hơn cả tốc độ cầu:
khả năng tương thích thực thi ≠ khả năng hiển thị vận hành.
Một đội ngũ có thể mang theo Solidity, các ví EVM, công cụ RPC và thói quen giám sát mà họ đã quen.
Nhờ vậy việc phát triển dễ hơn.
Nhưng nó cũng có thể tạo ra một giả định nguy hiểm: nếu giao dịch EVM trông có vẻ đã hoàn tất, thì hành động kinh tế cũng phải đã hoàn tất.
Đối với lệnh rút qua nhiều lớp (cross-layer), đó không nhất thiết là trạng thái quan trọng.
Phía EVM có thể cho bạn biết hành động bắt đầu ở đâu.
Phía Dusk vẫn quyết định khi nào lệnh rút thực sự sẵn sàng để chứng minh và hoàn tất.
Vì vậy, câu hỏi tôi sẽ hỏi một sàn giao dịch hoặc đội hạ tầng không phải là:
“Ngăn xếp EVM hiện tại của bạn có thể nhìn thấy DuskEVM không?”
Mà là:
Ngăn xếp đó có thể cho bạn biết khi nào một hành động xuyên lớp thực sự đã xong mà không cần bổ sung giám sát trạng thái riêng cho Dusk không?
Nếu câu trả lời là không, thì DuskEVM tạo ra một sự đánh đổi thú vị.
Tương thích giúp giảm chi phí chuyển đổi của nhà phát triển trong khi có thể che giấu một yêu cầu quan sát (observability) mới bên dưới lớp công cụ quen thuộc.
Đó là phần tôi sẽ theo dõi khi các ứng dụng thực sự bắt đầu xuất hiện.
Khoảng trống tương thích nguy hiểm nhất có lẽ là khoảng trống trông “đủ tương thích” đến mức không ai nghĩ đến việc phải giám sát theo cách khác.
#dusk $DUSK @Dusk
$ZEC
$ENA
Một chi tiết trong luồng cầu (bridge flow) của @Dusk đã khiến tôi suy nghĩ lại “tương thích EVM” thực sự đảm bảo điều gì.
Một lệnh rút bắt đầu trên DuskEVM.
Nhưng nó không kết thúc ở đó.
Người dùng khởi tạo ở phía EVM, sau đó lệnh rút phải được chứng minh và hoàn tất trên Dusk L1. Sự sẵn sàng phụ thuộc vào trạng thái đã được công bố, độ trưởng thành của bằng chứng và các kiểm tra tranh chấp — không chỉ đơn thuần vào việc đã trôi qua bao nhiêu thời gian.
Điều đó tạo ra một vấn đề mà tôi thấy thú vị hơn cả tốc độ cầu:
khả năng tương thích thực thi ≠ khả năng hiển thị vận hành.
Một đội ngũ có thể mang theo Solidity, các ví EVM, công cụ RPC và thói quen giám sát mà họ đã quen.
Nhờ vậy việc phát triển dễ hơn.
Nhưng nó cũng có thể tạo ra một giả định nguy hiểm: nếu giao dịch EVM trông có vẻ đã hoàn tất, thì hành động kinh tế cũng phải đã hoàn tất.
Đối với lệnh rút qua nhiều lớp (cross-layer), đó không nhất thiết là trạng thái quan trọng.
Phía EVM có thể cho bạn biết hành động bắt đầu ở đâu.
Phía Dusk vẫn quyết định khi nào lệnh rút thực sự sẵn sàng để chứng minh và hoàn tất.
Vì vậy, câu hỏi tôi sẽ hỏi một sàn giao dịch hoặc đội hạ tầng không phải là:
“Ngăn xếp EVM hiện tại của bạn có thể nhìn thấy DuskEVM không?”
Mà là:
Ngăn xếp đó có thể cho bạn biết khi nào một hành động xuyên lớp thực sự đã xong mà không cần bổ sung giám sát trạng thái riêng cho Dusk không?
Nếu câu trả lời là không, thì DuskEVM tạo ra một sự đánh đổi thú vị.
Tương thích giúp giảm chi phí chuyển đổi của nhà phát triển trong khi có thể che giấu một yêu cầu quan sát (observability) mới bên dưới lớp công cụ quen thuộc.
Đó là phần tôi sẽ theo dõi khi các ứng dụng thực sự bắt đầu xuất hiện.
Khoảng trống tương thích nguy hiểm nhất có lẽ là khoảng trống trông “đủ tương thích” đến mức không ai nghĩ đến việc phải giám sát theo cách khác.
#dusk $DUSK @Dusk
$ZEC
$ENA
