Different PETs to the Rescue

High level on the different tech solutions.

Different Privacy Enhancing Technologies can help solve on-chain privacy, let us present a high level below:


Zero-Knowledge Proofs (ZK)

Idea: Prove that a computation is correct without revealing its inputs.

Pros:

  • High verification efficiency — great for on-chain proofs.

  • Strong cryptographic soundness (no need to trust hardware).

  • Ideal for proving statements like “this transfer is valid” without revealing amounts.

Cons:

  • Limited expressiveness (complex circuits are costly).

  • Expensive proving time and large setup requirements.

  • Harder to implement arbitrary private smart contracts.

  • Not suitable for private shared state (application like sealed bid auctions, election, and many more).


Secret Sharing–Based MPC

Idea: Split data into shares and distribute them among parties that jointly compute a function without revealing their shares.

Pros:

  • No single point of trust — privacy is distributed.

  • Scales well for recurring computations between fixed parties.

Cons:

  • High communication rounds overhead.

  • Requires multiple online parties during computation.

  • Poor performance for dynamic or public blockchain environments.


FHE-Based MPC (Fully Homomorphic Encryption)

Idea: Perform computation directly on encrypted data without ever decrypting it.

Pros:

  • Data never leaves encrypted form.

  • No need for multiple parties during computation (but needed for decryption).

  • Suitable for cloud or off-chain confidential processing.

Cons:

  • Extremely slow (105–108× slower than plaintext computation). Hardware acceleration may reduce this overhead, but still very slow.

  • Complex key generation and management.

  • Difficult to integrate with composable smart contracts.


Garbled-Circuit-Based MPC

Idea: Encode a computation as a Boolean circuit that can be securely evaluated by one or more parties using encrypted “wire labels.”

Pros:

  • Constant-round protocols with low latency.

  • Efficient for arbitrary logic and branching (smart contracts).

  • Very flexible, supporting computation of normal logic (e.g., ADD256) and cryptographic logic (e.g., AES, SHA functions).

  • Suitable for decentralized execution (as in gcEVM).

Cons:

  • Requires relatively high bandwidth to deliver the garbled circuits to the evaluator, e.g., about 1KB per Private ERC20 (but this does not impact the real-time performance - resources consumption to execute an ingress private workload is very low).

  • Trustless setup requires cryptographic coordination between parties.


Indistinguishable Obfuscation (iO)

Idea: Make code publicly available but cryptographically obfuscated so that its logic cannot be reverse-engineered.

Pros:

  • Theoretically maximal privacy — hides how computation works.

  • Could enable private shared state in public contracts.

Cons:

  • Still largely theoretical — inefficient far from practical today.

  • Relies on unproven or heavy cryptographic assumptions.

  • Hard to update or debug obfuscated logic.


Trusted Execution Environments (TEE)

Idea: Execute code inside secure hardware enclaves that isolate computation from the host OS.

Pros:

  • Fast and practical today (near-native performance).

  • Enables off-chain confidential compute with on-chain attestation.

Cons:

  • Requires trusting hardware vendors (e.g., Intel, ARM), which repeatedly break

  • Vulnerable to side-channel and firmware attacks.

  • Limited scalability and decentralization - poses many single points of failure.

Last updated