Copy Constraint

A copy constraint is a mathematical rule that forces two or more variables in a computational trace to have the same value. This ensures that when a value is read from memory or used in multiple steps, it is identical each time, preventing logical errors in the zero-knowledge proof.

• Purpose: Guarantees that the prover's claimed execution path is internally consistent.
• Mechanism: Encoded as polynomial equations that must be satisfied for the proof to be valid.

In the Rank-1 Constraint System (R1CS), a copy constraint is expressed by wiring variables together. For example, if the output of gate A is meant to be the input to gate B, the R1CS enforces that the variable representing that wire has a single, consistent value throughout the circuit.

• Example: In a circuit calculating y = x * x, the variable for x must be the same in both multiplication inputs.

In modern proof systems like Plonk, copy constraints are managed through a permutation argument. This powerful technique checks that a set of values in one column of the execution trace is a permutation of values in another column, enforcing equality across arbitrary locations.

• Efficiency: Allows for more flexible and efficient circuit design compared to older methods.
• Core Component: The permutation argument is a fundamental building block of the Plonk protocol.

Without copy constraints, a malicious prover could "cheat" by using different values for the same logical variable at different steps, generating a valid proof for an incorrect computation. Copy constraints cryptographically bind these variables, making such attacks impossible.

• Security Role: Essential for the soundness of the zero-knowledge proof system.
• Result: The verifier can be certain the prover executed the program correctly, not just a similar-looking one.

It's crucial to distinguish between the two main types of constraints in zk circuits:

• Arithmetic Constraints: Enforce that a specific mathematical operation (e.g., addition, multiplication) was performed correctly on a set of inputs to produce an output.
• Copy Constraints: Enforce that values are carried forward correctly between operations, ensuring data integrity across the computation.

Together, they fully define a correct program execution.

A copy constraint ensures that a variable assigned in one part of a circuit is equal to the same variable used elsewhere. For example, in a digital signature verification circuit:

• The public key derived from the private key must match the public key provided as an input.
• The message hash computed inside the circuit must be identical to the signed hash. Without copy constraints, these values could differ, breaking the logical integrity of the proof.

A common technique is to prove a value is within a range (e.g., 0-255 for an 8-bit number). The circuit may split the value into bits and prove each bit is binary (0 or 1). A copy constraint is then used to reconstruct the original value from these bits, ensuring the decomposed representation is consistent with the input variable being range-checked.

In a zk-rollup, the proof must show that the new state root is correctly computed from the old state root and a batch of transactions. Copy constraints are critical here:

• The old root used in the state transition function must be the same as the publicly committed root.
• Intermediate Merkle tree paths and leaf values must be consistently used across multiple hash computations within the circuit.

In a private payment system like Zcash, a zero-knowledge proof must show that:

• The input notes being spent are valid and unspent.
• The total value of inputs equals the total value of outputs plus a transaction fee. Copy constraints wire the nullifiers (unique identifiers for spent notes) and commitments (new notes) correctly, ensuring the same secret values are used consistently to generate both, which prevents double-spending and preserves value balance.

Advanced proof systems like Plonk and Halo2 use lookup arguments to prove a value exists in a pre-defined table (e.g., a valid S-box output in AES encryption). This relies heavily on copy constraints to:

• Enforce that the queried value in the main circuit is identical to the value in the lookup table.
• Maintain consistency between the sorted copies of the main and table polynomials during the proof argument.

When a high-level program (e.g., written in Circom or Noir) is compiled to an arithmetic circuit, the compiler generates a Rank-1 Constraint System (R1CS) or Plonkish arithmetization. Copy constraints are automatically created to wire together all instances where the same variable is used across different gates or sub-components, forming the execution trace that the proof system must satisfy.

The constraint is enforced by a zero-knowledge proof circuit. It cryptographically binds a secret value (like a note's serial number or a commitment) to specific locations within the circuit's execution trace. The prover must demonstrate that the same value appears in all designated locations, proving consistent usage without revealing the value.

• Cryptographic Binding: Uses commitments or hashes to represent the secret data.
• Circuit Logic: The proof's arithmetic constraints verify equality of the hidden values.
• Soundness: The cryptographic assumptions of the proof system guarantee the constraint cannot be violated.

This is the canonical use case in privacy-preserving blockchains like Zcash. A spend authorization signature is valid only if it references a specific, unspent note commitment. The copy constraint ensures the same note's nullifier (proving it's spent) and the authorization secret are linked.

• Nullifier Generation: The nullifier is a deterministic function of the note's secret.
• Constraint Enforcement: The circuit proves the spender knows the secret corresponding to both the spent note and the nullifier.
• Result: A note cannot be used in two valid transactions, as its unique nullifier would be published twice.

In ZK-Rollups, copy constraints ensure user state updates are applied consistently across the rollup's Merkle tree. When a user's balance changes, the proof must show the old state root is correctly updated to a new one, with the user's account leaf modified accordingly.

• Merkle Path Verification: The circuit includes the authentication path for the user's leaf.
• Leaf Update: The constraint forces the old leaf hash and new leaf hash to correspond to the same public key/address.
• System Integrity: Guarantees the prover isn't incorrectly modifying another user's state or creating invalid transitions.

Modern proof systems like Plonk, Halo2, and R1CS implement copy constraints via wiring or permutation arguments. Instead of requiring equations to be literally equal, they allow the prover to specify that the value in one wire or cell must equal the value in another.

• Permutation Argument: A core component of Plonk that proves two sets of values are permutations of each other, enabling efficient equality checks across the entire circuit.
• Witness Copying: The prover's witness assignment must satisfy these predefined "copying" relationships.
• Efficiency: This method is more efficient than using a separate equality constraint for every pair of values.

Institutions can use ZK-proofs with copy constraints to prove compliance (e.g., solvency, transaction correctness) without exposing sensitive ledger data. The constraint ensures that the private inputs used to calculate a public summary (like a total balance) are the same inputs referenced in the underlying, hidden transactions.

• Data Integrity Proof: The auditor proves that all private entries sum to a public total.
• Constraint Role: Guarantees each hidden data point is used once and only in its correct calculation.
• Use Case: A dark pool proving it has sufficient collateral without revealing individual client positions.

It's crucial to distinguish copy constraints from range checks. Both are common in ZK circuits but serve different purposes.

• Copy Constraint: Enforces equality (a == b). "This secret value here must be the same as that secret value there."
• Range Check: Enforces bounds (0 <= a < 2^64). "This secret value must fit within 64 bits."

A single transaction proof will use both: range checks to ensure values don't overflow, and copy constraints to ensure consistency of secrets like keys and nullifiers.