ZEC – PRIVACY, ZERO-KNOWLEDGE
& COMPLIANCE

IPrivacy trong blockchain – Vấn đề bị hiểu sai

Quan niệm sai phổ biến nhất: blockchain ẩn danh vì người dùng không cần cung cấp tên thật. Thực tế, hầu hết blockchain (Bitcoin, Ethereum) là pseudonymous — mỗi địa chỉ là bút danh, nhưng mọi giao dịch đều public, không thể xóa, và có thể truy vết vô thời hạn bởi bất kỳ ai.

Vì sao pseudonymous không đủ

Nếu một điểm bất kỳ trong chuỗi giao dịch của một địa chỉ gắn được với danh tính thực — nạp tiền từ sàn KYC, nhận lương từ employer, mua hàng kèm delivery address — toàn bộ lịch sử trở nên visible. Blockchain không chỉ kém hơn hệ thống tài chính truyền thống về privacy — mà còn kém hơn theo một cách đặc biệt: lịch sử vĩnh viễn, hoàn toàn public, không cần warrant để truy cập, không có cơ chế xóa.

Trên Ethereum, không chỉ số dư và chuyển tiền là public — mà cả tương tác với từng protocol, token nắm giữ, NFT, lịch sử vote governance đều hiển thị hoàn toàn. Đây là mức độ transparency không tồn tại trong bất kỳ hệ thống tài chính nào khác.

Ba mức độ privacy — và sự khác biệt thực chất

Privacy là quyết định thiết kế, không phải tính năng

Blockchain được thiết kế để trust-minimized thông qua transparency — đây là lựa chọn có chủ đích, không phải lỗi thiết kế. Trade-off đi kèm là privacy thấp. Không hệ thống nào tối ưu cả hai đồng thời không có chi phí. Hiểu trade-off này là điều kiện tiên quyết để đánh giá bất kỳ giải pháp privacy nào.

IICryptographic Primitives – Nền móng không thay đổi

Mọi hệ thống ZK và privacy blockchain đều xây trên một tập primitives mật mã cơ bản. Phần này là nền tảng lý thuyết — không có expiry date.

Hash Function và chi phí trong ZK circuit

Hàm một chiều ánh xạ input bất kỳ thành output kích thước cố định. Ba tính chất bảo mật: preimage resistance (không thể từ output tìm input), second preimage resistance (không thể tìm input khác cho cùng output), và collision resistance (không thể tìm hai input khác nhau có cùng output). Trong ZK circuit, lựa chọn hash function ảnh hưởng trực tiếp đến prover cost: SHA-256 cần ~25,000 constraints trong R1CS, trong khi Poseidon — thiết kế tối ưu cho finite field — chỉ cần ~240 constraints. Đây không phải chi tiết nhỏ: nó quyết định prover time và tính thực tiễn của một application.

Commitment Scheme

Cơ chế hai giai đoạn: commit (cam kết giá trị mà không tiết lộ) và reveal (tiết lộ sau để xác minh). Hai tính chất bắt buộc: hiding (commitment không leak thông tin) và binding (không thể thay đổi giá trị sau khi commit). Pedersen commitment — xây trên elliptic curve — có thêm tính chất additively homomorphic: tổng của các commitment = commitment của tổng. Đây là cơ chế cốt lõi cho Confidential Transaction.

Elliptic Curve và Bilinear Pairing

ECC là nền tảng của ECDSA (chữ ký) và các ZK-SNARK dựa trên pairing. Pairing-friendly curve (BN254, BLS12-381) có phép toán bilinear: e(aP, bQ) = e(P, Q)^{ab}. Tính chất này là nền tảng để verify SNARK proof hiệu quả — verifier cần vài phép pairing (milliseconds) thay vì re-execute toàn bộ computation.

Arithmetic Circuit và R1CS

Để "compile" computation thành ZK proof, computation phải được biểu diễn dưới dạng arithmetic circuit — mạng cổng cộng và nhân trên finite field. Dạng chuẩn là R1CS (Rank-1 Constraint System): mỗi gate là constraint A · B = C. Số constraints quyết định prover complexity. Tối ưu circuit (giảm constraints) là kỹ năng chuyên môn riêng trong ZK engineering — không phải lập trình thông thường.

IIIZero-Knowledge Proof – Chứng minh mà không tiết lộ

