Public Input

In zero-knowledge proof (ZKP) systems, public input is the set of known, verifiable data points that are shared between the prover and the verifier. It represents the common, non-secret context for a computation, such as a public blockchain state, a known transaction hash, or a declared rule. The prover uses this data, along with private inputs, to generate a proof, while the verifier uses the same public inputs to check the proof's validity. This separation is critical: the prover demonstrates knowledge of secret information (private inputs) that correctly interacts with the agreed-upon public facts.

The role of public input is to anchor the proof to a specific, auditable claim. For example, in a zk-rollup on Ethereum, the public input might include the new Merkle root of the rollup state and the previous root. The prover generates a proof showing that, given the old state (public input) and a batch of private transactions (private input), the new state (also public input) was computed correctly. The verifier only needs the proof and these public inputs to be convinced, without seeing the private transaction details. This mechanism enables scalable and private verification of state transitions.

Technically, public inputs are explicitly encoded into the arithmetic circuit or computational constraint system that underlies the ZKP. They become part of the proof's verification key and are hashed into the final proof statement. Common implementations include the public_inputs array in Circom circuits or the public parameters in libsnark. Distinguishing public from private inputs is a primary design task when constructing ZK applications, as it defines the boundary between what must remain secret and what serves as the proof's public certificate of correctness.

In a zero-knowledge proof (ZKP), a public input is a piece of data that is explicitly revealed to and agreed upon by both the prover and the verifier. This shared, non-secret information forms the common ground for the proof statement, allowing the verifier to check the proof's validity against known parameters. For instance, in a proof demonstrating knowledge of a private key for a specific public address, the public address itself is the public input. The system's security relies on the prover's ability to convince the verifier of a claim related to these public inputs, while keeping the witness (the secret data) completely hidden.

The technical implementation involves embedding public inputs into the arithmetic circuit or constraint system that models the computational statement. During proof generation, the prover uses both the private witness and the public inputs to compute the proof. The verifier, who possesses only the public inputs and the final proof, runs a verification algorithm. This algorithm uses the same public inputs to check if the proof is consistent with the claimed statement. Crucially, the verification outcome is a binary true or false; a valid proof confirms the statement's truth relative to the provided public inputs without leaking any information about how it was derived.

Public inputs are essential for creating useful and flexible proofs. They enable scenarios like proving a transaction's inclusion in a specific block (where the block hash is public), verifying a user's membership in a published merkle tree root, or demonstrating that a secret number lies within a publicly declared range. In zk-SNARKs, public inputs are often hashed into the verification key, making them a fixed part of the verification logic. In contrast, some zk-STARK constructions or recursive proofs can handle public inputs more dynamically. Misalignment of a single public input value between prover and verifier will cause proof verification to fail, ensuring the integrity of the proven statement's context.

In the context of zk-SNARKs and zk-STARKs, a public input is a piece of data that is known to both the prover and the verifier. It is explicitly declared as an input to the arithmetic circuit or computational statement being proven, but unlike a private input (or witness), it is not kept secret. The prover uses this data to generate a proof, and the verifier must supply the same value to successfully verify the proof's validity. This mechanism binds the proof to specific, agreed-upon parameters.

The primary function of public inputs is to enable the verification of statements about public state. For example, in a blockchain ZK-rollup, the public input might be the new Merkle root of the state after a batch of transactions. The prover demonstrates they have correctly processed the transactions (using private witness data) to arrive at this specific root. The verifier, knowing the intended new root, can confirm the proof is valid for that exact state transition, ensuring consistency with the public ledger.

Technically, public inputs are often handled as a distinct component of the Rank-1 Constraint System (R1CS) or similar circuit representation. They are hashed or otherwise committed to as part of the proving key setup. A critical security property is that a proof is only valid for the exact public inputs used during verification; changing even one bit will cause verification to fail. This makes public inputs essential for applications like token transfers (where the recipient address is public) or voting (where the proposal ID is public).

Common implementations include the use of public inputs to represent nullifiers in anonymous systems like Zcash, where a spent note's nullifier is published on-chain as a public input to prevent double-spending, while the note's details remain private. In zkEVM circuits, public inputs routinely include block hashes, transaction hashes, and storage roots, anchoring the proof's correctness to the canonical chain history visible to all network participants.