Commitments and setup

Understand cryptographic commitments (hiding and binding), the idea of polynomial commitments at a high level, and the crucial distinction between trusted setup and transparent setup — including why that choice shapes trust, security and operational risk.

Track

Engineering

Module

4 · Zero-Knowledge Proofs

Prerequisites

Hash functions · Arithmetic circuits and R1CS

A cryptographic commitment is a sealed envelope. You write a value, seal it, and hand the envelope over: the recipient cannot see inside (hiding), and you cannot later swap the contents for something else (binding). When you choose to "open" it, you reveal the value plus the randomness used, and anyone can confirm it matches the sealed envelope. Commitments are how a prover locks in choices before seeing a verifier's challenge — the "commit" move in the protocols of earlier modules.

Modern succinct proof systems need more than committing to a single number — they commit to entire polynomials, then let a verifier ask "what is this polynomial's value at point r?" and get a short, checkable answer. That capability, the polynomial commitment, is the workhorse that makes proofs small and fast to verify. But the commitment scheme needs public parameters, and how those parameters are generated is where "trusted setup" enters.

A commitment scheme has a commit step, Commit(value, randomness) -> c, and an open step that reveals (value, randomness) so anyone can recompute c. The two security properties below are what make it a commitment rather than just an encryption or a hash. Polynomial commitment schemes (PCS) generalize this to committing to a polynomial and later proving evaluations of it.

Hiding

The commitment c reveals nothing about the committed value (until opened). Freshly-chosen randomness is what provides hiding.

Binding

You cannot open the same commitment to two different values; the committed value is fixed at commit time.

Polynomial commitment (PCS)

A scheme to commit to a polynomial with a short commitment, then prove its evaluation at any point with a short proof. Examples by name: KZG (pairing-based, needs trusted setup), IPA/bulletproofs-style (transparent), FRI (hash-based, transparent, used in STARKs).

Structured Reference String (SRS) / Common Reference String (CRS)

The public parameters a proof system uses. How the SRS is produced is exactly the trusted-vs-transparent question.

Two concrete pictures. First a simple Pedersen commitment (the classic hiding-and-binding example), then the shape of a polynomial commitment and of the two setup models. The notation g, h are group generators; a "secret scalar s" below is the dangerous part of a trusted setup.

Commitments and setup (schematic)
Pedersen commitment to value v (randomness r):
   c = g^v * h^r
   Hiding:  r random => c hides v (perfectly hiding)
   Binding: opening c to (v', r') != (v, r) requires breaking
            the discrete-log relation between g and h (computational)

Polynomial commitment (interface, system-agnostic):
   Commit(f)      -> C          # short commitment to polynomial f
   Open(f, z)     -> (y, pi)    # claims f(z) = y, with proof pi
   Verify(C, z, y, pi) -> accept/reject   # verifier never sees all of f

Trusted setup (e.g. KZG SRS):
   sample SECRET s;  publish ( g^1, g^s, g^(s^2), ..., g^(s^n) )
   then DESTROY s.    # s is "toxic waste"
   If s survives, the holder can forge proofs / open to any value.

Transparent setup (e.g. FRI / bulletproofs):
   parameters derived from PUBLIC randomness / a hash function;
   no secret is ever created, so there is no toxic waste.

The danger of a trusted setup is concrete: whoever knows the secret trapdoor s can produce convincing proofs of false statements. That is why real deployments use a multi-party "ceremony" where many independent participants contribute randomness, and the setup stays secure as long as at least one honest participant destroyed their share. Transparent setups avoid this entirely by using public randomness, but typically pay for it in larger proofs or different (often more conservative) cryptographic assumptions.

