Private Function Execution

PFE ensures the confidentiality of inputs and outputs for a specific function call. While the contract's public state and code remain verifiable, the private data passed into the function and the resulting computation are encrypted and visible only to authorized parties. This is distinct from fully private contracts, as it targets specific logic.

• Example: A sealed-bid auction where the bid amount is a private input, and the winning bidder is the private output, revealed only after the auction closes.

The integrity of private computations is enforced using Zero-Knowledge Proofs (ZKPs). The prover (often the transaction sender) generates a cryptographic proof that they executed the private function correctly according to the public contract logic, without revealing the private inputs. The network verifiers check this proof to ensure validity.

• Core Mechanism: A zk-SNARK or zk-STARK proof is submitted on-chain, attesting to the correct execution of the private function's constrained logic.

PFE enables controlled interaction between private and public contract state. A private function can read from public state and make authorized updates to it based on hidden logic, publishing only the resulting state change. This creates a hybrid model where public ledger integrity is maintained alongside private computation.

• Example: A private voting contract that reads a public list of token holders (public state), tallies encrypted votes (private computation), and updates the final vote count (selective public output).

An alternative to ZKPs, PFE can be implemented using Trusted Execution Environments like Intel SGX. Here, private data is processed inside a secure, isolated hardware enclave. The TEE provides an attestation that the code ran correctly, which is then verified on-chain. This method is often more computationally efficient for complex logic but introduces different trust assumptions regarding hardware integrity.

PFE systems require robust cryptographic access control to manage who can provide private inputs and who can decrypt outputs. This is typically managed via public-key encryption schemes. The function's logic defines the authorization policy, such as requiring a signature from a specific key to submit a private input or encrypting outputs to a recipient's public key.

• Common Pattern: Use of encryption to a committee's public key or threshold decryption schemes for output revelation.

This architecture separates the heavy off-chain computation (generating the proof or running the TEE) from the lightweight on-chain verification. The verifier contract on the blockchain is small and cheap to run, checking only the cryptographic proof or attestation. This design preserves scalability by keeping complex, data-intensive processing off the ledger while maintaining decentralized trust via verification.

Many real-world private execution systems use hybrid approaches that combine multiple cryptographic primitives to balance performance, security, and functionality.

• TEE + ZKP: Use a TEE for efficient private computation and a ZKP to create a verifiable attestation of the TEE's integrity and correct execution (e.g., proof of honest enclave).
• MPC + FHE: Use FHE to encrypt data for computation and MPC protocols to manage decryption keys among a committee.
• Goal: Mitigate the limitations of any single technology (e.g., TEE hardware trust, ZKP prover cost).

Private Oracles are specialized services that fetch, decrypt, and compute on off-chain private data (e.g., credit scores, medical records) before delivering an encrypted result or a zero-knowledge proof to the blockchain. They act as a bridge between private real-world data and on-chain private smart contracts.

• Function: Provide attested external data to private contracts without leaking the source data.
• Implementation: Often rely on TEEs to create a trusted environment for data processing.
• Example: A loan contract can privately verify a user's income via an oracle without exposing the actual salary figure on-chain.

PFE allows for the creation of on-chain dark pools, where large trade orders are matched without revealing size or direction to the public mempool.

• Key Mechanism: Order matching logic (price, size) is executed confidentially within a Trusted Execution Environment (TEE) or via ZK proofs.
• Benefit: Mitigates market impact and protects institutional traders from predatory MEV bots.
• Example: A DEX can offer a private order book where the matchOrders function's logic and inputs are kept secret.

PFE enables private voting on DAO proposals, protecting voter privacy while ensuring the tally is verifiably correct.

• Process: Voters submit encrypted votes or zero-knowledge proofs of their choice.
• Execution: A private function, such as tallyVotes, computes the result (e.g., yes/no count) without leaking individual votes.
• Advantage: Prevents voter coercion and vote-buying, common issues in transparent on-chain governance.

Web3 games and dynamic NFTs use PFE to manage hidden game state or reveal mechanics.

• Example: Mystery Boxes: The logic determining the NFT inside a box is executed privately. The outcome is only revealed to the opener.
• Example: Stealth Game Moves: A player's move in an on-chain strategy game can be committed privately and later revealed and verified.
• Technology: Often implemented using commit-reveal schemes with hashes, or more advanced ZK circuits for complex logic.

Businesses use PFE to run sensitive business logic on a blockchain while keeping inputs, outputs, and the logic itself confidential from competitors and even the node operators.

• Use Cases:
  • Supply Chain: Verifying a shipment meets conditions without exposing invoice details.
  • Credit Scoring: Computing a loan eligibility score using private user data.
  • Audits: Performing internal audits on encrypted financial data.
• Platforms: Implemented via confidential VMs like Oasis Sapphire or TEE-based chains.

PFE acts as a direct defense against Maximal Extractable Value (MEV) by hiding transaction intent until it is too late for bots to front-run.

• How it Works: A user's transaction (e.g., a swap) is submitted as an encrypted bundle or with a private function call.
• Execution: The sequencer or validator executes the trade logic in a private environment, only broadcasting the final, immutable state change.
• Result: The user's slippage tolerance and exact trade path are hidden, neutralizing sandwich attacks and unfair ordering.

A critical challenge in PFE is ensuring that the private inputs provided to the off-chain function are correct and available. Attack vectors include:

• Input withholding: A malicious party submits an execution result but refuses to reveal the input data needed for others to verify.
• Garbage input: Providing nonsensical private data that leads to a valid but meaningless state change. Solutions often involve commitment schemes (like hashes) to bind inputs to the public transaction and fraud proofs or validity proofs to challenge incorrect executions.

PFE systems often rely on a designated set of operators or a sequencer to perform the private computation. This introduces centralization risks:

• Censorship: Operators can refuse to process certain transactions.
• Liveness failure: If operators go offline, the private functionality halts.
• Collusion: Operators could collude to steal funds or manipulate outcomes. Trust models vary from permissioned (known entities) to permissionless with slashing (operators stake collateral) to decentralized networks (like a TEE-based proof-of-stake).

PFE can help smart contracts comply with data protection regulations like GDPR or HIPAA by ensuring personal data never touches the public ledger. However, this creates new considerations:

• Auditability: How do regulators or auditors verify compliance if data is private?
• Key Management: Who controls the encryption keys, and what happens if they are lost?
• Jurisdiction: Which laws apply to computations running in geographically distributed TEEs? PFE must be designed with privacy-by-design principles and clear operational governance.

A Confidential Smart Contract is a smart contract where the contract's state, inputs, and execution logic are kept private from the public blockchain and other participants, except for explicitly designated parties.

• Key Principle: Selective disclosure and state confidentiality.
• Implementation: Built using primitives like Private Function Execution, TEEs, or ZKPs.
• Example: A sealed-bid auction contract where bids remain encrypted until the reveal phase.

State Encryption refers to the practice of storing a blockchain's state (account balances, contract storage) in an encrypted form. Access to decrypt the state is controlled by cryptographic keys or conditions defined by Private Function Execution logic.

• Key Principle: Encrypted-at-rest storage.
• Function: Protects data privacy even from validating nodes that store the blockchain history.
• Relationship: Often the output or persistent data from a Private Function Execution is written to the chain as encrypted state.