Before we get into what a is, we need to understand what a ledger is.A ledger in computer science is software that stores transactions. A database is different from a ledger such that in a database we can add, remove, and modify records, whereas in a ledger we can only append but not delete or modify.
A blockchain is basically a data structure to implement a decentralized ledger. A blockchain is a chain of blocks connected to each other. Every block contains a list of transactions and certain other metadata, such as when it was created, which is it's previous block, the block number, who is the creator of the block, and so on. Every block maintains a hash of the previous block, therefore creating a chain of blocks linked with each other. Every node in the network should hold the complete copy of the blockchain and, when a new node comes in, it will request and download the blockchain from other nodes.
Note
Technologies such as blockchains are called Distributed Ledger Technology (DLT). A DLT is the process of replicating, sharing, and synchronizing digital transactions geographically stretched across numerous sites, countries, and/or institutions. You can think of a blockchain as a type of DLT. Also, not every DLT system has to be decentralized. In this book, we only learn to build decentralized blockchain-based applications.
The major advantages of using a blockchain is that it enables the facilitation of transactions without a central trusted party; data is secured using cryptography, and data is immutable, as blockchain removes friction and reduces risk so settlements happen in real time, and so on. Basically, it automates auditing, makes the application transparent, and provides a single source of truth.
In the real world, private blockchains are used in trade finance, cross-border payments, digital identity, the clearing and settlement of tokenized and digital assets, provenance of ownership of a product, record keeping for critical data, signing contracts, multi-party aggregation (namely, they can be used as a shared master repository for common industry information, allowing members to query for data), payment-versus-payment or payment-versus-delivery, and so on.
Every blockchain node maintains a database that contains the blockchain's state. The state contains the final result of running all the transactions in the blockchain. For example, in a blockchain, the state represents the final balances of all addresses. So when you query the blockchain node for an addresses balance, it doesn't have to go through all transactions and calculate the final balance of the address; instead, it directly fetches the balance from the state of the blockchain. Bitcoin uses LevelDB to maintain the state of the blockchain. Even if the database gets corrupted, the database can be restored by simply running all the transactions in the blockchain.
Byzantine Fault Tolerance (BFT) is a characteristic of a decentralized system that indicates that it can tolerate Byzantine failures. A crash failure is when nodes just stopping to do anything (no messages at all) and Byzantine failure is when nodes just don't do anything or exhibit arbitrary behavior. Basically, Byzantine failures include crash failures.
In any decentralized computing environment where a blockchain data structure is used, there is a risk that one or more rogue or unreliable actors could be a reason for the environment to disband. A server cluster will not work well if a few servers within it lose out on passing data to other servers in a consistent manner. In order to be reliable, the decentralized computing environment has to be designed in a way that it has solutions to these kinds of Byzantine failures.
On blockchain-based decentralised applications, there is, by definition, no central authority, so a special kind of protocol called the consensus protocol is used to achieve BFT.
In simple terms, you must be wondering how to ensure that everyone has the same copy of the blockchain, and how to know which blockchain is correct when two nodes publish different blockchains? Also, how do you decide who creates the blocks, as there is nothing such as a master node in decentralized architecture? Well, consensus protocols provide an answer to these questions. A few examples of consensus protocols are Proof-of-Work (PoW), Proof-of-Stake (PoS), Proof-of-Authority (PoA), PBFT, and so on.
A consensus protocol is designed specially for permissioned or public blockchains. A consensus protocol made for a public blockchain is likely to create security and performance issues when implemented in a permissioned blockchain. Every consensus protocol has different performance and scalability vectors. You have to be alert while selecting a consensus protocol for your blockchain-based DApp.
Note
Consensus protocols such as Raft and Paxos are not BFT; rather, they make the system only crash-tolerant. So, you should also consider this when choosing a consensus protocol.
You might have come across the term PoA. PoA is a categorisation of consensus protocols in which there is a set of authorities—nodes that are explicitly allowed to create new blocks and secure the blockchain. Ripple's iterative process, PBFT, Clique, Aura, and so on, are examples of PoA-based consensus protocols.
In blockchain-based applications, user accounts are identified and authenticated using asymmetric key pairs. The private key is used to sign transactions on behalf of the user. Username and password-based accounts systems will not work in blockchain as it cannot be used to prove which user has sent a transaction. The demerits in using private-public key pair include that they are not user-friendly and if you lose the private key then there is no way to recover it. So, it adds a new responsibility for the users to secure their private key. The address of a user account acts as the account identifier on blockchain. The address of a user account is derived from the public key.
Some blockchain applications use the UTXO model for transactions. Blockchain applications such as Bitcoin and MultiChain use this model. Even DLTs such as R3 Corda also use this model. Let's understand this model by understanding how Bitcoin transactions work.
In Bitcoin, a transactions is a collection of zero or more and outputs. These input and output objects are called Unspent Transaction Outputs (UTXO). Outputs of transactions are used as inputs of future transactions. A UTXO can be used as input only once. Each UTXO in Bitcoin contains a denomination and an owner (a Bitcoin address). In this model, the balances of addresses in the unconsumed UTXOs are stored. For a transaction to be valid, these requirements should be met:
- The transaction must contain a valid signature for the owner of each UTXO that it consumes
- The total denomination of the UTXOs consumed must be equal to or greater than the total denomination of the UTXOs that it produces
A user's balance is computed as the total sum of the denominations of UTXOs that they own. A transaction can consume zero or more UTXOs and produce zero or more UTXOs. For a miner to pay reward to itself, it includes a transaction in the block that consumes zero UTXOs but produces one UTXO with the denomination assigned the amount of Bitcoin it is supposed to award itself.
A UTXO transaction model is suitable when blockchain transactions involve the transfer of asset, but for non-assets transfer transactions such as recording facts, invoking smart contracts, and so on, this model it not suitable.