ZKP là giao thức cryptographic cho phép prover thuyết phục verifier rằng một statement là đúng, mà không tiết lộ bất cứ thông tin nào ngoài tính đúng đắn của statement đó.

Ba thuộc tính định nghĩa — bất biến về mặt lý thuyết

• Completeness: Nếu statement đúng và prover trung thực, verifier bị thuyết phục với xác suất 1 (hoặc negligibly close to 1).
• Soundness: Nếu statement sai, không prover gian lận nào thuyết phục được verifier — ngoại trừ xác suất negligible. Định lượng: với statistical soundness, xác suất fail giảm exponential theo số round.
• Zero-Knowledge: Verifier không học được gì ngoài tính đúng của statement. Định nghĩa kỹ thuật: tồn tại một simulator (không biết witness) có thể tạo transcript không thể phân biệt với transcript thực — chứng minh verifier không học được gì từ interaction.

Ví dụ trực quan: Ali Baba Cave

Peggy muốn chứng minh cô biết mật khẩu mở cánh cửa bí mật trong hang có hai nhánh A và B, nhưng không muốn tiết lộ mật khẩu. Victor đứng ngoài, Peggy vào chọn nhánh ngẫu nhiên. Victor hét yêu cầu ra từ một nhánh cụ thể. Nếu Peggy biết mật khẩu, cô luôn ra đúng nhánh. Nếu không, xác suất đúng là 50%. Sau 30 vòng: xác suất gian lận thành công = (1/2)³⁰ ≈ 9.3 × 10⁻¹⁰. Victor bị thuyết phục — mà không biết mật khẩu. Đây là interactive ZKP.

Fiat-Shamir Transform — Non-Interactive Proof

Interactive ZKP không thực tế trên blockchain (cần cả hai online đồng thời). Fiat-Shamir transform giải quyết: thay random challenge của verifier bằng hash của transcript tích lũy đến thời điểm đó — dùng hash như random oracle. Kết quả là NIZK: prover tạo proof một mình, bất kỳ ai verify được bất kỳ lúc nào.

IVzk-SNARK vs zk-STARK – Trade-off bền vững

Hai họ proof chiếm ưu thế trong thực tế. Trade-off giữa chúng là thuộc tính kỹ thuật bất biến — không phụ thuộc thời điểm hay ecosystem cụ thể.

zk-SNARK — Succinct nhưng cần trusted setup

Proof cực nhỏ (~200 bytes với Groth16), verification constant-time bất kể complexity của computation. Ưu điểm không thể bàn cãi cho on-chain verification: gas cost thấp và predictable. Nhược điểm cốt lõi: phần lớn zk-SNARK yêu cầu trusted setup — ceremony khởi tạo CRS (Common Reference String). Nếu toxic waste (secret trong ceremony) không bị xóa, ai giữ nó có thể forge proof hợp lệ cho statement giả mà verifier không phát hiện.

PLONK và các biến thể (Marlin, Sonic, HyperPlonk) giải quyết một phần: universal trusted setup — setup một lần cho tất cả circuit ≤ N constraints, thay vì setup riêng cho từng circuit như Groth16. Giảm gánh nặng nhưng không loại bỏ hoàn toàn trusted setup assumption.

zk-STARK — Transparent nhưng proof lớn

