A blockchain is a shared record of transactions that computers maintain under a common set of rules. Entries are grouped into blocks, and each new block refers back to the previous one using a cryptographic fingerprint. The result is a history whose order and contents can be checked without asking one organisation for the definitive copy.
That matters whenever several parties need to agree on who owns something, what has been paid or whether an obligation has been fulfilled. Bitcoin uses a blockchain to track spendable coins. Other networks run programs that manage loans, exchanges or digital claims. The technology is useful because it changes how participants verify a record, rather than because every record needs a token attached.
The National Institute of Standards and Technology’s 2018 overview describes blockchains as distributed ledgers that are tamper evident and tamper resistant. Those words are more precise than “impossible to change”. Cryptography makes alterations detectable; network rules and incentives determine whether an alternative history can become accepted. Current protocol documentation was checked for this guide on October 8, 2026, UTC.
Why share a ledger in the first place?
An ordinary bank ledger records customer balances, payments and adjustments. The bank controls the authoritative version, even when it keeps copies across several data centres. Customers rely on the institution, its controls and the legal system to maintain that record properly.
A public blockchain distributes the task. Independently operated computers receive proposed transactions, check them and maintain their own view of the ledger. A participant can verify the rules locally instead of accepting a central operator’s database result. There is still trust involved, but it moves toward software, cryptographic assumptions, network participation and the people controlling the surrounding services.
The difficult part is agreeing on one history. If a digital payment can be copied, a sender might try paying two people with the same funds. Both recipients could see an apparently authentic instruction. A working payment system must decide which spend counts and reject the conflicting one. That is the double-spending problem.
Simply copying a database does not solve it. The copies need rules for evaluating transactions, ordering them and recovering from disagreement. A blockchain combines those rules with cryptographic commitments that make each version of the history identifiable. Its distinctive feature is the whole arrangement, rather than a chain-shaped drawing or one particular encryption algorithm.
From a wallet instruction to a recorded transaction
Suppose Alice wants to transfer a digital asset to Bob. For a typical key-controlled wallet, the software constructs an instruction identifying what is being transferred, the recipient and the information required by that network. It then uses a private key to create a digital signature. The private key remains secret; the signature can travel with the transaction.
A signature allows other computers to check authorisation against the relevant public key and transaction data. It does not hide the payment, and it does not prove that Alice is a particular person. It shows that the required signing authority approved that instruction. A stolen signing key can therefore authorise a transaction that its rightful holder never intended.
Nodes also check whether the transaction is allowed by the ledger’s current state. Bitcoin tracks unspent transaction outputs: discrete amounts created by earlier transactions that have not yet been spent. A valid transaction consumes eligible outputs and creates new ones. Ethereum instead maintains account state, including balances and transaction sequence numbers, alongside the state of its programs.
Those sequence numbers, called nonces for ordinary accounts, help prevent the same signed instruction from being replayed as though it were a new payment. The checks depend on the network. A valid signature alone does not establish sufficient funds, an acceptable sequence or permission to perform every operation.
A proposed transaction is broadcast and may enter a node’s pool of pending transactions. A block producer selects transactions and proposes a block. Other nodes independently evaluate that block, including the effects of its transactions. Inclusion is an important milestone, but the strength of settlement depends on the chain’s consensus and finality rules.
What the links between blocks actually do
A cryptographic hash converts data into a fixed-length fingerprint. The same input produces the same result under the same algorithm. Changing the input produces a different result with overwhelming probability. A secure hash is designed to make finding a matching input or a useful collision computationally impractical.
Block headers contain commitments to transaction data and a reference to the preceding block. Bitcoin’s developer documentation explains how transaction hashes are combined into a Merkle tree, whose root is recorded in the header. The root commits to the transaction set without placing every transaction directly inside that small header.
If somebody changes an earlier transaction, the commitment changes. That changes the block’s fingerprint, leaving the next block pointing to the old version. Updating that pointer changes the next fingerprint too. The alteration propagates through the links rather than remaining an invisible edit in one row.
The worked example below uses a deliberately simplified block format and a single SHA-256 hash. Its transfer amounts are invented teaching inputs, not prices or blockchain observations. Real networks use their own encodings and hash constructions. The displayed fingerprints are shortened for readability; both independent calculations checked the full digests.
Anybody can calculate a new set of hashes for an edited teaching chain. That is why linked hashes alone are insufficient. The harder question is whether the replacement history satisfies the network’s rules and can displace the version other participants accept. Consensus supplies that missing part.
Apex had earlier explained that control of a Bitcoin private key is central to authorising spending. The ledger’s hash links protect commitments to its history; the wallet signature protects authorisation. They do different jobs, and neither should be confused with keeping all transaction details secret.
How computers agree without counting every identity
A public network cannot safely give every computer identity one equal vote. An attacker could manufacture identities cheaply and overwhelm the count. Consensus mechanisms therefore need a way to resist that manipulation, along with rules for choosing between competing valid histories.
Bitcoin uses proof of work. Miners repeatedly calculate hashes while searching for a block header that meets the current difficulty target. Nodes verify the result and the block’s transactions. When valid branches compete, the relevant measure is accumulated work, rather than merely the number of computers announcing support for one branch.
Producing that work costs hardware, electricity and operating expenditure. A competing branch must satisfy the same rules and overcome the work supporting the accepted history. More confirmations generally make a reversal harder, but confirmation is probabilistic: no particular count creates an unconditional guarantee for every payment.
Ethereum uses proof of stake. Validators put Ether at stake and participate in proposing and attesting to blocks. Fork-choice rules determine the head of the chain, while its finality mechanism gives certain checkpoints a stronger settlement status. The official consensus documentation describes this combination, rather than treating staking by itself as a complete consensus protocol.
Conflicting finalisation would require a major failure of the system’s economic security assumptions, including a substantial amount of stake violating its rules. Some violations can be punished through slashing. A network can also struggle to finalise when insufficient stake participates. Safety, continued operation and the cost of an attack are related questions, but they are not interchangeable.
A node and a block producer are different roles. A node verifies rules; a miner or validator helps propose or agree on blocks. One machine can perform more than one role, but buying a token or installing a wallet does not automatically make someone a validator. Nor does a large token price prove that independent verification is widely distributed.
What a blockchain record can establish
A block explorer makes recorded activity easier to inspect. It can show transactions, addresses, contract interactions and the status the network has assigned them. The interface is a presentation of blockchain data, not the blockchain itself. Different services may add labels, calculate figures differently or temporarily display different views during a reorganisation.
That distinction matters when interpreting a large transfer. As previously reported by Apex, a U.S. government-linked movement toward addresses labelled likely Coinbase Prime deposits did not establish that the assets had been sold. An onchain movement can be visible while the purpose, beneficial owner or next action remains uncertain.
Addresses are not automatically verified identities. Analysts combine transaction patterns with exchange disclosures, investigations and other evidence to attach names to them. Labels can be provisional or wrong. A record can establish that a particular authorised state change occurred without answering every economic question about the people behind it.
The same limit applies to information from outside the network. A program might need an exchange rate, a shipment confirmation or the outcome of an event. An oracle supplies that information. Recording an oracle’s message does not make the underlying claim true; the reliability of the supplier, its incentives and the method of resolving disputes still matter.
Smart contracts turn the ledger into a programmable system
A smart contract is a program deployed to a blockchain and executed according to that network’s rules. It can hold assets, apply conditions and update stored state when authorised transactions call it. Every validating node needs to agree on the resulting state rather than letting each computer invent its own answer.
Consider a lending program. It may require collateral, record a loan and permit liquidation when specified conditions are met. The blockchain checks the program’s execution. It does not decide that the loan is sensible, that the collateral is fairly valued or that a person can afford the consequences. Those judgments depend on design, information and the wider economy.
Programming also introduces failure points. An error can produce an unwanted but technically valid result. Some contracts include administrator permissions or upgrade mechanisms, giving particular parties continuing influence. Others rely on external price feeds. Calling a service decentralised is therefore the beginning of an investigation into control, not the end of it.
Why fees and scaling are economic questions
Block space and computation are limited resources. Fees influence which transactions obtain access and help support the network’s operation. On Ethereum, gas measures computational work; a transaction’s gas usage and the applicable price determine its execution charge. Gas is a unit of work, not a separate coin.
A more complicated instruction can require more work than a straightforward transfer. Competition for inclusion can raise prices independently of the asset’s market value. This creates an economic trade-off: a system can offer open access in principle while becoming expensive to use during heavy demand.
Layer-two systems move some activity away from the base layer while using it for defined security or settlement functions. Rollups process batches of transactions and publish the data and commitments required by their design. The base chain does not necessarily execute every individual transaction in the same way as a direct base-layer payment.
Optimistic rollups use a mechanism for challenging incorrect state claims. Zero-knowledge rollups submit validity proofs that their state transitions obey specified rules. Proof verification, the availability of the required data, operator permissions and the route for withdrawing assets all affect the protection users actually receive.
These diagrams show common mechanisms, not a ranking of particular networks. A quick confirmation displayed by an application may arrive before the stronger settlement stage. Different systems also have different upgrade controls and dependencies. A low fee does not, by itself, tell a user how much security the system inherits from its base chain.
When the technology earns its complexity
Blockchains can reduce the need for organisations to reconcile separate records. Participants may be able to inspect one shared state, transfer digital assets directly and connect financial processes through programs. That can change the economics of coordination, especially where counterparties do not want one firm controlling the authoritative ledger.
Those benefits come with costs. Replicating and verifying data takes resources. Public transparency can reveal commercially sensitive activity. Key management creates operational responsibilities, and a distributed system can be harder to change quickly than a centrally administered application. The design must solve a real coordination problem to justify those burdens.
Permissioned blockchains restrict participation through an administrator or consortium. They can serve a different objective from open public networks, such as coordinating records between known institutions. Their security depends on membership rules, governance and the permitted participants. Restricting access may improve control while concentrating authority.
A conventional database may be the better choice when one trusted operator already has a clear mandate and counterparties accept its records. The useful question is who needs to verify what, who may change the rules and what happens during a dispute. A blockchain can make a shared history independently checkable. The surrounding institutions still determine how much that history is worth.