Private computation system on blockchain

Development of Private Computation System on Blockchain

Smart contracts are public by definition: anyone can read the contract state, decode the transaction calldata, trace the history. This is an inherent property of blockchain — and simultaneously the main obstacle for an entire class of applications. Sealed-bid auctions, private medical data, corporate calculations, anti-front-running mechanisms in DeFi — all of this requires blockchain computations without revealing input data. Task: give a smart contract the ability to work with secret data while preserving result verifiability.

Three Technology Stacks, Three Sets of Tradeoffs

Before designing a system, you need to clearly understand which technology solves your specific task. There is no universal answer.

Zero-Knowledge Proofs (ZKP)

ZKP allows proving a fact without revealing data: "I know the private key", "my balance >= 100", "this transaction is correct". The proof is published on-chain, the verifier contract checks it in O(1) time.

When it fits: computation is deterministic, input data is static (doesn't change during computation), maximum decentralization is needed — no trust in third parties.

Key proof systems:

For Ethereum: Groth16 verification costs ~250K gas, PLONK — ~300-500K. STARKs are expensive for on-chain verify, better suited for L2 (StarkEx, StarkWare).

Developing ZK circuits. Circuits are written in specialized languages:

• Circom — most widespread, compiles to R1CS, generates Solidity verifier. Used in Tornado Cash, Semaphore, Aztec
• Noir (Aztec) — high-level, syntax close to Rust, compiles to PLONK
• Cairo (StarkWare) — for STARKs, used in StarkNet

Example circuit in Circom for proving knowledge of hash preimage:

pragma circom 2.0.0;
include "poseidon.circom";

template HashPreimage() {
    signal input preimage;   // private input
    signal input hash;       // public input
    signal output valid;

    component hasher = Poseidon(1);
    hasher.inputs[0] <== preimage;
    hash === hasher.out;
    valid <== 1;
}

component main {public [hash]} = HashPreimage();

Important nuance: using SHA256 in ZK circuits is expensive (many constraints). Poseidon — ZK-friendly hash function, specially optimized for circuits, an order of magnitude more efficient.

Operational limitations of ZKP. Proof generation time depends on circuit size: simple circuit (~10K constraints) — 1-5 sec on regular hardware. Complex (~1M constraints) — minutes. For user-facing applications you need a server for proof generation (centralized tradeoff) or WASM in browser (slow, but decentralized). zkVM solutions (RISC Zero, SP1) allow generating ZK proofs for arbitrary Rust/C code without writing circuits — this significantly lowers the barrier to entry.

Trusted Execution Environments (TEE)

TEE (Intel SGX, AMD SEV, ARM TrustZone) — hardware-isolated execution environment. Code and data in TEE are inaccessible even to the operating system and hypervisor. Technically: memory encryption at CPU level, code measurement via remote attestation.

When it fits: complex computations (ML inference, large data processing), low latency required, trust in hardware vendor is acceptable.

Integration with blockchain via attestation:

1. Code in TEE computes result
2. TEE generates attestation report (Intel DCAP or AMD SEV signature) — proof that exactly this code executed in the protected environment
3. On-chain verifier checks attestation and accepts result

Key projects: Phala Network (TEE for smart contracts on Substrate), Secret Network (TEE + Cosmos), Oasis Protocol (SGX for EVM-compatible contracts), Marlin Oyster (TEE compute marketplace for Ethereum).

TEE vulnerabilities. SGX has known side-channel attacks: Spectre, Meltdown, Plundervolt. Intel periodically releases microcode patches, but the fundamental problem remains: trust in the manufacturer. For high-stakes financial applications TEE alone is insufficient — use combination of TEE + MPC.

Multi-Party Computation (MPC)

MPC allows multiple parties to jointly compute a function of their private inputs without revealing those inputs to each other. Classic example: millionaires problem — determine who is richer without revealing actual amounts.

Key protocols:

• Secret Sharing (Shamir's) — secret is divided into N shards, any K recover the secret. Basic primitive for most MPC schemes
• Garbled Circuits — efficient for boolean computations, used in DECO (TLS oracle without data disclosure)
• SPDZ — arithmetic circuits, practical for financial computations with dishonest participants
• Threshold Signature Schemes (TSS) — decentralized key management without single point of compromise

For blockchain MPC is most often used for:

1. Threshold custody — key never exists in complete form in one place. Transaction signature — result of interaction between N nodes
2. Private price feeds — oracles compute median price without revealing individual values
3. Dark pool trading — order matching without revealing order book

Practical implementation. Libraries: MP-SPDZ (academic, supports many protocols), tss-lib (Go, used in tBTC, Binance Bridge), threshold-bls (Rust, used in Chainlink VRF and DRAND).

Architecture of Hybrid System

In practice, the most robust private computation systems combine technologies:

User (secret input)
        ↓
    [TEE enclave]
    Computes result
    Generates ZK proof of correctness
        ↓
    On-chain Verifier Contract
    Checks TEE attestation + ZK proof
        ↓
    Executes logic based on verified result

Such scheme: TEE provides confidentiality and speed, ZK proof provides verifiability without trusting specific TEE vendor.

Example: sealed-bid auction.

Problem: in public smart contract bids are visible to all before reveal phase. MEV bots can front-run.

Solution with Commit-Reveal + ZKP:

1. Participant hashes bid: commitment = Poseidon(bid_amount, salt)
2. Publishes commitment on-chain
3. After deadline publishes ZK proof: "my bid >= reserve price" without revealing amount
4. Winner determined via MPC among participants passing ZK verification

More complex variant (fully private): Aztec Connect or equivalent — entire auction inside ZK rollup.

Aztec Network: ZK-native Privacy

Aztec — L2 with native privacy for EVM. Smart contracts ("Aztec contracts" / Noir) have private functions (executed in browser, generate ZK proof) and public functions (regular EVM). Private function can call public, but not vice versa — this is fundamental architecture limitation.

Aztec.js SDK for interacting with private contracts:

import { createAztecNodeClient, Fr, AccountWallet } from '@aztec/aztec.js';

// Calling private function - proof generated locally
const tx = await contract.methods
  .private_transfer(recipient.address, amount)
  .send({ from: wallet });

await tx.wait(); // on-chain proof verification

Aztec Connect (deprecated, but architecturally instructive) allowed private interaction with Ethereum DeFi protocols through "shields" — aggregation of private transactions.

Critical Implementation Details

Randomness in ZK. Many cryptographic protocols require reliable randomness source. On-chain pseudorandom (blockhash, timestamp) is predictable. Solutions: Chainlink VRF (verifiable random function), DRAND (distributed randomness beacon), commit-reveal with multiple participants.

Gas costs. ZK verification on-chain is expensive. Groth16 verifier — 250K gas on Ethereum mainnet ($5-15 at moderate gas). For frequent operations: batch verification (multiple proofs in one transaction), or deploy on L2 (Base, Arbitrum — 10-50x cheaper).

Key management in MPC. Key generation ceremony — critical moment. If all participants are compromised simultaneously during keygen — entire scheme collapses. Practice: geographically distributed operators, different technologies (different TEE vendors), threshold >= 2/3.

Auditing ZK circuits. Standard Solidity audit is insufficient. Need separate circuit audit: checking underconstrained signals (signal without constraint can take any value — classic vulnerability), completeness (correct witness always creates valid proof), soundness (impossible to create proof for false statement). Firms with ZK expertise: Least Authority, Trail of Bits (ZK specialization), ABDK.

Design and Development Process

Phase 1 — Threat model and technology selection (1-2 weeks). What exactly is secret? From whom? What is threat model — curious observer, active adversary, compromised node operator? This determines choice: ZKP (trust no one), TEE (trust vendor), MPC (trust threshold of participants).

Phase 2 — Prototype and proof of concept (2-4 weeks). ZK circuit in Circom/Noir with minimal constraints. Benchmark: proof generation time, gas cost of verification, compatibility with target network.

Phase 3 — Development of production system (6-12 weeks). Circuit with full logic, on-chain verifier, off-chain components (proof generation server or WASM client), integration tests.

Phase 4 — Audit (4-8 weeks). ZK circuit audit + smart contract audit — these are different specializations. Cryptographic review for MPC protocol.

Phase 5 — Deployment and monitoring. Trusted setup ceremony (if Groth16/PLONK), parameters are publicly verifiable. Monitoring: proof generation latency, failed verification rate, gas consumption.

Realistic timeline for non-trivial private computation system — 4-6 months from design to mainnet, including audit.