Blockchain curriculum

Nothing is ever edited, so correcting a mistake means adding a compensating entry rather than changing the original — which is what makes history auditable and mistakes permanent. Every design decision downstream follows from choosing that property over convenience.

Replicating data is a solved and cheap problem; the expensive part is getting mutually distrusting machines to agree which of two conflicting writes came first. Understanding that the cost buys ordering, not storage, explains why consensus is worth what it costs.

Nodes do not accept a reported balance — they re-run the transitions and derive it, which is why an incorrect claim cannot survive. It also explains the determinism requirement: any divergence in execution would split the network's view of state.

Identifiers are not names and everything they do is public and permanent, so linking one to a person retrospectively exposes their entire history. The privacy model is therefore closer to a public ledger with nicknames than to anonymity.

Raising throughput by making blocks larger raises the cost of keeping up, which reduces how many independent machines can verify — so capacity is bought with decentralization. Naming the trade is what stops a proposed improvement being assessed on one axis alone.

Three separate permissions — reading, transacting and validating — can each be open or restricted, and a system can mix them. Treating it as one binary hides the interesting designs, which usually restrict validation while leaving reading open.

A fixed group jointly operating the validator set is an organizational arrangement rather than a technical category, and it changes what the system is for: coordination between known parties rather than trustlessness among strangers.

Once participants are identified and can be held accountable outside the protocol, the expensive anonymous-attacker defenses become unnecessary and much cheaper agreement protocols suffice. The security comes from the accountability rather than from the mechanism.

Two parties exchange signed updates privately and settle only the final position, turning many interactions into two settlement transactions. The cost is that both must stay online to contest a stale settlement, which is where the design's difficulty lives.

The same input always yields the same digest and any input size maps to a fixed one, which is what allows a digest to stand in for arbitrary data. Those two properties together are why hashes work as identifiers and as commitments.

A digest cannot be reversed, which is the property that makes hashing categorically different from encryption — there is no key and no decryption, because the original was never encoded in a recoverable form.

If two different inputs could be made to share a digest, two different blocks could claim the same identity and the chain's links would no longer pin anything. The whole structure's integrity reduces to this one property holding.

A single changed bit produces a digest with no visible relationship to the original, so there is no notion of a nearly-matching hash. That is what makes tampering detectable rather than something to be assessed by degree.

Publishing a digest binds you to data you can reveal later, which is how you prove you knew something at a time without disclosing it then. It is the primitive behind sealed bids, randomness protocols and a good deal of protocol design.

A single small root fixes an entire set, because changing any leaf propagates upward and changes it. That is what lets a header commit to thousands of transactions without containing them.

Proving membership needs only the sibling digests along one path, so the proof grows with the logarithm of the set rather than its size. That scaling is what makes light clients possible at all.

A valid proof shows only that the leaf was committed to, and says nothing about whether the transaction inside it obeyed any rule. Conflating the two is a genuine security error, because a proof of inclusion is frequently offered as if it were a proof of correctness.

A keyed structure lets one root prove a specific account's balance or a specific storage slot at a specific block, rather than only membership in a set. That keying is what makes state, not just transactions, provable to a light client.

Ethereum uses the pre-standardization variant, which differs from the finalized standard in its padding and therefore produces different digests for the same input. Using the wrong one produces addresses and selectors that are silently wrong.

Control is possession of the key and nothing else, so there is no authority able to restore access and no recovery process to appeal to. Every usability difficulty in this area descends from that single design choice.

Verification uses only the public key, so authorship is demonstrated without the secret ever leaving the signer. That asymmetry is what allows a permissionless network to check authorization with no registration and no shared secret.

The address is computed from the key rather than assigned by anyone, which is why an account exists before it has ever been used and why there is no registry to consult. It also means a typo produces a valid-looking address nobody controls.

The curve and scheme are shared by the major chains, and the signature's malleability in one component has practical consequences — it means a signature can be altered into another valid one for the same message, changing its hash.

Signing two messages with the same per-signature random value lets anyone solve algebraically for the private key from the two signatures alone. It is a catastrophic and entirely silent failure, which is why the next concept exists.

Deriving the per-signature value from the message and the key removes the random-number generator from the trust model entirely, which eliminates the failure above by construction. Batch verification being faster is a secondary benefit.

There is no stored balance anywhere — a wallet sums the unspent outputs it can sign for, which is why balances are a client-side computation. That also means two wallets can legitimately disagree about a balance if they track different outputs.

An output is consumed entirely, so spending part of one means explicitly returning the remainder to yourself. Forgetting the change output does not fail — it pays the difference as a fee, which is a famous and expensive category of mistake.

Debiting and crediting a stored balance makes persistent contract state natural to express, because a contract can simply have a number that changes. That expressiveness is the reason the model suits general computation.

Independent outputs touch disjoint state, so their validation can proceed concurrently, while two transfers from one account must be ordered. That difference is a structural throughput advantage of the one model and a structural simplicity advantage of the other.

A spent output cannot be spent again, so repetition is impossible for free; a mutable balance has no such property and needs an explicit counter. The same protection arrives from the data model in one case and from an added mechanism in the other.

The header carries the commitments and the body the data, which is what lets a client verify a proof against a header without ever holding the transactions. That separation is the structural basis of light verification.

Each header names its parent's digest, so the chain is linked by content rather than by position — which is what makes rewriting history require redoing everything after the edit. The numbering is a convenience, not the structure.

Old blocks are perfectly writable; rewriting them simply costs more than it is worth. Reading immutability as a physical property rather than an economic one leads to badly calibrated expectations about small or new chains.

Capping computation per block is what keeps verification finishable on ordinary hardware, which is what keeps the validator set wide. Raising it is therefore not a free throughput increase but a move along the trilemma.

A timestamp is asserted by whoever produced the block, constrained only within a tolerance, which makes it a weak clock. Contracts depending on it for anything valuable are depending on a number the proposer chooses.

There is no shortcut — participants vary a value and re-hash until the result falls below a target, so the only strategy is more attempts. That absence of structure is exactly what makes the work a fair and unforgeable measure of effort.

The target adjusts so that blocks arrive at a roughly fixed interval regardless of how much capacity joins or leaves, which is what makes the issuance schedule predictable. More participants therefore produce security rather than faster blocks.

Nodes follow accumulated work rather than block count or arrival order, which is what makes the rule objective — a newly-joining node reaches the same answer as everyone else without asking anyone.

Two valid blocks at one height is a normal occurrence resolved when one branch outgrows the other, returning the loser's transactions to the pending pool. Treating a shallow reorganization as an attack misreads ordinary operation.

No depth makes a block final; additional depth only makes reversal exponentially more expensive. That is why a confirmation count is a risk decision rather than a status, and why the right count varies with the value at stake.

The scarce resource becomes bonded capital, so an attack destroys the attacker's own stake rather than consuming electricity. The security argument changes from cost-to-compute to cost-to-lose, which is a different shape of guarantee.

Proposal rights are assigned per slot and votes aggregated per epoch by randomly sampled committees, which bounds the work while keeping participation broad. The sampling is what allows a very large validator set to reach agreement efficiently.

Validators vote on a head and on a checkpoint, and the accumulated weight of those votes selects the canonical chain. Knowing that the fork choice is vote-driven rather than work-driven explains why the finality rules look nothing like the proof-of-work ones.

Finality arrives through two linked supermajority steps rather than at a block depth, which makes it a discrete event with a defined meaning. That is a stronger guarantee than probabilistic settlement and it arrives on a schedule.

Reverting a finalized checkpoint requires a large fraction of all staked capital to be destroyed, which puts a concrete number on the cost of an attack. The security is quantifiable, which is unusual and is the point of the design.

One punishes provable contradictory behavior and the other gradually reduces the stake of validators who are simply absent, so the chain can eventually finalize again. They address different failures — malice and unavailability — and are frequently conflated.

A participant that lies and sends different things to different peers is strictly harder to tolerate than one that simply stops, because you cannot detect it by absence. Every threshold in this area is stated against that harder model.

