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:
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:
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: