The technology (that is, the architecture, mechanisms, security, and so forth) behind the blockchain can be seen both as the backbone for future accounting and as an engine for a modern message transport system. So how does a blockchain actually work during runtime?
The following diagram shows how blockchain systems must follow a specific flow of actions in order to consistently maintain a distributed ledger of facts (a key-value database with the current state of assets) and a separate history of their updates (distributed transaction log). The transactions that you submit are stored and verified without the involvement of a governing central authority using advanced mathematics and computer science, that is, cryptographic hash functions.
The blockchain not only secures these transactions but also protects their integrity (and anonymity). This demonstrated in the following diagram:
The flow that a transaction follows from submission to being verified by the majority of networks
Now let's take a closer look at the preceding diagram that describes the flow of transactions in a blockchain. When you want to exchange data with someone else on the blockchain, you do this by submitting a transaction in which you propose your changes. A Transaction usually contains the context (action) in which it should be executed and any asset that can be described in digital form, such as currency, contracts, and incident and medical records. The Data structure of proposed changes to an asset can be both structured and unstructured, but often it is represented as JSON (JavaScript Object Notation), which is a human-readable text format for data objects.
A typical blockchain provides client APIs to interact with the transaction, but generally you would use a web application that calls the API with which you would submit your transaction to one of the active nodes (peers) in the network.
Depending on the network's capabilities, the transaction is either locally validated or directly broadcast to all active nodes in the network using the peer-to-peer network (P2P). When locally validated, your transaction is only broadcast after validation, based on a set of network rules. Each node that receives your transaction will, depending on network rules, either verify it instantly or transcribe it into a secure record and place it in a queue of pending transactions. In this case, nodes, in other words, the participating computers or servers in the network, verify whether your transaction is valid based on a set of rules to which the network has agreed.
For example, your transaction can trigger participating nodes to execute business logic (such as a smart contract) and follow the consensus protocol to verify the results. Some consensus protocols require you to pay a transaction fee to get your transaction verified. The amount you pay is part of your transaction, and it determines the time it takes to get verified. Some nodes that create blocks only verify transactions that have a higher reward.
Depending on the rules defined by the network's protocol, validating nodes combine transactions into a block and digitally fingerprint the result so that they can be validated by other nodes in the network. Just like transactions, blocks are broadcast to all active nodes using the peer-to-peer network. When consensus is reached, depending on the network' rules, participating nodes either batch the transactions and store the results as a cryptographically secured, immutable data block, or they take the approved block and append it to their ledger. Consensus protocols may include a reward system for nodes that create a block or require you to pay a transaction fee to distribute the currency to the rightful recipient.
Following the consensus mechanisms and network rules, it may take several blocks until you can be certain that your transaction is verified and not part of an orphaned chain. It is possible for multiple peers to create a block at the same time or just a few seconds apart from each other. This can produce a fork in the chain. Both blocks are initially accepted by the majority of the network, creating two chains. For any block of transactions, however, there is only one way to the genesis block (that is, first created in the chain), and blocks that are part of the smaller chain are eventually rejected.
In the following diagram, you can see that the longest chain survives and that smaller chains are rejected:
The genesis block is shown in green. The main chain is shown in black and the orphaned/rejected chain appears in red.
Those transactions that are part of the rejected block(s) are added back to the pool of queued transactions and will eventually be included in another block. With blockchains that use an incentive model, the reward that someone receives for solving an orphaned block is practically lost.