How blockchain works

The first widely adopted implementation of Blockchain was designed to facilitate the invention of Bitcoin — a decentralized digital currency. More details around the circumstances of its creation are discussed in the previous post.

Before decentralized digital currencies and blockchain technology came along, the financial system was almost entirely managed by central entities such as Banks and other financial institutions. All transactions are processed and recorded in what’s commonly referred to as a ledger.

Ledger

A ledger, by definition, is a book or other collection of financial accounts. There are many ways to represent a ledger but for the sake of simplicity, imagine ledger as an ordered list of transactions for a given account as shown below.

Above is an example bank statement which could be thought as a form of ledger — all transactions on an account are recorded in the order they happen and balance updated after each transaction.

Centralized Ledgers

In the current system, this ledger is maintained by a central entity — such as a bank. Each transaction requires an interaction with the central ledger to verify its validity.

While this is simple by design, it has its drawbacks — most notably the following:

• Loss of control: Asset needs to be transferred to central entities; users lose control of their data. Under some circumstances, users can be denied access to assets.
• Hackable: Centralized systems are more susceptible to hacks. It is easier to attack a single entity than commandeering multiple entities simultaneously.
• Single point of failure: Downtime in a central system can compromise the availability of the ledger to all users.

Distributed Ledgers

Distributed ledgers could be thought of as having a copy of the ledger replicated, maintained and synchronized by multiple entities — individuals or institutions.

Moving from a centralized to distributed ledger requires a fundamentally different approach to how certain features of a ledger are implemented. Some of these aspects are:

• Accounts: an abstract wallet that hold assets controlled by a user.
• Transactions: how users transfer assets between accounts.
• Privacy: the identity and data of the parties transacting on the ledger should be protected.
• Consensus: refers to how the system comes to an agreement on the state of the ledger.
• Security: to prevent illegitimate changes to the ledger by malicious actors.
• Scalability: Scalability is essential for ubiquitous adoption of any ledger.
• Incentives: are what encourages different parties to allocate resources towards maintaining the system.

Blockchain

Blockchain is one way to implement a distributed ledger. It is easier to understand the workings of blockchain by broadly examining its structure.

• Transactions: A transaction is the atomic unit of a blockchain system — Homer sending $3 to Apu is one example of a transaction. Transactions form the basis for any ledger.
• Blocks: A set of transactions is grouped into what can be referred to as a block. New blocks are minted to accommodate the latest set of transactions.
• References: Each newly minted block contains a reference to the previous block. These backward references within blocks create a virtual chain of blocks — hence the name Blockchain 🤯. The importance of these references will become clear later in the context of security.

As evident from the high-level structure, a blockchain uses a slightly different format (data structure in computer science terms) to record transactions in contrast to a traditional ledger. The need for this architecture will become in the next sections. The diagram intentionally omits certain crucial aspects of the blockchain design — these are covered later on.

Transactions

Transacting on blockchain has certain similarities to the traditional banking system. When Alice opens an account with the bank, she gets an account number and a password. With blockchain, Alice uses a crypto wallet to generate a public key and a private key — these are elements taken from asymmetric cryptography and the keys always come in pairs.

