Back
Keentune
Blockchain curriculum 25 chapters
·
143 concepts
·
free
Everything the adaptive question bank can teach and test in Blockchain, from foundations through advanced practice. Work through it in order, or start practising and let the questions find your level.
Start practising Blockchain
New here? Read the Blockchain guide
A free 16-minute primer — the mental model, the mistakes beginners make, and what to practise first.
•
every node keeps the same ordered log, and entries are appended rather than edited in place
•
copying data is trivial; agreeing on ONE order for conflicting writes is what consensus actually buys
•
a block is a batch of state transitions every node re-executes, so state is recomputed, never reported
•
balances and transfers are world-readable, and one linked address exposes its entire history
•
throughput bought with bigger blocks is paid for in decentralization, because fewer machines can keep up
•
anyone may read, transact and validate on a public chain; a permissioned one restricts each of those to known parties
•
a fixed set of organisations jointly operates the validator set, which is a governance choice rather than a technical one
•
when validators are identified and accountable, cheap BFT consensus replaces costly proof of work
•
two parties transact off-chain and settle only the final balance, paying for two on-chain transactions instead of many
B. Cryptographic hash functions
•
any input size maps to a fixed-size digest, and the same input always produces the same digest
•
a digest cannot be run backwards, which is why hashing is not encryption and has no "decrypt"
•
two inputs sharing one digest must be infeasible to find, or two different blocks could claim the same identity
•
flipping one input bit changes about half the output bits, so a tampered block is not "nearly" the original
•
publishing a digest binds you to data you can reveal later without revealing it now
C. Merkle trees and proofs
•
one 32-byte root fixes an entire set, and changing any single leaf changes the root
•
membership needs only the sibling hashes along one path, so proof size grows with log(n), not n
•
a valid proof shows the leaf was committed to, not that the transaction inside it obeyed any rule
•
Ethereum's keyed trie lets one root prove a specific balance or storage slot at a specific block
•
Ethereum hashes with Keccak-256, the pre-standardization padding, not NIST's finalized SHA3-256
D. Keys, signatures and addresses
•
control is possession of a key, so there is no password reset and no authority that can restore access
•
a signature verifies against the public key without ever exposing the private key that made it
•
an Ethereum address is the last 20 bytes of the Keccak hash of the public key, so it is computed, never registered
•
Bitcoin and Ethereum sign with ECDSA over the secp256k1 curve, whose signatures are malleable in the s value
•
reusing the per-signature random value in ECDSA lets any observer solve algebraically for the private key
•
Ed25519 derives its per-signature nonce from the message and key, removing that RNG failure mode and verifying faster in batch
E. UTXO and account ledger models
•
a Bitcoin wallet's balance is the sum of unspent outputs it can sign for, computed by the client rather than stored
•
an output is consumed entirely, so the remainder must be returned to yourself as an explicit change output
•
Ethereum debits and credits a stored balance, which is what makes persistent contract state natural to express
•
independent outputs touch disjoint state, while two transfers from one account must be applied in sequence
•
a spent output makes a UTXO transaction unrepeatable for free; the account model needs an explicit nonce to get the same property
F. Blocks, chaining and immutability
•
the header carries the commitments and the body the transactions, which is why a header alone can verify a proof
•
each header names its parent's digest, making the chain a hash-linked list rather than a numbered sequence
•
old blocks are not physically unwritable; rewriting them is simply worth less than it costs
•
capping computation per block is what keeps validating one finishable on ordinary hardware
•
a block timestamp is asserted by the proposer within a tolerance, so it is a weak clock and not a trusted one
G. Proof of work, difficulty and reorgs
•
miners vary a nonce until the header digest falls below a target, and there is no shortcut, only more guesses
•
the target adjusts so blocks arrive at a fixed average interval no matter how much hash power joins or leaves
•
nodes follow the branch with the most accumulated work, not the one with more blocks and not the one seen first
•
two valid blocks at one height resolve when a branch outgrows the other, returning the loser's transactions to the mempool
•
no depth makes a proof-of-work block final; more depth only makes reversal exponentially more expensive
H. Proof of stake, validators and finality
•
the scarce resource is bonded capital, so an attack costs destroyed stake instead of burnt electricity
•
proposal rights are assigned per slot and votes are aggregated per epoch by randomly sampled committees
•
validators attest to a head block and a checkpoint, and the weight of those votes is what selects the canonical chain
•
two consecutive supermajority-linked checkpoints finalize, so finality is a two-step rule rather than a block depth
•
reverting a finalized checkpoint requires at least a third of all staked capital to be slashed
•
slashing punishes provable equivocation, while the leak bleeds offline validators until the chain can finalize again
I. Byzantine faults and attack economics
•
a Byzantine node lies and equivocates rather than merely crashing, which is a strictly harder failure to tolerate
•
agreement survives fewer than a third faulty participants, which is where the 33% finality threshold comes from
•
a 51% attacker reorders, censors and double-spends its own coins; it cannot forge a signature or mint from your account
•
excluding transactions denies a user progress without ever producing an invalid ledger
•
a new proof-of-stake node cannot safely sync from genesis alone and needs a recent trusted checkpoint
J. Nodes, clients and syncing
•
a full node re-executes every transition, which is precisely what removes the need to trust an RPC provider
•
headers plus Merkle proofs verify a fact without the full state, at the cost of assuming the data is available
•
a post-Merge node runs two paired clients talking over the Engine API, one ordering blocks and one executing them
•
a bug in a supermajority client can finalize an invalid chain, so no single implementation should dominate
•
a full node keeps recent state and can verify everything; an archive node also retains every historical state root
•
every node must reach the identical result, so no clock, no randomness and no network call exists inside execution
•
a bounded stack of 256-bit words, a width chosen to match hashing and elliptic-curve arithmetic
•
a failed call rolls back every change it made, but the gas already consumed stays spent
•
contracts do fixed-point arithmetic with integers, and integer division truncates rather than rounding
•
block fields and storage are visible to the proposer and to every contract, so they cannot seed a fair lottery
L. Gas and the fee market
•
you cannot decide in advance whether a program stops, so you charge per step and halt when the budget runs out
•
the state reverts but the consumed gas is kept, so a failed transaction is never a free transaction
•
writing a fresh storage slot costs orders of magnitude more than arithmetic, which is what shapes contract design
•
EIP-1559's base fee is computed by the protocol from how full the previous block was and is destroyed, not paid to the proposer
•
the tip is what competes for inclusion, since every transaction in a block pays the same base fee
•
you are charged base plus tip and refunded the difference, so setting a high max fee is not the same as paying it
M. Transactions, nonces and the mempool
•
sign locally, gossip to peers, wait in the mempool, get included by a proposer, then finalize under consensus
•
an account's transactions execute in nonce order, so one missing nonce stalls every later transaction behind it
•
a broadcast transaction cannot be recalled; you can only outbid it with a replacement carrying the same nonce
•
a pending transaction is readable by anyone before it executes, which is the raw material for front-running
•
contracts never act on their own, so every chain of internal calls traces back to an externally-owned account
•
EIP-155 binds a signature to one chain so the identical signed bytes cannot be replayed on another
N. Solidity and contract anatomy
•
public, external, internal and private restrict who may call a function, never who may read it
•
a read-only call costs nothing when queried from a node but costs gas when reached from a transaction
•
msg.sender is the immediate caller and tx.origin the original EOA, so authorizing on tx.origin is phishable
•
logs are cheap and indexable off-chain, and no contract can ever read one back
•
a bare transfer hits receive and an unknown selector hits fallback, and that fallback is what makes proxies possible
•
nothing executes without an incoming transaction, so any recurring behavior needs an external trigger
•
a deployed contract executes as written and carries no legal force of its own — enforceability is a separate question
•
contracts call each other permissionlessly, which is the source of both the leverage and the systemic risk
•
contracts are immutable by default and hold value directly, so a bug is exploitable and often unfixable
O. Data location and ABI encoding
•
persistent and expensive, volatile and cheap, and read-only and cheapest of the three
•
assigning through a storage reference mutates state, while copying the same value into memory does not
•
small variables share a 32-byte slot only when declared adjacently, so reordering fields changes gas
•
the first four bytes of the Keccak hash of the signature route a call, and two signatures can collide on one selector
•
the chain stores bytecode only, so a caller needs the compiler-produced ABI before it can encode anything
P. Deployment, delegatecall and upgradeability
•
code at an address cannot be patched, so every upgrade scheme is indirection rather than editing
•
the callee's logic executes against the caller's storage, balance and msg.sender
•
a thin proxy delegatecalls an implementation address it is able to swap
•
a new implementation that reorders variables writes the wrong slots, so the layout must only ever be appended to
•
an upgradeable contract is exactly as trustworthy as whoever holds the key that can replace its logic
Q. Vulnerability classes and defensive patterns
•
an external call hands control to the callee, which can call back in before your state was updated
•
validate, then write state, then call out; the ordering alone defeats most reentrancy
•
a guard on one function does not protect a sibling that reads the same state left stale mid-call
•
arithmetic wrapped silently before Solidity 0.8, now reverts by default, and unchecked deliberately opts back out
•
an unprotected privileged function is callable by anyone regardless of what the front end exposes
•
a raw call returns false instead of reverting, so ignoring its return value continues as if it had succeeded
•
the private keyword blocks other contracts from reading, while anyone can read the storage slot off the chain
•
the chain moves nothing natively; a token transfer is one contract editing two numbers it owns
•
letting a contract spend for you takes two steps because a plain transfer cannot notify the recipient
•
an infinite allowance stays live indefinitely, so a later bug in the spender drains a wallet that has done nothing since
•
changing a non-zero allowance can be front-run so the spender takes both the old amount and the new one
•
balances are plain integers and decimals is a hint, so assuming 18 breaks against a six-decimal token
•
each token id has exactly one owner, and safeTransferFrom checks that a contract recipient can accept it
•
one contract tracks many fungible and non-fungible ids and moves several of them in a single call
•
fiat-collateralised, crypto-collateralised and algorithmic designs fail in different ways, and the third has failed repeatedly
S. Rollups, data availability and L2 finality
•
a rollup runs transactions elsewhere and posts the inputs plus a state commitment back to layer 1
•
the guarantee that anyone can fetch the inputs and recompute the state is what makes a rollup trustless
•
the posted root is accepted unless someone submits a fraud proof inside the challenge window
•
that dispute period is why a native optimistic withdrawal takes about a week rather than minutes
•
a zk rollup proves correctness before layer 1 accepts the root, so the wait is proof generation, not disputes
•
rollup transactions stay public; the proof compresses verification rather than hiding anything
•
EIP-4844 blob data has its own fee market and is pruned after weeks, because availability, not permanence, is what is required
•
a sequencer's instant receipt is a promise, and the transaction is only final once layer 1 finalizes its batch
T. Bridges and cross-chain risk
•
the asset is locked on the source chain and a claim is minted on the destination; nothing actually crosses
•
a wrapped token is worth whatever the escrow behind it is worth, making it a credit exposure rather than a copy
•
a multisig attesting to deposits is a fundamentally different risk model from a contract verifying proofs
•
one contract holds every user's collateral, which is why bridges lead the exploit-loss tables
•
an externally-owned account is authorized by exactly one secp256k1 key, must hold ether for gas, and cannot batch or express rules
•
a smart account's own code decides what a valid signature is, which is what allows passkeys, multisig and spending limits
•
ERC-4337 adds a parallel mempool of user operations that bundlers pack into ordinary transactions, with no protocol change
•
a third party can pay the fee or accept it in a token, so a new user needs no ether before their first transaction
•
an EOA can delegate to contract code for a transaction, granting smart-account behavior without migrating funds
V. Wallets and key management
•
assets live in the ledger, and the wallet only stores the key that authorizes moving them
•
a BIP-39 phrase deterministically regenerates every key, so whoever reads it owns the entire wallet
•
the key signs inside the device so malware cannot extract it, but you still approve whatever the screen shows you
•
a custodian's balance is a database row backed by their solvency, while self-custody makes a lost key final
•
approving calldata you cannot read means trusting the interface, which is how most wallet-drainer scams close
W. MEV and transaction ordering
•
whoever chooses the order inside a block can extract value from that choice independently of fees
•
placing a trade before, after, or on both sides of a visible pending one, which a public mempool makes possible
•
a sandwich can only take what your tolerance permits, which makes that setting a security control rather than a preference
•
splitting who assembles a block from who proposes it limits what a validator has to be trusted with
X. Oracles and the trust problem
•
determinism forbids a network call from inside execution, so outside data must arrive as a transaction someone sends
•
a trustless contract fed by a single reporter is exactly as trustworthy as that one reporter
•
many independent reporters combined on-chain remove the single point of failure at the boundary
•
a deviation-threshold feed only writes when the value moves enough, so freshness must be checked rather than assumed
•
fair randomness must be unpredictable to the requester and to the proposer, which takes a commitment plus a verifiable proof
Y. Governance, forks and the EIP process
•
previously valid blocks become invalid, so un-upgraded nodes still accept the upgraded chain
•
previously invalid blocks become valid, so un-upgraded nodes reject the new chain and the network splits
•
Draft, Review, Last Call and Final, with Stagnant and Withdrawn as the terminal states
•
a Core change needs a coordinated fork, while an ERC is an application convention that needs no protocol change at all
•
client teams and implementers converge on calls, and holding coins confers no vote over protocol rules
Keentune is not affiliated with or endorsed by the organizations whose documentation informs these maps.
Start practising Blockchain
All about Blockchain practice
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.
© 2026 SportaApp LLC