What Is Blockchain? How It Works and What It Does

A blockchain is a digital ledger—a record of transactions or other data—that is shared among computers in a network. Instead of relying on one central operator to maintain the only authoritative copy, participating computers keep copies and follow common rules for accepting updates.

The name describes how the record is organized. New entries are grouped into blocks, and each block refers cryptographically to the block before it. This creates an ordered chain of records. If someone changes an older block, its cryptographic fingerprint changes too, disrupting the links to later blocks. Network rules make an accepted history difficult to rewrite without other participants detecting or rejecting the change.

Blockchains can record more than payments. Depending on the network, they may store token transfers, ownership changes, program instructions or compact references to information kept elsewhere. A blockchain is not necessarily a single physical file or one computer; it is a system for maintaining an agreed record across multiple machines.

The word can also refer to a particular network or its data structure. Bitcoin and Ethereum, for example, are separate blockchain networks with different rules and purposes. Neither is simply a synonym for blockchain technology as a whole. The basic idea is shared record-keeping; the way a given network controls access, confirms updates and handles applications varies.

A transaction is a proposed update to a blockchain. It might ask the network to transfer a digital asset, record a vote or run an instruction in a smart contract. Before it becomes part of the accepted record, the network checks that it follows that blockchain’s rules. For a token transfer, checks may include whether the sender can authorize it and has enough balance.

Accepted transactions are collected into a block. A block commonly contains transaction data, a reference to the previous block, and other information needed by the network. Its hash is a cryptographic output calculated from data in the block. Changing that data produces a different hash, so the previous block’s reference no longer matches. This makes tampering with past records detectable.

A simplified sequence looks like this:

1. A user signs and submits a transaction.
2. Nodes check it against the network’s rules.
3. A miner or validator proposes a block, depending on the consensus design.
4. Other participants accept, reject or build on that block according to protocol rules.
5. Later blocks add to the history, usually increasing confidence that the record will remain in place.

This is a useful overview, not a universal blueprint. Networks differ in how they select block producers, how quickly transactions are treated as final, and whether they group all data directly on-chain. “Immutable” is therefore a shorthand for difficult to alter under the system’s rules, not a promise that change is physically impossible.

A node is a computer running blockchain software and participating in the network. Nodes communicate to share transactions and blocks, check that updates follow protocol rules, and maintain a copy or usable representation of the ledger. The exact tasks depend on the software: some nodes verify and relay data, while miners or validators also take part in proposing blocks.

When a transaction is broadcast, multiple nodes can independently check it. A transaction that breaks the rules—such as one with an invalid signature—should not be included in a valid block. After a block is proposed, nodes verify it too. This independent checking helps prevent one participant from unilaterally inserting an invalid update into the shared history.

Not every node has the same influence or stores every detail. A full node may verify the chain’s data from its rules, while a lighter client may rely on another node for some information. Some networks have a small set of authorized operators; others allow broad participation. The number of computers alone does not tell you how independent or secure a network is. Operator concentration, software diversity, access rules and incentives also matter.

“Decentralized” describes a spectrum, not a simple yes-or-no feature. A network can distribute data across many machines while depending on a narrow group to control upgrades or block production. To understand who can change or censor records, look at who runs the infrastructure and how decisions are made—not just the number of nodes claimed by a project.

Nodes need a way to agree on which valid transactions belong in the shared history and in what order. Consensus is the set of processes and incentives used to reach that agreement. It is especially important when participants do not all trust one another and there is no central record keeper.

Two widely used approaches are proof of work and proof of stake. In proof of work, miners compete by performing computational work, and the network follows rules for choosing among valid blocks. In proof of stake, validators commit or stake assets and are selected or rewarded under protocol rules for proposing and checking blocks. Each design has different security assumptions, operating costs and consequences for participation. Many variations exist, so a label alone does not describe a network’s full design.

Consensus does not mean every computer votes on every transaction in the same way. Rather, protocol rules let nodes determine which history they should accept, even if messages arrive at different times or some participants behave dishonestly. A block may be accepted quickly but become more secure as additional blocks build on it. Some networks provide explicit finality rules; others make reversal increasingly unlikely over time.

Consensus also has limits. It cannot make false external information true, guarantee a bug-free application, or ensure that a network is equally controlled by all users. Security depends on the specific protocol, participant incentives, software and operational practices. For a user, confirmation and finality expectations can differ by chain and by the service receiving a transaction.

Blockchains can be grouped by who is allowed to read data, submit transactions and help operate the network. These labels describe access models, not a guarantee of quality or security.

Type	Typical access	Common trade-off
Public, permissionless	Anyone can usually read the ledger and seek to transact or participate	Open access, but activity and fees may be visible and network performance can vary
Private, permissioned	An organization or approved group controls participation	Greater control over access, but less open verification and more reliance on administrators
Consortium	A defined group of organizations shares operation or governance	Shared control among members, with rules and trust still concentrated in the group

These categories can overlap. A company might publish proofs to a public chain while keeping the underlying records private. A public network may also rely on a limited set of infrastructure providers or have governance concentrated among a smaller group than its open transaction system suggests.

