DuskEVM 这东西，我最近翻了翻，发现一个挺关键的问题——"EVM tương thích" thực ra chỉ giải quyết được một nửa vấn đề. Solidity, Foundry, Hardhat những công cụ chuỗi cung ứng đúng là có thể dùng trực tiếp, nhưng trong các kịch bản tài chính còn có một bài toán khó nhằn hơn: các tổ chức có thật sự sẵn sàng công khai toàn bộ số dư, vị thế và giá trị giao dịch không?
Giải pháp của Dusk là Hedger — đưa mã hóa đồng cấu (homomorphic encryption) và bằng chứng không kiến thức (zero-knowledge proofs) vào quy trình làm việc (workflow) của EVM. Phía trước giúp dữ liệu tham gia tính toán ở trạng thái được mã hóa, còn phía sau chứng minh rằng kết quả thỏa mãn các quy tắc. Dữ liệu không cần công khai, nhưng việc thực thi vẫn có thể được xác minh. Nhà tạo lập thị trường có thể ẩn các vị thế nhạy cảm, số dư tài khoản được bảo mật; khi cần kiểm toán thì lại có thể ủy quyền công bố.
Tuy vậy, vấn đề là Hedger không phải kiểu plugin "thêm vào là chạy". Nó kết hợp mã hóa đồng cấu, bằng chứng không kiến thức và mô hình UTXO/tài khoản lai, hoàn toàn không giống logic lưu trữ của ERC-20 tiêu chuẩn. "EVM tương thích" giải quyết cách để nhà phát triển bước vào hệ thống, còn Hedger phải giải quyết sau khi tổ chức đã tham gia thì những dữ liệu nào rốt cuộc không nên được công khai.
Tài liệu chính thức nói rất rõ — DuskEVM dựa trên OP Stack, chạy môi trường thực thi tương đương EVM (EVM-equivalent), dùng chuỗi công cụ quen thuộc. Nhưng cầu bắc tầng (cross-layer bridge) hiện tại vẫn kết nối tới testnet, chỉ hỗ trợ token thử nghiệm. Công cụ đưa người ta vào được thôi; chạy ra ứng dụng thực mới là thứ để lại dấu ấn.
Nếu chạy một phiên bản fork của Uniswap trên DuskEVM, lớp shielding pool phải được viết lại. Khi logic AMM cốt lõi đụng vào lớp riêng tư thì phải làm lại, không phải "di chuyển liền mạch".
EVM tương thích giải quyết vấn đề của chuỗi công cụ phát triển; Hedger giải quyết câu hỏi tài chính dữ liệu có nên được công khai hay không. Liệu DuskEVM có chạy thông suốt confidential EVM workflow được hay không mới là nơi nó thực sự tạo khác biệt. Hiện tại Hedger vẫn đang được mài giũa trên testnet; đợi khi nó được mainnet hóa rồi mới quay lại xem các vấn đề di chuyển này.
#dusk $DUSK @Dusk
Giải pháp của Dusk là Hedger — đưa mã hóa đồng cấu (homomorphic encryption) và bằng chứng không kiến thức (zero-knowledge proofs) vào quy trình làm việc (workflow) của EVM. Phía trước giúp dữ liệu tham gia tính toán ở trạng thái được mã hóa, còn phía sau chứng minh rằng kết quả thỏa mãn các quy tắc. Dữ liệu không cần công khai, nhưng việc thực thi vẫn có thể được xác minh. Nhà tạo lập thị trường có thể ẩn các vị thế nhạy cảm, số dư tài khoản được bảo mật; khi cần kiểm toán thì lại có thể ủy quyền công bố.
Tuy vậy, vấn đề là Hedger không phải kiểu plugin "thêm vào là chạy". Nó kết hợp mã hóa đồng cấu, bằng chứng không kiến thức và mô hình UTXO/tài khoản lai, hoàn toàn không giống logic lưu trữ của ERC-20 tiêu chuẩn. "EVM tương thích" giải quyết cách để nhà phát triển bước vào hệ thống, còn Hedger phải giải quyết sau khi tổ chức đã tham gia thì những dữ liệu nào rốt cuộc không nên được công khai.
Tài liệu chính thức nói rất rõ — DuskEVM dựa trên OP Stack, chạy môi trường thực thi tương đương EVM (EVM-equivalent), dùng chuỗi công cụ quen thuộc. Nhưng cầu bắc tầng (cross-layer bridge) hiện tại vẫn kết nối tới testnet, chỉ hỗ trợ token thử nghiệm. Công cụ đưa người ta vào được thôi; chạy ra ứng dụng thực mới là thứ để lại dấu ấn.
Nếu chạy một phiên bản fork của Uniswap trên DuskEVM, lớp shielding pool phải được viết lại. Khi logic AMM cốt lõi đụng vào lớp riêng tư thì phải làm lại, không phải "di chuyển liền mạch".
EVM tương thích giải quyết vấn đề của chuỗi công cụ phát triển; Hedger giải quyết câu hỏi tài chính dữ liệu có nên được công khai hay không. Liệu DuskEVM có chạy thông suốt confidential EVM workflow được hay không mới là nơi nó thực sự tạo khác biệt. Hiện tại Hedger vẫn đang được mài giũa trên testnet; đợi khi nó được mainnet hóa rồi mới quay lại xem các vấn đề di chuyển này.
#dusk $DUSK @Dusk
