#dusk $DUSK
Những ngày này mình tiếp tục xem Hedger của @Dusk . Có một chỗ trước đây mình hiểu quá đơn giản.
Mình trước đây nghĩ rằng: chỉ cần có ZK là đủ rồi chứ?
Nếu ZK có thể chứng minh “giao dịch này là đúng”, vậy tại sao Hedger còn phải chồng thêm một lớp Homomorphic Encryption (HE) nữa?
Sau đó mình lật đi lật lại tài liệu vài lần mới nhận ra: thực ra chúng đang giải quyết hai việc khác nhau.
ZK giống như đang trả lời:
“Bạn làm sao chứng minh rằng mình không gian lận?”
Còn HE trả lời:
“Trong trường hợp dữ liệu không công khai, bước tiếp theo có còn tính toán tiếp được trên dữ liệu đó không?”
Sự khác biệt này đặt vào bối cảnh tài chính là rất rõ ràng.
Số dư là confidential (bí mật). Vị thế cũng là confidential. Trạng thái còn lại từ giao dịch trước cũng là confidential.
Nhưng giao dịch tiếp theo vẫn phải tiếp tục dùng những trạng thái đó.
Nếu mỗi lần cập nhật đều phải giải mã trước, thì quyền riêng tư sẽ chẳng còn ý nghĩa.
Vì vậy, cách nghĩ của Hedger không phải là chỉ “bọc giao dịch bằng một lớp ZK”.
Mà là để một phần encrypted state vẫn có thể tham gia vào các phép tính về sau, rồi dùng ZK để chứng minh việc thay đổi trạng thái tuân thủ các quy tắc.
Mình nghĩ đây cũng là điểm đáng xem của Hedger hơn nhiều so với các câu chuyện “ZK Privacy” khác.
Nó không theo đuổi full anonymity (ẩn danh hoàn toàn).
Ngay phía chính thức cũng thừa nhận rằng mô hình account của EVM có ranh giới.
Thứ nó thực sự muốn làm là:
Giữ cho confidential state có thể nằm trong quy trình tài chính trên EVM, đồng thời vẫn không đánh mất việc xác minh và kiểm toán.
Tất nhiên, cũng đừng coi HE là chiếc “chìa khóa vạn năng”.
Hedger không phải là một FHE VM kiểu “mọi logic Solidity đều có thể chạy tùy ý trong bản mã” — hiện tại nó cũng vẫn đang ở Testnet.
Vì vậy, phần tiếp theo mình sẽ thật sự xem không phải là “đã dùng bao nhiêu thuật ngữ mã hóa”, mà là những encrypted balances, ownership và transfers trong ứng dụng thực tế chạy được tới mức nào.
Quan trọng hơn một câu “privacy EVM” rất nhiều.
Những ngày này mình tiếp tục xem Hedger của @Dusk . Có một chỗ trước đây mình hiểu quá đơn giản.
Mình trước đây nghĩ rằng: chỉ cần có ZK là đủ rồi chứ?
Nếu ZK có thể chứng minh “giao dịch này là đúng”, vậy tại sao Hedger còn phải chồng thêm một lớp Homomorphic Encryption (HE) nữa?
Sau đó mình lật đi lật lại tài liệu vài lần mới nhận ra: thực ra chúng đang giải quyết hai việc khác nhau.
ZK giống như đang trả lời:
“Bạn làm sao chứng minh rằng mình không gian lận?”
Còn HE trả lời:
“Trong trường hợp dữ liệu không công khai, bước tiếp theo có còn tính toán tiếp được trên dữ liệu đó không?”
Sự khác biệt này đặt vào bối cảnh tài chính là rất rõ ràng.
Số dư là confidential (bí mật). Vị thế cũng là confidential. Trạng thái còn lại từ giao dịch trước cũng là confidential.
Nhưng giao dịch tiếp theo vẫn phải tiếp tục dùng những trạng thái đó.
Nếu mỗi lần cập nhật đều phải giải mã trước, thì quyền riêng tư sẽ chẳng còn ý nghĩa.
Vì vậy, cách nghĩ của Hedger không phải là chỉ “bọc giao dịch bằng một lớp ZK”.
Mà là để một phần encrypted state vẫn có thể tham gia vào các phép tính về sau, rồi dùng ZK để chứng minh việc thay đổi trạng thái tuân thủ các quy tắc.
Mình nghĩ đây cũng là điểm đáng xem của Hedger hơn nhiều so với các câu chuyện “ZK Privacy” khác.
Nó không theo đuổi full anonymity (ẩn danh hoàn toàn).
Ngay phía chính thức cũng thừa nhận rằng mô hình account của EVM có ranh giới.
Thứ nó thực sự muốn làm là:
Giữ cho confidential state có thể nằm trong quy trình tài chính trên EVM, đồng thời vẫn không đánh mất việc xác minh và kiểm toán.
Tất nhiên, cũng đừng coi HE là chiếc “chìa khóa vạn năng”.
Hedger không phải là một FHE VM kiểu “mọi logic Solidity đều có thể chạy tùy ý trong bản mã” — hiện tại nó cũng vẫn đang ở Testnet.
Vì vậy, phần tiếp theo mình sẽ thật sự xem không phải là “đã dùng bao nhiêu thuật ngữ mã hóa”, mà là những encrypted balances, ownership và transfers trong ứng dụng thực tế chạy được tới mức nào.
Quan trọng hơn một câu “privacy EVM” rất nhiều.