Recreating Bitcoin 13:P2P Network
Epilogue #
Satoshi found inspirations on Bitcoin from evolutionary processes in nature. Next step would be implementing these inspirations.
The evolution of an organism starts with single-cellular ones to multicellular ones, and then organs emerge, ending with the formation of the brain.
Satoshi started designing the basis of Bitcoin’s existence (the inner circle of the vortex model) — that is, the peer-to-peer accounting network.
The definition of Bitcoin could thus be a peer-to-peer digital cash system.
Of course, Bitcoin’s definition in future could change. It could be a peer-to-peer general computer, a peer-to-peer super-intelligence or the root of the world: METANET.
Anyway, back to where we are: implementation of the accounting network.
Starting with Two Nodes #
“The server Bitcoin has right now is one single node,” Satoshi said.
“Like a single-cell organism?” asked Gilfoyle.
“Not exactly,” Satoshi said. “It is fundamentally different from single-cell organisms. Single-cell organisms live among their own kind, just like when we were talking about those bioluminescent bacteria. Right now, Bitcoin is just one single cell, but one single cell cannot really survive in the natural world. At the moment, we are its source of maintenance and electricity. Independently, its survival cannot continue. So, it doesn’t really count as an autonomous system. What we need to do now is to upgrade it into an autonomous swarm system that can live on itself and self-evolve.”
“We start from the simplest scenario: we add one more node to the Bitcoin network, so it becomes a dual-node swarm system.”
“I can get us a new server from home then,” said Gilfoyle.
“Excellent! That’d save us from buying a new one,” Satoshi said.
After a while, Gilfoyle put an old computer on the coffee table, and now they have two servers.
Installing the previous Bitcoin server code would be ineffective at this point, as the two servers would think that they were the sole server in the network and make communications impossible.
“First, we need to connect the two servers for them to be aware of each other’s existence,” said Satoshi.
“Then we need them to communicate with each other and sync the ledger between themselves,” added Gilfoyle.
“Yes,” said Satoshi. “There will be many more problems coming. We will solve them as we go.”
Connecting the Two Nodes #
“How can the two nodes connect to each other like two neurons?” Gilfoyle posed the question.
Neuron connections
Neural network between two neurons
First of all, let’s take a look at how neurons connect to each other. Each neuron has dendrites and axons. The role of dendrites is to receive signals from other neurons, and the role of axons is to transmit signals (see graph below).
A neuron extends its network to other neurons with its dendrites connecting to the axons of other neurons through neural transmitters. Its axons extend themselves to the dendrites of other neurons (see graph below for neural transmission between neurons).
Information passes through dendrites and axons freely through neural transmitters
“We can use the TCP/IP protocol to achieve the same capabilities,” Satoshi said.
IP is equivalent to the coordinates of the neuron.
Socket Server is equivalent to the axon that sends messages.
Socket Client is equivalent to the dendrites of the neuron that receives messages.
One node needs independent IP and needs to at least create a Socket Server and a Socket Client.
A Socket Client can proactively connect to a Socket Server of its corresponding IP address, like a dendrite connecting to the axon of another neuron.
One Socket Server can be connected to multiple Socket Clients, like an axon connected to a group of dendrites.
Once Socket Client and Socket Server connects successfully, the information channel is established so that messages can transmit between two nodes bi-directionally, just like how two neurons continuously pass information to each other both ways.
Satoshi modified the code based on the above logic and deployed it on both servers. Now a very simple P2P network was complete (see graph below).
Of course, there was a lot of redundancy in the code, but it could be dealt with later. Now there were only two nodes running the network.
The network may still appear insufficient to demonstrate the complexity of a P2P network. We will add in one more node for illustrative purposes (see graph below).
P2P network consisting of 3 nodes
“Complexity will grow exponentially as the number of nodes increases in future,” Satoshi pointed out.
“Therein lies the fundamental difference between clock system and the swarm system,” Gilfoyle nodded.
Changing from Web Client to P2P Client #
With the server adapted for a P2P network, the client needed to be adapted as well, as the previous web architecture had the problem of a single point of failure as in the website bitcoin.org (see graph below: under the web architecture the Node 2 could never be accessed.)
Node 2 will never be accessed under the web architecture
User would open the browser and try to access bitcoin.org. The browser then visits the DNS server, which stores the corresponding IP address for the URL. Because the DNS only has one corresponding IP address, Node 1 is the only node that has access to the website. Killing Node 1 would kill the whole network.
Therefore, there cannot be a single point in the swarm system. As long as there is a single point, the system can die if the single point dies.
“We can tell if a system is a swarm system by checking whether or not there is a single point of failure,” Satoshi said. “Traditionally, although the swarm system has been claimed to be a distributed system, the distribution is not truly decentralized, because there would always be one node for load balancing or service discovery that is responsible for allocating access paths in the architecture.” (see graph below)
Traditional distributed architecture
To avoid the single point problem, Bitcoin client needs to get rid of the web browser to become a node that directly connects to a ledger node in the network. This client node is the light node we mentioned in the previous chapter, as it does not contain the whole of the ledger history. And because light nodes need to rely on their own lightweight storage to achieve independent transaction simple verification (simple verification requires the concept of MERKLE TREE, which will be discussed in subsequent chapters), So there is a technical term for it: Simplified Payment Verification (SPV for short).
Client changed from browser to a SPV, which meant that a user needed to install an independent app on its device. This also meant that the engineering of Bitcoin now had evolved into two parts: the full node and the SPV.
Satoshi finished coding the SPV and completed its app. He published online for user download.
In the SPV code, the IP address of the full node was fixed as a temporary solution. The SPV would connect to the IP address to connect with the full node. The whole network architecture became as followed (in graph below)
Overall peer-to-peer network architecture
At this point, as long as there is one full node in operation, killing every single other full node would still leave the system working properly for users.
Of course, the system is not working properly yet. Although the two nodes are connected, they work independently when accounting, so the ledgers are inconsistent. For example, it is easy to find that the balance is 100 when the user visits node 1, and 90 when the user visits node 2. The user will be confused.
How to achieve ledger synchronization between nodes? That’s the next question for Satoshi and Gilfoyle.
In addition, connections between SPVs would evolve into P2P connections in the future, and the functionalities of SPV would extend beyond mere transactions, It is precisely because the SPV has the mutability space of its own algorithm that Bitcoin can evolve into a super-intelligence on its own, just as the evolution of life is based on individual genetic variations. (in graph below)
P2P network composed of SPV and SPV
If the swarm system is compared to a vortex, the inner ring turns and the outer ring emerges. Then the future bearer of the outer ring emergence of the protagonist must be SPV network.
Of course, this is way ahead of the game, and we’re just focusing on the survival of Bitcoin: the construction of the accounting network.
Epilogue #
In the next book we will discuss SPV and SPV network, where Alice and Bob can transfer money point-to-point, without being mediated through the accounting network
We will discuss how to synchronize the ledgers of full nodes in the next chapter.
Next chapter :Recreating Bitcoin 14:Synchronizing Transactions
CONTENTS #
Recreating Bitcoin:A Fictional Story of Why Bitcoin was Designed This Way
Part one : Transactions
Recreating Bitcoin 1:Start over with a Simple Web Transaction System
Recreating Bitcoin 2:First Version is Online!
Recreating Bitcoin 3:Getting Rid of the Account Model
Recreating Bitcoin 4:Digital Signature
Recreating Bitcoin 5:Public Key and Private Key
Recreating Bitcoin 6:Version 0.0.2 is Online!
Recreating Bitcoin 7:UTXO
Recreating Bitcoin 8:System Refactoring Based on UTXO
Recreating Bitcoin 9:Everything is Transaction
Recreating Bitcoin 10:Transaction Script
Part Two : Swarm System
Recreating Bitcoin 11:Swarm System (Part I)
Recreating Bitcoin 12:Swarm System (Part II)
Recreating Bitcoin 13:P2P Network
Recreating Bitcoin 14:Synchronizing Transactions
Recreating Bitcoin 15:Synchronizing Ledger
Recreating Bitcoin 16:Block chain
Recreating Bitcoin 17:Network Flexibility
Recreating Bitcoin 18:Proof of Work (Part I)
Recreating Bitcoin 19:Proof of Work (Part II)
Recreating Bitcoin 20:The Reorganization and Division of
Forking
Complete book selling at Amazon( > US > UK > CA > JP > DE > FR > ES > IT) #
BSV Donate:
1Djc4TdVBi8urzmSXKHwg8cpEAYKcRQxgY
©2019 - Recreating.org all rights reserved