Agreement survives while faulty participants stay below a third, which is where the commonly cited finality threshold comes from. It is a mathematical bound rather than a chosen parameter, which is why the same fraction appears across unrelated systems.

A majority attacker can reorder, censor and reverse its own recent transactions, and cannot forge a signature or move someone else's funds. That distinction is routinely lost in reporting, and it is what makes the attack expensive and limited rather than total.

Excluding transactions denies progress without ever producing an invalid ledger, which means the usual verification detects nothing. It is a different kind of failure, and it is why liveness is stated as a separate property from safety.

A newly-joining node cannot safely reconstruct the chain from the beginning alone, because old keys may have been sold and could sign an alternative history cheaply. A recent trusted checkpoint is required, which is a real and deliberate assumption.

A full node re-executes everything and therefore needs to trust nobody, which is precisely the property lost when an application reads state from a provider instead. The convenience trade is real and is usually made without being named.

Headers plus proofs verify specific facts without holding the state, at the cost of assuming the underlying data is actually available. That assumption is the weak point, and it is the same one rollup security rests on.

A modern node is two paired programs with separate responsibilities communicating over a defined interface — one agrees on ordering, the other computes the result. That split is why operators now run two clients and why diversity is measured separately for each.

A bug in an implementation running on a supermajority of nodes can finalize an invalid chain, because the majority agrees on the same wrong answer. Diversity is therefore a protocol-level safety measure rather than a matter of preference.

A full node keeps what is needed to verify and to continue; an archive node additionally retains every historical state, which is what lets it answer questions about the past. The storage difference is large, which is why most infrastructure is not archival.

Every node must reach an identical result, which rules out clocks, randomness and any network access from inside execution. Most of the awkwardness in contract design — oracles, randomness, scheduling — is a consequence of that single constraint.

A bounded stack of unusually wide words, chosen to match the arithmetic that hashing and elliptic curves need. The width makes cryptographic operations natural and ordinary integer work comparatively wasteful, which shows up in gas costs.

A failure rolls back every state change the call made and keeps the gas already consumed, because the work was genuinely performed. That asymmetry is what makes spamming failed transactions expensive.

Contracts work in integers with fixed-point conventions, and integer division truncates. Every rounding decision is therefore explicit and every fractional quantity needs a scale factor, which is a frequent source of off-by-a-factor errors.

Block fields and storage are readable by the proposer and by other contracts, so nothing on the chain can serve as a hidden seed. Attempting to source randomness from them produces a lottery the proposer can win at will.

Since it is undecidable in general whether a program terminates, the protocol charges per step and stops when the budget is exhausted. That is an engineering answer to a theoretical impossibility, and it is why every operation has a price.

The state reverts and the consumed gas is kept, so a failed transaction is never free. That is the property that makes denial-of-service expensive, and it is what surprises users who expect a failure to cost nothing.

Writing a fresh storage slot costs orders of magnitude more than computation, because it imposes a permanent burden on every node. That single ratio shapes contract design more than any other cost — it is why so much is kept in logs or off-chain.

The protocol computes it from how full the previous block was and destroys it, which means the proposer gains nothing by including transactions that pay only the base amount. Burning rather than paying is what removes the incentive to manipulate it.

Every transaction in a block pays the same base amount, so the tip is the only thing competing for inclusion. That is why a stuck transaction is a tip problem rather than a total-fee problem.

You are charged the base plus your tip and refunded the rest, so a high ceiling is protection against a rising base rather than an amount you are offering. Users routinely read it as the price and conclude they overpaid.

Five distinct stages, and a transaction can stall at any of them for different reasons — a bad signature, no peers, too low a tip, no proposer, or an unfinalised chain. Knowing which stage it is stuck at is the whole of debugging here.

Transactions from an account execute in counter order, so a gap blocks everything behind it indefinitely. That is why one under-priced transaction can freeze an account's activity, and why the fix is replacing it rather than sending another.

Nothing can be recalled once broadcast; the only option is outbidding it with a replacement carrying the same counter. A cancellation in a wallet interface is that replacement, sending nothing to yourself, which is worth knowing when it fails to take effect.

