Hyperledger is an umbrella of frameworks, and Fabric, Sawtooth, and Besu each give different meanings to words like transaction, state, and smart contract; that overlap is the hard part of this material. Anchor every term to its owning framework, then trace a concrete deployment, state update, or identity decision through that framework's own lifecycle before comparing it with the nearest analogue in the others. Work the paper scenarios below, score yourself with the self-check rubric, and rehearse the preparation sequence instead of rereading definitions.
Why framework mixing breaks Fabric answers
Fabric answers go wrong when Sawtooth or Besu vocabulary is imported into them. The fix is to anchor every term to its owning framework before you reason about the question.
Fabric is a permissioned 'execute-order-validate' system: endorsed peers simulate a transaction proposal, the ordering service establishes a total order, and validation applies endorsement policy checks plus multi-version concurrency control before a block commits. Ethereum-style chains such as Besu use an execute-and-commit model where validating nodes process transactions against a single shared state. If you describe a Fabric transaction as being 'mined' or 'validated by every node', the answer is describing Besu, not Fabric.
A practical revision technique is to prefix every flashcard term with its framework: Fabric-transaction, Sawtooth-transaction-family, Besu-block. Then rehearse a one-sentence trace for each: who proposes, who orders, who validates, and what state changes. A question about 'how a transaction becomes ledger data' is only answerable after you decide which ledger the material is describing, and that decision should take one glance, not one minute.
- Fabric: proposal, endorsement, ordering, validation, commit
- Sawtooth: transaction families, batches, validator-side consensus
- Besu: Ethereum-compatible execution against a shared world-state
Fabric network topology: trace the request path
Topology questions turn on organizations, peers, ordering nodes, certificate authorities, and channels. Rather than memorizing component lists, trace a single transaction through each component in order and answer from the trace.
A Fabric network is a set of organizations, each with its own certificate authority, running peers that host channels. Each channel has its own ledger, its own ordering configuration, and its own endorsement policy. The ordering service is logically separate from the peers: it receives endorsed transactions, sequences them into blocks, and distributes them to the peers on a channel. An application connects to a peer for proposal endorsement and to the ordering service for submission.
Practice by drawing a two-organization supply chain: each org has one peer and one CA, a shared ordering service, and one channel for shared data. Label which component sees a given transaction first, which one applies the endorsement policy, and which one holds the committed copy of the state. If you can fill in every arrow in that drawing without hesitation, topology material becomes structured traces rather than memory tests.
- Organization: identity and membership boundary
- Peer: hosts ledgers, endorses proposals, commits blocks
- Ordering service: sequences transactions into blocks per channel
- Channel: scoped ledger, configuration, and membership
Chaincode lifecycle gating: install is not approval
Fabric chaincode becomes invocable only after package, install, approve, and commit complete. Learn what each step changes, who can perform it, and what stays blocked when a step is missing.
In current Fabric, the chaincode lifecycle is governed by a chaincode definition rather than by installation alone. An organization packages the chaincode, installs the package on its own peers using its own admin identity, approves the definition with a name, version, and sequence number, and a commit step makes the definition effective on the channel once enough organizations have approved. Worked scenario: two organizations on one channel. The Org A developer packages the chaincode and installs it on Org A's peers, then approves the definition. Org B's admin installs the package on Org B's peers but never approves the definition. The commit transaction then fails, because Fabric's default lifecycle endorsement policy requires approval from a majority of channel organizations and only one of two has approved. The plausible mistake is treating installation as the gate and assuming Org A's developer can finish the deployment alone; the better decision is to query checkcommitreadiness before committing and confirm each organization's approval against the sequence number. It matters because a package on a peer and an organizational approval of the definition are different gates, and the second one is channel-wide.
Rehearse the four steps as a table in your notes: what the step touches (a single peer, one organization, or the channel), what state it changes, and what breaks if it is skipped. Then walk the paper scenario in reverse: Org B has installed but not approved. State exactly where the process stops and which check would have caught it. Converting lifecycle vocabulary into this kind of decision is the transferable skill behind lifecycle material.
- Package: bind chaincode source into a package
- Install: place the package on a peer, using that organization's identity
- Approve: the organization signs the definition (name, version, sequence)
- Commit: makes the definition effective once required organization approvals are met
World state versus blockchain: where a write actually lives
Fabric keeps a keyed current-state database per peer plus an immutable hash-chained blockchain. Decide which layer a question targets before answering, because chaincode writes are provisional until commit.
Fabric's ledger has two parts: the blockchain, a hash-chained file of blocks containing transactions, and the world state, a current-value database (typically LevelDB or CouchDB) holding the latest committed value per key. Chaincode reads and writes world state during a proposal; only committed blocks update the blockchain. Changes made during endorsement are provisional until the transaction passes validation and commits. Worked scenario: a transfer chaincode reads an account's balance and writes a deduction, but a second transaction on the same account commits between endorsement and validation. The first transaction is marked invalid by multi-version concurrency control even though the chaincode executed without error. The plausible mistake is treating the absence of a chaincode error as proof of a valid transaction; the better decision is to check the read-set for a stale key and retry. It matters because concurrency, not contract logic, decided the outcome.
Turn this into a tracing exercise: pick one proposal and follow it through provisional write, ordering, validation, and commit, noting at which step each layer changes. Use a simple self-check rubric, scored one to five and used only as a learning milestone: five means you can name the layer each step touches and explain why an invalid read-set fails validation without notes; three or below means the provisional-versus-committed distinction is not yet solid and needs another pass.
- Blockchain layer: hash-chained blocks, immutable history
- World state: current keyed values, updated per commit
- Provisional writes: exist during endorsement only
- MVCC: validation-time check against recorded read versions
Identity and access control: certificates, MSPs, and channels
Fabric identity is X.509 certificates issued by certificate authorities and interpreted by an organization's Membership Service Provider. Access questions resolve through MSP, channel membership, and endorsement or chaincode policy.
Each organization's Membership Service Provider (MSP) defines which certificates belong to which organization and role. There is no global 'one account signs everything' model as in public chains: a client identity signs a proposal, endorsing peers sign the result, and policies decide whether the combined signatures satisfy the requirement. A useful paper scenario: an organization is enrolled in channel one but not channel two, and the same client identity succeeds on the first and is rejected on the second. The plausible mistake is hunting for a code bug; the better decision is to run the four identity checks in order. It matters because the failure is a membership decision, not an application fault.
Make the four checks a fixed routine: the CA issued the certificate, the peer's local MSP recognizes the organization, the channel membership includes the org, and the endorsement or chaincode policy authorizes the action. Practice explaining the channel-one-versus-channel-two rejection aloud using exactly those four checks. When you can attribute any access failure to one specific check in the sequence, identity material stops feeling like trivia and starts resolving like the scenarios it is.
- CA: issues X.509 certificates
- MSP: maps certificates to organizations and roles
- Channel membership: scopes who can transact
- Endorsement policy: which organizations must sign
SDK integration: map every call to a lifecycle step
A Fabric client loads a wallet identity, connects through a gateway, submits a proposal for endorsement, sends the assembled transaction to ordering, and listens for commit. Map every SDK call to one of those steps.
The SDK abstracts the flow, but a productive exercise is to predict where each failure surfaces before you run anything. Write the sequence as five numbered steps and assign each SDK call to one step. Then classify failures by step: a proposal rejection points to endorsement; a submission failure points to ordering or connectivity; a timeout with no error points to commit listening. Turning the SDK flow into a step-by-step map makes failure diagnosis a matching exercise instead of guesswork.
Compare this with a Besu-style flow: the client signs an Ethereum-style transaction, sends it to a node, and waits for a receipt; there is no endorsement-collection step at all. Write the two sequences side by side in your notes, with Fabric's five steps next to the send-and-wait flow, and mark the steps that have no counterpart. Seeing the structural difference on one page is what prevents the two integration models from collapsing into each other during revision.
- Wallet: holds the client identity and key
- Gateway: connection target for proposals
- Submit: proposal, endorsement collection, ordering, listen for commit
- Besu analogue: sign and send, then wait for a receipt
Sawtooth, Besu, and choosing the right performance lever
Sawtooth carries contract logic in transaction families with validator-level consensus, while Besu is Ethereum-compatible. Performance reasoning should start by identifying which layer creates the bottleneck before choosing a lever.
In Sawtooth, a transaction family bundles transaction types with their handling logic, so the 'smart contract' concept lives in the family rather than in a deployed chaincode package, and consensus is pluggable at the validator level. Besu is an Ethereum client suited to permissioned deployments, using Ethereum-style accounts and contracts. The table below is worth reproducing from memory during revision; if any cell is blank, that framework needs one more focused pass.
Worked performance scenario: a Fabric channel has four endorsing organizations, an endorsement policy requiring all four, and slow chaincode. Each lever touches a different layer, so match the lever to the bottleneck rather than applying all of them: narrowing the endorsement policy reduces coordination among endorsers, block-cutting settings shape latency in the ordering layer, and optimizing chaincode affects execution on peers. Note that these are conditional, simplified relationships; in a real network the actual bottleneck must be measured. On paper, the skill is justifying each change against the layer it touches.
- Sawtooth: transaction families define the contract model
- Sawtooth consensus: pluggable, at the validator level
- Besu: Ethereum-compatible permissioned client
- Fabric performance levers: endorsement breadth, block cutting, chaincode cost
| Concept | Fabric | Sawtooth | Besu |
|---|---|---|---|
| Smart contract model | Chaincode packages governed by lifecycle definitions | Transaction families bundle types with handling logic | EVM-compatible contracts, Ethereum style |
| Ledger state | Per-peer world state database plus hash-chained blocks | State derived from batches processed by validators | Shared world-state updated per block |
| Consensus placement | Separate ordering service between endorsement and commit | Pluggable consensus at the validator level | Consensus among permissioned validators |
| Identity model | X.509 certificates mapped by organization MSPs | Key pairs with batch signing by clients | Ethereum-style accounts and keys |
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.