← Back to the Academy
From zero to how blockchains, cryptography, smart contracts, the EVM, and crypto security actually work — with a moving picture for every idea.
Imagine a notebook where everyone in town writes down every payment. Once ink is on the page, you can't erase it without everyone noticing. A blockchain is that notebook, copied onto thousands of computers. Each page is a block, and every new page carries a tiny fingerprint of the page before it. Tamper with an old page and every fingerprint after it stops matching — so cheating is obvious.
With thousands of copies, the network needs a fair way to agree on the next page. That agreement rule is called consensus. The two big flavours are Proof of Work and Proof of Stake.
Here's the thing nobody could crack before Bitcoin: how do you get a crowd of strangers, some of whom are lying, to agree on one history — with no referee? Computer scientists called this the Byzantine Generals Problem. Picture generals surrounding a city, sending each other messengers to agree "attack at dawn." Some messengers are traitors who change the message. How do the honest generals still end up in sync? For decades the answer was "you can't, not without trusting someone." Blockchains are the first practical machine that lets a leaderless crowd agree even while some members cheat — that breakthrough is the whole reason crypto exists.
The specific cheat the notebook stops is the double-spend: spending the same coin twice by telling two people two different stories. Because everyone shares one ordered history, the second story simply doesn't fit. Ordering is the magic — not secrecy.
When two valid next-pages appear at once, the network follows a tie-break rule. Bitcoin uses the heaviest chain rule: keep building, and whichever branch ends up with the most accumulated work wins; the loser's blocks become orphans. This is why people "wait for confirmations" — each block stacked on top makes rewriting history exponentially more expensive. To erase a buried transaction an attacker would need to out-build the entire honest network, the famous 51% attack.
You don't need to do the math — you just need to know what each tool does. Three ideas power almost everything in crypto: hashing, digital signatures, and Merkle trees.
A hash function takes any input and spits out a fixed-length fingerprint. Change a single letter and the whole fingerprint scrambles completely — the avalanche effect. You can't run it backwards to recover the input.
You have a secret private key and a shareable public key. Signing with your private key produces a signature anyone can verify against your public key — without ever seeing your secret. That's how a wallet authorizes a transaction.
Hash every transaction, then hash the hashes in pairs, again and again, until one fingerprint remains: the Merkle root. With it you can prove a single transaction belongs in a giant block by checking just a handful of hashes.
Your keys rest on something called a trapdoor function: easy to walk through one way, practically impossible to reverse. Bitcoin and Ethereum use elliptic-curve cryptography on a specific curve named secp256k1. Your private key is just a giant secret number. Multiply a fixed point on the curve by that number and you get your public key. Going forward is one multiplication; going backward — figuring out the secret number from the public key — is the discrete logarithm problem, which would take every computer on Earth longer than the age of the universe.
This is why "not your keys, not your coins" is the first law of crypto. The private key is ownership. There's no password reset, because there's no company holding a backup — the security comes from math, and math doesn't make exceptions.
Remembering a 64-character secret number is hopeless, so wallets use BIP-39: they turn that number into 12 or 24 ordinary words (your seed phrase). From that one seed, a hierarchical-deterministic (HD) wallet (BIP-32) can grow an endless tree of addresses — like one master key that can cut unlimited specific keys, all recoverable from the same words.
A smart contract is a program that lives on the blockchain. Once deployed, it runs exactly as written, the same way for everyone, with no one able to quietly change it. Sending it a transaction runs its code and can update its stored state.
Every operation costs gas. You set a gas limit — the most you'll pay. If the program runs out of gas mid-way, it stops and reverts. This stops infinite loops from freezing the whole network.
A reentrancy bug happens when a contract sends money out before updating its books. The receiver can call back in and withdraw again and again before the balance is set to zero — like a leak that drains the vault. Famous hacks (The DAO) worked exactly this way.
onlyOwner decide who may call sensitive functions. Forgetting one is a top cause of hacks.Developers write contracts in a readable language (usually Solidity), but the blockchain can't read that. A compiler translates it into bytecode — raw machine instructions — which is what actually gets deployed and frozen on-chain. Alongside it lives the ABI (Application Binary Interface): a little menu that tells apps which functions exist and how to call them. Source → bytecode → deployed address → ABI is the lifecycle of every contract you'll ever touch.
A contract has three places to put data, and mixing them up is a classic rookie (and expensive) mistake. Storage is the permanent vault written to the blockchain — costly, and it persists forever. Memory is a scratchpad wiped after each call — cheap and temporary. Calldata is the read-only envelope the incoming transaction arrived in. Good contracts touch expensive storage as little as possible.
The EVM (Ethereum Virtual Machine) is the engine that actually executes smart contracts. It's a simple stack machine: it works on a tall stack of values, pushing numbers on top and popping them off to do tiny operations called opcodes (ADD, PUSH, SSTORE…).
A normal call runs the other contract's code in its own storage. A delegatecall borrows the other contract's code but runs it in the caller's storage — the trick that makes upgradeable proxies possible (and dangerous if misused).
Everything on Ethereum is an account, and there are exactly two flavours. An EOA (externally-owned account) is a normal wallet, controlled by a private key — it can start transactions. A contract account is controlled by code and can only react when something pokes it. The entire blockchain is really just one giant list of accounts and their balances — the world state — and every transaction is a tiny, agreed-upon edit to that list.
Gas is the meter; the gas price is what you pay per unit. Since EIP-1559, each block has a base fee that's automatically burned (destroyed), plus an optional priority tip you add to jump the queue when the network is busy. The total you pay is roughly gas used × (base fee + tip). When you hear "gas is high tonight," it means the base fee rose because everyone wants in at once.
When you press a button in an app, it builds calldata: the first four bytes are a function selector (a hash of the function's name) and the rest are your arguments, packed in a standard ABI encoding. The contract reads those four bytes like a switchboard — "ah, you want transfer" — and runs that branch.
One shared calculator is secure but slow and pricey, so the ecosystem moved most activity to Layer 2 rollups: they execute thousands of transactions off to the side, then post a compressed summary back to Ethereum for safekeeping. Optimistic rollups assume the summary is honest and allow a challenge window; zk-rollups attach a mathematical proof that it's correct. Either way, you get cheaper, faster transactions while still inheriting Ethereum's security.
In crypto, a bug isn't a crash — it's a withdrawal. Because contracts hold real value and run forever, security engineering means imagining every way someone could abuse your code before they do. That starts with threat modeling: mapping what's valuable and where it could be attacked (the attack surface).
A fuzzer fires thousands of random inputs at the contract looking for one that breaks an assumption — it finds edge cases humans miss. An audit is expert humans reading the code line-by-line and writing up findings by severity. It lowers risk, but never makes a contract "unhackable."
Good engineers never rely on a single lock. The most famous safety pattern is checks-effects-interactions: first check the rules, then update your own books, and only then talk to the outside world — so a reentrancy caller finds the vault already marked empty. A reentrancy guard adds a simple "occupied" flag while a function runs. And pull-over-push means: instead of sending everyone their money (risky), let each person withdraw their own (safe).
Not every hack breaks the code. Many recent disasters used the contract exactly as written but bent the incentives — manipulating a price, a vote, or a liquidity pool so the rules paid out wrongly. That's why security is half computer science and half game theory: you must ask not only "can this break?" but "can someone profit by making it behave?"