For the Certified Ethereum Professional (CEP), build one skill: given any Ethereum property, state which layer owns it — the protocol (consensus, gas rules), a deployed contract (standards, access control), or a rollup (execution off L1, settlement on L1). When two claims both sound true, the deciding question is whether each is true at the same layer. Practice by tracing one transaction end to end, writing down exactly what each layer guarantees.
Layer-tracing: the method that separates true claims from misapplied ones
Treat the CEP syllabus as a stack of three layers — protocol, contract, and rollup — and assign every property you learn to exactly one.
Ethereum's syllabus topics overlap on purpose. A claim like "this transaction is final" mixes consensus (when the block is sealed), execution (when the state change is applied), and, on a rollup, a bridge delay. If you memorize topics separately, two statements in a comparison can both look correct because each is true somewhere in the stack. Layer-tracing forces you to ask: true at which layer, for whom, and under what delay?
Make the method concrete now. Draw three columns — Protocol (L1), Contract, Rollup — and list every fact you study in the matching column. Validators, base fees, and state roots go in Protocol. Token interfaces and access control go in Contract. Batch posting and fraud-proof windows go in Rollup. When a fact seems to belong in two columns, write the one-line condition that separates them; that condition is usually the concept itself, stated precisely for the first time.
- Protocol layer: proof-of-stake validator duties, block production, base fee mechanics, state roots
- Contract layer: token interfaces, ownership checks, reentrancy guards, proxy storage
- Rollup layer: sequenced execution, data availability on L1, withdrawal proving
Who does what: validator duties versus execution results
Proof-of-stake governs block production and attestation; the EVM only executes transactions inside those blocks. Keep the two job descriptions apart.
Under proof-of-stake, validators are selected to propose blocks and attest to what they see, and staked ether serves as the bond behind those duties. The EVM, by contrast, is deterministic: given the same transactions and the same starting state, any node computes the same ending state. A comparison worth practicing pairs "attestation" with a smart-contract result, or "deterministic execution" with a validator reward — resolving it requires keeping those job descriptions separate.
Trace one block mentally as a scenario. A validator proposes a block; every full node re-executes its transactions and checks the resulting state root before the block counts. Consensus decides which block is canonical, while execution decides what the state inside it contains — neither replaces the other. Validators do not compute contract outputs; node re-execution verifies them, and the proposal and attestation process is what makes the chain agree.
- Validators: propose, attest, stake at risk of penalties for provable misbehavior
- Nodes: re-execute transactions independently and compare the resulting state root
- EVM: deterministic state transition machine — same input, same output, every time
EVM state: why reads are cheap and writes change the tree
Reading storage costs little; writing alters the state tree that every node must store and verify, so writes cost far more gas.
The EVM keeps account balances, nonces, code, and storage in a state tree referenced by a root hash in each block header. Changing any storage slot changes a hash chain up to the root, which is why persistent writes are priced far above reads, and why computations that vanish at the end of a transaction (memory, stack) are cheaper than storage. The read-versus-write distinction is the principle to internalize before any gas arithmetic.
Work an example with labeled numbers. Suppose a function reads a mapping entry, does an arithmetic check, and writes a new uint256 value only if the check passes. A proposed optimization removes the storage write when the value is unchanged. The saving comes from skipping the tree update, not from skipping the check, and the read still happens. Reads do not alter the root; writes do — that rule, not arithmetic, explains where the cost lives.
- Storage (persistent): written to the state tree — expensive
- Memory and stack (transient): cleared after the transaction — cheap
- Logs: emitted for off-chain consumers, not stored in contract state
Token standards: what each interface promises — and what it does not
ERC-20, ERC-721, and ERC-1155 define function interfaces, not guarantees; separating the promise from the implementation is the skill to practice.
Treat the standards as contract-level commitments. ERC-20 defines fungible token functions such as transfer and approve; ERC-721 defines non-fungible items with unique identifiers; ERC-1155 batches multiple token types in one contract, mixing fungible and non-fungible IDs. None of these interfaces guarantees anything about value, backing, or behavior beyond the functions specified — an ERC-20 with an owner-controlled blocklist can still conform to the interface.
Exercise: pick any three token contracts you can find on a public explorer, read their approve and transferFrom logic, and write down where each departs from the plain interface. The classic approve-then-transferFrom flow lets a spender move your tokens up to an allowance, so approving an unlimited amount hands over open-ended permission until changed. ERC-721 approvals are per-token or per-operator — a different shape of permission. Doing this on paper teaches you to attribute over-broad allowances to the contract layer rather than to a bridge or consensus problem.
- ERC-20: fungible units; approve and transferFrom allowances are the risk surface
- ERC-721: unique IDs; per-token and operator approvals
- ERC-1155: many token types per contract; batch transfers, distinct IDs
Contract security: the reentrancy scenario, step by step
Reentrancy exploits external calls that hand control to another contract before your state updates finish; checks-effects-interactions closes it.
The checks-effects-interactions pattern orders a function to validate inputs, update its own state, and only then call external contracts. Reentrancy becomes possible when a function calls an untrusted address while its state still shows the old value — the callee re-enters and repeats a withdrawal before the balance is decremented. Guard modifiers exist, but the ordering rule is the primary defense, so practice diagnosing which ordering step was skipped rather than stopping at the bug's name.
Worked scenario: a withdrawal function reads the caller's balance, sends ether via a plain call, then zeroes the balance. A malicious recipient's fallback re-enters withdrawal repeatedly while its recorded balance is still untouched, emptying the pool. The mistake to avoid is blaming the call itself or the recipient; the better decision is to pinpoint the ordering flaw — state updated after the external call — and select the fix that zeroes the balance before sending. It matters because the same ordering bug reappears disguised in staking, auction, and reward-distribution designs.
- Checks: validate conditions first, before any state change
- Effects: update the contract's own storage second
- Interactions: call external contracts and transfer value last
Rollups and DeFi infrastructure: where execution runs and what a withdrawal proves
Rollups execute off L1 and post results to L1; optimistic rollups use fraud-proof windows, validity-proof rollups publish proofs, and both settle on L1.
Apply layer-tracing to scaling. A rollup transaction executes on the rollup, not the EVM main chain; what L1 receives is batch data plus a commitment that anchors the rollup state. Withdrawals differ by design: optimistic rollups assume results are valid unless challenged during a window, while validity-proof designs publish a proof accepted up front. When a scenario describes a delayed withdrawal, trace it to the rollup layer's proving model — do not confuse it with L1 confirmation times or with a token contract's transfer rules.
Scenario: a user bridges funds through an optimistic rollup and expects the withdrawal within minutes. The tempting but wrong reading treats the wait as an L1 congestion problem or a contract bug. The better decision is recognizing that the fraud-proof window is a designed property of optimistic proving, so the honest options are a liquidity bridge at the contract layer or patience for the window — not "fixing" the L1. The same delay described with a validity-proof rollup would instead point to proof generation and posting costs. For DeFi topics, anchor each pattern to the layers you know: automated market makers are contracts holding pooled reserves and pricing by a formula, lending markets are contracts enforcing collateral ratios, and oracles deliver external data to contracts. When your notes mix a price-feed fact with a bridge or pool fact, ask which layer each belongs to before comparing them.
| Property | Optimistic rollup | Validity-proof rollup | Layer-1 execution |
|---|---|---|---|
| Where transactions execute | Sequenced and run on the rollup | Sequenced and run on the rollup | Directly in L1 blocks by the EVM |
| How correctness is established | Assumed valid unless challenged via fraud proofs | Cryptographic proof posted with results | Every node re-executes every transaction |
| Withdrawal character | Subject to a challenge window before exit | Exit once the proof verifies | No separate proving step |
| Data availability role | Batch data posted to L1 | Batch data posted to L1 | Inherent — full blocks on L1 |
A four-week preparation sequence with a self-check rubric
Spend week one mapping facts to layers, week two tracing a transaction end to end, week three drilling standards and security, week four running timed comparisons.
Week one: fill the three-column layer map from section one until every syllabus topic — consensus, EVM state, standards, security, DeFi, scaling — sits in a column with a one-line justification. Week two: trace one simulated transaction on paper from signature to state root, noting what the validator does, what nodes re-execute, and which contract functions fire. Week three: hand-draw the three token interfaces and the checks-effects-interactions ordering, then rewrite each from memory. Week four: write your own comparisons between layers and answer them against your map. For administrative details about the credential itself, refer to the issuer, the Blockchain Training Alliance.
Self-check rubric for the paper exercise: (1) Can you state which layer owns a given fact with a one-sentence why — target 18 of 20 facts correct? (2) Can you trace a transaction and name exactly one guarantee per layer without gaps? (3) Can you explain the reentrancy scenario by pointing to the skipped ordering step, not just the bug's name? (4) Can you fill the rollup table from memory? These are learning milestones to guide review, not predictions of a result; if a milestone fails, return to that section's exercise before moving on.
- Milestone 1: layer map complete — every syllabus topic assigned with justification
- Milestone 2: transaction trace written with one guarantee named per layer
- Milestone 3: token interfaces and security ordering redrawn from memory
- Milestone 4: rollup table reproduced without notes
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.