The CBSP exam's central challenge is breadth with precision: the syllabus spans consensus mechanisms, cryptography and key custody, smart contracts, network infrastructure, and governance, and each threat demands a different control. Studying one undifferentiated list of 'blockchain attacks' makes mitigation advice blur together. Work from a layered model instead: for every vulnerability you learn, record which layer it lives at, its signature symptom, and its matching first-line mitigation. The worked scenarios, the classification drill, and the four-week sequence below turn that model into repeatable exam reasoning.
One Syllabus, Six Domains, Five Layers: Mapping the CBSP Stack
Treat the CBSP domains as layers of one stack: consensus, key custody, contract code, network infrastructure, and governance, with DApp and ecosystem security as a cross-cutting domain that touches all five. Naming the layer first narrows the candidate vulnerabilities and points to the matching mitigation.
The CBSP program's published module list moves from blockchain basics and consensus through cybersecurity threats, security mechanisms, risk assessments, two-factor authentication, vulnerabilities and attacks, and alternative DLT architectures. That sequence rewards a stack model: each module's threats sit at a specific layer, and three questions organize them — where does the weakness live, what does an incident look like, and which control addresses it. The catalog's DApp and ecosystem security topic is the exception worth handling deliberately: a decentralized application is an assembly of a frontend, contracts, wallets, and network nodes, so its incidents are classified by tracing which layer failed rather than by treating 'the DApp' as a sixth layer.
Apply the model to practice questions. Before reading the answer options, write down the layer and the mechanism; then check which option describes a control that operates at that layer. This ordering protects you from the most instructive distractor: an answer that names a real security technique but attaches it to the wrong layer, such as auditing code for an incident caused by a compromised signing key. When a question describes a DApp ecosystem incident, decompose it — is the signature logic, the custody, or the node view corrupted? — and the layer, and the answer, follows.
| Threat | Layer | Typical signature | First-line mitigation |
|---|---|---|---|
| Majority (51 percent) attack | Consensus | Chain reorganization and double spends against parties accepting fast confirmations | Decentralized consensus power; confirmation depth appropriate to the chain's power distribution |
| Reentrancy | Smart contract | Balance drained through repeated external calls before the state updates | Checks-effects-interactions ordering plus a reentrancy guard |
| Hot-wallet key compromise | Key custody | Unauthorized transfers carrying valid signatures | Cold storage, multisig approval policy, 2FA on operational access |
| Eclipse attack | Network infrastructure | A node sees an attacker-curated view because its peer connections are controlled | Diverse persistent peers and peer scoring on the node |
Consensus Attacks: 51 Percent, Selfish Mining, and Eclipse Attacks Differ
A 51 percent attack concerns majority consensus power, selfish mining concerns withholding blocks to gain an unfair reward share, and an eclipse attack concerns isolating one node. Each implies a different control point.
Keep the mechanisms separate. A majority attack requires a coalition controlling most of the consensus power, which lets it reorganize recent blocks and double-spend against anyone accepting shallow confirmations. Selfish mining is a strategy in which a miner withholds discovered blocks so honest miners waste work on stale chains; it distorts rewards without needing a true majority. An eclipse attack targets a single node's peer connections so it receives an attacker-filtered view of the network — a network-layer problem, not a protocol-vote problem.
In questions, let the mitigation confirm the classification. Decentralizing hashpower or validator stake addresses majority attacks; protocol incentive design addresses selfish mining; peer management and node hardening address eclipse attacks. Also state the chain type before reasoning: permissioned networks typically run different consensus assumptions than public proof-of-work chains, and the module on alternative DLT architectures exists precisely because different structures change which of these attacks even applies.
Key Custody: Hot Wallets, Cold Storage, Multisig, and Where 2FA Fits
Key management is operational security, not code security. Hot wallets hold online-signable keys, cold storage keeps keys offline, multisig requires multiple approvals, and 2FA authenticates users to services that use those keys.
These concepts differ along two axes. Connectivity: hot versus cold describes whether a key can sign while exposed to the network. Approval policy: multisig describes how many independent signatures a transaction needs, independent of where keys are stored. Two-factor authentication sits further out — it protects a person's access to a wallet service or signing system. The CBSP syllabus treats 2FA with blockchain as its own module, and the correct placement is as an access control around key usage, never a substitute for custody design.
Worked scenario: an operations engineer approves a wallet-signing prompt on a spoofed frontend, and the attacker drains the treasury with valid signatures. The team's first move is to commission a full audit of the treasury smart contract — plausible but misdirected, because the contract behaved exactly as written and an audit would pass while leaving the exposure intact. The better decision treats this as a custody incident: rotate keys, move reserves to cold storage under a multisig policy, and enforce 2FA on the signing service. The layer determines whether the fix closes the gap at all.
Smart Contracts: Reentrancy, Overflow, and Access Control Are Different Bugs
Reentrancy exploits call ordering, integer overflow exploits numeric type limits, and access-control flaws let unauthorized callers invoke privileged functions. Each has a distinct signature, so diagnose the mechanism before selecting a fix.
Learn the three signatures side by side. Reentrancy appears when a contract makes an external call to an attacker-controlled address before updating its own state, letting the attacker re-enter the function against stale balances. Arithmetic overflow appears when values exceed their type's limits during computation. Missing or incorrect access restrictions appear when functions meant for administrators can be called by anyone. The matching tools differ: checks-effects-interactions ordering and reentrancy guards for the first, checked arithmetic for the second, and explicit role-gated modifiers for the third.
Worked scenario: a developer reviews a contract drained through repeated withdraw calls and writes it off as an overflow bug, planning to add checked arithmetic. The signature says otherwise — the balance is read and updated after an external call to the recipient, which is the reentrancy pattern. The better decision is to reorder the function to checks-effects-interactions, add a reentrancy guard, and then review every external call in the codebase for the same ordering flaw. Checked arithmetic would not stop the drain, and the ordering bug would remain live in sibling functions.
Risk Assessment and Governance: Scope the Asset Before Choosing Controls
Blockchain risk assessment starts with what is protected — keys, contract funds, data integrity, network availability — then maps threats to each asset. Governance choices such as public versus permissioned change the threat model itself.
The risk-assessment domain rewards a repeatable flow: identify assets at every layer, evaluate likelihood and impact for the threats that apply to each, select controls, and document residual risk. Governance decisions feed that flow. A permissioned consortium reduces exposure to anonymous Sybil-style participation but concentrates trust in node operators and admission processes, so the register gains entries for operator compromise and admission abuse that a public chain does not carry the same way. Alternative DLT architectures shift which consensus threats apply at all.
Apply this with a short example: a consortium proposes adding 2FA 'to make the blockchain itself secure.' The better decision splits the claim. Two-factor authentication hardens user access to wallets and signing services — one register entry, owned by operations. Consensus integrity depends on validator distribution and protocol rules — a separate entry, owned by the protocol team, with different controls. Matching each control to its own entry, with its own owner, is exactly the classification habit the layered model trains.
Layered Classification Drill: Practice Exercise and Self-Check Rubric
Write or collect five short incident descriptions covering different layers, classify each, and name one matching mitigation. Score yourself against the four-criterion rubric; a misclassification is the finding to study, not merely a wrong mitigation.
Build the drill from one-sentence incidents, or use mixed items from the free practice bank. For each, record five things: the layer, the named concept, a one-line causal mechanism, the first-line mitigation, and whether that mitigation is preventive or detective. Expected observation: incidents reading 'funds moved with valid signatures to a wrong recipient,' 'balance drained through repeated external calls,' and 'a node stuck seeing stale blocks' should sort to three different layers even though all three sound like 'funds lost.' If two land at the same layer, re-read the signatures.
Score each item against the rubric below, two points per criterion, for a maximum of eight per item. Run the drill daily for a week and log every misclassification; the log becomes your personal syllabus map. Aim to average seven or higher per item before moving to timed practice — these are learning milestones for your own tracking, not predictions of any exam outcome.
- Layer identified (0-2): custody, consensus, contract, network, or governance — never just 'general blockchain.'
- Named concept cited (0-2): for example reentrancy, eclipse attack, multisig policy — no generic 'hacking' label.
- Mechanism stated (0-2): one sentence of causal path, not a restatement of the consequence.
- Mitigation matches the layer (0-2): a code fix proposed for a custody problem scores zero here.
Four-Week CBSP Sequence and Concrete Readiness Checks
Spend week one mapping the syllabus onto layers, weeks two and three building vulnerability cards and running drills, and week four on timed mixed practice. Verify readiness with the checks listed below.
The sequence below is adaptable: compress it if you already work in security, expand week three if contract mechanics are new. The design principle is that cards should carry four fields — concept, layer, signature, mitigation — rather than term and definition, and drills should mix domains so classification is exercised every session. One administrative note: exam format, enrollment, and policy details are maintained by the issuer, so confirm them on the Blockchain Council's certification page rather than relying on third-party summaries.
Readiness checks before you sit the exam: you can state the difference between selfish mining and a majority attack without notes; given a fresh incident paragraph, you place it at the correct layer in under a minute; for every named concept you can name a mitigation and explain why it belongs to that layer; your drill rubric averages seven or above across items. If any check fails, return to that layer's module material and rebuild its cards rather than adding new topics.
- Days 1-7: rebuild the six topic areas into the layer model; write one summary page per layer plus one for DApp ecosystem incidents.
- Days 8-14: create four-field cards for each named concept; a working deck is roughly 20-30 cards.
- Days 15-21: run the classification drill daily with mixed-domain incidents and log every misclassification.
- Days 22-28: work timed practice questions from the free practice bank; review every miss by layer, not by topic.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.