A pending transaction is readable by anyone before it executes, which turns intent into a tradeable signal. Every extraction technique in this area begins there, which is why private submission paths exist.

Contracts never act spontaneously, so every chain of internal calls traces back to an account that signed something. That is why nothing recurs on its own and why an apparently autonomous system always has someone paying to poke it.

Binding a signature to a specific chain means the identical bytes cannot be replayed elsewhere, which matters whenever a chain splits or a testnet mirrors a mainnet. Without it, a signature valid on one network is valid on every compatible one.

The modifiers restrict who may call a function and say nothing about who may read data. Reading them as access control for information rather than for invocation is the misunderstanding behind the private-is-not-confidential problem later in this curriculum.

Querying a read-only function directly from a node costs nothing because nothing is executed on-chain; reaching the same function from within a transaction costs gas like any other computation. The same code has two different costs depending on the caller.

One is whoever called you and the other is the account that started the whole chain, which diverge the moment a contract is in between. Authorizing on the second means any contract a user is tricked into calling can act with their authority.

Logs are written cheaply and indexed off-chain, and no contract can ever read one back. That one-way property is what makes them the right place for history and the wrong place for anything the contract itself needs later.

A bare transfer and an unrecognized call reach two different entry points, and the second is what makes proxying possible — it catches everything and forwards it. Understanding that mechanism is a prerequisite for understanding upgrades.

Nothing executes without an incoming transaction, so any recurring behavior requires someone outside to trigger it and pay for it. Designs assuming a contract can act on a timer are assuming a capability that does not exist.

Deployed code executes exactly as written and carries no legal force by itself; whether an arrangement is enforceable is a separate question answered by law rather than by the chain. The two meanings of the word cause real confusion about what is being promised.

Contracts call each other without permission, which is what allows a system to be assembled from parts nobody coordinated. The same property means a failure or an exploit in one part propagates to everything built on it, which is the systemic half of the bargain.

Code is immutable by default and frequently holds value directly, so a bug is both immediately exploitable and often unfixable. That combination is why review is proportionally far more important here than in software that can be patched on Monday.

Three locations with very different costs — persistent and expensive, temporary and cheap, and read-only and cheapest. Choosing among them is one of the largest gas decisions available, and the default is frequently not the cheapest option.

Assigning through a reference to persistent state mutates it, while copying the same value into temporary space does not. The two look nearly identical in source and differ completely in effect, which makes it a classic source of silent bugs.

Small variables share a slot only when declared next to each other, so reordering a struct's fields changes its storage cost without changing its behavior. It is one of the few places where source formatting has a direct price.

Calls are routed by a short prefix of the signature's hash, which is short enough that two different signatures can collide. That collision possibility is exploitable in proxy patterns, which is why the risk is worth knowing rather than dismissing as improbable.

The chain stores bytecode and not the interface description, so a caller needs the compiler's output before it can encode anything. That is why a verified source listing is so valuable and why an unverified contract is hard to interact with correctly.

Code at an address cannot be patched, so every upgrade mechanism is indirection — pointing somewhere else — rather than editing. Knowing that reframes the whole topic: the question is always who controls the pointer.

The called code executes against the caller's storage, balance and identity, which is powerful and is exactly why it is dangerous. Almost every upgrade pattern and several major exploits are consequences of this one instruction.

A thin contract keeps the state and forwards calls to a swappable logic address, which is the standard shape of an upgradeable system. The state staying put is what makes the upgrade invisible to users and to other contracts.

A replacement whose variables are in a different order writes to the wrong slots, corrupting state that looked fine a moment earlier. That is why layouts may only be appended to, and why the discipline has to survive every future change.

An upgradeable contract is exactly as trustworthy as whoever can replace its logic, which means the code you read is not necessarily the code that will run. It is a governance property being described in technical language.

An external call hands control to the callee, which can call back before your state was updated — so the contract sees its own stale state and acts on it again. The vulnerability is in the ordering rather than in the call.

Validate, then write state, then call out. The ordering alone defeats most of the class, because a re-entering call finds the state already updated. It is a pattern rather than a guard, which is why it composes better than a lock.

A lock on one function does not protect a sibling that reads the same state, so re-entry through a different entry point sees the mid-update values. That is why reasoning about locks per-function rather than per-state is insufficient.

Arithmetic wrapped silently in older compiler versions and now reverts by default, with an explicit construct to opt back out for gas. Knowing the version boundary matters because a great deal of published advice predates the change.

An unprotected privileged function is callable by anyone regardless of what the interface exposes, because the interface is not the boundary. It is the simplest vulnerability in this list and one of the most frequently exploited.

A raw call returns a success flag instead of reverting, so ignoring the return value continues as though it worked. The failure is silent and the subsequent logic proceeds on a false premise, which is worse than a revert would have been.

The keyword prevents other contracts from reading and does nothing to prevent anyone reading the storage directly off the chain. Storing a secret in a private variable is a common and complete misunderstanding of what the visibility means.

The chain moves nothing natively — a transfer is one contract decrementing one number and incrementing another in state it owns. Everything about token behavior follows from it being ordinary contract code rather than a protocol feature.

Letting a contract spend on your behalf takes two steps because a plain transfer cannot notify the recipient, so the allowance is set first and drawn on later. The two-step shape is the source of several of the problems below.

An unlimited allowance remains live indefinitely, so a bug discovered in the spender years later can drain a wallet that has not interacted since. The convenience is real and the exposure is open-ended, which is why revoking is worth doing.

Changing a non-zero allowance can be front-run so the spender uses the old amount and then the new one. The standard workaround is setting it to zero first, which is why some interfaces require two transactions to change an allowance.

Balances are plain integers and the decimals value is a presentation hint that no arithmetic respects. Assuming the common value breaks against tokens that use a different one, and the failure is off by orders of magnitude rather than slightly.

Each identifier has exactly one owner, and the safe variant checks that a contract recipient can actually handle the token. Using the unsafe one to a contract that cannot is how tokens become permanently stuck.

One contract tracks many identifiers, fungible or not, and can move several in a single call. The batching is the efficiency argument, and the single-contract design is what makes it suitable for large collections.

Three families backed by fiat reserves, by over-collateralised crypto, or by an algorithm — and they fail in different ways, with the third having failed repeatedly and spectacularly. The peg is a claim about the mechanism, not a property of the token.

Transactions run elsewhere and the inputs plus a commitment to the resulting state are posted back, which is what buys throughput without asking the base layer to execute everything. The base layer becomes the settlement and data layer rather than the compute one.

The guarantee that anyone can retrieve the inputs and recompute the state independently is what makes the arrangement trustless. Without it the operator's claim about the state is unfalsifiable, which is the difference between a rollup and a database.

The posted result is accepted unless challenged within a window, which makes the common case cheap and the dispute case expensive. The security rests on at least one honest party watching and being able to afford to challenge.

The dispute period is why a native withdrawal takes days rather than minutes — the funds cannot be released until the result can no longer be contested. Third-party services that front the liquidity are pricing that delay, not removing it.

Proving correctness before acceptance removes the dispute period entirely, so the delay becomes proof generation rather than a waiting period. That is a fundamentally different security argument: mathematical rather than economic.

The transactions remain public; the proof compresses verification rather than hiding anything. The name misleads almost everyone once, and privacy is a separate property that these systems mostly do not provide.

Data posted for availability has its own fee market and is pruned after a period, because what is required is that anyone could have fetched it — not that it is stored forever. That distinction is what makes the cost reduction sound rather than a shortcut.

An operator's instant receipt is a promise about what will be posted, and finality arrives only once the base layer finalizes the batch. Treating the receipt as settlement is the same error as treating an unconfirmed transaction as settled.

Nothing crosses — the asset is immobilized on one side and a claim is issued on the other. Understanding that there are two assets rather than one moving is the prerequisite for understanding what can go wrong.

The wrapped token is worth whatever the escrow behind it is worth, which makes holding one a credit exposure to the bridge rather than ownership of the underlying. The name suggests a copy and the reality is an IOU.

A group attesting to deposits and a contract verifying proofs are entirely different risk models that present identically to a user. Which one a bridge uses is the single most important thing to know about it.

