Bitcoin was built to enable decentralized agreement, or consensus, on data. Bitcoin’s Proof-of-Work, a mining consensus algorithm, was built to achieve this goal and maintaining this decentralization is fundamental to the systems structure and security model. However, this is a very different structure than most of us are used to working with. Interacting with a blockchain is not like querying a database; it is much more complex.
Let’s start by taking a look at the beginning of digital, decentralized networks in an effort to gain some insight into this structure.
These networks began with the internet. While the internet itself soon developed a client-server model, many networks online developed a truly decentralized, peer-to-peer structure. Some examples being:
The decentralized network that is most commonly known is likely BitTorrent which is used for peer-to-peer (P2P) file sharing. It might be helpful to keep this architecture in your head when visualizing the bitcoin network.
Bitcoin is a decentralized, P2P network in a very similar fashion to a file sharing network. (Learn about decentralized file storage here.)
When you download the Bitcoin client software, it generally comes with the IP address of a few well-known nodes. When the software runs, it queries those nodes to find it’s connections continues like a ripple effect. Bitcoin main net connections happen on port 8333, and the program looks for connections there.
The software is constantly connecting with peers to receive network data and transaction data. A full node will keep a full copy of the blockchain, check the validity of the data it is receiving, and then pass it along to peers. In this way nodes on the network play an important role in maintaining network consensus.
A “full node” is a computer that is running bitcoin software and maintaining a complete copy of the bitcoin blockchain. In contrast, a “light client” is a computer, or sometimes a mobile phone, that is running bitcoin software, but that does not maintain a complete copy of the blockchain. This is often done to save space on a machine or mobile phone. For example, a bitcoin wallet running on a smartphone. In this scenario incoming transactions are validated via a process called SPV, or Simplified Payment Verification.
We briefly covered the mining process in lesson two, Enter the Blockchain Part I, and here we’ll dive a bit deeper into consensus algorithms and maintaining consensus long term with governance systems.
It’s rather remarkable that a collection of computers, with no central authority, can come to an agreement on the state of the network. This process is called emergent consensus. We call it emergent because it is not brought about explicitly but through the interplay of four processes which happen independently on nodes throughout the network.
The longest, valid chain with the most accumulated proof-of-work is the chain that a node is programmed to follow. Accumulated proof-of-work can be thought of as a measure of the amount of hashing power or computing power that went into making that chain of blocks.
Proof-of-Work, discussed in our second lesson, is only one step in this process and can be replaced with other consensus mechanisms such as Proof-of-Stake.
While we won’t dive into differing consensus algorithms here, it is important to note that many options have been developed since the invention of Nakamoto proof-of-work consensus in 2008.
While Bitcoin is a software project, the network that it creates is sustained and managed with incentives and game theory. Let’s take a look at how that protects the network in the below video: