Getting into Blockchain: How does it really work?

Imagine that you want to retain and track changes to a file, for example, a transaction log. Also, imagine that you want to verify an uninterrupted history of all changes made to the file. How do you do this?

A well-understood solution for verifying a file uses cryptographic hash functions.

The ideal cryptographic hash function has five main properties:

• It is deterministic, so the same message always results in the same hash.
• It is fast to compute the hash value for any given message.
• It is not feasible to generate a message from its hash value except by trying all possible messages.
• A small change in a message should change the hash value so widely that the new hash value appears to be uncorrelated with the previous hash value.
• It is not feasible to find two different messages with the same hash value.

Note that there are different hash algorithms that point to similar results as described above. Also note that as you type in the text box, the hash is updated and even a tiny change in the input creates a completely different hash. Finally, note that each algorithm produces hashes of the same size consistently, regardless of the size of the input.

A hash can be used to prove that an entry matches the original exactly, but the original cannot be reconstructed from a hash.

This simple process is sometimes used to confirm the integrity of a large file, such as a software update. An authoritative source, such as a publisher’s website, will present a hash of the legitimate file. With that hash, users can confirm that a received file exactly matches the original content. They simply process the file they have themselves and compare the result with the expected result.

How can you extend this idea to confirm an unbroken transaction history?

You can start with the first version of a file and record a hash of the file contents. This can be as simple as an empty log with no transactions because nothing has happened yet. Also, you can assume that you will have a rule: you can only add new entries at the end of the file. That is, the transaction history will be an append-only structure. Accountants have known the advantages of aggregate-only ledgers for centuries.

The following examples are written in pseudocode:

versión1Hash = hash(versión1)

In this example, version1 is the empty initialized record.

How can you add new transactions and show an uninterrupted history of changes?

You can create a rule that states that, in addition to the new content, the previous hash will also be an entry for the next hash.

version2Hash = hash(version2Changes + version1Hash)

In this way, you can examine the candidate changes and confirm that the previous file is correct and that subsequent changes are accurately revealed. This process is repeated for all subsequent versions.

version3hash = hash(version3Changes + version2Hash)

In case it is not clear, version3Hash depends on version2Hash and version1Hash. Therefore, if two parties separately compute identical version2Hashes, they will know that they share identical transaction records from the beginning.

If two nodes agree on version2Hash and support the same set of transactions proposed in version3, they will definitely compute the same version3Hash.

Any version of the file content can be shown as part of an unbroken chain of changes, from the beginning of the file. This is pure mathematics. Any deviation from the system, such as a hash that is not calculated as expected, demonstrates a break in the history and is therefore invalid.

Since knowledge of the current hash of the last valid version is an input to the hash function of the next version, it is not possible to generate a new valid version without knowing the valid version that precedes it. This process forces changes to be added to a previous valid version.

Blockchain works in a similar way. Transaction blocks are aggregated using previous block hashes as inputs into subsequent block hashes. Any participant can quickly verify an unbroken chain of blocks (in the correct order).

Transaction ordering is surprisingly challenging in a blockchain system due to design goals and constraints.

• As a distributed network, everyone has some authority. For example, all nodes can generate transactions and then advertise that information to other nodes.
• In a truly distributed network, no one’s clock is considered more authoritative than anyone else’s clock. Therefore, the network needs a transaction ordering solution that does not involve timestamps or network time.
• Anyone can listen to transaction proposals and organize a valid block containing an opinion on the correct order of events.
• Due to network physics and latency, everyone in the network will know the transaction proposals in a slightly different order.

How do you determine the correct order of transactions?

Even if you assume that all network members have good intentions and participate honestly, they will surely come to somewhat different opinions about the correct order of transactions and there is no obvious way to resolve the issue.

The order of transactions must be resolved because processing transactions out of order produces non-trivial differences in results. Without agreement on the transaction order, there can be no agreement on the results.

Bitcoin uses a process called Proof-of-Work that can be thought of as a lottery.

The lucky winner wins the privilege of having authority for a block of transactions. The winning lottery ticket, called a nonce, is used as another input to the hash function. This is easily verified by other participants.

The lottery winner’s opinion of the order of transactions within the block becomes the de facto official result of the network.

A valid block is a well-ordered set of transactions, contains the hash of the previous block and contains a “winning lottery ticket” (nonce). Other participants recognize this unlikely combination (unlikely due to the winning lottery ticket) and accept the block as a de facto correct opinion on the order of transactions. This process removes the ambiguity of the order of transactions, even though well-meaning nodes independently arrive at slightly different opinions on the matter.

Cryptographic hash functions are critical because they allow all participants to ensure that they have an undistorted history of everything. Since all nodes can independently verify the chain, they can proceed on the assumption that all other nodes will eventually come to an agreement on the history of everything. This is known as eventual consensus.

A blockchain starts with a known state. A blockchain proceeds by building a verifiable and widely accepted history of everything that has happened. Nodes independently construct a current state of the universe by reviewing the ordered history of every change (transactions) that has ever occurred. The history of everything that has ever happened moves forward in time as new blocks of transactions are announced by “lottery winners” and accepted as valid by consensus of the network participants.