Blockchain across Oracle
上QQ阅读APP看书,第一时间看更新

Distributed and decentralized

In the previous chapter, you learned that one of the key properties of the blockchain is that entities (or nodes) that want to transact with each other are part of the same peer-to-peer network. Examples of such networks have existed for years, such as BitTorrent and even the older Napster. In the same way that transactions are broadcasted to each node in the network, blocks are also distributed and stored across the network. This eliminates the risk of data being held by a central authority since there is no centralized point that hackers can exploit.

In this decentralized network of computer nodes, every node has a copy of the blockchain. Because there is no central owner (or copy) of the data, the quality of the data is maintained by replication of the database among users. No central owner means that the "trust level" is the same for everybody—there are no special privileges. Since every node has its own copy, when one of the nodes is compromised, that can easily be detected.

This distributed copy of the ledger eliminates the risk of the "double spending" problem, where someone can spend or transact the same asset twice in consecutive transactions. The ledger maintains a chronologically-ordered, time-stamped list of transactions and when a blockchain peer proofs transactions, it can recognize that the ownership of an asset is incorrect and reject the wrongful transaction. In the following example, you can see three peers (A, B, and C) that currently are in sync:

All peers have the same version of the ledger and are in sync with each other

In case the last block of Peer B is compromised, that block will need a different nonce to solve its mathematical puzzle. The compromised block can be revalidated to solve the correct nonce. You can see that this has been done in the following diagram:

A compromised block is deliberately revalidated by peer B to fix its chain

After the peer has revalidated this last block containing the compromised transaction in the block data, it can create new blocks based on the previous valid block hash. Now the power of the decentralized network comes into play. Other peers validate the blocks that are added to the chain and conclude that the new blocks created by Peer B have a different hash and nonce than the majority of the peers, and the result is that blocks from Peer B are rejected, as demonstrated in the following screenshot:

Blocks created on the chain from Peer B are rejected since it's no longer the longest chain