Study for CEBA by practicing written, justified decisions rather than platform recall. For every syllabus domain, produce a short decision record that names the requirement, the chosen mechanism, the rejected alternative, and the tradeoff you accept. Re-derive these decisions from scratch until the reasoning is automatic.
Why the same ledger design fails two different enterprises
Enterprise architecture starts from requirements — who validates, who sees data, what regulators demand — not from a favored platform. The identical ledger technology can be correct for one enterprise and unsuitable for another.
Separate three deployment models before anything else: public permissionless networks where anyone can validate, permissioned consortium networks where known organizations run nodes, and private single-organization ledgers. What changes between them is the trust model — whether validators are accountable institutions — plus data visibility and the meaning of finality. A design that names the deployment model implicitly names the trust assumptions, and reviewers can then check whether those assumptions match the business requirement.
Worked scenario: a five-company food-supplier consortium wants shared provenance records, and its architects choose a public network because tutorials and tooling for it are abundant. The mistake is environmental, not technical: commercial pricing data would sit where competitors can read it, and validator accountability rests on anonymous economic incentives rather than contractual obligations. The better decision is a permissioned consortium ledger with restricted membership and channel- or partition-based data separation, accepting slower ecosystem tooling in exchange for governance that matches the consortium's legal relationships.
- Public permissionless: open validation, transparent data, probabilistic or economic finality assumptions.
- Permissioned consortium: known validators, contract-based accountability, configurable visibility.
- Private ledger: one operator controls validation; useful when external trust is unnecessary.
Choosing a consensus protocol you can defend in one paragraph
Name the fault model and the finality property first. Nakamoto-style proof of work gives probabilistic finality in open networks; BFT-style protocols give deterministic finality among known validators; Raft handles only crash faults.
The three families answer different questions. Proof of work assumes anonymous participants and buys security with computational cost, so finality is probabilistic — a block can in principle be reorganized. Practical Byzantine Fault Tolerance and its derivatives assume a bounded set of known validators and tolerate a fraction of arbitrary (Byzantine) faults, producing deterministic finality once quorum is reached. Raft-style protocols tolerate crash faults only — a node stops, not lies — which is acceptable inside one organization where misbehavior is handled by employment and audit, not cryptography.
A defensible one-paragraph decision states the validator set, the fault type you are insuring against, and the finality your business process needs. Settlement between rival firms usually justifies Byzantine fault tolerance because participants do not trust each other's operators. A workflow ledger inside a single bank can often use crash-fault-tolerant ordering, because a lying node is an insider-threat and governance problem rather than a protocol problem. When you study, rewrite any consensus question as: who runs nodes, what fault do I fear, and does the process need instant or eventual settlement certainty?
Mini-exercise: take three fictional projects — a public donation tracker, a six-bank settlement ring, and one retailer's internal audit log — and write the one-paragraph consensus choice for each. Compare your three paragraphs; the reasoning should differ in fault model and finality, not in platform preference.
| Consensus family | Fault model | Finality | Typical setting |
|---|---|---|---|
| Nakamoto-style proof of work | Byzantine, open membership | Probabilistic | Public, permissionless networks |
| BFT family (e.g., PBFT derivatives) | Byzantine, bounded known set | Deterministic at quorum | Permissioned consortium networks |
| Crash-fault-tolerant ordering (e.g., Raft) | Node crashes only, known operators | Deterministic at quorum | Single-organization or tightly governed deployments |
Reading a smart contract scenario for reentrancy and access control
Security reasoning on paper means tracing execution order: checks before effects, state updated before external calls, and every privileged function guarded. Reentrancy and missing access control are the canonical paper-exercise risks.
Reentrancy arises when a contract makes an external call — often a transfer or an attacker's fallback function — before it has finished updating its own state, letting the callee call back in and re-execute logic against stale balances. The structural fix is the checks-effects-interactions pattern: validate inputs, update internal state, and only then interact with external contracts. Modern languages and compilers add further guards such as integer overflow protection, so knowing which guarantees the runtime provides and which the design must supply is part of the answer.
Access control is the second thread to trace. For every function in a scenario, ask who may call it, how that identity is established on-chain, and what happens if the check is absent or wrong. Worked scenario: a contract lets an administrator set a price parameter, then transfers tokens, and the transfer happens before the internal ledger is updated. The plausible mistake in a written answer is to flag the price function and stop there; the better decision identifies the ordering of the transfer against the state update as the reentrancy hazard, applies checks-effects-interactions, and then confirms the administrative function is restricted — because fixing only one of the two leaves the contract exploitable.
When zero-knowledge proofs beat channels — and when they are overkill
Permissioned channels and access control solve privacy when participants are known. Zero-knowledge proofs earn their complexity when public verifiability and confidentiality must coexist — proving a statement without revealing the underlying data.
Zero-knowledge proofs let a prover convince a verifier that a claim is true — a shipment passed inspection, a balance covers a payment — without exposing the inputs. Decentralized identifiers and verifiable credentials extend this to identity: a holder presents a credential, the issuer's signature is verified, and selective disclosure reveals only the required attributes. These mechanisms differ from simple hashing, which hides content but proves only that identical data existed, not that unrevealed data satisfies a condition.
Worked scenario: a trade-finance network must prove to customs authorities that invoices are authentic without rival banks seeing each other's commercial terms. The tempting mistake is specifying a full zk-SNARK pipeline immediately, because it is the strongest-sounding tool; the better decision first checks the trust model. If all readers are known consortium members, channel-based visibility plus access control achieves the goal with far less cryptographic and key-management complexity, and zero-knowledge techniques are reserved for the edge case where an external, non-member verifier needs assurance. Conversely, if public verifiability with confidential data is a hard requirement, no amount of channel configuration substitutes for a proof — recognizing which side of that line a scenario sits on is the skill to drill.
Interoperability: bridging assets without inventing a new trust problem
Every cross-chain mechanism reintroduces some trusted component. Distinguish notary or federated bridges, light-client relayers, and hash time-locked atomic swaps, and match the trust assumption to the scenario.
A federated bridge relies on a small committee that observes one chain and attests events on another, inheriting the committee's honesty assumption. A light-client relayer verifies the counterpart chain's consensus on-chain, reducing trust in intermediaries at the cost of complexity. Hash time-locked contracts enable atomic swaps by making two transactions succeed or fail together under timeout conditions. Oracles are the related problem for data rather than assets: a feed is only as trustworthy as its operator and aggregation design.
The paper skill is stating, for a given integration scenario, which party is newly trusted and whether the business can accept it. Worked scenario: an enterprise wants its consortium ledger to reflect a public network's asset transfers, and the tempting answer is a custom bridge owned by one member. The better decision weighs a federated bridge whose committee mirrors the consortium's existing governance — reusing an accountability structure the members already trust — and documents the failure mode if the committee colludes or stalls. Enterprise integration frequently does not require a cryptographic bridge at all: signed off-chain events consumed through standard APIs and event queues solve many system-to-system cases without adding a consensus boundary.
Scalability: deciding what actually belongs on the ledger
Scaling decisions start by shrinking the problem: keep commitments, state transitions, and anything requiring multi-party consensus on-chain; keep raw documents, media, and high-volume telemetry off-chain with on-chain hashes.
Layer the options by where the work happens. Protocol-level improvements raise base throughput but are usually governed, not chosen, by the architect. Layer-2 techniques — state channels for bilateral interaction, rollup-style execution that posts compressed results — move computation off the consensus path. Sidechains trade main-network security guarantees for capacity. Application-level choices are often the largest lever: batching operations, storing document content in conventional storage with only its hash anchored on-chain, and designing data models so unrelated parties never process each other's transactions.
The recurring written mistake is scaling the wrong layer — proposing exotic execution layers while shipping megabyte payloads on-chain. The better decision sequence asks, in order: does this data need consensus at all; if yes, does it need to be on the main chain or a partition; can multiple operations be committed as one batch; and only then, which capacity mechanism fits. For a high-volume provenance use case, anchoring document hashes on a consortium ledger while bulk data lives in the enterprises' existing storage typically resolves the load without touching consensus parameters — and keeps personal or regulated content out of an immutable store, which is a privacy decision disguised as a performance one.
A decision-log exercise with a self-check rubric
Build a three-decision architecture record for one fictional enterprise scenario, then score it against a rubric. The rubric measures justification quality — requirement, mechanism, rejected alternative, accepted tradeoff — not platform vocabulary.
Exercise: write a one-page decision log for a fictional procurement consortium of eight mid-sized firms that must share purchase orders and delivery confirmations, with commercial pricing hidden from non-counterparties and an annual external audit. Produce three records: ledger placement (public, consortium, private), consensus choice, and privacy mechanism. Each record must fit in a short paragraph and follow the pattern used throughout this guide — trust model first, mechanism second, tradeoff stated last.
Expected observations and self-check rubric (score each record 0–2): the requirement names who validates and who sees data, not just a business goal; the mechanism matches the trust model rather than defaulting to the most familiar platform; a rejected alternative is named with a reason; the accepted tradeoff is explicit (for example, slower tooling for accountable validators); and no claim appears that the scenario's evidence does not support. A total of 4/6 or higher across records is a reasonable study milestone indicating the reasoning pattern is settling — it is a learning signal, not a prediction of exam performance. Adapt the sequence: week one, redo the ledger-placement decision for three different scenarios; week two, add consensus and privacy records and compare them against the table in this guide; week three, answer practice questions at the free practice link and rewrite any question you missed as a decision record; week four, re-derive all records from a blank page and check them against the rubric.
One administrative note: for credential logistics such as registration and current certification terms, refer to the issuer's certifications page linked in the sources below rather than secondhand summaries.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.