Formal Predicate

A formal predicate is a pure function that takes on-chain data as input and returns a boolean (true/false) output. Its result is deterministic—given the same inputs, it will always produce the same output, allowing any observer to independently verify the condition's state. This eliminates ambiguity and ensures trustless execution.

• Example: A predicate checking if a wallet's USDC balance is > 1000 will always return the same result for a given block height.

Predicates are designed as atomic logic units that can be combined using logical operators (AND, OR, NOT) to form complex conditional statements. This composability allows developers to build sophisticated on-chain automations and access control rules from simple, auditable components.

• Example: (Wallet Age > 30 days) AND (TVL > $1M) OR (Has Specific NFT) creates a multi-faceted condition for a lending protocol.

Predicates evaluate against a specific, immutable state root (e.g., a block hash). This ensures the condition is checked against a consistent snapshot of the blockchain, preventing race conditions and front-running. The predicate logic is executed off-chain by indexers, with only the cryptographic proof of the result submitted on-chain for verification.

• Key Benefit: Enables gas-efficient evaluation of complex conditions without expensive on-chain computation.

While predicates commonly query core blockchain state (balances, transaction history), they can be extended to incorporate verified data from oracles (e.g., price feeds) or cross-chain state proofs. The predicate's logic defines the data sources, making it a flexible tool for conditions that depend on real-world or multi-chain information.

• Use Case: A predicate could check if (ETH price > $3500 on Chainlink) AND (user has staked 10 ETH on Lido).

Each predicate is defined by a formal specification that precisely outlines its required inputs, the logic to be applied, and the expected output type. This specification acts as a single source of truth, enabling different parties (developers, indexers, verifiers) to have a shared, unambiguous understanding of the condition's behavior, which is critical for security and interoperability.

These predicates verify that a transaction is authorized by the rightful owner of an asset, typically by checking a cryptographic signature. They are the most fundamental type, enforcing the non-repudiation and authenticity of state changes.

• Example: A standard Bitcoin or Ethereum transaction uses a signature check to prove control of the private key associated with the UTXO or account.
• Mechanism: The predicate evaluates isValidSignature(tx, pubKey, sig) == true.

These predicates enforce that a state transition can only occur after (or before) a specific point in time or block height. They are essential for implementing vesting schedules, time-based releases, and commitment schemes.

• Example: A smart contract that locks tokens until a block.timestamp > unlockDate.
• Types: Absolute locks (after date X) and Relative locks (after N blocks from now).

These predicates require authorization from a predefined subset of a group of signers. They decentralize control and are used for treasury management, corporate governance, and escrow.

• Structure: Defined by parameters (m, n), where m signatures are required from a set of n possible public keys.
• Example: A 2-of-3 multisig wallet where any two designated key holders must sign to execute a transaction.

These predicates evaluate conditions based on the current on-chain state, such as account balances, storage values, or oracle data. They enable complex conditional logic and composability.

• Example: A predicate that allows a withdrawal only if contractBalance > 100 ETH or if a specific oracle price feed reports price > $50.
• Use Case: The foundation for decentralized finance (DeFi) lending protocols and conditional payments.

These are arbitrary, Turing-complete programs that define custom validation logic. They offer maximum flexibility, allowing developers to encode any computable condition. Bitcoin Script and Ethereum Smart Contracts are prominent examples.

• Characteristic: The predicate's code is part of the output or contract and is executed during validation.
• Trade-off: Greater power comes with increased complexity and potential for bugs or high gas costs.

These advanced predicates use cryptographic proofs (like zk-SNARKs or zk-STARKs) to verify that a state transition is correct without revealing the underlying data. They are critical for privacy and scaling.

• Mechanism: The predicate validates a zero-knowledge proof attesting that the new state is the correct output of applying a valid transaction to the old state.
• Application: Used in zk-rollups (e.g., zkSync, StarkNet) and private payment systems.

A formal predicate is a function that returns a boolean value (true/false) based on a set of inputs, formally specifying a condition that must be satisfied. In blockchain, it acts as the executable rule within a zero-knowledge proof or a smart contract.

