The Blockchain as a Timechain

timechain

#1

the-blockchain-as-a-timechain-01
via kiara

Bitcoin as a Blockchain

Visualizing the blockchain is straightforward.

You put some transactions in a block, then connect the blocks to make a chain.

At first glance, the blocks appear to be arbitrary groupings of transactions. The concept of a “block” in a blockchain tells you little about the actual purpose of blocks at all.

So why put transactions in blocks at all?

The most basic requirements of any ledger, blockchain or otherwise, is the ability to record inputs and outputs that occurred at some specific date and time. But when we take a closer look at the Bitcoin blockchain, we see that the transactions within a block don’t have individual timestamp.

How You Think a Transaction Should Look:

Timestamp / Input Value / Output Value

How You Think a Transaction Actually Looks:

Index / Input Value / Output Value

Instead, transactions are numbered with an index zero through ~10,000. More important than an exact time and date is transaction order. Transactions that occur within a small time window are grouped together and the timestamp is applied to the whole block instead of each transaction. But why?

It takes time for data to travel from a server in one part of the world, to a server in another part. In the Bitcoin network, these servers are called nodes. Nodes are independently run by bitcoin users all over the world. Every node validates each transaction independently, and each transaction must travel to every node in the network. This ability gives the blockchain its distributed quality.

A Bitcoin full node is a server that: propagates transactions in the network.

Every bitcoin transaction originates at one of the Bitcoin nodes in the network. If you’re using a mobile wallet you’re trusting the node they’re connecting you to. Or you can run your own, and use your full node as a wallet.

If a few people around the world make transactions at exactly the same time, nodes closer together see transactions originating from their local area before they see transactions that occurred at the opposite end of the world. This is generally true because it takes longer to travel farther distances, on intercontinental communications or via undersea cables. Transactions cannot be received by all nodes in the network at exactly the same time.

Each node eventually receives and validates a full record of each transaction, but each node does it at slightly different times. In a decentralized network we can’t reliably know the real world time each transaction occurred.

If A, B, and C on the map are nodes, and each node independently broadcasts a transaction at the same time, C and B will see the transactions from each other sooner than they’ll see the transaction from A. If transactions each had their own timestamp, B and C would order their transactions as having occurred before the transaction originating from A, because they’re closer together. You can see the problem with this.

In a decentralized network, data that is sent and received locally appears to have happened “first” . I could get into a rant about how Einsteins theory of relativity first made sense to me after I finally understood this about Bitcoin but I’ll spare you.

Instead here’s a breakdown of the apparent transaction order from the perspective of each node from the map:

Node A Node B Node C
Transaction 1 A → B B → A B → A
Transaction 2 B → A A → B A → B

We can’t know the exact order of transactions on the blockchain in real time because there is no exact order of transactions until the block of them has been confirmed by consensus (proof-of-work and the miners).

Because of network latency—transactions can never be processed by everyone in the network at exactly the same time. Decentralized ledgers require that transactions be grouped together in “blocks”. So the timestamp can be applied to transactions that occurred within the same general time frame rather than to each transaction individually.

Instead of seeing arbitrary blocks of transactions on the blockchain, now we can see how the blocks on the ledger are used to keep transaction order and time.

Bitcoin as a Timechain

The terms “blockchain” and “timechain” were never used in the Bitcoin whitepaper, although Satoshi does describe the blockchain as a timeserver that chains together timestamped transactions. But the term “timechain” is mentioned exactly once as a comment, in the original Bitcoin source code.

The idea of the timechain does not conjure up as clear a visual as a blockchain, but it does serve to highlight the more specific function of the Bitcoin system.

Why Bitcoin Needs an Internal Source of Time

  1. New bitcoins need to be issued in a reasonably consistent time schedule.

  1. Merchants need some guarantee that payments are valid within a time window.

  1. And transactions need to be processed over time.

In order to do this trustlessly, without relying on a outside source of time, Bitcoin needs an internal source of time.

Creating a Decentralized Clock

The blockchains clock keeps time with blocks generated in a control loop in proof-of-work, by dynamically adjusting the difficulty set on mining.

Hashrate Creates the Control Loop:

The network hashrate is the total CPU power of all the miners in the network. The difficulty affects how much power is needed to find a solution to the block hash. The block time is average time it takes to find each block.

  • When the hashrate increases, the difficulty increases to slow down average block time.
  • When the hashrate decreases, the difficulty decreases to speed up average block time.

All three of these variables are dynamic. The total hashrate adjusts as miners enter or fall off the network. Based on that total hashrate the difficulty is adjusted by the nodes to hit the ten minute block time target.

When a new block is found, it’s time-stamped by the miner who found it. Each node calculates a network time from the average of the previous eleven blocks, rejecting any outdated block timestamped as older than network time, or more than two hours beyond the current network time. This averaging creates a self-enforcing upper and lower bound of acceptable timestamps for the validation of new blocks.

Each node independently calculates and resets the proof-of-work difficulty every 2,016 blocks, or about every two weeks. A security cap controls how far the difficulty can move in either direction.

  • If the difficulty sinks too low, blocks are found faster and the difficulty is readjusted within two weeks.
  • If the difficulty rises too high, blocks are on average found slower and the difficulty takes slightly longer to readjust.

Its this control loop that creates a decentralized clock. Right now, most Bitcoin node clocks are fairly accurate, but keeping time via blocks doesn’t necessarily reflect real-world time—because the system doesn’t require that the time be perfectly accurate. Only that blocks are set in a canonical order for Bitcoin transactions.

Bitcoins’ proof-of-work only provides a time relative to the previous blocks in its own chain that does not correspond to any real-world chronology of when the transactions occurred. The control loop protects against hyper inflation, it ensures coins are released on a reliable schedule, and that transactions are processed in roughly ten-minute blocks. The result is that blocks generated by proof-of-work create an internal source of time, a trustless timestamp server, with the blocks serving as the “tick” of a vast, decentralized clock.

If you learned something from this post, this is the first in a week long series about Bitcoin. Subscribe to follow along.