DEV Community: Olusola Caleb

Why Every Computation Has an Unavoidable Energy Cost

Olusola Caleb — Tue, 04 Aug 2026 18:37:44 +0000

Every time your computer performs a computation, it consumes energy. We all know this intuitively, your laptop battery drains as you use it. But that raises a deeper question: is this merely an engineering limitation, or does physics itself require computation to consume energy?

To answer that question, we need one idea from information theory: entropy.

Information theory tells us that:

The total entropy of a system can only go up or stay constant. It never goes down [unless you supply energy into the system] That's why things rot when you leave them, and that's why cold things gradually and spontaneously warm up if you leave them alone. But a warm thing will never spontaneously cool down after it has reached thermal equilibrium, because a system with less thermal energy usually has fewer accessible microstates, hence lower entropy.
The higher the possible number of possible microstates of a system, the higher the entropy.

This is where information theory becomes surprisingly useful...

Remember, logic is just state manipulation. We take some input state and transform them to some desired output state.

Every computation can ultimately be broken down into billions of these tiny state transitions happening inside logic gates.

Let's examine how the state evolves over the course of an AND operation, one of the simplest logical operations.

From truth tables, we know that two input bits produce one output bit.

AND Truth Table

$P$	$Q$	$P \land Q$
0	0	0
0	1	0
1	0	0
1	1	1

So we have 4 possible input states (00, 01, 10, 11), which the AND operation shrinks to 2 possible output states (0 or 1).

Looking at that in isolation, you might say, what?! In this closed system, you had 4 possible input states and this "AND operation" maps 4 possible input states onto only 2 output states, and we know that entropy increases as the number of accessible microstates increases, so does this "AND operation" thing, violate the laws of thermodynamics by somehow decreasing entropy? At first glance, this seems impossible.

...but of course, we do not violate any physical laws.

Because the 4 input states collapse into 2 outputs, 1 bit of logical information is permanently erased (notice that from the output alone, you can no longer tell whether the input was 00, 01, or 10. That information has been irreversibly lost.). Landauer's principle dictates that this lost information must physically manifest as an increase in the entropy of the gate's environment, which we measure as waste heat.

Therefore, every time your CPU performs an irreversible computation, it must dissipate at least a tiny amount of energy as heat. Modern processors are still millions to billions of times above this theoretical minimum because of real-world electrical losses, but Landauer’s principle tells us that even a perfectly engineered computer could never reduce that cost to zero for irreversible computation. That’s one of the fundamental reasons computation isn’t free, and ultimately why your CPU gets hot.

Landauer's principle is how we calculate that theoretical minimum amount of energy required for irreversible computation or bit erasure. It is stated in the formula:

E \geq k_{B} T ln 2

Where,

k_{B}

is the Boltzmann constant, and

T

is the absolute temperature

Numerically, the Landauer limit represents an energy value of about $0.018 e V or 2.9 \times 1 0^{- 21} J o u l es$ .

This is the minimum amount of energy required to irreversibly erase one bit of information. Any irreversible computation must incur at least this cost, although real computers consume vastly more energy for other physical reasons.

More information about it here:
landauer's theory wikipedia

Bonus:

Strictly, Landauer's limit applies to irreversible logic operations (such as AND, OR, etc), and not reversible ones (such as CNOT, CCX gates). So if you had a computer built out of reversible logic gates, you could theoretically avoid that energy cost completely.

Reversible logic operations are computation steps where the input states can be uniquely retrieved from the output states, meaning no information is erased, and energy loss is avoided.

(Note: This theoretical limit assumes zero leakage and infinitely slow operations, but the principle stands).

Conclusion

What fascinates me most is that a simple question about why computers consume power ultimately leads to information theory, thermodynamics, and statistical mechanics. It’s one of those rare moments where two seemingly unrelated fields turn out to be describing the same underlying reality.

