Distributed Systems and All the Rage
What is a distributed system?
A distributed system is a system with multiple components located on different machines that communicate and coordinate actions in order to appear as a single understandable system to the end-user.
In other words, a number of independent computers linked by a network.
With all those machines interacting with each other and there being multiple parts of the system on different machines, how do we verify what information is true?
Who gets to call the shots?
Let us break it down a little bit further.
Software relies on a system of hierarchy. Meaning, the machines need to know where to turn to for their commands. Being that hierarchy is the basis, no matter how complex the system, it relies on a central form of governance that the machine trusts.
There have been many attempts to create a system free of hierarchy, with standalone independence. The issue it always ran into was timing. I don’t mean that as a pun, I mean it quite literally; what goes first? Timing.
You see, the most important thing in updatable information is what comes before what. For example, imagine you’re a bank computer server and you got a request asking you to send $100 from account A to account B. However you also got a request to send $100 from account A to account C. The problem is that account A only has $100. Who do you send the money to?
The answer is whichever was first. The thing with timing is it doesn’t really matter which command you received first it matters which was sent first. Because the one that was sent first was the command that happened first and should therefore get precedence. However, the receiving computer has no way of knowing which command was truly first. It doesn’t know who to trust. This is because the internet is made up of physical wires which, depending on the course it takes, or the packet it travels can have different amounts of time it takes to reach its destination.
This problem might not seem like such a big deal, but it is the very heart of anything that requires order. Thus, for distributed servers and most applications, the order is of paramount importance.
There are solutions to this problem but all require trust in a single entity in the communication process, making it a central governance system. This means that if you trusted each sender on which was first, the sender can tell one server one thing and a different server another and then you’d be left with contradicting data. If you (all) trust the servers owned by a single entity to coordinate and determine which came first, well, that trust becomes a central system.
Enter (drum roll please) Satoshi Nakamoto, the inventor of Bitcoin. Their brilliance was in finding a solution to the “double-spend” problem explained above. Nakamoto’s solution, while simple, was brilliant. Nakamoto asked, who cares who actually came first? We just need a way where we can all agree on whom should be first. A system where there is no trust, hence the term “Consensus”, was born on the chain. The idea here is that we already have a way of confirming it was initiated by the owner of the account (with SHAW 256). Even if we get what came first wrong the system can see a definite result and correct itself. In other words, there’s no way to lie, there’s only a way to game the system. So we can just have the receiver see a determined result and then act accordingly. It’ll be on the sender for “double spending”.
Allow me to do a little clarifying using our previous “double-spending scenario. A sends to both B and C 100$ at the same time, when there is only 100$ in the account. All the servers will then agree on choosing between B and C who will get the money. Then the servers will post a definite result on to whom they all agreed to send the money. B and C can see a definite result on who actually got it, as it can only send to one (at this point it doesn’t matter to which one it sends so long as there is a consensus). So one will see a definite result of having 100$ sent to them, and one will see a definite result in not having money sent to them. Either way, they are seeing a definite result based on the consensus that was reached between all three servers. Thereafter, whoever is missing the funds will turn to A and ask where their money is.
The novelty of this approach is that it does not rely on one central system which determines who was first. Rather it relies on all the servers involved to make a consensus. This removes the hierarchy of software and allows it to truly become a distributed system.