Skip to main content

Introduction to the Millennium Prize

"If P\mathcal{P} equals NP\mathcal{NP}, then the world would be a profoundly different place." — Scott Aaronson, Computational Complexity Theorist


A Prize Nobody Has Claimed

In the year 2000, a private foundation called the Clay Mathematics Institute sat down and made a list. Not a grocery list, and not a to-do list. They listed the seven most important unsolved problems in all of mathematics — problems so deep, so resistant to attack, that they had survived decades of effort from the most brilliant minds on Earth.

They called them the Millennium Prize Problems.

Then they did something extraordinary: they put a $1,000,000 bounty on each one.

Two and a half decades have passed since that announcement. Six of those problems remain completely unsolved. One was solved — by a Russian mathematician named Grigori Perelman, who famously turned down the money because he didn't care about it.

The problem we care about — P versus NP — still stands. Untouched. Unclaimed.

What is the Clay Mathematics Institute?

The Clay Mathematics Institute (CMI) is a non-profit organization founded in 1998 by businessman Landon T. Clay and mathematician Arthur Jaffe. Its mission is to increase and disseminate mathematical knowledge. The Millennium Prize Problems were announced on May 24, 2000, at a conference in Paris.


So What Exactly Is P vs NP?

Here is the core question. Mathematicians write it like this:

P=?NP\mathcal{P} \stackrel{?}{=} \mathcal{NP}

That small question mark sitting above the equals sign carries an entire universe of meaning. Translated into plain English, it asks:

If the solution to a problem can be verified quickly, can it also be solved quickly?

That one sentence is the million-dollar question.

It sounds almost too simple, right? Like something you could answer over breakfast. But beneath it sits one of the deepest questions about the nature of computation, logic, and even human creativity itself.

Don't worry about what P\mathcal{P} and NP\mathcal{NP} formally mean just yet — we'll build those definitions carefully across the next several posts. For now, think of them as two boxes:

  • P\mathcal{P} — the box of problems a computer can solve fast
  • NP\mathcal{NP} — the box of problems a computer can verify fast

The question is: are these two boxes actually the same box?

Let's make this concrete with two things you already know.

Imagine someone hands you a completed Sudoku puzzle and says: "Is this correct?"

Your job is easy. You scan each row — nine numbers, no repeats. Each column — same check. Each 3×33 \times 3 box — same again. Done. Even if the grid were 100×100100 \times 100, the number of cells you need to inspect grows predictably — roughly proportional to n2n^2 for an n×nn \times n grid. That kind of growth is manageable. Fast. Computers handle it effortlessly.

This is verification — given a finished answer, confirming it's right. It takes what we call polynomial time, written as O(n2)O(n^2) here. You'll learn exactly what that means in Post #5, but the short version is: fast enough to be practical.

Both analogies point to the same underlying tension: checking an answer and finding an answer feel like completely different kinds of work. The P vs NP question is asking whether that feeling is mathematically real — or whether there's always a shortcut hiding somewhere that makes finding as easy as checking.


Two Worlds, Two Outcomes

This question isn't just a piece of pure mathematics that lives only in journals and lecture halls. The answer — whichever way it falls — would reshape our world.

If PNP\mathcal{P} \neq \mathcal{NP} (the common belief)

This means solving is genuinely harder than verifying. Some problems are fundamentally difficult, and no amount of clever programming will change that. This result — the one most experts expect — actually protects us. Every time you buy something online, your credit card number is kept safe by the mathematical assumption that PNP\mathcal{P} \neq \mathcal{NP}. The encryption holding together the internet depends on this being true.

If P=NP\mathcal{P} = \mathcal{NP} (the world-changing scenario)

This means every problem whose solution can be checked quickly could also be solved quickly. Drug discovery, supply chains, artificial intelligence, financial markets — all of these involve problems we currently approximate or brute-force. A proof that P=NP\mathcal{P} = \mathcal{NP} would mean perfect solutions become easy to find. It would also mean every encryption scheme protecting your passwords, your bank, your private messages — would collapse overnight.


