Blockchain for non-tech-savvy — Part I
Introduction
Over the past few years, Blockchain has evolved into an extremely extensive technological topic, having thousands of business entities working hard to make it easier to use and understand, for both consumers and developers. This effort has resulted in millions of Euros invested, leveraging the research and execution of innovative solutions for a reason: Blockchain technologies had proven its value in hundreds of projects like Bitcoin and MakerDAO, even though the spectrum of its use cases is still extraordinarily narrow, for those aware of some of its key concepts.
Therefore, this article will be split into 2 parts. As the article doesn’t only focus on developers, in Part 1, I first try to contextualize readers with some Blockchain topics and try my best to offer a high-level understanding of its functionalities.
Later in Part 2, I will talk about what I believe to be the fundamentals to develop a business application over Blockchain technology, also called decentralized applications (dApps).
There is already a wide variety of Blockchain definitions online, although they typically involve words like “ledger”, “records”, “blocks”, “nodes” etc — this is extremely confusing not only for non-tech-savvy-folks, but also for people who are familiarized with standard tech language like SOAP, REST, and Relational Databases. Why? Because Blockchain is relatively new and introduces procedures that do not apply to those standards.
Throughout my experience, I found myself struggling many times to explain Blockchain concepts and functionalities to Backend, Frontend, and Full-Stack Developers. I ended up concluding that it is smarter to explain them using words and concepts that they are already familiar with. So, briefly, this is my pseudo-description for them:
Blockchain is a distributed database maintained across a network of computers. Each computer holds a live software that keeps the current state of the database as well as ALL changes it has ever undertaken. Any state change to this database must be signed by the responponsible entity using unique and private identifiers. Also, as states change, all the other computer databases must verify those changes and change accordingly to them, if valid.
On the other hand for a non-tech individual, it is easier to explain Blockchain fundamental behavior making use of real-life analogies, like:
Imagine a Blockchain as multiple stacks of paper that hold certain data. These paper stack’s content would be replicated through many desks in the same room that belong to different people. Each new paper appended to the stack would have to be placed on top of the previous appended one, having its page number as an unique identifier. Everytime a new paper would be added to the stack by its owner, he or she would have to go and deliver a copy of it to the other stack owners. Finally, they would have to verify the content of the new paper, by checking if the new paper’s data doesn’t create a conflict with the rest of the stack.
This is a very short and abstract metaphor for the Blockchain functionalities because, during these descriptions, I assumed the entities would always behave fairly. What if a stack owner would try to distribute a paper which had been tampered with? To go deeper into details, I will have to explain a couple of consensus and cryptography concepts.
Cryptography
The Wikipedia definition of Cryptography is
Cryptography or cryptology is the practice and study of techniques for secure communication in the presence of third parties called adversaries.
and I still remember the first time I heard this word… it sounded extremely scary for some reason. Don’t take me wrong, it is indeed a complex topic. However, there are hundreds of subtopics within the Cryptography scope, and, luckily for us, we mostly need to understand one for now: Public-key cryptography, also known as asymmetric cryptography. Even though this is another sophisticated word, this technique’s theoretical underpinnings are rather simple to understand. This technique can offer users a way to achieve public identification, and at the same time, something users should keep private that proves its identification is trustworthy. This identification is called a public key, and the proof is the private key.
Both these keys are linked through mathematical laws. Essentially, a private key is any decimal number picked at random between 0 and 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129, 639,95.
The reason for this number is that a private key has 32 bytes size, which is the same as having 16 possible numbers and letters (0–9 and A-F) to fit in a 64 character space. As you may notice, it is indeed possible to guess a private key, although, the odds are extremely low as you can better see in this funny, yet realistic article. On the other hand, public keys derive from their private counterparts by making use of the Elliptic Curve Equation. The process’ core is rather complex to understand, although essentially, it is special because it can only go one way, i.e. normal arithmetic math doesn’t apply for this equation, therefore it is extremely easy to derive a public key from the private key, but impossible to do the other way around.
From a Blockchain perspective, public and private keypairs are essentially the way to identify an entity (public key) and prove its ownership (private key), i.e, the private key is used to identify the responsible for the Blockchain state change. Also, as the name itself says, a private key should be kept secure, while the public key is the way to publicly identify yourself. For a natural understanding, we can think of the public key as your Bank IBAN, and the private key as your access code to manage the account.
Consensus
Let’s go a few steps back to the paper stack example and consider we have three distinct Stacks and owners representing our Blockchain.
The consensus is the fault-tolerant mechanism each Stack owner needs to follow for everyone to agree on a single current state. The mechanism varies according to the Blockchain technology we address. Therefore, for the sake of this article, I will focus the Ethereum 1.0 consensus, Proof of Work.
For the next Blockchain analogy, I will not cover the full technological process behind Proof of Work. Instead, I intend to offer a view of how this consensus mechanism could be interpreted in daily life actions and events.
Blockchain Flow Analogy
Still looking at the three Stacks, whenever an entity would add a paper to a Stack with new data, it would be required for each Stack owner to validate the new entries and decide if it conforms with the rest of the data previously appended to the Stack. Let’s take a realistic scenario and make a few assumptions:
- Each paper holds a unique page ID that increments with every new appended page. Being an incremental identification let’s assume this is a way to also know what was the previous appended page ID, which is then identified by the current ID-1 (important to note that this specific assumption takes place solely for the sake of this example because it occurs differently within the Blockchain technology). Apart from the ID, it also has a list of Euro transactions from one entity to another, like so:
- Each Stack already contains 100 papers filled with arbitrary transactions and all Stacks are in conformity
- By concurrently tracing each paper’s content back to the previous, all the way to its first page, we can verify any entity’s balance doing simple arithmetic operations like addition, when a transaction signed by someone else increments our balance, and subtract when we make a transaction to someone else. Therefore, at Page 100, assume the following balances:
Taking these assumptions into consideration, eventually, at some point in time, someone will want to transfer some € to someone, and add that transaction to the new paper and append it to the top of the Stack, so let’s say that Alice and Bob want to send some money to Peter. Therefore, they both write the transactions “20€ from Alice to Peter” and “10€ from Bob to Peter” on a new page. Consequently, they hand it over to the owner of Stack 2. Doing so, they each sign their respective sentence with their private key (that only they know), certifying that they are indeed the ones making this request.
At this point, the Stack 2 owner that received the paper, verifies 2 things:
1) Do Alice and Bob have enough € to successfully execute their request — since the Stack 2 owners can check their balance state, he or she confirms that they have enough balance;
2) Do these signatures belong to Bob and Alice, accordingly — if you remember from the Cryptography section, this is easy to validate. Therefore the paper is marked as valid and appended to stack 2;
Doing so, the owner of Stack 2 now delivers a copy of the new paper to all the other Stack owners (1 and 3). Consequently, they would look at it and ask themselves the exact same questions as the Stack 2 owner did: “Does Alice has 20€?” — yes, according to my Stack state, she has 80€, which is enough to send 20€; “Does Bob has 10€?” — yes, according to my Stack state, he has 50€, which is enough to send 10€; “Are signatures ok?” — yes. Concluding, the Stack owners would mark the new paper as valid and append it to the top of their Stacks. Great! So, now we successfully appended a new paper with valid data, having our Blockchain’s last paper and Balance state look something like this:
This whole process occurred with no data tampering and everyone behaved fairly according to the protocol. This could go on forever, appending new papers with valid transactions. Even if for example Bob tries to transfer more money than he owns, after he hands the new paper to a Stack owner, he or she would automatically reject his transaction, not passing that paper on to other Stack owners, nor append it to their own Stack.
Now let’s assume misbehavior. Let’s say Bob is the owner of Stack 3 and he appends a new paper to it containing a 200€ transaction from him to Peter. Afterwards, he hands over the new paper to the other Stack owners, which would eventually reject it after validating that their Stack state says “Bob only has 40€”. At this point we would have 3 stacks, not in conformity:
This is perfectly normal Blockchain behavior and what happens next has the name of an orphan paper.
Since this network of stacks is in the same room, their owners can verify each other’s state and follow the state majority because the protocol has mechanisms to encourage them to do so. In our particular case, we have 2 stacks with the same state, and another with its own (note the number of stacks is arbitrary and could achieve thousands). Therefore, page 102 of Stack 3 would still exist but would become orphan, as no Stack on the network would accept it. The process could repeat many times, always finding the same ending, until a new majority agrees on the wrong state and the network subsides to a 51% attack, one of the most known possible ways of tampering with Blockchain technology.
Conclusion
It is important to be aware that I skipped a few technical steps of the process, although, this article focused solely on explaining a Blockchain basic flow using a real-life analogy, abstracting a couple of tech-focused topics. The best part is… now that you concluded the reading, you may proceed to read it again and replace the following words for their corresponding pair… and voilà! There’s your Blockchain.
Paper — Block
Paper ID — Block Height
Stack owners — Nodes
Stack — Node that keeps a record of the ledger
Entity — Public and private keypair
Alice/Bob/Peter — Entities’ public key
Signs — Uses a private key to prove it’s ownership
Euro € — Ether or Wei
Transactions — State changes
Append a paper — Mining a Block
Stacks conform — Nodes are synced
Being in the same room — The same Peer-to-Peer network
Orphan paper — Orphan block
