# Các mối đe dọa hậu lượng tử đối với quyền riêng tư của Ethereum
*Xin cảm ơn Alex, Andy, Keewoo, Miha, Moven, Nico, Oskar, Sora, Thore, Vitalik, Yanis và Zoey vì những phản hồi về các bản thảo trước đó. Bài viết này được nghiên cứu và biên soạn với sự hỗ trợ của trí tuệ nhân tạo.*
## Tóm tắt
Đối với các bề mặt bảo mật tồn tại lâu dài và dễ bị thu thập - giải mã - thu thập trước, việc chuyển đổi quyền riêng tư cần được xử lý nhanh chóng hơn so với việc chuyển đổi xác thực - không gì có thể ngăn cản kẻ thù giải mã các bản mã đã thu thập được bằng máy tính lượng tử trong tương lai, trong khi việc giả mạo chữ ký ít nhất có thể được khắc phục một phần thông qua các nhánh cứng và chuyển đổi khóa (mặc dù với chi phí đáng kể về sự mơ hồ, xác định nguồn gốc và hoàn tác). Ngành công nghiệp đã triển khai rộng rãi việc trao đổi khóa PQ trước tiên (Chrome, iMessage, AWS, Cloudflare); xác thực PQ vẫn còn ở giai đoạn đầu, đặc biệt là trong PKI web công cộng mặc định. Ethereum kế thừa mã hóa vận chuyển PQ cho một số bề mặt (HTTPS/JSON-RPC qua TLS bằng Go 1.24), nhưng quyền riêng tư ở lớp ứng dụng - các giao thức mật mã được xây dựng trên EVM chứ không phải được hỗ trợ nguyên bản bởi các mã lệnh hoặc biên dịch trước, chẳng hạn như địa chỉ ẩn danh, zkID và các giao dịch bí mật - yêu cầu công việc cụ thể của Ethereum.
| # | Vấn đề | Trạng thái |
|—|---------|--------|
| 1 | Khả năng mở rộng địa chỉ ẩn PQ | Nghiên cứu đang được tiến hành; tình trạng phình to dữ liệu cuộc gọi và chi phí bộ nhớ OMR vẫn còn tồn tại |
| 2 | ML-KEM bên trong MPC/2PC cho zkTLS | Không có giao thức nào nằm trong thời gian chờ thực tế |
| 3 | Số hóa chữ ký NIST PQ để nhập zkID | Khoảng cách 131x so với SNARK tiền lượng tử |
| 4 | Chi phí xác minh thông tin xác thực PQ cho việc nhập zkID | Khoảng cách SNARK 131x; [EIP-8051]( EIP-8051: Biên dịch trước để xác minh chữ ký ML-DSA )/[8052]( EIP-8052: Biên dịch trước để hỗ trợ Falcon ) (bản nháp) được đề xuất làm cơ sở hạ tầng hỗ trợ |
| 5 | Mã hóa PQ đã được chứng minh là chính xác cho kiểm toán viên được chỉ định | Phát hiện và gắn cờ có thể là đủ; mô hình thực thi giao thức chưa được giải quyết |
—
## Giới thiệu
Mối đe dọa hậu lượng tử đối với blockchain đã được nhận thức rộng rãi và có thể được phân loại thành hai nhóm: **tính xác thực** và **tính riêng tư** . Tính xác thực đề cập đến việc làm giả chữ ký số và hình thức rộng hơn của chúng - bằng chứng không tiết lộ thông tin. Tính riêng tư đề cập đến tính bảo mật của dữ liệu trên chuỗi và ngoài chuỗi, cũng như tính ẩn danh và không thể liên kết của người dùng và hành động của họ.
Nỗ lực đáng kể đã được dành để giảm thiểu các mối đe dọa về tính xác thực. Vào tháng 8 năm 2024, NIST đã hoàn thiện ba tiêu chuẩn PQC đầu tiên của mình — ML-KEM (FIPS 203), ML-DSA (FIPS 204) và SLH- DSA (FIPS 205). Đến đầu năm 2026, Quỹ Ethereum đã nâng cao mức độ bảo mật PQ trong lộ trình phát triển giao thức và bắt đầu tổ chức các nhóm làm việc công khai chuyên trách về PQ.
Ngược lại, các mối đe dọa về quyền riêng tư lại đặc biệt cấp bách do chiến lược "thu thập trước, giải mã sau" (HNDL) — chiến lược thu thập dữ liệu được mã hóa ngay hôm nay và tích trữ chúng cho đến khi một máy tính lượng tử đủ mạnh có thể phá vỡ mã hóa. Trên một mạng thông thường, kẻ thù phải chủ động nghe lén lưu lượng truy cập để thu thập văn bản mã hóa, nhưng blockchain là sổ cái công khai, chỉ ghi thêm: dữ liệu được mã hóa ở lớp ứng dụng — văn bản mã hóa trên chuỗi, thông báo địa chỉ ẩn danh, ghi chú được mã hóa, khóa xem — đã hiển thị vĩnh viễn cho mọi người. Không có bước chặn; chính chuỗi là kho lưu trữ. Bất kỳ văn bản mã hóa nào liên quan đến quyền riêng tư được đăng tải hôm nay đều có thể thu thập được theo mặc định và sẽ vẫn hiển thị trong suốt vòng đời của sổ cái. Không giống như các lỗi xác thực, có thể được khắc phục một phần thông qua phối hợp khẩn cấp (mặc dù với [sự mơ hồ đáng kể và chi phí hoàn tác]( Cách thực hiện hard-fork để cứu hầu hết tiền của người dùng trong trường hợp khẩn cấp lượng tử )), các vi phạm quyền riêng tư là không thể đảo ngược — một khi văn bản mã hóa được giải mã bởi một kẻ thù lượng tử trong tương lai, không có bản nâng cấp giao thức nào có thể mã hóa lại nó. Ngành công nghiệp nhận ra sự bất đối xứng này: Chrome, Apple iMessage (PQ3), AWS và Cloudflare đã tích hợp tính năng trao đổi khóa PQ, trong khi xác thực PQ trong PKI web công cộng mặc định vẫn chưa được triển khai rộng rãi — bởi vì việc trao đổi khóa bảo vệ chống lại HNDL nhưng xác thực chỉ cần chống lại việc giả mạo thời gian thực ([ethresear.ch PQ tasklist]( Danh sách nhiệm vụ cho ETH hậu lượng tử ), [F5 Labs]( Tình trạng của mật mã hậu lượng tử (PQC) trên Web | F5 Labs )).
## Những gì Ethereum được tặng miễn phí — và những gì nó không được tặng miễn phí
Không phải tất cả quá trình chuyển đổi sang mã hóa bảo mật PQ đều yêu cầu nghiên cứu cụ thể về Ethereum. Quá trình chuyển đổi mã hóa trong ngành công nghiệp rộng lớn hơn đã bao gồm một số giao diện truyền tải: Geth được viết bằng Go, và Go 1.24 tích hợp sẵn TLS PQ lai (X25519MLKEM768) — [Kubernetes v1.33]( Mã hóa hậu lượng tử trong Kubernetes | Kubernetes ) đã tự động có tính năng trao đổi khóa PQ chỉ bằng cách nâng cấp Go. Các điểm cuối HTTPS JSON-RPC, kết nối trình duyệt với dApp và bất kỳ triển khai libp2p nào sử dụng TLS 1.3 thông qua ngăn xếp TLS của Go đều kế thừa giao thức truyền tải được mã hóa PQ mà không cần thay đổi giao thức Ethereum. (Ngăn xếp DevP2P/RLPx gốc của Ethereum chạy trên TCP, không phải TLS, vì vậy nó không tự động được hưởng lợi; và libp2p cũng hỗ trợ Noise như một tùy chọn kênh bảo mật, tùy chọn này sẽ cần nâng cấp PQ riêng.)
Điều mà Ethereum *không thể* kế thừa là tính bảo mật **lớp ứng dụng** — các giao thức mật mã được xây dựng trên nền tảng EVM thay vì được hỗ trợ nguyên bản bởi các opcode hoặc precompiled. Các bản mã trên chuỗi, việc tạo khóa dựa trên ECDH để khám phá ghi chú (xem khóa), tạo địa chỉ ẩn dựa trên ECDH, mã hóa được chứng minh bằng ZK (chứng minh bên trong mạch ZK rằng bản mã được tạo chính xác bằng khóa công khai nhất định, như được sử dụng trong các giao dịch chuyển khoản được che chắn tuân thủ), và việc che giấu mẫu truy cập (ngăn người quan sát biết được người dùng đọc hoặc ghi những bản ghi nào trên chuỗi, ví dụ: họ quét hoặc chi tiêu những ghi chú nào) đều là những vấn đề đặc thù của blockchain mà không có giải pháp tương đương trong ngành. Phần còn lại của bài viết này sẽ tập trung vào những lỗ hổng này.
## Tính ẩn danh và không thể liên kết
Các công nghệ như Stealth Addresses, zkID và zkTLS mang lại trải nghiệm người dùng tốt về tính ẩn danh và khả năng không thể liên kết, đủ đáp ứng hầu hết các trường hợp sử dụng hiện nay. Câu hỏi đặt ra là liệu điều này có còn đúng trong kỷ nguyên hậu lượng tử hay không.
### Địa chỉ ẩn
Địa chỉ ẩn danh dựa vào thuật toán trao đổi khóa Diffie-Hellman đường cong Elliptic (ECDHKE), vốn bị phá vỡ bởi máy tính lượng tử. ECDHKE có thể được thay thế bằng ML-KEM ngoài chuỗi, nhưng văn bản mã hóa ML-KEM-768 có kích thước 1.088 byte — lớn hơn 33 lần so với các điểm ECDH được nén. Các khối dữ liệu EIP-4844 bị cắt tỉa sau khoảng 18 ngày, vì vậy việc sử dụng chúng cho văn bản mã hóa địa chỉ ẩn danh sẽ yêu cầu người nhận phải lấy được văn bản mã hóa trong khoảng thời gian đó — bổ sung thêm yêu cầu về tính khả dụng mà các thiết kế địa chỉ ẩn danh hiện tại không có.
Một giải pháp tiềm năng mà không gây gánh nặng cho dữ liệu cuộc gọi là Truy xuất Tin nhắn Không Rõ ràng (OMR) dưới dạng sidecar ngoài chuỗi. Điều này đưa ra giả định về độ tin cậy của dữ liệu mà các địa chỉ ẩn danh trên chuỗi không có: người nhận phụ thuộc vào nhà điều hành sidecar để lưu trữ và cung cấp bản mã. Nếu nhà điều hành ngoại tuyến hoặc giữ lại dữ liệu, người nhận không thể quét tìm ghi chú của họ. ML-KEM có cấu trúc tương thích với OMR hơn ECDH. [một giao thức địa chỉ ẩn danh dựa trên Module-LWE]( Giao thức Địa chỉ Ẩn danh Hậu Lượng tử ) vượt trội hơn ECPDKSAP cổ điển khoảng 66,8% về thời gian quét, và giao thức lai [“Đường cong Hiệu quả”]( [2504.06744] Giao thức Địa chỉ Ẩn danh Hiệu quả hơn ) đạt được tốc độ quét nhanh hơn khoảng 3 lần. Bản thân OMR đã được cải tiến từ [cấu trúc ban đầu]( Oblivious Message Retrieval ) đến [PerfOMR]( PerfOMR: Oblivious Message Retrieval with Reduced Communication and Computation ) (~40 ms/tin nhắn, khóa nhỏ hơn 235 lần) và [HomeRun]( HomeRun: High-efficiency Oblivious Message Retrieval, Unrestricted ) (thời gian chạy nhanh hơn 3.830 lần). Tuy nhiên, chi phí bộ nhớ của OMR (~20 GB trở lên) vẫn không thực tế đối với cơ sở hạ tầng nhẹ.
### zkTLS
Khi các máy chủ TLS chuyển sang trao đổi khóa PQ lai (X25519MLKEM768), zkTLS cũng phải làm theo: MPC/2PC giữa người dùng và Notary phải cùng thực hiện cả hai phần X25519 và ML-KEM-768 của quá trình bắt tay mà không tiết lộ khóa phiên cho bất kỳ bên nào. Các giao thức zkTLS hiện tại như TLSNotary hoạt động trên TLS 1.2; hỗ trợ TLS 1.3 (nơi diễn ra quá trình đàm phán X25519MLKEM768) nằm trong lộ trình phát triển nhưng chưa được triển khai. Ngay cả đối với việc trao đổi khóa X25519 cổ điển bên trong TLS 1.3 MPC/2PC, cũng không có triển khai zkTLS nào đang được sử dụng — việc thêm ML-KEM-768, với phép toán đa thức NTT tốn kém trong các khung MPC chung, càng làm tăng thêm thách thức. Một minh chứng cụ thể có thể yêu cầu thiết kế đồng thời MPC với cấu trúc đại số của ML-KEM thay vì sử dụng các khung chung.
### zkID
zkID yêu cầu người dùng chứng minh *bên trong mạch ZK trên thiết bị của họ* rằng họ đã xác thực chữ ký một cách chính xác, sau đó chỉ gửi bằng chứng — chứ không phải thông tin xác thực — cho người xác minh. ZkID PQ đầy đủ yêu cầu hai lớp bảo mật hậu lượng tử: (1) bản thân *sơ đồ chữ ký* phải an toàn PQ (để kẻ thù lượng tử không thể làm giả thông tin xác thực), và (2) *hệ thống chứng minh* tạo ra bằng chứng ZK cũng phải an toàn PQ (để kẻ thù lượng tử không thể làm giả bằng chứng). Câu hỏi cốt lõi cho việc triển khai thực tế là việc xác minh chữ ký PQ có thể được tính toán lại một cách tiết kiệm như thế nào bên trong một hệ thống chứng minh PQ.
Các lược đồ dựa trên hàm băm (XMSS, Winternitz, SPHINCS+) được xây dựng hoàn toàn từ việc đánh giá hàm băm. Thay thế hàm băm nội bộ (SHA-256: ~25.000+ ràng buộc R1CS) bằng một giải pháp thay thế gốc ZK như Poseidon (~240 ràng buộc — xem [ZKPlus benchmarks]( Benchmarks of Hashing Algorithms in ZoKrates - ZKPlus ), [Guo et al.]( [2409.01976] Benchmarking ZK-Friendly Hash Functions and SNARK Proving Systems for EVM-compatible Blockchains )), và mạch xác minh sẽ giảm đi khoảng 100 lần. Điều này hoạt động vì chữ ký dựa trên hàm băm là *chung chung* trên hàm băm — chúng chỉ cần khả năng chống va chạm và chống tìm ảnh ngược, chứ không cần đại số cụ thể. Chữ ký vẫn an toàn PQ và việc chứng minh trở nên rẻ hơn trong ZK. Chữ ký dựa trên lưới (ML-DSA, FN-DSA) thiếu thuộc tính này: phép toán đa thức NTT của chúng tốn kém để tính toán, khiến chúng phù hợp hơn cho việc xác minh trực tiếp trên chuỗi thông qua biên dịch trước ([EIP-8051]( EIP-8051: Biên dịch trước để xác minh chữ ký ML-DSA ), [EIP-8052]( EIP-8052: Biên dịch trước để hỗ trợ Falcon )) hơn là được chứng minh là đúng bên trong mạch ZK (nghĩa là người dùng chứng minh “Tôi đã xác minh chữ ký này” trong môi trường không tiết lộ thông tin xác thực).
#### Xuất ID Ethereum
Điều này hoàn toàn khả thi: hệ sinh thái có thể thiết kế chữ ký PQ dựa trên hàm băm *gốc Ethereum* với các thành phần nội bộ của Poseidon, và người dùng chứng minh việc xác thực bên trong STARK trên thiết bị của họ. Một lưu ý quan trọng: đây là thiết kế tùy chỉnh, dành riêng cho Ethereum — không phải là SLH-DSA tiêu chuẩn (FIPS 205 chỉ quy định các bộ tham số dựa trên SHAKE/SHA2). Nó sẽ không tương tác với PKI bên ngoài hoặc đáp ứng các khung tuân thủ yêu cầu các thuật toán được NIST phê duyệt. Cách tiếp cận này hấp dẫn chính vì hệ sinh thái kiểm soát cả người ký và người xác minh, nhưng nó nên được hiểu là một lựa chọn thiết kế gốc, chứ không phải là một lựa chọn tuân thủ tiêu chuẩn.
#### Nhập ID thực tế
Điều này rất khó: các nhà phát hành sẽ sử dụng ML-DSA hoặc SLH-DSA tiêu chuẩn với SHA-256/SHAKE, chứ không phải Poseidon. Quá trình xác minh đầy đủ — bao gồm SHA-256/SHAKE và (đối với ML-DSA) NTT lưới — phải được tính toán nguyên trạng. Có một sự không phù hợp sâu sắc hơn: các lược đồ chữ ký thực tế thường được tối ưu hóa cho việc ký nhanh (một máy chủ ký nhiều chứng chỉ) với chi phí xác minh cao (một máy khách xác minh), điều này trái ngược với thiết lập blockchain, nơi việc xác minh diễn ra trên chuỗi hoặc bên trong mạch ZK và phải có chi phí thấp. Sự bất đối xứng trong thiết kế này là lý do cấu trúc khiến việc nhập chứng chỉ thực tế vốn dĩ rất tốn kém. [ZKSNARK dựa trên lưới của Wu và cộng sự]( https://www.cs.utexas.edu/~dwu4/papers/LatticeDVSNARKs.pdf ) đạt được bằng chứng ~16 KB (nhỏ hơn Aurora 10,3 lần) nhưng vẫn lớn hơn Groth16 131 lần; Lưu ý rằng thiết lập người xác minh được chỉ định có nghĩa là bằng chứng chỉ có thể được kiểm tra bởi một người xác minh cụ thể nắm giữ khóa bí mật, chứ không được xác minh công khai trên chuỗi — một hạn chế bổ sung cho các trường hợp sử dụng blockchain. STARK là con đường PQ thực tế nhất (chúng chỉ dựa vào hàm băm chống va chạm, không có giả định về mạng lưới hoặc ghép cặp) nhưng tạo ra bằng chứng lớn hơn đáng kể so với SNARK tiền lượng tử như Groth16. Những khoảng trống còn lại: thu hẹp khoảng cách 131x giữa PQ và SNARK tiền lượng tử; tính toán hiệu quả việc xác minh chữ ký NIST PQ; một SNARK PQ sẵn sàng cho sản xuất để xác minh thông tin xác thực.
## Bảo mật
Bảo mật — che giấu số tiền giao dịch, số dư và trạng thái hợp đồng — là nguyên tắc của cơ sở hạ tầng Ethereum L2 tập trung vào quyền riêng tư như [Aztec]( https://aztec.network ) (Chuỗi Ignition được ra mắt vào tháng 11 năm 2025, mặc dù giai đoạn 1 của mạng chính vẫn chưa thực hiện các giao dịch của người dùng) và các công cụ lớp ứng dụng như Railgun và Privacy Pools. Cam kết trạng thái (cây Merkle, hàm băm ghi chú) có thể sử dụng các hàm băm an toàn PQ như Poseidon — lỗ hổng nằm ở lớp *mã hóa* . Hai vấn đề phụ riêng biệt phát sinh:
- **Phát hiện ghi chú và trao đổi khóa** : việc xem khóa trong các hệ thống như Aztec dựa trên việc tạo khóa dựa trên EC — người gửi mã hóa thành khóa công khai của người nhận để người nhận có thể xác định các ghi chú dành cho họ. ML-KEM có thể thay thế ECDHKE ở đây (cùng mức độ phình to bản mã 33 lần như địa chỉ ẩn, cùng đường dẫn giảm thiểu dựa trên OMR), nhưng việc trao đổi khóa này diễn ra *bên ngoài* mạch ZK và không yêu cầu chứng minh trong mạch.
- **Mã hóa chính xác đã được chứng minh cho kiểm toán viên/người nhận tuân thủ được chỉ định** : để tiết lộ có chọn lọc trong các giao dịch được che chắn tuân thủ, người gửi mã hóa trực tiếp bằng khóa công khai đã biết của người nhận được chỉ định và chứng minh tính chính xác bên trong mạch ZK. Người nhận có thể là một cơ quan quản lý, một bộ phận tuân thủ của tổ chức, một kiểm toán viên kho bạc DAO hoặc bất kỳ bên nào mà giao thức chỉ định. Trước kỷ nguyên lượng tử, ElGamal đã thực hiện điều này một cách tiết kiệm (một phép nhân vô hướng EC, rất thân thiện với ZK). Sau kỷ nguyên lượng tử, người gửi sẽ sử dụng PKE dựa trên mạng lưới (ví dụ: Kyber.CPAPKE hoặc mã hóa Regev LWE đơn giản). Đối với hầu hết các thiết kế thực tế, người gửi có thể thực hiện PKE dựa trên mạng lưới *bên ngoài* mạch, tạo ra một khóa đối xứng và chứng minh mã hóa đối xứng chính xác *bên trong* mạch bằng cách sử dụng Poseidon ở chế độ sponge (~240 ràng buộc trên mỗi hoán vị, an toàn PQ, đã được Aztec sử dụng để mã hóa ghi chú). Nếu người gửi gian lận (mã hóa bằng khóa giả), người kiểm toán sẽ nhận được dữ liệu rác và gắn cờ giao dịch — một mô hình phát hiện và gắn cờ. Một mô hình mạnh hơn — trong đó giao thức *đảm bảo* người nhận được chỉ định có thể giải mã — sẽ yêu cầu chứng minh PKE mạng lưới là chính xác bên trong mạch ZK, điều này vẫn tốn kém do sự không khớp trường (phép toán mạng lưới trên q = 3.329 so với các trường hệ thống chứng minh như BN254), mặc dù đơn giản hơn ML-KEM đầy đủ. Liệu mô hình phát hiện và gắn cờ yếu hơn có đủ hay không là một câu hỏi chính sách mở cũng như một câu hỏi về mật mã.
## Chứng minh phía máy khách như một yếu tố phụ thuộc
Cả zkID và tính bảo mật đều yêu cầu người dùng tạo bằng chứng ZK *trên thiết bị của riêng họ* — việc ủy thác cho máy chủ sẽ làm rò rỉ các thông tin đầu vào riêng tư mà bằng chứng đó nhằm mục đích bảo vệ. Mặc dù tăng tốc GPU mang lại lợi ích cho tất cả các hệ thống chứng minh, nhưng các hệ thống chứng minh PQ sẽ được hưởng lợi nhiều hơn một cách không cân xứng vì hai lý do: (1) hiệu suất CPU hiện tại khiến việc tạo bằng chứng PQ trở nên không khả thi đối với việc sử dụng phía máy khách, tạo ra sự phụ thuộc khó khăn hơn vào tăng tốc GPU so với các hệ thống tiền lượng tử, và (2) các phép toán PQ — phép toán đa thức dựa trên NTT trên các trường nhỏ — phù hợp hơn với kiến trúc GPU so với các phép toán đường cong elip dựa trên nhóm, vốn phải đối mặt với [giới hạn trên về tăng tốc lý thuyết]( Metal MSM v2: Khám phá khả năng tăng tốc MSM trên GPU của Apple | PSE ) do sự phụ thuộc vào chuỗi truyền tuần tự của chúng. NTT là *nguyên thủy chung* trong các hoạt động chứng minh và mạng lưới STARK, và các lược đồ PQ trường nhỏ (M31, q = 3.329) đạt được [100+ Gops/s trên GPU di động so với < 1 Gops/s cho BN254]( Tăng tốc GPU phía máy khách cho ZK: Con đường hướng tới quyền riêng tư Ethereum hàng ngày | PSE ) — vì vậy thông lượng thô là có.
Tăng tốc GPU áp dụng cho cả đường dẫn ID gốc của Ethereum (chữ ký dựa trên hàm băm nội bộ của Poseidon đã được chứng minh trong STARK) và đường dẫn nhập ID thực tế (xác minh chữ ký NIST PQ trong SNARK). Nhưng đường dẫn gốc của Ethereum cung cấp một lộ trình dễ dàng hơn đáng kể để bảo mật phía máy khách: bằng cách kiểm soát lược đồ chữ ký, hệ sinh thái có thể chọn các thuật toán vừa an toàn PQ vừa thân thiện với GPU ngay từ đầu, thay vì tính toán các thuật toán được áp đặt từ bên ngoài. Do đó, ưu tiên không gian thiết kế ID của Ethereum cũng là một chiến lược chứng minh phía máy khách thực tế.
Việc chứng minh bằng GPU phía máy khách là một thách thức rộng hơn đối với cơ sở hạ tầng Ethereum (mang lại lợi ích cho việc chống kiểm duyệt, bằng chứng xác thực, v.v.), chứ không chỉ riêng đối với quyền riêng tư hậu lượng tử. Chúng tôi lưu ý điều này ở đây như một yếu tố phụ thuộc: Quyền riêng tư PQ không thể hoạt động nếu thiếu nó, nhưng [hệ sinh thái GPU ZK]( GitHub - zkmopro/awesome-client-side-gpu: Awesome things around client-side GPU ecosystems. · GitHub ) và [lộ trình PQ]( Client-Side GPU Acceleration for ZK: A Path to Everyday Ethereum Privacy | PSE ) nên được giải quyết như một nỗ lực xây dựng cơ sở hạ tầng chứng minh tổng quát.
## Các khuyến nghị về lộ trình ngắn hạn
Các vấn đề nêu trên nằm ở các mức độ trưởng thành khác nhau. Một số vấn đề đã có giải pháp thay thế cho PQ và có thể chuyển sang giai đoạn triển khai; những vấn đề khác vẫn đang trong giai đoạn nghiên cứu. Một lộ trình hữu ích sẽ phân biệt những gì có thể triển khai ngay lập tức với những gì cần đột phá — và tránh tích lũy thêm rủi ro trong khi chờ đợi.
> **Nguyên tắc thiết kế: không có khoản nợ riêng tư cổ điển mới.** Khoản nợ bảo mật là không thể đảo ngược — không giống như khoản nợ xác thực, có thể được khắc phục một phần thông qua việc xoay vòng khóa hoặc các nhánh khẩn cấp. Mỗi giao thức bảo mật mới lưu trữ bản mã có thời gian tồn tại lâu dài được tạo ra từ ECDH đều mở rộng vĩnh viễn cửa sổ phơi nhiễm HNDL. Các thiết kế mới nên mặc định sử dụng trao đổi khóa PQ cho bất kỳ bề mặt bảo mật nào tồn tại ngoài một phiên duy nhất, với các ngoại lệ được ghi chép rõ ràng trong trường hợp các giải pháp thay thế PQ chưa khả thi.
1. **Định lượng bẫy bảo mật.** Một *bẫy lượng tử* là tổng giá trị có thể trích xuất mà một máy tính lượng tử đủ mạnh có thể mở khóa khi bắt đầu hoạt động. Bẫy xác thực — tổng giá trị trong các tài khoản có khóa dễ bị tấn công lượng tử — rất lớn nhưng có giới hạn: cộng đồng có thể phối hợp thực hiện [phân nhánh cứng khẩn cấp]( Cách thực hiện phân nhánh cứng để cứu phần lớn tiền của người dùng trong trường hợp khẩn cấp lượng tử ) để đóng băng các tài khoản bị lộ và chuyển sang chữ ký PQ.
Cơ chế bẫy *bảo mật* có cấu trúc khác biệt và là trọng tâm của bài viết này. Đó là dữ liệu được mã hóa tích lũy trên chuỗi khối kể từ khi khởi tạo, tăng lên theo từng khối. Không có nhánh nào có thể mã hóa lại các bản mã cũ. Mỗi loại rủi ro được tính toán độc lập:
- **Giao dịch được bảo vệ và ghi chú được mã hóa:** một kẻ tấn công lượng tử sẽ giải mã ngược lại mọi số dư, số tiền chuyển khoản và trạng thái hợp đồng đã từng được cam kết vào một nhóm được bảo vệ — toàn bộ lịch sử tài chính của mọi người tham gia.
- **Liên kết địa chỉ ẩn danh:** Các địa chỉ ẩn danh được tạo ra từ ECDH trở nên có thể truy vết ngược lại người nhận, phá vỡ tính không thể liên kết mà các lược đồ ẩn danh được thiết kế để cung cấp.
- **Thông tin xác thực được tiết lộ có chọn lọc:** các thông tin được bảo vệ theo quy định dành cho kiểm toán viên được chỉ định có thể bị đọc bởi bất kỳ ai có máy tính lượng tử — làm lộ dữ liệu KYC, vị thế tổ chức và liên kết danh tính cho các bên không mong muốn.
- **Xem khóa và phát hiện ghi chú:** Việc tạo khóa dựa trên EC để quét ghi chú cho thấy ghi chú nào thuộc về người nhận nào, làm lộ danh tính toàn bộ biểu đồ giao dịch ngay cả khi số tiền vẫn được che giấu sau mã hóa đối xứng.
Hậu quả về mặt xã hội khác biệt so với hành vi trộm cắp: việc tiết lộ danh tính các nhà tài trợ chính trị một cách hồi tố, sự phá vỡ quyền riêng tư tài chính của các cá nhân và tổ chức, việc phơi bày các mối quan hệ tuân thủ. Cái bẫy xác thực có thể bị rút cạn và sau đó bị chặn lại. Cái bẫy quyền riêng tư chỉ có thể được ngăn chặn để không cho nó tiếp tục phát triển — mỗi lần chặn đều làm tăng thêm sự phơi bày không thể đảo ngược.
*Sản phẩm bàn giao:* một ước tính định lượng, được cập nhật thường xuyên về "bẫy dữ liệu bảo mật" — các loại dữ liệu có nguy cơ bị xâm phạm, tốc độ tăng trưởng của mỗi loại và thời gian khắc phục — cung cấp cho ban quản trị cơ sở cụ thể để đánh giá mức độ khẩn cấp của việc chuyển đổi. Một ước tính tương tự cho "bẫy dữ liệu xác thực" (giá trị rủi ro, mức độ sẵn sàng cho việc phân nhánh) sẽ hữu ích trong việc cung cấp bối cảnh nhưng đã được hiểu rõ hơn.
2. **Xây dựng sổ đăng ký bề mặt bảo mật.** Liệt kê mọi bề mặt bảo mật nơi mã hóa hoặc vật liệu khóa tồn tại lâu hơn một phiên làm việc: thông báo ẩn, khóa xem, ghi chú được mã hóa, mã hóa lớp ứng dụng, nhập thông tin xác thực, luồng tiết lộ có chọn lọc. Gắn thẻ cho mỗi bề mặt với thời gian lưu trữ, giả định mật mã và khả năng thay thế PQ. Kết quả đầu ra là một sổ đăng ký có cấu trúc mà các nhóm có thể truy vấn để ưu tiên di chuyển — chứ không phải là một mô hình mối đe dọa dựa trên tường thuật.
Để cập nhật sổ đăng ký, các EIP và thông số kỹ thuật giao thức mới có liên quan đến hoặc phụ thuộc vào các bề mặt bảo mật cần bao gồm một **phần mô hình mối đe dọa PQ** — tương tự như yêu cầu Cân nhắc An ninh hiện có — xác định các giả định dễ bị tổn thương lượng tử, dữ liệu bị lộ HNDL và các lộ trình di chuyển. Điều này biến sự sẵn sàng PQ từ một cuộc kiểm toán hồi tố thành một ràng buộc thiết kế thường trực.
3. **Cung cấp thư viện tham chiếu và tiêu chuẩn đánh giá cho các bề mặt có thể xử lý được.** Hai bề mặt có các phần tử PQ cơ bản đã biết và có thể chuyển sang giai đoạn triển khai ngay bây giờ:
- *Khám phá ghi chú ML-KEM:* tạo và quét bản mã, giao diện ví/bộ lập chỉ mục, các thành phần phụ trợ truy xuất OMR.
- *ZkID gốc Ethereum:* Chữ ký PQ dựa trên hàm băm nội bộ của Poseidon với mạch xác minh STARK, được đánh giá hiệu năng về thời gian chứng minh phía máy khách và kích thước bằng chứng.
Mục tiêu là thiết lập các tiêu chuẩn chung, chứ không phải là sự sẵn sàng cho sản xuất — lý tưởng nhất là được xác thực toàn diện với ít nhất một lớp L2 hoặc ngăn xếp ứng dụng hướng đến quyền riêng tư để phát hiện các vấn đề tích hợp mà chỉ dựa vào các tiêu chuẩn đánh giá bỏ sót.
4. **Xác định phạm vi các vấn đề chưa được giải quyết như các hướng nghiên cứu không gây cản trở.** Ba lĩnh vực quan trọng nhưng chưa được giải quyết là: zkTLS tương thích PQ (MPC/2PC trên các giao thức bắt tay ML-KEM), nhập zkID thực tế (số hóa quá trình xác minh chữ ký NIST PQ), và mã hóa được chứng minh là chính xác theo giao thức cho các kiểm toán viên được chỉ định. Hiện chưa có giao thức cụ thể nào cho bất kỳ lĩnh vực nào trong số đó trong phạm vi thực tế. Hãy tài trợ và theo dõi các vấn đề này, nhưng đừng cản trở tiến trình xây dựng sổ đăng ký, thư viện tham khảo hoặc nguyên tắc thiết kế nêu trên.
—
*Rất mong nhận được phản hồi — đặc biệt là về khung bẫy bảo mật, đánh giá khả năng theo dõi và bất kỳ khía cạnh bảo mật PQ nào mà chúng tôi có thể đã bỏ sót.*
