We finally met the curves. Two points, one line, a flip — and suddenly we have a group that hides numbers inside geometry. This is where everything from Weeks 1–3 converges.
João started from the absolute basics. A curve is a set of points that satisfy some equation. That's it. You have an equation with two variables, x and y. Every (x, y) pair that makes the equation true is "on the curve." Every pair that doesn't is not.
That equation is a line — degree 1. Things get more interesting at higher degrees:
| Equation | Degree | Curve Name |
|---|---|---|
x² + y² = r² |
2 | Circle |
xy = 1 |
2 | Hyperbola |
3x² + 7y² = 10 |
2 | Ellipse (the shape planets trace around the sun) |
y² = x³ + ax + b |
3 | Elliptic curve |
The name is misleading. An elliptic curve is not an ellipse. The name comes from a historical connection to elliptic integrals (used to compute the arc length of ellipses), but the shapes are completely different. An ellipse is a closed oval. An elliptic curve looks like a swooping, open shape that extends to infinity. João was clear about this: "The name elliptic curve is terrible."
The key distinction: circles, ellipses, and hyperbolas are all degree 2 (quadratic). Elliptic curves are degree 3 (cubic). That one extra degree of polynomial power is what gives elliptic curves the geometric property that makes them useful for cryptography.
Every elliptic curve we'll work with can be written in this form:
But not every a and b gives a valid elliptic curve. There's one constraint:
João showed three example curves to make this concrete:
| Curve | a | b | 4a³ + 27b² | Valid? |
|---|---|---|---|---|
🔴 y² = x³ − 3x − 1 |
−3 | −1 | 4(−27) + 27(1) = −81 ≠ 0 | ✅ YES |
🔵 y² = x³ + 3x + 16 |
3 | 16 | 4(27) + 27(256) = all positive ≠ 0 | ✅ YES |
🟢 y² = x³ |
0 | 0 | 0 + 0 = 0 | ❌ NO — singular |
The green curve (y² = x³) has a sharp cusp at the origin — a point where the curve bends so sharply that you can't draw a unique tangent line. Is it this tangent? Or that one? There's no answer. And as we'll see, the tangent line is essential to the group operation. No tangent → no group → useless for cryptography.
In practice, nobody accidentally picks a singular curve. The standard curves used in cryptography (secp256k1 for Ethereum/Bitcoin, BN254 for Groth16) all satisfy the discriminant condition by design. But it's worth knowing why the constraint exists.
Here's the property that makes elliptic curves special — and why degree 3 matters:
If you take any two points on an elliptic curve and draw a straight line through them, that line is mathematically guaranteed to intersect the curve at exactly one more point.
(Edge case: if the line is vertical, it doesn't hit a third point — we handle that separately.)
This doesn't work for degree 2 curves. Draw a line through two points on a circle — it just exits the other side. No guaranteed third intersection. But cubic curves have this beautiful property: a line always comes back.
And this is exactly what we need to define an operation between points. Take two points → draw a line → get a third point. Input: two points. Output: one point. That's a binary operation. And if we set it up right, the set of points on the curve becomes a group.
This is the core of the lecture. João constructed the group step by step, handling every case.
Our set is: all points (x, y) on the curve, plus one extra point we'll introduce called the point at infinity (written 𝒪). Our operation is called the chord-and-tangent rule.
Take points A and B (where A ≠ B). Draw a straight line through them. Because the curve is cubic, the line hits the curve at exactly one more point. Call that intersection point C'.
Now flip C' across the x-axis to get C. That is: if C' = (x, y), then C = (x, −y).
A + B = C (the flipped point).
Take point A. Since there's no second point to draw a line through, draw the tangent line at A instead. The tangent touches the curve at A and (because cubic) intersects at exactly one other point C'.
Flip C' across the x-axis to get C.
A + A = C (the flipped tangent intersection).
If A and B are vertically aligned (same x, opposite y), the line through them is vertical. A vertical line doesn't hit the curve a third time. There's no intersection point to flip.
For this case, we introduce a special element: the point at infinity (𝒪). It's not a real point on the curve — we add it by hand.
A + B = 𝒪 (whenever A and B form a vertical line).
Since we introduced 𝒪, we need to define how it interacts with every other point. The rule is simple:
𝒪 + P = P for any point P (including 𝒪 + 𝒪 = 𝒪).
The point at infinity "does nothing" — it's the identity element.
These four rules cover every possible combination of two inputs. The operation is fully defined.
We have a set (curve points + 𝒪) and an operation (chord-and-tangent with flip). Let's verify the group axioms from Week 2:
Bonus: it's commutative too. A + B = B + A. This is actually obvious from the geometry — drawing a line from A to B is the same as drawing a line from B to A. Same line, same intersection, same flip. So this is an abelian group (commutative group), which is even stronger than what we need.
Brandon asked the question everyone was thinking: "Why do we flip the intersection point? What breaks if we don't?"
João demonstrated this with a brilliant counterexample. Suppose we define A + B as the unflipped intersection (call it C'). Let's see what happens:
Without flipping, you can also derive contradictions like A + A = 𝒪 for points where that shouldn't hold. The unflipped operation creates a tangled mess of inconsistencies.
With flipping, these contradictions disappear. João showed that if A + B = −C' (the flipped version), then A + B + C' = 𝒪 and A + C' + B = 𝒪 — perfectly consistent, since the group is commutative (A + B = B + A means the order on the left doesn't matter).
The intuition: The flip introduces a negation that "resets" the operation — it prevents the output from being trivially related to the inputs in a way that would break associativity. Three collinear points A, B, C' satisfy A + B + C' = 𝒪 (they sum to the identity). The flip is what makes this identity work, and it's this identity that gives the group its consistent structure.
The geometric description (draw a line, find intersection, flip) is great for intuition, but for computation you need formulas. João showed the coordinates for both cases:
Two things to notice. First, both formulas involve division — which is why we need a field (Week 2). Division must be defined and invertible. Second, the doubling formula uses a (the curve parameter from y² = x³ + ax + b) — the tangent slope depends on the curve shape at that point.
These same formulas work whether x and y are real numbers or elements of a finite field. You just do the arithmetic mod p instead of over the reals. That's the bridge to cryptography.
Everything up to this point used real numbers — x and y can be any real value. The curve is a smooth, continuous shape you can draw on paper. Beautiful, but useless for cryptography (infinite precision, no discrete structure).
For cryptography, we restrict x and y to a finite field 𝔽p. João used 𝔽13 as an example — the curve y² = x³ + 8x + 8, where all arithmetic is done mod 13.
When you plot all valid points, the result looks nothing like a smooth curve. It's a scatter of dots on a 13 × 13 grid. No swooping lines, no visual continuity. Just seemingly random points.
But the dots still preserve one key property: symmetry. For every point (x, y) on the curve, the point (x, −y mod p) is also on the curve. In 𝔽13, the inverse of (2, 5) is (2, −5 mod 13) = (2, 8). The inverse of (8, 5) is (8, −5 mod 13) = (8, 8). The reflection is still there — just computed modularly instead of geometrically.
The computation is algebraic, not geometric. Over a finite field, you can't "draw a tangent line." There's no visual geometry to work with. But the formulas are identical — the same λ, x₃, y₃ equations work. You just do every operation mod p. The geometry was only ever a way to see what the formulas do. The formulas are what actually matter.
A nice exercise (João's suggested homework): code the point addition and doubling formulas, generate all valid points on the curve over 𝔽13, and verify that adding any two points gives a third point that's also on the curve.
At the end of class, a student asked: "Can you give us a sneak peek of how elliptic curves connect to ZK proofs?"
João's answer was the most exciting part of the entire lecture. Here's the idea:
The group we built from an elliptic curve has a special property — it's cyclic. That means there's some element G (called a generator) where if you keep adding G to itself, you eventually visit every point in the group:
This creates a mapping from numbers to points: the number 4 maps to the point 4G. The number 7 maps to 7G. Every number in {1, 2, ..., n} has a unique corresponding point on the curve.
Here's the critical property. Going from number to point is easy: given 4, compute 4G by adding G four times (and there are efficient algorithms for large numbers). But going from point back to number is hard: given the point 4G, find 4. This is the elliptic curve discrete log problem — the same problem we discussed in Week 3.
Number → Point: Easy. Just multiply. (This is computing your public key from your private key.)
Point → Number: Hard. No known efficient algorithm. (This is why nobody can derive your private key from your public key.)
João then showed the key insight for ZK. Because the mapping preserves addition — meaning 4G + 5G = (4+5)G = 9G — you can do arithmetic on the hidden values without ever revealing the original numbers.
This is the core of why elliptic curves matter for ZK. They give us a way to compute on hidden values. The prover does math with real numbers, converts them to curve points, and sends the points. The verifier does math on the points and checks that the relationships hold — without ever learning the underlying numbers.
João's vision for the future: "What you hope for Google or any search engine to do one day — you send the information you want to search, and they search their database without knowing what you're asking for. They do operations without understanding what you're sending." We're not there yet, but homomorphic hiding on elliptic curves is the mathematical foundation that makes it conceivable.
Brandon asked a sharp follow-up: "Is there any way to go from 4G back to 4, if you know some secret?"
João's answer: No. That's the entire point. If you could reverse the mapping, the cryptography is broken. The number-to-point direction is easy. The point-to-number direction is hard. This asymmetry is what makes public-key cryptography work — your private key is the number, your public key is the point. Anyone can have your public key (the point). Nobody can derive your private key (the number) from it.
Four weeks in, and the pieces are clicking together:
Next week: elliptic curves over finite fields in depth. This week was primarily over the reals — the smooth curves, the geometric intuition. Next week we move fully into 𝔽p, where the curves become scattered dots and the computation is purely algebraic. We'll work with cyclic groups, generators, and the order of the group. João also hinted at the homework: code the point addition formulas, reproduce the 𝔽13 curve, and verify the operations yourself.
João mentioned this topic will span three to four weeks total — elliptic curves are that important. The roadmap: curves over reals (this week) → curves over finite fields (next) → cyclic groups and generators → pairings → Groth16.
Week 4 done. We have a group made of points, an operation made of lines, and a one-way function that hides numbers in geometry. The curve is set. Next week, the numbers take over. 📐
📝 ZK and cryptography evolve fast — if any tip here is outdated, incorrect, or no longer applies, please reach out on X so I can update this article accordingly.