1. 1Commit: the prover computes a commitment to each polynomial representing its witness/computation, using fresh randomness for hiding.
2. 2Challenge: the verifier (or Fiat–Shamir hash) picks evaluation points the prover could not anticipate.
3. 3Open: the prover produces short evaluation proofs showing the committed polynomials take specific values at those points.
4. 4Verify: the verifier checks the openings against the commitments using the public parameters (the SRS/CRS) — never seeing the full polynomials.
5. 5Setup, done once beforehand: generate those public parameters either by a trusted-setup ceremony (and destroy the toxic waste) or transparently from public randomness.

synthetic — commit now, reveal later; and why setup trust matters
# Sealed-bid style commitment (per-agent):
secret_bid = 42
r          = random()
c          = Commit(secret_bid, r)     # publish c; bid stays hidden (hiding)
# ...later, to reveal:
reveal     = (42, r)
assert Commit(42, r) == c              # cannot have been 43 (binding)

# Setup contrast for the proof system underneath:
#  Trusted setup:  one-time ceremony makes SRS; if trapdoor s leaks,
#                  an attacker forges proofs -> trust assumption on ceremony.
#  Transparent:    no trapdoor exists -> nothing to leak, but proofs are
#                  typically larger / verification can be costlier.

The commitment half is unconditional in spirit: binding stops you changing the bid, hiding stops observers reading it early. The setup half is a trust decision: a trusted setup buys small, cheap-to-verify proofs at the price of a one-time ceremony you must believe was honest; a transparent setup removes that belief at the price of size or cost. Neither is "better" in the abstract — it depends on who must be trusted and what the proofs are for.

Agents use commitments to pin down intent before acting: an agent can commit to a planned action, then reveal it only when a condition is met, preventing after-the-fact tampering. Underneath, the proof system that lets an agent prove authorization relies on a commitment scheme and a setup. If that system uses a trusted setup, the whole fleet inherits a trust assumption on the ceremony — a centralized point of failure that must be governed. A transparent setup removes that shared dependency, which can matter when agents span organizations that do not trust a common ceremony.

The practical takeaway for agent architects: the setup model is a security-governance choice, not just a performance knob. It determines whether your authorization proofs rest on "a ceremony was honest" or only on "a hash function is secure".

• ▸Trusted-setup toxic waste is a real catastrophic risk: if the trapdoor survives, an attacker can forge proofs of false statements undetectably. Multi-party ceremonies mitigate but do not eliminate the trust assumption.
• ▸A setup can be universal/updatable (one SRS reused across circuits, as in some systems) or circuit-specific (a fresh ceremony per circuit) — the latter multiplies operational risk.
• ▸Transparent setups remove the trapdoor but usually cost larger proof sizes or heavier verification, and may rest on different assumptions.
• ▸Hiding depends on good randomness: a predictable or reused commitment randomness can break hiding entirely.
• ▸Binding is often only computational; a future break of the underlying hardness assumption (including by a quantum adversary, for discrete-log/pairing-based schemes) can retroactively undermine binding.

Expected direction: Team A must argue the ceremony can be run so at least one honest participant destroys their share, that the toxic waste is truly gone, and who governs/audits it — in exchange for small, cheap-to-verify proofs. Team B must argue that larger proofs and heavier verification are acceptable, in exchange for no trapdoor and no cross-org trust in a ceremony. The deciding question: is there any party both organizations are willing to trust to have honestly run (and destroyed the secret of) a setup ceremony? If not, transparent setup is strongly preferred.

What are the two defining properties of a commitment, and what does each prevent?

Hiding (the commitment reveals nothing about the value before opening) and binding (the value cannot be changed after committing). Hiding prevents early disclosure; binding prevents tampering.

What is "toxic waste" in a trusted setup, and why is it dangerous?

The secret trapdoor (e.g. the scalar s) used to generate the SRS. If it is not destroyed, whoever holds it can forge proofs of false statements, breaking soundness for everyone using that setup.

What do you gain and lose by choosing a transparent setup over a trusted one?

You gain the elimination of any trapdoor/ceremony trust assumption; you typically lose some efficiency — larger proof sizes and/or costlier verification — and may rely on different cryptographic assumptions.