Cryptography

Prove what's true.
Keep the rest private.

Zero-knowledge circuits, proof-system selection and secure multiparty computation, from the paper to the production prover.

Technology · 4 min read

On this page
  1. What cryptography is for here
  2. Commitments
  3. Zero-knowledge proofs
  4. Choosing a proof system
  5. Secure multiparty computation
  6. Confidential transactions
  7. How Rump Labs works in cryptography
  8. Where it shows up
  9. Where to start
  10. Further reading

What cryptography is for here

Most people meet cryptography as encryption: keeping data secret in transit or at rest. The work we do is mostly about something else: proving things about data without revealing it, and computing on data that no single party is allowed to see.

That shift changes what systems can do. A service can check that a user is over 18 without seeing their date of birth. Two companies can find their shared customers without exchanging lists. A key can sign transactions without ever existing in one place.

Commitments

A commitment is a sealed envelope. You publish a value that fixes your choice without revealing it, and later open it to show what you committed to. It has two properties:

  • Hiding: the commitment reveals nothing about the value.
  • Binding: you cannot later open it to a different value.

Hashing a value together with random blinding is the simplest commitment. Pedersen commitments add a useful property: they can be added together, so you can prove two committed amounts sum to a third without revealing any of them. A Merkle root is a commitment to a whole set, with short proofs that one item belongs. Polynomial commitments such as KZG commit to a polynomial and prove its value at a point; they sit at the heart of modern proof systems.

Zero-knowledge proofs

A zero-knowledge proof convinces a verifier that a statement is true and reveals nothing else. The statement is a relation between public inputs and a private witness, written as a circuit. Here is one that proves a committed age is at least 18, without revealing the age:

Circom
pragma circom 2.1.6;
include "circomlib/circuits/poseidon.circom";
include "circomlib/circuits/comparators.circom";

template AgeOver18() {
    signal input age;          // private
    signal input blinding;     // private
    signal input commitment;   // public

    component c = Poseidon(2);
    c.inputs[0] <== age;
    c.inputs[1] <== blinding;
    commitment === c.out;      // opens the commitment

    component bits = Num2Bits(8);
    bits.in <== age;           // range check first: comparators assume 8-bit inputs

    component ge = GreaterEqThan(8);
    ge.in[0] <== age;
    ge.in[1] <== 18;
    ge.out === 1;
}

component main {public [commitment]} = AgeOver18();

The range check is the kind of line that separates a correct circuit from one that merely produces valid proofs. What a zero-knowledge proof actually proves covers where those gaps hide.

Choosing a proof system

The same circuit can be proven with different systems, and the choice shapes cost, setup and assumptions.

Groth16PLONK familySTARKs
SetupTrusted, per circuitTrusted once, universal (KZG)None
Proof sizeSmallestSmallLarge
Best whenVerifying on-chain, stable circuitCircuits still changing, lookupsLarge computations, no setup

We write circuits in Circom, Halo2 and Noir, and choose the system from the constraints: where the proof is verified, how large the computation is, how often the circuit changes. Groth16, PLONK or STARKs sets out the full trade-off.

Secure multiparty computation

Secure multiparty computation (MPC) lets several parties compute a function over their private inputs and learn only the output. The building blocks are secret sharing, where a value is split into shares that reveal nothing individually, and protocols that compute on those shares.

Its most practical use today is threshold key management: a signing key is split across machines or people, signatures are produced jointly, and the whole key never exists in one place. Compromise one machine and the attacker gets a share, not a key. MPC costs rounds of communication and bandwidth, and its guarantees depend on how many parties may be dishonest; those are design decisions, not details.

Confidential transactions

Confidential transactions combine the pieces above. Each amount is hidden in a Pedersen commitment; because the commitments add up, anyone can check that inputs equal outputs without seeing a single amount. A range proof (Bulletproofs is a well-known construction) shows each hidden amount is non-negative, so nobody can create money with a negative output. The result is a ledger that is private and still auditable.

How Rump Labs works in cryptography

This is where the lab started. Our founder, Hridam Basu, has spent over a decade in cryptography research and engineering in the blockchain industry, building systems on zero-knowledge proofs and secure multiparty computation, and has spoken at Devcon and given invited lectures, including at ISI Kolkata.

We write ZK circuits in Circom, Halo2 and Noir, select proof systems between Groth16, PLONK and STARKs, and build MPC and confidential-transaction systems, from the paper to the production prover. The work is public where it can be: the Anon-Aadhaar talk at Devcon SEA and our published research.

Engagements usually start with a Technical Brief: a written answer on what to build, which proof system, and what it will cost. Circuit work can also run inside a Contract Sprint. And we teach it: Rump Gurukul is a 40-hour, self-paced zero-knowledge course with no prerequisites.

Where it shows up

Every domain we work in rests on it. Each one uses it differently.

Where to start

Service 02

The Technical Brief

Know what to build and what it costs, before you spend.

3 business days · $490

Further reading

Cryptography

Bring the hard question.
Get a written answer.

Thirty minutes with an engineer, free. Which proof system, what it costs, and whether it is the right tool at all.