BLEPM key terms

A system in which identical or reconcilable records of transactions are held and updated across multiple independent nodes, with no single node holding unilateral authority over the shared record.

A ledger structure that links batches of transactions into cryptographically chained blocks, so that altering an earlier block invalidates all later ones and is detectable by any participant.

A one-way mathematical function that maps any input to a fixed-length output, where small input changes produce unpredictable new outputs and finding two inputs with the same output is infeasible.

A binary tree of hashes in which each parent hash summarizes its children, allowing a participant to prove a single transaction is in a block by checking only a short path of hashes.

The property that recorded transactions cannot practically be altered or deleted after commitment, achieved through hash chaining, replication across nodes, and consensus rules rather than through physical write protection.

A participant's running copy of the ledger software that stores ledger state, validates transactions and blocks against agreed rules, and communicates with peers to propagate updates.

The first block in a chain, hard-coded or configured at network creation, which anchors all subsequent blocks and defines the starting state of the ledger.

The number of blocks from the genesis block to the current tip, used as a rough measure of ledger age and as a reference point when comparing competing chains.

A divergence in ledger history where two valid versions of the chain exist, arising from concurrent block production or from deliberate rule changes that split the network.

The protocol by which independent nodes agree on transaction order and ledger state while tolerating faulty or malicious participants, determining throughput, latency, and failure assumptions.

A class of consensus protocols that keeps a network consistent even when some nodes fail arbitrarily or send conflicting messages, typically tolerating fewer than one third of participants misbehaving.

A consensus approach where participants expend computational effort to find a hash below a target, making block production costly and history revision economically impractical.

A consensus approach where the right to propose and attest blocks is weighted by bonded economic stake, and validators lose stake if they violate protocol rules.

A consensus approach in which a known, permissioned set of validators signs blocks, trading open participation for high throughput and predictable block times in consortium settings.

The minimum number or weight of participants whose agreement is required to commit a transaction or elect a leader, often expressed as a fraction of voting power.

The assurance that a committed transaction will not be reversed, either probabilistic when reversal merely becomes increasingly unlikely or deterministic when protocol rules guarantee no competing block can replace it.

Code deployed to a ledger that executes deterministically when triggered by a transaction, updating ledger state according to rules that all validating nodes apply identically.

In Hyperledger Fabric, the packaged program installed on peers and instantiated on a channel that implements business logic and reads or writes world state through a defined interface.

The requirement that contract execution produce identical results on every validating node for the same inputs, so contracts must avoid randomness, wall-clock time, and external calls that vary.

A unit that meters computational work performed by a contract, priced and prepaid by the submitter to bound execution cost and prevent infinite loops from halting the network.

The current values of all ledger variables as of the latest committed block, held in a database for fast reads and derived from the accumulated history of transactions.

The key-value or document store that holds the latest world state for efficient queries, rebuildable from ledger blocks and therefore not itself the authoritative record.

The append-only record of committed transactions plus the current state derived from them; in enterprise platforms it is replicated only to peers authorized for the relevant channel.

A private sub-network in Hyperledger Fabric in which a defined subset of organizations shares its own ledger, chaincode, and membership, isolating data from other channel participants.

A Fabric feature that distributes specified transaction fields only to authorized organizations while other channel members receive a hash of that data for verification purposes.

A ledger network where participation, transaction submission, and validation rights are restricted to identified and approved members under an agreed membership policy.

The Fabric component that defines which certificate authorities and identities are trusted for an organization, translating X.509 certificates into roles the network enforces.

A trusted service that verifies an entity's identity and issues the signed digital certificate binding that identity to a public key used in authentication and signing.

A cryptographic value produced with a private key over a message digest, verifiable by anyone holding the corresponding public key, providing authenticity and tamper evidence.

A cryptographic method letting a party prove a statement is true, such as holding a valid credential or a value in range, without revealing the underlying data.

A privacy design in which a participant reveals only the transaction attributes a counterparty or regulator needs, keeping other fields confidential through encryption or proofs.

A rule in Hyperledger Fabric specifying which organizations must simulate and sign a transaction proposal before it can be ordered and committed to the ledger.

The Fabric component that receives endorsed transactions, establishes a total order, and delivers them in blocks to peers, separating consensus from execution.

The ability of separate ledger networks and legacy systems to exchange data and value through agreed standards, message formats, and bridging or gateway mechanisms.

A trusted service that brings off-ledger data, such as prices, shipment events, or payment confirmations, into a contract, introducing a dependency on that service's reliability.

An integration layer that authenticates external callers, maps their requests to ledger transactions or queries, and shields client systems from node and protocol details.

Representing a real-world asset or right as a ledger entry with defined ownership and transfer rules, enabling fractional holding and automated settlement.

A structured evaluation of whether a proposed blockchain use case needs shared multi-party state, disintermediation, or auditability enough to justify the cost of a distributed ledger.

Redesigning cross-organizational workflows and roles around shared ledger data rather than simply automating existing paper or message-based steps on the new platform.

The documented decision rights, membership rules, dispute resolution, change control, and operating obligations that let multiple organizations run a shared ledger network durably.

A group of organizations that jointly operate a permissioned ledger network, sharing costs and governance while retaining independent business interests and competing in some areas.

The practice of tracing each ledger data flow and control to applicable obligations, such as data protection, record retention, financial reporting, and audit rights, before deployment.

A data protection obligation allowing individuals to demand deletion of personal data, which conflicts with immutable ledgers and is usually addressed by keeping personal data off-chain.

Keeping large or sensitive payloads outside the ledger and recording only a hash or reference on-chain, preserving verifiability while supporting deletion and confidentiality requirements.

A bounded build that tests whether a chosen platform and contract logic can satisfy defined technical and business criteria before committing to production investment.

A limited production deployment with real users and data in a controlled scope, used to validate operations, governance, and benefits before scaling network-wide.

The lifecycle practices for generating, storing, rotating, backing up, and revoking private keys and certificates, including hardware security modules and separation of duties.

The onboarding, role assignment, credential renewal, suspension, and offboarding of participant identities, kept synchronized with organizational joiner-mover-leaver processes.