BLEPM cheat sheet

A blockchain is an append-only, replicated, cryptographically linked log; each block header commits to the previous block hash, so altering history requires redoing all later proof-of-work or violating the consensus threshold.

Hash function requirements: deterministic, fixed-length output, preimage-resistant, second-preimage-resistant, collision-resistant; SHA-256 outputs 256 bits and Bitcoin block headers use double SHA-256.

Merkle tree: leaves are transaction hashes, each parent hashes its two children; a block of n transactions needs only about log2(n) hashes to prove inclusion (Merkle proof).

Digital signature = sign with private key, verify with public key; ECDSA over secp256k1 (Bitcoin/Ethereum) and Ed25519 (Hyperledger Fabric) are common; a signature proves key possession, not real-world identity.

Distributed ledger taxonomy: public/permissionless (anyone can read and write), private/permissioned (membership gated), consortium (governed by a set of organizations); permissioning is orthogonal to consensus choice.

UTXO model tracks unspent outputs consumed whole with change returned; account model keeps balances and nonces. UTXO parallelizes validation, account model simplifies stateful contracts and replay protection via nonce.

CAP framing for DLT: during a network partition a ledger chooses consistency or availability; most enterprise ledgers favor consistency and finality over partition-tolerant availability.

Finality: probabilistic finality improves with each confirming block (Bitcoin ~6 blocks), absolute/deterministic finality occurs when a BFT-style protocol commits a block irrevocably.

Triple-entry accounting: each transaction is co-signed by counterparties and anchored in a shared ledger, giving a third, mutually agreed entry alongside each party's own books.

Hyperledger Fabric: permissioned, channels for data isolation, peers execute and endorse, an ordering service (Raft or BFT) orders transactions, and a separate membership service provider (MSP) issues identities.

Fabric transaction flow: client proposes to endorsing peers, each simulates against its ledger and returns a read-write set with signature, client submits to orderer, orderer batches and delivers blocks, peers validate and commit.

Fabric chaincode defines endorsement policy (e.g., AND of two orgs), private data collections keep subsets of state off-channel with hashes on-ledger, and lifecycle (v2) manages package, approve, commit.

Ethereum Enterprise (Quorum lineage): EVM contracts, private transactions via Tessera/private state, and consensus options such as IBFT/Clique; the public Ethereum mainnet moved to proof-of-stake in 2022 (the Merge).

Corda: not a global-broadcast chain; point-to-point transaction sharing, notary services for uniqueness/finality, states are immutable and consumed, contracts are JVM code verifying transactions.

Architecture layers to specify: identity and membership, network/ordering, ledger and state store (LevelDB, CouchDB for rich queries), smart contract runtime, API/gateway, and operational monitoring.

Node roles: endorsing/executing peers, committing peers, orderers, notaries, validators; separating execution from ordering (Fabric) improves scalability and confidentiality versus order-execute designs.

On-chain vs off-chain decision rule: put shared multi-party state and its invariants on-chain; put large documents, personal data, and high-churn data off-chain with on-chain hashes and pointers.

Deployment options: managed blockchain services, self-hosted Kubernetes, or hybrid; sizing must account for block size, transaction rate, state growth, and endorsement fan-out.

Proof-of-work: miners find a nonce so the block hash is below a target; security scales with hash rate, energy cost is the Sybil-resistance mechanism, and forks resolve by cumulative work (longest/heaviest chain).

Proof-of-stake: validators lock stake, are chosen to propose/attest, and are slashed for provable misbehavior; security is economic (cost to acquire a third or more of stake), not physical.

BFT consensus (PBFT, IBFT, Raft-family): tolerates f faulty nodes among n = 3f + 1 in classic BFT; Raft is crash-fault-tolerant only and assumes a known, trusted validator set.

Consensus selection rule: public and adversarial participants -> PoW or PoS; known consortium with no Byzantine assumption -> Raft/CFT; known consortium with possible malicious members -> BFT.

Smart contract determinism: every node must reach identical state; avoid wall-clock time, randomness, floating point, and external API calls at execution; use block timestamp bounds and oracles instead.

Reentrancy: an external call before state update lets the callee re-enter; mitigate with checks-effects-interactions, mutexes, and pull-payment patterns.

Integer safety: Solidity 0.8+ reverts on overflow/underflow by default; earlier code needs SafeMath. Fabric chaincode should validate inputs and avoid unbounded iteration over the world state.

Upgrade and lifecycle: Ethereum uses proxy patterns (delegatecall) or migration; Fabric uses chaincode sequence numbers and endorsement-policy approval for lifecycle commits.

Gas and resource limits: Ethereum charges gas per opcode and a block gas limit bounds work; Fabric has no gas but needs endorsement timeouts and chaincode-level rate limits to resist denial of service.

Fit test: multiple organizations, no trusted central intermediary, shared need for a consistent record, and a process cost from reconciliation or disputes. A single-organization use case rarely needs a blockchain.

Trade finance and supply chain: track provenance, certificates, and bills of lading; value comes from reducing reconciliation and fraud, and requires shared data standards plus legal recognition of electronic records.

Reference frameworks: the UN/CEFACT-style buy-ship-pay model and GS1/EPCIS event standards help align on-chain events with existing process steps.

Re-engineering rule: redesign the process before coding; if the ledger merely mirrors existing silos with duplicated approvals, savings are minimal and latency rises.

Tokenization and payments: asset tokenization needs legal enforceability of the token, custody rules, and settlement finality; wholesale CBDC pilots target interbank settlement, not retail deposits.

