How Does a Blockchain Work? Blocks, Transactions and Consensus

Why you should know this

A blockchain can look like a simple list of transactions, but the important question is why different computers accept the same history and what happens when they disagree.

Academy 14 is where “I know the term” stops being enough. A useful technology explanation should let you predict what happens when one component fails, which party still has power, and which part of the user outcome sits outside the technology. That is the standard we will use here.

A blockchain is a shared state machine, not just a database

At the surface, a blockchain stores ordered records. The more useful mental model is a shared state machine: participants start from an agreed state, valid transactions change that state, and the network needs rules for deciding which changes become part of the accepted history. That is what separates “a database that several people can read” from a system where parties who do not fully trust one another can still coordinate around one history.

A block groups transactions, but a block by itself does not create trust. Nodes independently check whether transactions obey the protocol rules. Consensus then determines which valid block history the network treats as canonical. The exact mechanism differs by network, but the reader should always ask the same questions: who proposes updates, who verifies them, how conflicts are resolved, and when an update becomes difficult enough to reverse that a user can treat it as settled.

Transactions move state; signatures prove authorization

A transaction is an instruction to change the ledger state. In a payment example, it may reduce one address balance and increase another. In a smart-contract system, it may call code and change application state. Cryptographic signatures help the network verify that the party controlling the relevant key authorized the instruction.

That does not mean the network knows the real-world identity or intent of the signer. A valid signature proves control of a key, not that the transaction was wise, lawful, scam-free, or reversible. This distinction matters later when we study consumer rights and operational recovery.

Consensus solves disagreement, not every form of trust

Consensus mechanisms are designed to keep distributed participants aligned on a valid history even when messages arrive at different times or some participants behave badly. They do not automatically solve oracle truth, custody risk, software bugs, governance disputes, or the legal meaning of an asset.

A useful habit is to separate the trust removed by the protocol from the trust moved somewhere else. If a token represents pesos held by an issuer, the blockchain may make transfers transparent while the reserve still depends on the issuer and its banking arrangements. If a bridge moves value between networks, the destination token may depend on bridge verification and custody even though both chains themselves continue operating correctly.

Finality is a spectrum of confidence

People often speak about a transaction as “confirmed,” but settlement confidence can grow over time. Some networks use probabilistic finality, where reversal becomes less likely as more blocks build on top. Others introduce explicit finality rules. In either case, an application chooses how much confirmation is enough for the value and risk of the transaction.

That choice is operational, not merely technical. A low-value transfer may accept less settlement confidence than a treasury movement. The lesson is not to memorize one magic number; it is to understand that confirmation policy should match the consequence of being wrong.

Worked example — follow the mechanism, not the slogan

Imagine a fictional PHP 50,000 transfer represented on a shared ledger. The sender signs a transaction, nodes verify that the signature and balance are valid, a proposer includes it in a block, and the network eventually treats that block as part of the accepted history. The important exercise is to mark which questions the blockchain answers—authorization, ordering, ledger state—and which it does not—whether the recipient is the correct person, whether the transaction can be legally reversed, or whether the asset itself can be redeemed for pesos.

What this lesson does not prove

Understanding a mechanism does not establish that a particular product is safe, legal, available, efficient or suitable. A protocol can work exactly as designed while a custodian, bridge, issuer, oracle, wallet, bank, service provider or user process fails around it. Current implementations can also change through upgrades and governance.

That is why technical literacy should increase caution, not replace it. The better you understand the system, the more precisely you can ask where evidence is still missing.

Philippine and Asian lens

For a Philippine or Asian payment user, the blockchain rules are global but the surrounding route is local. On-ramp, off-ramp, identity checks, FX, support and legal recourse can determine whether an otherwise valid on-chain transfer solves the real problem.

Practice — no money needed

Take the worked example above or a historical system you already know. Draw a simple flow using boxes and arrows. For each box, write:

1. What state or decision changes here?
2. Who or what authorizes the change?
3. What data does this step trust?
4. What can fail even if the underlying protocol remains healthy?
5. What evidence would tell you the step actually worked?

Then write one sentence beginning: “This technology solves , but it still depends on .”

If you cannot fill the second blank, you probably have a slogan rather than a system model.

How this connects to market mastery

Market mastery is not predicting which technology will win. It is being able to separate architecture from marketing, trace dependencies, compare alternatives and keep confidence proportional to evidence. That skill becomes essential in Academy 15, where the same technologies meet consumer rights, regulation and accountability.