Cách đây vài hôm, khi đang lướt qua X, tôi bắt gặp một bài viết về testnet DuskEVM và có một chi tiết khiến tôi chú ý. Vào ngày 10 tháng 8, testnet DuskEVM đã chính thức ra mắt. Solidity và Hardhat hoạt động trơn tru, nhưng Hedger—cỗ máy hợp đồng bảo mật (confidential) cốt lõi—đã được chạy tách biệt trên testnet Ethereum Sepolia từ tháng 11 năm 2025. Nhóm chính thức vẫn chưa công bố khi nào hai phần này sẽ được hợp nhất.
Khi mọi người thấy khoảng trống 9 tháng như vậy, phản ứng đầu tiên thường là lo ngại. Một blockchain tập trung vào quyền riêng tư mà lớp quyền riêng tư và lớp EVM lại được thử nghiệm tách rời có thể nghe không thật quen.
Nhưng sau khi đọc qua tài liệu kỹ thuật, tôi bắt đầu nghĩ rằng việc thử nghiệm theo hai nhánh song song này có thể thực ra là một lựa chọn bị đánh giá thấp trong kiến trúc của Dusk. Stack của Dusk được phân lớp. #Dusk handle xử lý thanh toán và tính sẵn có của dữ liệu, DuskEVM là lớp EVM, còn Hedger là lớp quyền riêng tư sử dụng mã hóa đồng cấu (homomorphic encryption) và bằng chứng không kiến thức (zero-knowledge proofs).
Nếu cả ba lớp được kiểm thử cùng lúc, một lỗi trong mật mã và một lỗi trong hợp đồng có thể trở nên khó phân biệt. Việc thử nghiệm tách rời cho phép nhóm đưa lớp EVM chạy trước, để các nhà phát triển triển khai ứng dụng, sau đó xác thực Hedger riêng biệt trên Sepolia, và cuối cùng hợp nhất lại vào $DUSK . Cách này giúp quá trình debug rõ ràng hơn nhiều.
Tôi chưa chắc đánh giá này có đúng hay không. Cũng có thể các xung đột giao thức sẽ xuất hiện trong lần hợp nhất cuối cùng và buộc phải làm lại một phần công việc trước đó. Tính mô-đun nghe có vẻ tốt, nhưng kỹ thuật luôn đi kèm chi phí phối hợp.
Tuy nhiên, từ một góc nhìn khác, các khách hàng tổ chức lại sợ điều gì đó hỏng hơn là sợ tiến độ chậm. Việc triển khai theo giai đoạn có thể đáng tin cậy hơn là dồn hết mọi thứ vào một lần rồi sau đó phải quay lui.
Việc khởi chạy EVM trước và hợp nhất Hedger sau khi đã được xác thực đầy đủ có thể chỉ đơn giản là một cách để đảm bảo nền tảng thật sự vững chắc.
Các bạn nghĩ sao về chiến lược thử nghiệm theo hai nhánh song song này? Tôi muốn nghe ý kiến của mọi người.@Dusk
Khi mọi người thấy khoảng trống 9 tháng như vậy, phản ứng đầu tiên thường là lo ngại. Một blockchain tập trung vào quyền riêng tư mà lớp quyền riêng tư và lớp EVM lại được thử nghiệm tách rời có thể nghe không thật quen.
Nhưng sau khi đọc qua tài liệu kỹ thuật, tôi bắt đầu nghĩ rằng việc thử nghiệm theo hai nhánh song song này có thể thực ra là một lựa chọn bị đánh giá thấp trong kiến trúc của Dusk. Stack của Dusk được phân lớp. #Dusk handle xử lý thanh toán và tính sẵn có của dữ liệu, DuskEVM là lớp EVM, còn Hedger là lớp quyền riêng tư sử dụng mã hóa đồng cấu (homomorphic encryption) và bằng chứng không kiến thức (zero-knowledge proofs).
Nếu cả ba lớp được kiểm thử cùng lúc, một lỗi trong mật mã và một lỗi trong hợp đồng có thể trở nên khó phân biệt. Việc thử nghiệm tách rời cho phép nhóm đưa lớp EVM chạy trước, để các nhà phát triển triển khai ứng dụng, sau đó xác thực Hedger riêng biệt trên Sepolia, và cuối cùng hợp nhất lại vào $DUSK . Cách này giúp quá trình debug rõ ràng hơn nhiều.
Tôi chưa chắc đánh giá này có đúng hay không. Cũng có thể các xung đột giao thức sẽ xuất hiện trong lần hợp nhất cuối cùng và buộc phải làm lại một phần công việc trước đó. Tính mô-đun nghe có vẻ tốt, nhưng kỹ thuật luôn đi kèm chi phí phối hợp.
Tuy nhiên, từ một góc nhìn khác, các khách hàng tổ chức lại sợ điều gì đó hỏng hơn là sợ tiến độ chậm. Việc triển khai theo giai đoạn có thể đáng tin cậy hơn là dồn hết mọi thứ vào một lần rồi sau đó phải quay lui.
Việc khởi chạy EVM trước và hợp nhất Hedger sau khi đã được xác thực đầy đủ có thể chỉ đơn giản là một cách để đảm bảo nền tảng thật sự vững chắc.
Các bạn nghĩ sao về chiến lược thử nghiệm theo hai nhánh song song này? Tôi muốn nghe ý kiến của mọi người.@Dusk