A blockchain records proposed updates in blocks, while network participants check those updates against the system’s rules and use consensus to agree on an accepted history. Put simply, it is a shared ledger maintained through a process of validation and agreement—not a guarantee that all blockchains work alike or that a recorded payment can be reversed.

What a blockchain records

A blockchain is a database shared across networked computers. Blocks cryptographically reference earlier blocks, and nodes use consensus to agree on the network’s state. That makes blockchain one type of distributed ledger, not a synonym for every database shared among multiple parties. Depending on the system, entries may represent transactions or other information; the term alone does not mean that every entry is a payment. source source

A ledger is a record of entries. “Distributed” describes a system in which the record is maintained across a network rather than treated as one central repository. But that high-level description does not tell a reader who may participate, which information is visible, or exactly how agreement is reached. Those characteristics depend on the particular system.

It is also useful to separate a blockchain’s recordkeeping function from applications built around it. The ledger records updates according to network rules. A wallet, exchange, payment service, or other application may have its own role in preparing or presenting activity, but those services are not the blockchain itself. The existence of a shared ledger does not establish how a particular service handles a user’s request.

From a proposed transaction to a block

A transaction is a proposed update to a ledger. It may represent a transfer, but calling something a transaction does not mean the network has accepted it or added it to the shared history. The proposal still has to be processed under the rules of the relevant blockchain.

Transactions that meet a system’s criteria can be grouped into a block. A block is a unit of records that becomes part of the blockchain’s history when accepted under that network’s rules. The exact transaction fields, eligibility criteria, and processing steps are chain-specific. A simple explanation can describe the general sequence, but it should not imply that every network uses one transaction format or identical block contents.

The distinction between “proposed” and “recorded” matters. A user interface or service may show that activity has been submitted, but that alone is not the same statement as saying the network has accepted it into a block. The record-and-verification model concerns what happens as the network checks a proposed update and determines whether it belongs in the shared history.

A useful mental sequence is: a transaction is proposed; the network’s participants or software check it under applicable rules; eligible activity is grouped into a block; and the network’s agreement process determines whether that block becomes part of the accepted record. This is a conceptual outline, not a universal checklist. A blockchain’s specific rules determine how each stage works.

How the blockchain checks and adds records

Before a proposed update becomes part of a blockchain’s accepted history, it must be handled according to the network’s rules. Participants do not simply accept every submitted update because it has been proposed. The checks and the roles of participants vary among systems.

For a specific illustration, an Ethereum node receiving a proposed block checks the block and re-executes its transactions to verify the resulting state change before accepting it. This example describes Ethereum’s block-processing behavior; it should not be generalized into a claim that every blockchain uses the same validation procedure. source

Checking a proposed update and agreeing on the accepted history are related but distinct ideas. Validation asks whether the update satisfies the system’s rules. Consensus is the process by which the network agrees on the state or history to accept. The general blockchain model says that nodes use consensus to agree on network state, but it does not prescribe one universal way to reach that agreement. source

Once accepted, a block references an earlier block cryptographically. These references create an ordered chain of blocks. If information in an earlier block were changed, the relationship between it and later blocks would no longer match as expected under the system’s rules. This is why linked records can make changes detectable. It is more precise to say that the links help make alteration detectable than to say that alteration is impossible in every circumstance. The practical security properties depend on the system and its rules.

Bitcoin provides one example of a chain-specific block-production mechanism. In its original proof-of-work design, work is produced by varying a nonce in a block until the resulting hash meets the network’s target condition. This describes Bitcoin’s mechanism, not a generic rule for how all blockchains produce or accept blocks. source

What the shared ledger does—and does not—mean

Calling a ledger “shared” does not settle who can read it or join its network. Blockchain designs differ, and the broad definition does not establish that a given ledger is public, permissionless, or equally accessible to all participants. Nor does the word “blockchain” alone reveal how a particular network assigns responsibilities or reaches agreement.

A recorded address or transaction also does not, by itself, establish the real-world identity of the person associated with it. The ledger entry and a person’s identity are different questions. This explanation does not determine what information a particular blockchain exposes or how someone might connect an address to an individual.

Likewise, a record becoming part of a shared history is not the same as a guarantee that a payment can or cannot be reversed. Recordkeeping, reversal rules, and any protections offered by a surrounding service are separate matters. The general blockchain model does not establish how a specific payment product handles errors or disputes.

The same care applies to security. Linked blocks and network validation describe parts of a record-and-agreement process; they do not prove that every blockchain is equally secure or that every implementation will work as intended. This article explains the basic structure, not the security properties of a particular network.

A simple analogy, with its limits

Imagine a shared record book. One person proposes an entry; participants check it against agreed rules; and an accepted group of entries is written onto a new page that refers back to earlier pages. In this analogy, the proposed entry stands for a transaction, the page stands for a block, and the participants’ agreement represents consensus.

The comparison helps make the sequence memorable: propose, check, agree, and add to the record. It also shows why blockchain is not just a static list of entries. The system has rules and a process for determining which updates become part of its history.

But a record book is only an analogy. It does not capture the cryptographic details used to link blocks, the specific procedures used to check updates, or the different ways blockchain systems organize participation and agreement. It also should not suggest that every participant has the same role. The actual network rules—not the analogy—determine what counts as a valid update and how the accepted history is formed.

Where blockchain payment use fits

A blockchain used for payments can record transfers of digital assets under that network’s rules. The ledger entry is the recordkeeping part of the activity. It does not, by itself, explain how a wallet prepares a request, how an exchange or payment service handles it, or whether any separate process exists outside the blockchain.

This distinction prevents a common misunderstanding: a blockchain is not itself a complete payment product. The network maintains its record according to its own rules; applications and services may perform other tasks around a transfer. Their responsibilities and procedures cannot be inferred solely from the fact that a blockchain records an update.

In short, a transaction begins as a proposed update, network rules govern how it is checked, consensus helps determine which updates form accepted history, and blocks link that history together. This simple model explains how blockchain records are created and verified while leaving chain-specific procedures, identity questions, reversibility, and payment-service handling appropriately separate.

Sources and references