Patterns: shared ledger for provenance, escrow/smart-contract settlement, multi-party KYC registries, and tokenized incentives; each must name the current pain metric it improves (cycle time, dispute rate, cost per transaction).

Business case inputs: implementation cost, integration cost, governance cost, transaction fees, and avoided reconciliation labor; compare against a centralized database with an API, which often wins on cost.

Adoption depends on network effects: a ledger with one participant adds no trust value; consortia need an anchor participant and a clear incentive for smaller members to join.

Measure outcomes with baseline cycle time, error/rework rate, dispute resolution time, and audit effort before and after deployment.

Identity models: X.509 certificates in Fabric MSPs, decentralized identifiers (DID) with verifiable credentials, and public-key addresses on permissionless chains; each maps a key to an authorized participant.

Permissioning layers: network admission, channel/private-data scoping, transaction-level authorization in chaincode, and attribute-based access control (ABAC) using certificate attributes.

Privacy techniques: channels, private data collections, zero-knowledge proofs (zk-SNARK/zk-STARK), secure multi-party computation, and off-chain storage with on-chain hashes; note that hashing low-entropy personal data is still re-identifiable.

Key management: HSMs or cloud KMS for signing keys, separation of duties, rotation, and revocation via certificate revocation lists or MSP updates; a stolen admin key compromises the whole organization's endorsement.

Threats to cover: 51% attacks on small PoW chains, eclipse attacks, transaction malleability, smart-contract exploits, malicious insiders, and endpoint compromise (the ledger cannot fix a compromised client).

GDPR tension: immutability versus erasure rights; mitigations include storing personal data off-chain with deletable pointers, encryption with crypto-shredding, and data minimization on-chain.

Audit and monitoring: log all administrative actions, monitor endorsement-policy changes and chaincode upgrades, and run static analysis plus fuzzing on contracts before deployment.

Confidentiality vs auditability: private transactions hide payloads from non-participants but regulators may need a view key or a permissioned regulator node; design this access path explicitly.

Integration patterns: REST/gRPC gateways to chaincode, event listeners on commit events, message queues for asynchronous flows, and an anti-corruption layer so legacy schemas do not leak into ledger state.

Idempotency: clients must use unique transaction IDs and deduplicate retries; a submitted transaction can succeed while the response is lost, so reconciliation queries are required.

Interoperability approaches: hash time-locked contracts (HTLC) for atomic swaps, notary/relay schemes, and cross-chain messaging protocols; each adds a trust assumption that must be documented.

Atomicity across a ledger and a database is not natively possible; use saga/compensating transactions or an outbox pattern with an idempotent consumer.

Data mapping: define canonical schemas and versioning, map legacy identifiers to ledger keys, and store hashes of source documents to prove correspondence.

Event-driven design: subscribe to block/commit events, checkpoint block heights, and replay from a known height after outage to avoid missed updates.

Performance: batching, connection pooling to peers, and async submission raise throughput; endorsement fan-out and ordering latency are usual bottlenecks.

Legacy connectivity: mainframe/ERP integration often needs middleware or an API gateway; avoid direct database writes to the ledger's state store, which breaks consensus guarantees.

Consortium governance must define membership admission/removal, voting thresholds, upgrade approval, dispute resolution, cost sharing, and exit/asset-recovery terms in a signed agreement.

Legal questions: is the ledger record admissible evidence, when is settlement final, which jurisdiction governs, and how are smart contracts mapped to enforceable contracts (e.g., e-signature and electronic-records laws).

Data protection: GDPR/CCPA obligations apply to on-chain personal data; roles of controller and processor must be assigned among consortium members, and cross-border transfer rules apply.

Financial regulation: AML/KYC, sanctions screening, securities law (token classification), and payments rules apply depending on the asset and activity; permissionless does not exempt anyone.

Audit and recordkeeping: retention periods, audit trails, and the ability to produce records to regulators; consider a regulator node or read-only access rather than ad hoc exports.

Smart-contract liability: decide who is liable for bugs, whether code is the final contract, and include human override or pause mechanisms for regulated processes.

Tax and accounting: tokenized assets may be property or securities; on-chain settlement still needs booking entries in each party's ERP.

Compliance-by-design: embed KYC checks and policy enforcement in chaincode and membership services, and log policy decisions for supervisory review.

Strategy gate: confirm multi-party need, quantify baseline pain, identify an anchor participant, and define a minimum viable ecosystem before platform selection.

Platform selection criteria: privacy model, consensus and finality, smart-contract language and tooling, permissioning, performance, licensing, talent availability, and vendor roadmap.

Delivery phases: proof of concept on one process, pilot with real counterparties and real data, production hardening (HA, monitoring, DR), then network expansion.

Operations: run redundant orderers/peers across availability zones, back up ledgers and state, monitor block height, endorsement failures, and certificate expiry, and plan disaster recovery with tested restores.

Cost model: infrastructure, licenses, integration, governance overhead, and per-transaction fees; permissioned networks often cost more to operate than a centralized database, so benefits must be quantified.

Change management: retrain staff, redefine approval steps, and agree data ownership; most failures are organizational rather than technical.

Metrics: transaction throughput and latency, endorsement success rate, dispute rate, onboarding time for a new member, and cost per transaction against baseline.

Risk register: key compromise, smart-contract defects, consortium member exit, regulatory change, and vendor lock-in; each needs an owner and mitigation.