Finite Fields - The Hidden Math Powering Blockchains
Source: Dev.to
Overview
A few weeks ago, I promised a public build challenge: we’d explore blockchain from the ground up in Go, week by week, sharing insights, code, and the intuition behind it all.
Here’s the first installment.
Before elliptic curves, digital signatures, or zero‑knowledge proofs, blockchains rely on something much more fundamental: finite fields. If this concept isn’t clear, cryptography feels like magic; once it is, everything else starts to click.
Modular Arithmetic (The Clock Analogy)
Think of a 12‑hour clock:
- The numbers only go from 0 to 11.
- (9 + 5) doesn’t give 14; it wraps around to 2.
That’s modular arithmetic. A finite field works the same way, except the “clock size” is a prime number.
Finite Fields
- Every non‑zero number has a multiplicative inverse.
- Division is always possible.
That last point is why primes matter so much in cryptography.
Why Finite Fields Matter
- Deterministic arithmetic (no floating‑point errors).
- No rounding ambiguity.
- Guaranteed inverses (critical for signatures).
Elliptic curves, ECDSA, Schnorr signatures, and related constructions are all built on top of finite fields.
Field Elements in Go
A field element is simply a number that lives inside a finite field, so “7” and “7 mod 19” are not the same mathematically. My FieldElement type models this idea as a value plus the field it belongs to.
By enforcing:
- Values always stay within the field.
- Operations only happen between elements of the same field.
we make invalid math impossible to ignore. Errors surface early instead of silently breaking cryptographic logic later—by design.
Next Steps
With finite fields in place, we can move up the stack:
- Elliptic curve points
- Point addition and scalar multiplication
- Digital signatures
Check out the full Go implementation here:
If you’d like the next post to dive into inverses or elliptic curves themselves, drop a comment below.