Also, fun fact, your brain runs on a continuous 20w power draw to run your entire life, Let's do the math: Landauer per bit operation is $2.9 \times 1 0^{- 21} J$ . The brain does ~ $1 0^{15}$ synaptic operations per second. $20 W /1 0^{15} \approx 2 \times 1 0^{- 14} J / o p$ . That is ~7,000,000 times higher than the theoretical Landauer limit, which is is remarkably efficient compared to modern silicon (which is ~ $1 0^{9}$ times over the limit)

Further reading:
Landauer Principle and Thermodynamics of Computation by Pritam Chattopadhyay, Avijit Misra, Tanmoy Pandit, and Goutam Paul - Cryptology and Security Research Unit, Indian Statistical Institute, Kolkata 700108, India
https://arxiv.org/pdf/2506.10876v2

Week 2: Multiplicative Inverses in Finite Fields: When Division Still Works in a Closed World

Olusola Caleb — Fri, 09 Jan 2026 02:58:37 +0000

A few weeks back, I kicked off a public build challenge: constructing a blockchain from absolute zero, in Go, one layer at a time.

We started at the very bottom, with finite fields. It’s the fundamental math that every modern cryptographic system is built upon.

If you missed that first part, you can catch up here:
Week 1: Finite Field Elements, the math quietly powering blockchains

Today, we are digging into what makes finite fields actually work for cryptography: multiplicative inverses. This is where things get interesting.

Wait, Division in a World Without Fractions?

If we think about normal math for a second, the multiplicative inverse of $k$ is just $\frac{1}{k}$ . Easy.

But in a finite field, there are no fractions. Everything is a whole number, and all the math wraps around a fixed number called the modulus $p$ . So how do you “divide”?

That’s where the multiplicative inverse comes in.

In a finite field with a prime size $p$ , for every non-zero element $a$ , there has to be some other element $b$ such that:

a \times b \equiv 1 (mod p)

We call $b$ the inverse of $a$ , written $a^{- 1}$ .

So to “divide” by $a$ , you just multiply by $a^{- 1}$ . It’s a clever workaround that keeps everything nice, neat, and within the field.

Finding the Inverse: Fermat’s Little Theorem to the Rescue

I remember getting stuck here at first. How do you find this inverse without fractions?

Then I discovered: Fermat’s Little Theorem.

It says that for a prime $p$ and any $a$ not divisible by $p$ :

a^{p - 1} \equiv 1 (mod p)

Do a little algebraic rearranging:

a \times a^{p - 2} \equiv 1 (mod p)

And there it is! Comparing this to our definition, we see:

a^{- 1} \equiv a^{p - 2} (mod p)

The inverse is just the element raised to the power $p - 2$ . No fractions needed- just exponentiation!

Here’s the example I worked through in my notes:

In the finite field $GF (19)$ (so $p = 19$ ), what’s the inverse of $7$ ?

7^{- 1} \equiv 7^{17} (mod 19)

Calculating $7^{17} mod 19$ gives us $11$ , and sure enough, $7 \times 11 = 77$ , and $77 mod 19 = 1$ . Perfect.

Why Primes Are Non-Negotiable

Here’s a crucial point: this guarantee holds when the modulus defines a field, prime moduli are the simplest case.

If you use a composite number (like 10), some elements won’t have an inverse. For example, in mod 10 arithmetic, what number multiplied by 5 gives you 1? There isn’t one. The whole system breaks.

That’s why in cryptography, we almost always work with prime fields. Guaranteed inverses aren’t a nice to have, they’re mandatory. Signature algorithms rely on fields where inverses are well defined, even if implementations try to avoid computing them directly.

Translating the Math Into Go

So, how does this look in our actual Golang code? Pretty clean actually.

The Inverse() method for our FieldElement type boils down to:

func (a FieldElement) Inverse() FieldElement {
    // Hello, Fermat's Little Theorem
    exponent := a.prime - 2
    return a.Pow(exponent)
}

This ensures a fundamental truth always holds:

