Sara Adams (@psycyber13nv) on X

What it is

The thread's actionable core beyond the summary is the specific circuit/construction recipe and a precise statement of what a ZKP does and does not guarantee — namely that it proves "a computation ran correctly on some inputs," not that those inputs are true in the real world.

How it works

The author lays out the actual construction pipeline used in production systems: (1) write the claim as a circuit or constraint system (e.g., "ECDSA signature verifies AND birth_year + 21 ≤ 2026 AND name is not revealed"), (2) encode the circuit as polynomials (R1CS → QAP, AIR, Plonkish), (3) commit to those polynomials (Pedersen, KZG, Merkle/FRI), (4) open a few evaluation points so the verifier checks algebra instead of re-running the computation. This is why verification cost stays tiny relative to the original computation — the stated reason ZK rollups can settle thousands of transactions with a single proof. The Fiat-Shamir transform is given concretely as c = H(public statement ‖ commitment), converting an interactive challenge-response into a single non-interactive proof.

flowchart LR
    A[Claim as circuit/constraints] --> B[Encode as polynomials: R1CS/QAP, AIR, Plonkish]
    B --> C[Commit: Pedersen, KZG, Merkle/FRI]
    C --> D[Open evaluation points]
    D --> E[Verifier checks algebra, not full computation]

Preconditions / Affected

Applies to anyone evaluating SNARK vs STARK tradeoffs for a system: SNARKs need a trusted setup ceremony (producing "toxic waste" that, if leaked, forges proofs) and rely on elliptic-curve/pairing assumptions vulnerable to quantum attacks; STARKs need no trusted setup and rely on collision-resistant hashes, giving a more post-quantum-friendly path, at the cost of proof sizes in the tens-to-hundreds of KB versus hundreds of bytes for SNARKs.

What to do

The thread gives a concrete production pattern: mix the two families — prove with STARK techniques (no trusted setup, large computations) then wrap the result in a SNARK for a small final on-chain-verifiable proof. It also gives a verification discipline: a valid proof only means the circuit accepted, so before trusting one, pin down (a) the exact statement being proven, (b) which keys are involved, and (c) whether the issuer of any signed input is trustworthy — a ZKP of "I hashed my manifesto" is called out explicitly as weak unless these are specified tightly.

Caveats

The author states these limits directly: circuit bugs or bad constraints prove the wrong statement; leftover trusted-setup material in some SNARKs can enable forged proofs; proof generation remains heavier than hashing, so phones handle small identity proofs but not large archives cheaply; and a ZKP never certifies that signed inputs (e.g., a birthdate on a license) were honestly issued or accurate in the real world.