Không cần trusted setup — transparent, dựa hoàn toàn trên hash function và random oracle. Proof lớn (40 KB–200 KB), verification tốn kém hơn. Hai ưu điểm quan trọng: transparency (không cần tin ceremony hay bên thứ ba) và post-quantum security (bảo mật dựa trên collision resistance của hash, không dựa trên discrete log — không bị Shor's algorithm phá).

So sánh — tính chất bền vững

Folding Schemes — Hướng tiếp cận thứ ba

Bên cạnh SNARK và STARK, một họ kỹ thuật dựa trên folding đang phát triển (Nova, HyperNova, SuperNova). Ý tưởng cốt lõi: thay vì prove toàn bộ computation trong một proof lớn, "fold" nhiều step nhỏ vào nhau theo cách accumulative — prover time giảm đáng kể cho computation lặp lại (VM execution step-by-step). Đây là contribution lý thuyết có giá trị lâu dài, bất kể tên implementation cụ thể thay đổi.

VPrivacy Transaction – Các cơ chế ẩn danh hóa

Mỗi kỹ thuật bảo vệ một khía cạnh khác nhau: sender, receiver, amount, hoặc transaction graph. Hiểu từng cơ chế riêng biệt trước khi đánh giá hệ thống tổng hợp.

Stealth Address — Ẩn receiver

Mỗi lần nhận tiền, receiver tạo một one-time address duy nhất từ public key của mình (thường qua ECDH key agreement). Sender tính được địa chỉ đó từ public key receiver, nhưng observer bên ngoài không thể link địa chỉ đó với receiver hay với các payment trước. Không có hai payment nào đến cùng địa chỉ — loại bỏ hoàn toàn receiver clustering.

Trade-off: receiver phải scan blockchain để tìm payment của mình — overhead compute. Giải pháp: tách scanning key (chỉ detect payment, không chi tiêu) khỏi spending key, có thể delegate scanning mà không ảnh hưởng security.

Ring Signature — Ẩn sender

Prover ký bằng một "ring" gồm nhiều public key (key thực và decoy). Verifier xác minh chữ ký đến từ ai đó trong ring, không biết ai. Bảo vệ phụ thuộc vào anonymity set size — số key trong ring. Ring nhỏ (2–4) dễ bị statistical analysis; ring lớn tốn bandwidth hơn. RingCT kết hợp ring signature với Pedersen commitment để ẩn đồng thời sender và amount.

Pedersen Commitment và Confidential Transaction — Ẩn amount

Pedersen commitment: C = r·G + v·H trong đó v là amount, r là blinding factor, G và H là generator points độc lập. Commitment ẩn v (hiding) và không thể thay đổi sau khi commit (binding). Tính chất additively homomorphic quan trọng: C₁ + C₂ = Commit(v₁+v₂) — cho phép verify balance equation (tổng input = tổng output) mà không biết giá trị cụ thể của bất kỳ amount nào.

ZK-SNARK trong shielded transaction — Hệ thống đầy đủ nhất

Zcash shielded transaction dùng zk-SNARK chứng minh đồng thời: (1) sender sở hữu note hợp lệ trong Merkle tree của shielded pool, (2) note chưa được tiêu (nullifier hợp lệ, ngăn double-spend), (3) tổng input = tổng output, (4) commitment output được tạo đúng — tất cả mà không tiết lộ sender, receiver, amount hay transaction history. Proof Groth16 ~192 bytes, verify trong ~1 ms.

VIZK trong L2 Rollup – Scalability khác với Privacy

ZK Rollup dùng Zero-Knowledge Proof để giải quyết scalability — không phải privacy. Đây là điểm nhầm lẫn phổ biến nhất trong lĩnh vực này, với hậu quả thực tế nếu không được làm rõ.

Cơ chế ZK Rollup

Sequencer batch nhiều transaction, thực thi off-chain, tạo validity proof (SNARK hoặc STARK) chứng minh toàn bộ batch được thực thi đúng theo quy tắc protocol, rồi submit proof và state root lên L1. L1 smart contract verify proof (vài ms, ít gas) thay vì re-execute tất cả transaction. Kết quả: throughput cao hơn, cost thấp hơn, settlement bảo đảm bởi L1 security.

Vì sao ZK Rollup không mặc định có privacy

Trong ZK Rollup tiêu chuẩn, toàn bộ transaction data vẫn public — calldata hoặc blob — để bất kỳ ai cũng có thể reconstruct state và verify proof. ZKP ở đây đảm bảo correctness (computation đúng), không phải confidentiality (data bí mật). Ai cũng đọc được lịch sử giao dịch trên ZK Rollup thông thường.

Privacy ZK Rollup — Kết hợp cả hai mục tiêu

Kiến trúc kết hợp: transaction data mã hóa, chỉ tồn tại dưới dạng encrypted commitments on-chain. Validity proof chứng minh correctness và conservation of value — mà không reveal transaction detail. Circuit phải encode đồng thời: proof of note ownership, proof of state transition, proof of balance conservation — trong một proof duy nhất có thể verify on-chain. Prover time và circuit size là bottleneck kỹ thuật chính, không phải lý thuyết.

VIISelective Disclosure – Privacy có kiểm soát

Selective disclosure giải quyết tension cơ bản: người dùng cần privacy, nhưng nhiều bối cảnh yêu cầu chứng minh thuộc tính nhất định. Thay vì "tiết lộ tất cả" hoặc "ẩn tất cả", người dùng prove chính xác điều cần prove — không hơn không kém.

Bốn loại attribute proof phổ biến

• Range proof: "Tôi ≥ 18 tuổi", "Balance ≥ 10,000 USD" — không tiết lộ giá trị chính xác. Cơ chế: Bulletproof, ZK range proof trong R1CS.
• Set membership: "Tôi là công dân EU" — không tiết lộ quốc tịch cụ thể. Cơ chế: Merkle membership proof với ZK.
• Negative proof / Non-membership: "Tôi không trong danh sách sanctioned" — không tiết lộ danh tính. Cơ chế: ZK non-membership proof.
• Predicate proof: "Credential này được ký bởi issuer X, còn hiệu lực" — không tiết lộ nội dung credential. Cơ chế: ZK signature verification.

Kiến trúc ZK-KYC

Mô hình ba lớp: Issuer (ngân hàng, cơ quan nhà nước) thực hiện KYC và ký digital credential. Holder (người dùng) lưu credential và tạo ZK proof khi cần. Verifier (dApp, exchange) verify proof mà không nhận credential gốc. Verifier chỉ biết "credential hợp lệ, ký bởi issuer X, thỏa predicate P" — không biết bất cứ thông tin cá nhân nào.

Nullifier Pattern — Ngăn Double-Signaling

Trong giao thức như Semaphore, người dùng đăng ký trong group (Merkle tree of commitments), sau đó signal (vote, prove membership) với một nullifier: hash của secret key và external context. Nullifier ngăn cùng một người signal hai lần trong cùng context, mà không reveal ai đã signal. Đây là pattern tái xuất hiện trong nhiều hệ thống: anonymous voting, private attestation, whistleblowing protocol.

VIIICompliance & Privacy – Không mâu thuẫn về mặt kỹ thuật

Tranh luận phổ biến đặt privacy và compliance ở hai cực. Thực tế: tension này không phải bất khả giải về mặt kỹ thuật — chỉ là chưa có standard được chấp nhận rộng rãi.

Nguồn gốc của tension

Compliance truyền thống (AML, KYC, Travel Rule) thiết kế cho hệ thống có intermediary: ngân hàng biết tất cả và báo cáo khi được yêu cầu. Trên blockchain public, không cần báo cáo vì tất cả đã public. Trên privacy blockchain, intermediary không tồn tại và data không public — cần mechanism thay thế về mặt kỹ thuật.

Ba mô hình compliance bằng ZK — nguyên lý bền vững

Compliance Key / Viewing Key: Mỗi shielded transaction include một encrypted memo chứa thông tin plaintext, chỉ decrypt được bằng compliance key. Regulator được cấp key — có thể audit mà public không biết. Đây là giải pháp pragmatic nhất: không thay đổi giao thức. Zcash Viewing Key là implementation đơn giản nhất của concept này.

ZK Audit Proof: VASP prove cho regulator rằng "tổng volume tuân thủ threshold X" hoặc "không có transaction từ danh sách Y" — bằng ZKP, không tiết lộ từng giao dịch cụ thể. Equivalent của báo cáo aggregated trong tài chính truyền thống, nhưng verifiable bằng toán học thay vì tin tưởng tổ chức.

Proof of Innocence: Người dùng chứng minh tiền không đến từ source bị sanctioned — mà không tiết lộ source thực. Đảo ngược burden of proof: thay vì "prove guilty", người dùng chủ động prove "không thuộc danh sách đen".

Các tension chưa được giải quyết hoàn toàn

IXConfidential DeFi – Tài chính riêng tư và bài toán MEV

DeFi public state tạo ra chi phí ẩn mà phần lớn người dùng không nhận ra: mọi pending transaction, position, order đều visible trước khi confirm — và điều đó có thể bị khai thác.

Vấn đề cấu trúc của public mempool

Front-running: Attacker thấy pending transaction, submit transaction tương tự với gas cao hơn để execute trước và profit từ price movement do victim tạo ra. Sandwich attack: Attacker đặt transaction mua trước victim (đẩy giá) và bán ngay sau (ăn slippage). Liquidation targeting: Vì collateral position public, attacker theo dõi và liquidate ngay khi threshold đạt — đôi khi trước cả liquidation bot của protocol.

Tổng hợp các hình thức này gọi là MEV (Maximal Extractable Value). MEV không vi phạm protocol rules — nó là hệ quả tất yếu của public mempool kết hợp block producer có quyền sắp xếp transaction tùy ý.

Bốn hướng giải quyết kỹ thuật

Encrypted Mempool: Transaction encrypt trước khi broadcast, decrypt sau khi committed vào block. Attacker không thấy nội dung để front-run. Mechanism decrypt: threshold decryption (yêu cầu đa số validator cooperate), time-lock encryption (decrypt được sau một thời điểm), hoặc TEE. Mỗi cách có trade-off riêng về latency và trust assumption.

Commit-Reveal: Người dùng commit hash của transaction trước, reveal sau một delay. Đơn giản hơn encrypted mempool, nhưng latency cao hơn và không giải quyết mọi loại MEV.

ZK Order Matching: Order submit dưới dạng ZK commitment, matching engine hoạt động trên encrypted state, chỉ reveal kết quả. Phức tạp vì matching algorithm (AMM curve, order book) phải được encode vào ZK circuit.

Private State Machine: Protocol hoạt động hoàn toàn trên encrypted state. Mỗi interaction tạo validity proof chứng minh state transition đúng mà không reveal state. Hướng triệt để nhất, khó nhất — yêu cầu redesign toàn bộ protocol logic.

Trade-off không thể tránh: Privacy vs Liquidation

Trong lending protocol, liquidation phụ thuộc vào việc ai đó biết position đang dưới ngưỡng collateral. Trên DeFi public, mọi người thấy — liquidation bots cạnh tranh, protocol luôn solvent. Trên Confidential DeFi, không ai biết position ở ngưỡng nào — ai liquidate? Khi nào?

Hướng giải quyết: ZK proof of undercollateralization (prove position dưới ngưỡng mà không reveal số cụ thể), keeper network với ZK authorization, hoặc partial disclosure (ẩn identity, không ẩn collateral ratio). Không có giải pháp perfect — đây là tension cơ bản giữa privacy và protocol correctness trong DeFi.

XDeanonymization – Kỹ thuật, giới hạn và nguyên lý

Hiểu cách deanonymization hoạt động quan trọng hơn tin tưởng vào một hệ thống privacy "không thể trace". Các kỹ thuật dưới đây là nguyên lý bền vững — không phụ thuộc vào tool hay tên công ty cụ thể.

Address Clustering — Kỹ thuật nền tảng

Với UTXO-based chain, khi một transaction dùng nhiều input, heuristic mạnh là tất cả input thuộc cùng entity (Common Input Ownership Heuristic). Kết hợp nhiều transaction, xây được đồ thị cluster địa chỉ. Một anchor duy nhất — địa chỉ được biết thuộc entity X — deanonymize toàn cluster. Với account-based chain (Ethereum), clustering dễ hơn: mọi interaction từ một address đều linked trực tiếp.

Timing Correlation

Nếu deposit vào privacy pool lúc 14:34 và withdraw lúc 14:41 cùng denomination — tương quan thời gian đủ để suggest link, dù không có địa chỉ chung. Timing attack hiệu quả khi pool có ít giao dịch và denomination ít. Giải pháp: fixed-size batching (xử lý theo batch cố định) và mandatory delay (tối thiểu một số block trước khi withdraw).

Anonymity Set Degradation

Bảo vệ của privacy system phụ thuộc vào anonymity set — số người dùng/transaction trong cùng pool. Anonymity set nhỏ = dễ guess hơn. Hệ quả thực tế: shielded pool kém bảo vệ hơn khi đa số người dùng dùng transparent address — anonymity set thực tế nhỏ hơn nhiều so với tổng người dùng. Ring signature với ring size nhỏ dễ bị statistical deanonymization.

Off-chain Leakage — Điểm yếu không phải mật mã

Phần lớn deanonymization thực tế không phá vỡ mật mã — mà khai thác thông tin off-chain: IP khi broadcast, KYC tại on/off ramp, metadata từ dApp interaction. Hệ thống mật mã mạnh nhất cũng vô nghĩa nếu người dùng broadcast transaction qua IP lộ rồi rút về tài khoản ngân hàng có tên thật.

XILayered Privacy Architecture – Thiết kế hệ thống toàn diện

Privacy là thuộc tính hệ thống, không phải tính năng của một component. Mô hình phân tích chuẩn chia thành ba lớp độc lập — mỗi lớp có threat model và giải pháp riêng. Điểm yếu ở bất kỳ lớp nào quyết định privacy của toàn hệ thống.

Lớp 1 — Network Layer

Threat: IP address khi broadcast transaction bị ghi và link với on-chain activity qua timing. Tor và I2P là giải pháp kinh điển — latency overhead nhưng trustless. Dandelion++ thiết kế riêng cho blockchain: transaction forward qua chuỗi node theo "stem" trước khi "fluff" ra toàn mạng — giảm khả năng trace IP nguồn gốc. Mixnet (Nym) thêm một lớp: mix message với decoy traffic, không phân biệt được message thật với giả theo thời gian.

Lớp 2 — Transaction Layer

Threat: sender, receiver, amount, transaction graph đều visible. Đây là lớp được nghiên cứu nhiều nhất và có production-ready solution. Stack đầy đủ: stealth address (ẩn receiver) + ring signature hoặc ZK-SNARK (ẩn sender) + Pedersen commitment (ẩn amount) + nullifier (chống double-spend). Kết hợp đầy đủ nhất là Zcash shielded transaction và Monero RingCT.

Lớp 3 — Execution Layer (Computation Privacy)

Threat: logic của smart contract execution và contract state đều visible. Ba hướng công nghệ, mỗi hướng có trust assumption khác nhau:

• FHE (Fully Homomorphic Encryption): Tính toán trực tiếp trên dữ liệu mã hóa mà không decrypt. Tính chất lý tưởng: hoàn toàn trustless, kết quả đúng, không trust bất kỳ party nào. Bottleneck hiện tại: overhead computation cao. Đây là bài toán engineering đang được giải quyết qua hardware acceleration — không phải impossibility lý thuyết.
• MPC (Multi-Party Computation): Nhiều party tính kết quả mà không bên nào biết input của bên kia. Phù hợp khi data phân tán tự nhiên. Chi phí chính: số round communication — bottleneck là bandwidth và latency, không phải compute.
• TEE (Trusted Execution Environment): Hardware enclave thực thi code isolated, không đọc được từ bên ngoài. Nhanh nhất trong ba nhưng cần trust hardware manufacturer — đây là trust assumption khác, không phải không có trust. Side-channel attack từng exploit một số TEE trong điều kiện cụ thể.

Ma trận đánh giá — Tính chất bền vững

XIIKết luận – Privacy là kiến trúc, không phải tính năng bổ sung

Blockchain public đặt transparency là nền tảng của trust — đây là lựa chọn đúng đắn cho nhiều bài toán. Nhưng transparency tuyệt đối tạo ra exposure tuyệt đối. Không hệ thống tài chính nào hoạt động theo mô hình đó — và không nên.

ZKP cung cấp công cụ để giải quyết tension này không phải bằng cách giảm transparency, mà bằng cách biến transparency thành selective: chứng minh điều cần chứng minh mà không tiết lộ những gì không cần thiết. Bước chuyển từ "tin tưởng vì tất cả đều thấy" sang "tin tưởng vì toán học đảm bảo".

Sáu nguyên lý không thay đổi theo thời gian

• Privacy là thuộc tính hệ thống, không phải component — cần thiết kế đa tầng từ đầu
• Deanonymization phần lớn đến từ operational security failure, không phải cryptography failure
• ZK Rollup và Privacy ZK Protocol dùng cùng công nghệ cho mục tiêu khác nhau — scalability ≠ privacy
• Selective disclosure — không phải full anonymity — là mô hình phù hợp nhất khi cần kết hợp compliance
• Trusted setup là assumption, không phải lỗ hổng — cần hiểu đúng mức độ rủi ro thực tế
• FHE overhead cao là vấn đề engineering đang được giải quyết, không phải giới hạn lý thuyết

Những gì thay đổi và không thay đổi

Không thay đổi: Toán học của ZKP — ba thuộc tính (completeness, soundness, zero-knowledge), Fiat-Shamir transform, Pedersen commitment, trade-off cơ bản SNARK vs STARK. Đây là nền tảng lý thuyết đã được chứng minh qua nhiều thập kỷ.

Sẽ thay đổi: Prover time sẽ giảm qua hardware acceleration, proof size nhỏ hơn qua thuật toán mới, FHE overhead giảm, tên dự án và ecosystem xáo trộn. Nhưng bài toán cơ bản — làm thế nào chứng minh mà không tiết lộ, làm thế nào tuân thủ mà không surrender privacy — là bất biến.