• Structure: Typically expressed as an arithmetic circuit or a constraint system.
• Purpose: To prove knowledge of a witness that satisfies the predicate without revealing the witness itself.
• Example: A predicate could verify that a transaction input's value equals its output's value, proving conservation of assets.

In zk-SNARKs and zk-STARKs, the formal predicate is the NP statement being proven. It defines the relationship between a public statement and a private witness.

• Public Inputs: Known parameters (e.g., a Merkle root, a transaction hash).
• Private Witness: Secret data known only to the prover (e.g., a private key, a Merkle path).
• Role: The prover generates a proof that they know a valid witness making the predicate evaluate to true, which the verifier can check using only the public inputs.

zkVMs (Zero-Knowledge Virtual Machines) like zkEVM compile high-level code (e.g., Solidity) into a formal predicate represented as a circuit. This allows for proving general computation.

• Process: Program logic is transformed into a set of constraints over a finite field.
• Tools: Frameworks like Circom, Halo2, and Noir are used to write and compile these predicates.
• Output: The resulting circuit is the formal predicate that defines the valid execution trace of the program.

Beyond ZK proofs, predicates are fundamental to conditional logic in smart contracts and oracle systems.

• Smart Contracts: An if statement checking a balance is a simple predicate.
• Oracle Services: Pyth Network's price feeds use predicates to verify that a reported price is signed by a quorum of authorized publishers.
• State Channels: Predicates define the conditions under which a channel can be settled or disputed.

A formal predicate generalizes the concept of a digital signature. While a signature validates a specific message from a specific key, a predicate can encode far more complex authorization logic.

• Signature: verify(pubKey, message, sig) == true
• Predicate: Can express "signed by one of these 5 keys" OR "proves knowledge of a valid ZK proof" OR "spent a specific type of NFT."
• Framework: Covenants in Bitcoin and predicate locks in UTXO-based chains use this for advanced spending conditions.

A computational model that represents a formal predicate as a series of addition and multiplication gates over a finite field. It is the primary structure used to encode complex statements for zero-knowledge proofs.

• Purpose: Translates high-level program logic into a format a ZK-SNARK or ZK-STARK prover can process.
• Example: A statement like "I know the private key for this public address" is compiled into a circuit where the prover's secret witness values satisfy the circuit's constraints.

A specific, intermediate representation of an arithmetic circuit, commonly used in ZK-SNARK constructions like Groth16. It expresses the circuit's logic as a set of quadratic equations that the prover's witness must satisfy.

• Structure: Defined by three matrices (A, B, C) that encode the circuit's constraints.
• Role: Serves as the standardized format for the trusted setup ceremony and proof generation, bridging the circuit to the final cryptographic proof.

The private data known only to the prover that satisfies the formal predicate. It is the secret input to the arithmetic circuit or R1CS.

• Function: Acts as the solution to the constraint system. The prover uses it to generate a proof without revealing it.
• Key Property: In a ZKP for transaction validity, the witness includes private keys, intermediate hashes, or other confidential state that validates the public statement.

A Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, a cryptographic protocol used to prove the validity of a formal predicate. It is characterized by small proof sizes and fast verification.

• Key Features: Succinctness (proofs are small), Non-interactivity (no back-and-forth needed after setup).
• Relation to Predicate: A ZK-SNARK system takes a compiled predicate (e.g., as an R1CS) and generates a proof that the prover knows a valid witness for it.

A one-time, ceremony-dependent initialization phase required for many ZK-SNARK systems (e.g., Groth16). It generates public parameters (a Common Reference String) needed to prove and verify a specific formal predicate or circuit.

• Critical Security Assumption: The ceremony's toxic waste must be securely discarded; if compromised, false proofs could be generated.
• Alternatives: ZK-STARKs and some newer SNARKs (e.g., PLONK with universal setup) reduce or eliminate this trust requirement.

A modern, universal ZK-SNARK construction that allows many different formal predicates (circuits) to share a single trusted setup. This contrasts with circuit-specific setups used in earlier SNARKs.

• Key Innovation: Its universal and updatable setup reduces overhead and improves flexibility for blockchain applications.
• Mechanism: Uses a permutation argument to check the consistency of wire values across the entire circuit, enabling efficient proof generation for complex predicates.