Asymmetric cryptography is used extensively in many Internet protocols which stood the test of time. Whenever a webpage is loaded securely (starts with https:// in the url), asymmetric crypto is working its magic behind the scenes.

Private key is kept secret and used for authentication and encryption. This is similar to the role of password or any other form of authentication in the tradition banking. In stark contrast to a password, private keys achieve authentication by digitally signing a piece of information — only those who have access to the private key can sign using it. Unlike the real world hand signatures that are susceptible to forgery, private key signatures are highly improbable to imitate.

Public key: is publicly known and essential for identification. Its role is very similar to that of account numbers in traditional banking. It is also used to verify the information signed using the corresponding private key.

Address: public key is made up of an extremely long string of numbers. So it is compressed and shortened to form the public address. These are the addresses that appear in the transactions on a blockchain. This is analogous to another way of representing account numbers in traditional banking.

A transaction is essentially a transfer of ownership of an asset — Homer sending 10 coins to Apu necessitates Homer transferring ownership of 10 coins that he owns, over to Apu. So transactions on a blockchain are largely transferring the ownership of a crypto coin from one party to another.

For a transaction to be valid, it must be signed using the private key of the current owner of the asset — since only the owner has access to the private key, only they can transfer the asset on to another party.

The adoption of asymmetric cryptography fundamentally allows anyone to verify the signature on a transaction while still limiting the ability to sign a transaction to the party that has access to the private key.

Privacy

The centralized ledger model achieves a level of privacy by limiting access to transaction information to the parties involved and certain trusted third parties. The necessity to announce all transactions publicly or at least to every node in the network precludes this method. Privacy in blockchains can still be maintained by keeping the addresses anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone in the real world. This is similar to the level of information released by stock exchanges, where the time and size of individual trades is made public, but without telling who the parties were.

Consensus

Blockchains runs on a distributed network and the entities participating in the network are often dispersed geographically. Since there is always a finite delay in propagating information between the nodes in the network, nodes could occasionally go out of sync — the copies of their ledger do not match.

A consensus algorithm is a procedure through which all the entities of the Blockchain network reach a common agreement about the present state of the distributed ledger. In this way, consensus algorithms achieve reliability in the Blockchain network and establish trust between unknown parties in a distributed computing environment.

Malicious nodes in the network could also bring about a similar situation in the network, albeit intentionally. Therefore, all implementations of blockchain must incorporate a strategy to reach consensus. There are many implementations of blockchain — Bitcoin, Ethereum, Litecoin, and Polka dot just to name a few, and each of them have their own consensus mechanism. While there are many consensus algorithms, the popular ones are:

• Proof of Work (PoW): The central idea behind this algorithm is to solve a complex mathematical puzzle and give out a solution. This mathematical puzzle requires a lot of computational power and thus, the node who solves the puzzle as soon as possible gets to create the next block. The solution, once found, can be easily verified by any node.
• Proof of Stake (PoS): In this, nodes invest in the coins of the system and lock up some of their crypto assets as stake. After that, all the validator nodes will start validating the blocks. The specifics of the node selection and block creation process can vary per implementation. But the central idea is that all nodes have their assets at stake to act honestly.

More details on how different consensus algorithms work will be covered in future posts.

Security

The records on a blockchain are secured through cryptography. Users authenticate transactions with digital signatures using their own private key. If a transaction is altered, the signature will become invalid and the participants in the network can detect it. Editing a past transaction and signing it again accurately is also not possible as blocks are immutable by design. Immutability is baked into the design through the use of cryptographic hash functions when creating block references.

A cryptographic hash function (CHF) is a mathematical algorithm that maps data of arbitrary size (the “message”) to a fixed size output (the “hash”). It is a one-way function — a function which is practically infeasible to invert.

The hash functions adopted by blockchain implementations are such that a small change to the contents will change the hash value so extensively that the new hash value is completely uncorrelated with the old hash value.

Malicious nodes in the network is a widely discussed phenomenon in any blockchain. Since each transaction has to be signed with the private key of the owner of the asset, the nodes cannot arbitrarily transfer assets to themselves. They can however double spend their own assets!

For example: Mr. Burns, can operate a malicious nodes in the network. Burns can transfer the assets to Lisa, receive the services in return, and then create a new block with a transaction transferring the same assets to Bart. This is referred to as the Double spend problem. The attacker can do this by creating a new branch of block(s)— referred to as forking the chain.

Branches are not acceptable legal states for a blockchain and all implementations have mechanics to avoid or eventually resolve branches by discarding all but one branch that will define the new state of the blockchain. In the example of Mr. Burns, it resolves to keeping only one of the 2 conflicting transactions — avoiding double spend. Depending on the implementation and resources, an attacker could convince the network to discard legitimate transactions that are deemed as confirmed by the users. More on these attacks in future posts in the context of each implementation.

Bugs and other systematic errors are also possible in a blockchain, much like in central ledgers.

Scalability

Scalability in blockchain could mean many things but this section is limited to transaction throughput.

Transaction throughput is the rate at which the network can process transactions.

This number can vary widely depending on the implementation but the early implementations like Bitcoin (27 tps), Ethereum (15 tps) have struggled with low throughputs, causing longer than usual delays in confirming transactions — to put this in perspective, Visa network can operate at 65,000+ tps. Limits on transaction throughput are related to the fact that blocks in the blockchain are limited in size and frequency — there’s often a limit on how many transactions can be put in a single block and the rate at which new blocks are generated.

The Blockchain Trilemma

The Blockchain Trilemma, termed by Vitalik Buterin (creator of Ethereum), addresses the challenges developers face in creating a blockchain that is scalable, decentralized and secure — without compromising on any facet. Blockchains are often forced to make trade-offs that prevent them from achieving all 3 aspects simultaneously:

1. Decentralized: creating a blockchain system that does not rely on a central point of control or co-ordination.
2. Scalable: the ability for a blockchain system to handle an increasingly growing number of transactions.
3. Secure: the ability of the blockchain system to operate as expected, defend itself from attacks, bugs, and other unforeseen issues.

While some developers believe that the blockchain data structure itself has inherent limitations that prevent it from scaling, many architects believe that it is possible to build a blockchain that hits all three targets. More details on where each blockchain fits in this Trilemma will be covered in future posts.

Incentives

A blockchain runs on the resources provided by the nodes participating in the network. Incentives are what encourage participants to join and contribute to a specific blockchain network. All practical implementations of blockchain incorporate a model for incentives. Commonly adopted models are:

• Block rewards: The node that mints the next block is rewarded with a defined number of new tokens.
• Transaction fees: The node that mints that next block takes a transaction fee from all transactions that make up the block.
• Participation reward: A mix of the earlier two could be combined with aggregating rewards across the network and re-distributing based on the level of participation of each node.

These are just some examples of straightforward incentive models. There is plenty of on-going research in the area of Blockchain incentive models. Incentive models are specific to blockchain implementation.

Final thoughts

While this post gives a general overview on how blockchain technologies work, there are numerous other aspects which are unique and specific to individual implementations. Future posts will explore each of these major implementations and cover the concepts in greater detail. The diagram below summarizes all the high level high-aspects of a blockchain transaction.

I hope you enjoy reading and learning from this series as much as I enjoy writing it. Show your support by sharing. See you again on this channel soon!