Pairings are maps between two elliptic-curve groups and a target group. Their useful trick is bilinearity: secret multiplications can be moved across an equation and compared without exposing the secret.
Ordinary elliptic-curve cryptography turns a secret number into a public point. A pairing adds a second kind of operation: it takes one point from G1 and one point from G2, then checks whether their hidden scalar multiplication agrees in GT.
The public key hides the secret key inside a point. Observers seepk, but they should not be able to recoversk.
Qsk is privatepk = 23QH(m) = 17PThe signature hides sk * H(m). The public key hidessk. The pairing compares those hidden products without exposing sk.
e(signature, Q) = e(88P, Q) = 537e(H(m), pk) = e(17P, 23Q) = 537same hidden product17 * 23 mod 101 = 88P88P88 * 1 mod 101 = 8817 * 23 mod 101 = 88In this toy model, a point in G1 is written as aP, a point in G2 is written as bQ, and the pairing output is controlled by a * b mod 101. Real pairings do this with elliptic-curve points and a real target group.
12P9Q482e(12P, 9Q)12 * 9 mod 101 = 764^7 mod 607 = 4823P36Q482e(3P, 36Q)3 * 36 mod 101 = 764^7 mod 607 = 482e(12P, 9Q) = e(3P, 36Q)The verifier compares the two GT outputs. Matching outputs mean the hidden scalar products match, even if the original G1 and G2 points look different.
The demo uses additive source groups of order 101 and a target group modulo 607 with generator 64. A real pairing uses elliptic-curve groups, not these small numbers.
e(13P, 29Q) = 64^74 mod 607 = 418e(P, Q)^(13 * 29) = 64^74 mod 607 = 418e(13P, 29Q) = 418e(P, 29Q)^13 = 418e(13P, 29Q) = 418e(13P, Q)^29 = 41813P29Q13 * 29 mod 101 = 74418Validators sign blocks and attestations with BLS signatures over BLS12-381. Pairings let many signatures be aggregated and checked with a compact equation.
e(signature, G2) = e(hash_to_G1(message), public_key)Blob transactions carry KZG commitments and proofs. The point-evaluation precompile verifies that a committed polynomial evaluates to a claimed field value.
e(C - yG1, G2) = e(proof, tauG2 - zG2)Groth16-style verifiers compress a large arithmetic statement into a small number of pairing product checks over proof elements and verification-key elements.
product of pairings == identity in GTEach card reduces the idea to scalar products modulo 101. The numbers are intentionally small: the point is to see that pairing checks compare hidden products, not raw secrets.
This is the smallest version of the trick. The secret scalar can sit inside the G1 input or the G2 input, and the target result stays the same.
e(37P, Q) = 143e(P, 37Q) = 143Pairing check passes37 * 1 mod 101 = 371 * 37 mod 101 = 37same exponent in GTThe pairing is not checking whether the visible points are identical. It is checking whether their hidden scalar products match modulo the group order.
e(12P, 9Q) = 482e(3P, 36Q) = 482Pairing check passes12 * 9 mod 101 = 73 * 36 mod 101 = 7same GT elementA valid BLS signature hides sk * H(message). The public key hides sk. Pairing verification proves those two uses of sk agree.
e(signature, Q) = e(28P, Q) = 369e(H(m), pk) = e(44P, 19Q) = 369signature accepted19Q44 * 19 mod 101 = 28P28PWhen two signers sign the same message, their signatures add in G1 and their public keys add in G2. The pairing still sees the same total hidden product.
e(sigA + sigB, Q) = e(81P, Q) = 559e(H(m), pkA + pkB) = e(22P, 45Q) = 559aggregate accepted22 * 14 mod 101 = 5P22 * 31 mod 101 = 76P14Q + 31Q = 45QFor a correct opening, f(tau) - y equals q(tau) * (tau - z). A wrong y leaves a remainder, and the pairing equality breaks.
e((f(tau) - y)P, Q) = e(96P, Q) = 346e(q(tau)P, (tau - z)Q) = e(8P, 12Q) = 346opening accepted812096