One contract holds the collateral of everyone who has ever crossed, which makes it the most valuable single target in the ecosystem. That concentration, rather than any particular bug class, is why they dominate the loss tables.

A plain account is authorized by exactly one key of one type, must hold the native asset to pay fees, and cannot batch or express any rule. Every limitation people complain about in wallet usability traces to that list.

When the account is code, it decides what counts as a valid authorization — which allows familiar authentication methods, multiple approvers, spending limits and recovery. The capability comes from moving the check into programmable code.

A parallel pool of intents packed by third parties into ordinary transactions delivers the capability without changing the protocol. That no-fork property is why it could be adopted incrementally rather than waiting for a coordinated upgrade.

A third party can pay the fee or accept it in another asset, which removes the requirement to acquire the native token before doing anything. It addresses the first-transaction problem, which is the most abrupt part of onboarding.

Allowing an existing account to delegate to contract code for a transaction grants the smart-account behaviors without migrating funds to a new address. That migration cost was the main obstacle to adoption, which is what this removes.

The assets are entries in the ledger and the wallet holds only the key authorizing their movement, which is why restoring a wallet on a new device recovers everything. It also means the software holds nothing of value except the key.

A recovery phrase deterministically regenerates every key, so whoever reads it owns the entire wallet immediately and permanently. It is the single point of total failure, which is why every legitimate interface refuses to ask for it.

The key signs inside the device so malware on the computer cannot extract it — and you still approve whatever the device's screen shows. It protects the key and not the decision, which is the boundary of what it can do.

A custodian's balance is a database entry backed by their solvency and their controls; self-custody makes a lost key permanent. Both are real risk models and the choice is between counterparty risk and operational risk.

Approving data you cannot read means trusting the interface that produced it, which is how most drainer scams work — the signature is legitimate and its meaning was not what the user believed. Readable transactions are a security feature.

Whoever chooses the order within a block can extract value from that choice independently of what anyone paid in fees. Recognizing ordering as a valuable right rather than an implementation detail is the whole subject.

Placing a trade before, after or on both sides of a visible pending one, which is possible precisely because intent is public before execution. The sandwich is the compound case and the most extractive of the three.

An extractor can only take what the tolerance permits, which turns that setting into a security control rather than a convenience. A high tolerance set to avoid failed transactions is an explicit offer of the difference.

Splitting block assembly from block proposal limits what a validator must be trusted with and what they can extract. It is a structural response to the extraction problem rather than an attempt to eliminate it.

Determinism forbids a network call from inside execution, so external data has to arrive as a transaction someone chooses to send and pay for. Every oracle design is a way of arranging who sends it and why they can be believed.

A contract that is trustless in every other respect is exactly as trustworthy as whoever supplies its prices. That is why the interesting question about a protocol is usually about its data source rather than its own code.

Combining many independent reporters on-chain removes the single point of failure at the boundary, converting a trusted party into a threshold assumption. The security then depends on the independence of the reporters, which is harder to verify than their number.

A feed that writes only when the value moves beyond a threshold is by design out of date most of the time. Consuming one without checking its age is assuming a freshness the design never offered.

Fair randomness must be unpredictable both to whoever requests it and to whoever produces the block, which requires a commitment plus a proof that the value was generated correctly. Anything simpler is manipulable by one party or the other.

Making previously valid blocks invalid means un-upgraded nodes still accept the upgraded chain, so the change can roll out without a split. The compatibility comes from the direction of the change rather than from coordination.

Making previously invalid blocks valid means un-upgraded nodes reject the new chain, so the network splits unless everyone upgrades. That is why such changes need coordinated activation and why they are politically expensive.

A proposal moves through defined stages with terminal states for those that stall or are abandoned, which makes the status a reliable signal about maturity. Citing a draft as though it were settled is a common error in this area.

One changes the protocol and requires coordinated activation; the other is an application-level convention needing no protocol change at all. That is why token standards proliferate easily while protocol changes take years.

Protocol changes are settled by implementers converging in public discussion, and holding the asset confers no vote over the rules. Assuming ownership implies governance is a widespread misreading of how these systems are actually changed.