Privacy needs special care. A public address is not automatically a person’s name, but transactions can be visible and linked over time. Exchanges, payment providers and other services may require identity checks, and public activity can sometimes be connected to a user through outside information. Private blockchains may restrict access but do not automatically provide strong privacy either; administrators may be able to inspect records.

When evaluating a chain, ask who can read, write and validate; who can change its rules; and what information is placed on-chain. “Public” and “private” answer only part of the question.

A blockchain is not the same thing as a cryptocurrency. A cryptocurrency is an asset or payment system; a blockchain is one way of maintaining a shared record. Bitcoin’s network records transfers of bitcoin, while Ethereum records transactions involving ETH and supports applications that use smart contracts. Some permissioned blockchains may have no publicly traded token at all.

Many blockchains support smart contracts: programs stored and executed according to network rules. A contract can update records or transfer tokens when specified conditions are met. Developers use them to build decentralized applications, including decentralized exchanges and lending protocols. For example, Uniswap is a decentralized exchange protocol, and Aave is a lending protocol; their applications use blockchain infrastructure to process on-chain actions. Hyperliquid is an example of a blockchain built around on-chain trading.

Smart contracts do not understand the world on their own. If a program needs an outside fact, such as an asset price or a sports result, it depends on a separate data provider or oracle. Nor does a contract automatically make a service decentralized in every respect: front ends, governance, administrators and infrastructure can introduce points of control.

Blockchains are also distinct from their applications. A blockchain provides rules and infrastructure; an application uses that infrastructure to offer a service. A wallet helps a user manage keys and submit transactions, but it is not itself the blockchain. This distinction helps clarify what a project actually does and which parts of a service rely on the chain, a company or a third party.

Blockchains are most useful when multiple parties need to share a record but do not want one party to control the only authoritative version. Digital asset transfers are the best-known example: a network can record who sent a token, who received it and whether the transaction followed its rules.

On public blockchains that support smart contracts, users can interact with applications without asking a single company to update a private database for each action. Decentralized exchanges can process token swaps, while lending protocols can record deposits, collateral and borrowing. These systems can be composable: one application may interact with another, although this can also pass risk between them.

Other proposed or deployed uses include tracking goods, recording credentials, coordinating shared digital assets and maintaining audit trails. Whether a blockchain helps depends on the problem. If one trusted organization already manages a database effectively and participants do not need independent verification, a conventional database may be cheaper, faster and easier to correct. A blockchain does not make inaccurate data accurate; it can only preserve what the network accepts.

A practical test is to ask:

• Do several independent parties need to update or verify the same record?
• Is it important that no single operator controls the history?
• Can sensitive information be kept off-chain or adequately protected?
• Are the fees, delays and governance trade-offs acceptable?

For developers who need to query data across chains, services such as Envio provide blockchain indexing and data tools. That kind of infrastructure makes on-chain records easier for applications to use, but it does not replace the chain’s validation rules.

Blockchains can offer a shared history that participants can independently inspect and verify, depending on the network and the data it exposes. This can reduce the need for a central operator to reconcile separate records. Cryptographic signatures also let a user authorize transactions using a private key, while other participants can check the signature without needing to know the key itself.

A chain’s records can be persistent and difficult to alter once accepted. That property may help with audit trails, asset transfers and applications that need consistent rules. Public networks can also let developers build services that interact with the same underlying assets and contracts. These features can enable open access and interoperability, though actual access may still depend on wallets, interfaces, regulations and infrastructure providers.

The benefits come with trade-offs. Public visibility can conflict with confidentiality. Network fees and processing capacity can vary, and transactions may take time to confirm. A lost or stolen private key can mean losing control of assets, while a transaction sent to the wrong address may be difficult or impossible to reverse. Smart-contract bugs can cause losses even if the underlying blockchain is operating as designed.

There are also environmental and operational differences between networks. Proof-of-work systems use energy for mining; other consensus systems have different resource demands and security assumptions. It is not accurate to claim that every blockchain is equally energy-intensive or that any consensus method is cost-free. Evaluate the particular network and the specific use case, rather than treating “blockchain” as a guarantee of speed, transparency, security or fairness.

Before using a blockchain, identify the exact network and asset involved. A wallet address on one chain may not work the same way on another, and sending a token through an unsupported network can lead to lost funds. Check the network name, token contract where relevant, recipient address and transaction details before signing. A wallet signature can authorize an action, not merely confirm that you read a message.

Also understand what cannot be undone. A blockchain transaction is generally not reversed just because the sender changes their mind. Keep private keys and recovery phrases secret; legitimate support staff should not need them. Treat unexpected token approvals, links, airdrops and requests to connect a wallet as potential risks. A blockchain’s public records do not reveal whether a website or application is trustworthy.

When comparing chains or applications, consider more than transaction speed or fees. Ask who operates validators, how upgrades are approved, whether smart contracts have been independently audited, what happens if a bridge or oracle fails, and whether the project publishes clear information about risks. Audits reduce some risks but do not guarantee safety. For live costs, activity and network status, use the chain’s own current tools or the application’s official interface; figures can change quickly.

A blockchain is a method for coordinating and preserving digital records under shared rules. It can be a useful foundation where independent verification matters, but it is not automatically better than a conventional database, and it does not remove the need for trust. You still need to assess the people, software, incentives and services around the network.