// If this isn't true, something is terribly wrong.
a.Mul(a.Inverse()).Equals(One) // This will always be true.

Baking this math directly into our types is how we make crypto code that’s hard to misuse.

for those crious what that looks like in action?

// Let's test it in GF(19)
a := NewFieldElement(7, 19)
inverse := a.Inverse()  // This computes 7^(17) mod 19
fmt.Printf("The inverse of 7 is: %d\n", inverse.Value) // Output: 11

// Let's verify
result := a.Mul(inverse)
fmt.Println(result.Value == 1) // Output: true

This Isn't Just Academic: Actual Blockchains Run On It

Multiplicative inverses aren't some math trivia. They are essential for:

Elliptic curve cryptography: Adding and doubling points on a curve requires "division," which is just multiplication by an inverse.
Digital signatures (ECDSA/Schnorr): The signing process involves solving equations within the field. No inverses, no signatures.
Zero-knowledge proofs: These systems perform complex polynomial math, all of which depends on the ability to invert elements cleanly.

In short, if finite fields are the foundation, multiplicative inverses are the load bearing beams. No inverses, no zero trust guarantees, no blockchain.

So, What's Coming Next?

With a solid grasp of field arithmetic and inverses under our belt, we’re ready to climb the next layer: elliptic curves. This is where our field elements become (x, y) coordinates, and cool math becomes beautiful, usable cryptography.

You can follow along with the full Go implementation here:
GitHub: Building a Blockchain in Go

What should we dive into next?

Elliptic curve point addition in Go?
How scalar multiplication powers key generation?
The step from curves to actual digital signatures?

Let me know in the comments.

The takeaway?

Finite fields feel abstract until you need to actually use them. Then, concepts like the multiplicative inverse become your most important tools. They transform a theoretical "closed number system" into the practical bedrock of digital trust.

Finite Fields: The Hidden Math Powering Blockchains

Olusola Caleb — Thu, 01 Jan 2026 23:24:04 +0000

Week 1: Finite Field Elements: the math quietly powering blockchains

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.
If it is clear, everything else starts to click.

What is a Finite Field?

Think of a clock.

On a 12 hour clock:

The numbers only go from 0 to 11
9 + 5 doesn’t give 14, it wraps around and gives 2

This is an example of modular arithmetic, a simple way to understand finite fields.

A finite field works similarly, but with some important differences:

The “clock size” (the number of elements) is usually a prime number or a power of a prime
Every non-zero number has a multiplicative inverse
This makes division always possible within the field

That last property is why primes are critical in cryptography: without inverses, many algorithms break.

Why Blockchains Care

Finite fields provide:

Deterministic arithmetic: every operation is predictable
Exact computation: no floating-point errors or rounding ambiguity
Guaranteed inverses: critical for cryptographic signatures and key operations

Elliptic curves, ECDSA, Schnorr, all of it is built on top of this.
If arithmetic isn’t perfectly predictable, cryptography collapses.

What’s a Field Element?

A field element is simply:

a number that lives inside a finite field

Its value is always interpreted modulo the field size.
For example, in GF(19), 7 and 26 are actually the same field element because 26 ≡ 7 mod 19.

Field elements are the building blocks of cryptography: they’re the “numbers” that elliptic curves, signatures, and blockchains operate on.

That’s exactly what my FieldElement type models: a value plus the field it belongs to.

Values always stay within the field
Operations only happen between elements of the same field

This design ensures invalid math is impossible to ignore. Errors show up early, instead of silently breaking cryptographic logic later. That’s intentional.

What’s next

With finite fields in place, we’re ready to move up the stack:

Elliptic curve points
Point addition and scalar multiplication
Digital signatures

Check out the full Go implementation here: https://github.com/Caleb40/elliptic-curves-go

This post is about understanding why the code exists, not just making it compile.

If you want the next post to dive into inverses or elliptic curves themselves, drop a comment below.