VI. Adding to Ownership Records

A decision toward one direction moves away from another.

Blockchain Algorithm

Gossip-style messaging results in asymmetrical information. It takes time for transaction information to reach every node in the network. Disputes over the current state of ownership occur because each node maintains its independent copy of the transaction history. To clarify ownership, and reach consensus, blockchain networks establish an authoritative history.

The authoritative history is the timeline of blocks considered to be true by the majority of nodes. Authoritative history is aggregated into the current state of ownership in order to verify new transfers. To replace central authority the integrity of a blockchain’s authoritative history must be guaranteed.

The blockchain algorithm defines a process for adding new transactions to the authoritative history. The threats to integrity that a decentralized network are accounted for. Blockchain systems coordinate node behavior to ensure only valid transactions are executed.

Decentralized systems are contradictory. They derive resilience from a network of diverse nodes that cannot be trusted. Malicious nodes threaten the authoritative history’s integrity. 
 
 Nodes could—

  • Submit fraudulent transactions
  • Accept invalid transaction data or blocks
  • Attempt to crash other nodes with excessive amounts of transaction data
  • Refuse to process transaction data
  • Refuse to forward information

To address these threats, blockchain systems incentivize proper behavior. Nodes on a blockchain continuously take part in a two-step rewarded competition. This competition results in the entire network scrutinizing every transaction request before it is added to the authoritative history and executed.

Speed Competition

A Transfer Request is formed when a wallet owner groups formal, semantic, and authorization data into a message and pings it out the network. Peer nodes witness the transaction request as it is forward around the network. First, peer nodes verify that the request contains valid formal, semantic, and authorization data.

  • Formal Correctness:
    The request contains all of the required information in correct format.
  • Semantic Correctness:
    The request follows contextual rules specific to this blockchain system. If the blockchain system was built to comply with specific an industry regulations, does this request comply with those regulations?
  • Authorization:
    The request contains proof that the account owner consents to this transaction.

Requests that are found to be valid are placed into the witnessing node’s request queue.

Once a node has queued enough requests it groups them into a block. Blocks have a size limit established by the specific blockchain system’s protocol. Nodes prioritize which transaction requests to include according to their contained transaction fees.

Nodes are incentivized to submit blocks. If a node’s submitted block is added to the authoritative history, this node receives the block’s included transaction fees. Nodes race to compile blocks of transaction requests and submit them to the network for consideration as soon as possible. This is the “speed competition.” In order to submit a block to the network nodes must find the correct solution to their block’s “Hash Puzzle.”

Hash Puzzles

Hash Puzzles use the unique properties of Hash Values to create computational puzzles. These puzzles limit the amount of blocks a node can submit to the authoritative history at one time. These puzzles also ensure that nodes properly verify the transaction information contained in the submitted blocks.

The pseudorandom quality of Hash Values ensures that the solution to a Hash Puzzle cannot be predetermined. Hash Puzzles require submitting nodes to find a random sequence of numbers, called a Nonce, that results in a specific Hash Value when hashed with the block’s transaction data.

To find the correct answer nodes must guess. They are forced to increment the nonce, hash it with the block data, and check if it meets the network’s specifications. This is repeated until the correct nonce is found. The correct nonce corresponds to a difficulty level set dynamically by the blockchain protocol.

For example, the network could say that submitting this specific block requires finding the nonce that results in a Hash Value with three leading zeros. Due to the randomness of Hash Values it could take an infinite amount of time to find the correct nonce if the difficulty level is high enough. The more computer power dedicated to generating potential Nonces the better.

When a node finds the correct nonce it appends the nonce to their block’s header. It then immediately submits the block and nonce for verification by peer nodes. Once a node has submitted a block the speed competition ends. The submitting node then becomes the only candidate for part two of the competition: the quality competition.

Quality Competition

Peer-to-peer messaging spreads the speed competition’s winning block through the network rapidly. Every node that receives this block knows that it has lost the speed competition, and immediately abandons the block it had hoped to submit. These receiving nodes begin to verify the received block and nonce pair.

Nodes verify submitted blocks by rehashing the block and the submitted nonce. The output hash value is quickly compared to system specifications. Blocks with a correct nonce are added to the receiving node’s copy of the authoritative history. Once a majority of network nodes add the block to their independent copies of the authoritative history, the submitted block is effectively added to the authoritative history as the head of the chain.

Then, a new speed competition begins with freshly arriving transaction data.

This two-part competition creates a coordinated rhythm on the blockchain network. All blockchain nodes are in one of two states: working to submit a new block, or evaluating a submitted block for correctness. This ensures the entire decentralized network validates transactions without a central authority.

Blocks that are found to be false are invalidated by peers. When a block is invalidated any rewards given to the submitting node are reclaimed. Transaction requests inside invalidated blocks are returned to queue, grouped into new blocks, and reevaluated in subsequent competitions.

Blockchain systems use net-loss as a punishment. Nodes that are unable to win a speed competition by guessing a correct nonce are uncompensated. The electricity cost incurred by this guesswork creates a net-loss that serves as punishment.

Consensus

When nodes validate transactions according to out-of-date — or asymmetrical — information a dispute over the authoritative history occurs. Blockchain networks require an objective way to reach consensus on which authoritative history is accurate. The computational expense of Hash Puzzles can be used to reach consensus.

We can follow the “Heaviest Chain Criterion” and select the authoritative history with the most computational effort in its timeline. We find the total computational effort by adding up the difficulty levels of every hash puzzle in each version of authoritative history. Because hash puzzle difficulty is calculated dynamically, blocks will differ in the computational effort it took for nodes to add them to the authoritative history. We then tally how many nodes “vote” for each version of the authoritative history.

The majority vote for an authoritative history results in an authoritative path. By selecting an authoritative path consequences occur. As in real life, a decision leads you to a specific direction and away from another. Deciding on an authoritative path has similar consequences for the blockchain. More so, because the Blockchain is immutable there is no going back. We cannot undo a decision on the a blockchain’s cryptographic, interdependent, and globally distributed authoritative history.

Blocks that are excluded from the authoritative path become “orphan blocks.” Orphan blocks cannot be used to clarify ownership any longer and do not contribute to the authoritative history. Rewards given to nodes that submitted orphan blocks are reclaimed.

The blockchain’s chronological order results in what is called “eventual consistency.” The deeper down the authoritative history a block is located, the more likely it is to remain in the authoritative path. Blocks closer to the head of the chain are most affected by the verification of newly arriving blocks.

Consensus Threats

Blockchains are targeted for manipulation because they manage valuable assets. Attempts to manipulate blockchain systems focus on establishing a new authoritative path. The goal of attackers is to establish an alternative state of ownership that is favorable to the attacker.

Threats to consensus attempt to establish centrality in decentralized networks to force a majority vote for a new authoritative path.

  • Economic Threats:
    Aim to change asset ownership allocation by changing the collective history of transaction data.
  • Decision Making Threats:
    Aim to enforce a desired result by gathering the majority of voting power.
  • Technical Threats:
    Aim to undermine system integrity.

The path with most computational effort is seen as the authoritative history, so 51% of a blockchain network’s total computation power is required to establish a new authoritative path. The attacker must use the majority of computing power to recalculate each Hash Reference and Hash Puzzle from the editing point to the current head of the chain.

The integrity of a blockchain system’s authoritative history relies on the assumption that no entity can acquire a majority of computational power. This means that the more peers, the more nodes, the more people connected to — and invested in — a Blockchain network, the more integrity it has.

Next…
VII. Cryptocurrency as Incentive