The Problem With Solving It

You might wonder: why hasn't anyone solved this yet? We have supercomputers. We have machine learning. We have thousands of brilliant researchers.

The answer is deeply humbling: nobody even knows how to approach a proof.

It's not that we haven't tried hard enough. It's that every known proof technique runs into a wall. To prove PNP\mathcal{P} \neq \mathcal{NP}, you'd need to show that no possible algorithm — not just the ones we've tried, but every algorithm that could ever be invented — can solve certain problems quickly. That's not a statement about code. It's a statement about the fundamental limits of logic itself.

Over the decades, researchers have identified multiple fundamental barriers — mathematical reasons why entire families of proof strategies are doomed to fail. We'll dissect all of them in Phase 4.

A Warning About Amateur Proofs

Every few years, someone announces they've solved P vs NP. These proofs almost always fail within days or weeks. The problem is subtle in ways that aren't obvious. Part of this documentation exists to help you understand why it's hard to prove, not just what it asks.


Why This Documentation Exists

My name is Aziz, and I'm a first-year ICS student in Lahore, Pakistan.

I didn't start this project because I know the answer. I started it because I encountered P\mathcal{P} vs NP\mathcal{NP} and felt something rare: a problem so beautiful, so fundamental, so completely open that it made me want to understand everything around it.

This documentation — called Azeon — is my structured, public attempt to do exactly that. It follows a curriculum I designed, starting from the very basics of what an algorithm is, all the way through the known barriers, the real-world consequences, and the open frontiers of research.

A few promises I'm making to you as a reader:

  • I will never assume you already know something without explaining it first.
  • I will use real analogies from everyday life, not textbook abstractions.
  • When I introduce a math expression like O(n2)O(n^2) or 2n2^n, I will always explain it in plain words alongside it.
  • I will be honest when I am confused — this is a learning journal as much as a reference.
  • Every post will build on the last, so the order matters.

How This Documentation Is Structured

The Azeon project is divided into seven phases:

PhaseTitleWhat It Covers
Phase 1FoundationsAlgorithms, Turing machines, O(n)O(n) notation, defining P\mathcal{P} and NP\mathcal{NP}
Phase 2NP-CompletenessReductions, SAT, graph problems, the hardest problems in NP\mathcal{NP}
Phase 3Complexity ZoocoNP\text{coNP}, PSPACE\text{PSPACE}, EXP\text{EXP}, quantum computing
Phase 4Failed ProofsWhy every known proof technique fails, and what that tells us
Phase 5Real-World ImpactCryptography, logistics, biology, AI — where this problem lives
Phase 6HeuristicsHow engineers cope with NP\mathcal{NP}-Hard problems in practice
Phase 7Final VerdictConsequences, consensus, and what the future of research looks like

You can jump around if a specific topic interests you, but if you are a complete beginner, I recommend reading in order. Each phase assumes the vocabulary of the phase before it.


Before You Continue

Here are a few things to set your expectations correctly:

No Math Background Required

You do not need to know calculus, linear algebra, or formal logic to follow this documentation. Every time a symbol like \forall, \in, or \sum appears, it will be explained from scratch before being used.

No Programming Experience Required

Some posts include code examples (usually in Python), but they are always optional. You can understand the ideas entirely without them.

This Is Not a Proof

I am not claiming to solve P\mathcal{P} vs NP\mathcal{NP}. I am documenting my journey of understanding the problem. If, somewhere along the way, an idea occurs to me — I will write about it honestly, including why it probably fails.


Ready to Begin?

The next post starts from the very beginning: What is an Algorithm?

If you think you already know the answer, you might be surprised. The formal definition of an algorithm is more interesting — and stranger — than it first appears.

See you there. 🚀


Azeon is an open documentation project by Aziz. If you find an error, have a question, or want to suggest an improvement, open an issue on the GitHub repository linked in the sidebar.