What is a Blockchain?
Blockchain is increasingly becoming the new forefront in technological innovation. Companies are finding that distributed ledger technology offers a workaround for some of the largest industrial problems, such as real-time cross-border payments, real-time inventory and procurement systems, and secure data storage and servicing.
Despite this, most people are unaware what a blockchain is. This guide will take a moment to discuss what this technology is and what the implications of its existence are.
What is a Blockchain?
The best way to think of a blockchain is to imagine a baking club. Members of the club “purchased” the right to use the kitchens of other members to bake goods for sale and these goods are anonymously sold using the members’ ledger to pay for supplies and compensation for kitchen use. The members’ ledger is independently maintained by each member; it is the responsibility of each member to report to all the other members kitchen rental and any good sales.
The ledger system was created because there was active discrimination among the membership. Some members would use other members’ kitchens freely, but only allow their friends to use theirs. The ledger system makes it clear that members do not need to gain permission from other members to use the club’s resources, while maintaining accountability.
Disputes among this club are handled by a “longest list wins” where the most complete ledger is the most accurate. Members can enter and leave the club at will and technically, can join the club anonymously (although entering one’s kitchen without announcing himself/herself is ill-advised). All decisions are democratically-decided and discussed via social media.
The members’ ledger would be the blockchain. In the simplest terms, a blockchain is a collection of cryptographically-encoded records. These records store tokens — permanently-stored data containers capable of storing value – as well as the public keys needed to locate and decrypt the tokens, and a non-corruptible record of all transactions involving the tokens.
These records – known as blocks – are either predefined or discovered through a method called “mining,” in which network nodes compete to complete the proof-of-work first: finding a special number called a nonce, which when hashed with the block content, produced a result that is smaller than the blockchain’s current difficulty target. The proof behind detecting the nonce is easy for a node to verify, but difficult to calculate. For bitcoin, the difficulty is increased every 2,016 blocks.
Each progressive block is encoded with the cryptographic hash of the previous block, creating a Merkle tree-encoded chain. This chain is stored in a ledger file stored by each of the network’s nodes or clients. Token transactions are broadcasted to all nodes, where they verify them consecutively. These transaction verifications are then recorded to the blockchain. A token can only be used or transferred if the user has the private key that corresponds with the token’s public key.
Blockchains are either partially or fully decentralized. Self-managing, disputes between conflicting versions of the blockchain are resolved via a comparison of work completed, with priority given to the blockchain that has the most work completed. This means that the longest ledger is favored, with the smaller ledgers being automatically replaced. This is not always the case, however. A change in the blockchain software rules can create blocks no longer considered valid by the software or can create blocks that are considered valid but contentious by the rest of the node community. This would fork or split the blockchain into two.
Bitcoin is the proof-of-concept for blockchain. “The problem of course is the payee can’t verify that one of the owners did not double-spend the coin,” bitcoin founder Satoshi Nakamoto wrote in his whitepaper in explanation of why a blockchain is needed. “A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.”
“We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced, and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.”
As blockchains are decentralized, they are trustless. There is no way to verify the integrity or the motivation of a transaction partner when that partner is semi-autonomous. This “good faith” assurance is the backbone of blockchain technology.
Generals and Trust
In cryptography, the Byzantine Generals Problem is a well-known thought exercise. It goes like this: “A reliable computer system must be able to cope with the failure of one or more of its components. A failed component may exhibit a type of behavior that is often overlooked–namely, sending conflicting information to different parts of the system. The problem of coping with this type of failure is expressed abstractly as the Byzantine Generals Problem. We devote the major part of the paper to a discussion of this abstract problem and conclude by indicating how our solutions can be used in implementing a reliable computer system. We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement.”
“The generals must have an algorithm to guarantee that A) All loyal generals decide upon the same plan of action,“ Leslie Lamport, Robert Shostak, and company from the University of California Berkeley wrote. “The loyal generals will all do what the algorithm says they should, but the traitors may do anything they wish. The algorithm must guarantee condition A regardless of what the traitors do. The loyal generals should not only reach agreement, but should agree upon a reasonable plan. We therefore also want to insure that B) A small number of traitors cannot cause the loyal generals to adopt a bad plan. Condition B is hard to formalize, since it requires saying precisely what a bad plan is, and we do not attempt to do so. Instead, we consider how the generals reach a decision. Each general observes the enemy and communicates his observations to the others. Let v(i) be the information communicated by the ith general. Each general uses some method for combining the values v (1) ….. v (n) into a single plan of action, where n is the number of generals. Condition A is achieved by having all generals use the same method for combining the information, and Condition B is achieved by using a robust method. “
“For example, if the only decision to be made is whether to attack or retreat, then v(i) can be General i’s opinion of which option is best, and the final decision can be based upon a majority vote among them. A small number of traitors can affect the decision only if the loyal generals were almost equally divided between the two possibilities, in which case neither decision could be called bad.”
Going back to the baking club example, how can one trust another member when it is unclear if you can trust him/her? A member that refuses open access to his/her kitchen compromises the whole enterprise, but there is no way to doublecheck compliance in the moment. What is needed is a way to audit a transaction to the members’ ledger independently and in a compulsory way.
This quality, known as Byzantine fault tolerance (BFT) is the defining quality of blockchains. It is a necessary component of consensus, or the network’s ability to find trust in decisions made by a trustless party. For bitcoin and similar “mined” networks, this consensus is proven by “proof of work” or the difficulty it takes to fake a transaction, versus the ease in proving a valid transaction. As it takes a significant effort to fake a transmission and as that fake transmission would likely be rejected on confirmation from other nodes, it is considered wasteful to try.
This is not to say that it is impossible to fake a transaction. If a bad actor was to gain most of the hashing power on a crypto network, he can fake acceptance of his false transaction, forking the blockchain. As the fork would be growing faster than the “real” blockchain, new transactions would link to the “fake” blockchain, giving the bad actor the ability to double-spend tokens, reject transactions, and steal block rewards. Such attacks are known as “51 percent attacks.”
Smaller valuation coins, which are easier to take majority control of, such as monacoin, bitcoin gold, Litecoin Cash, zencash, and verge have all been subjected to 51 percent attacks. The only known way to prevent this is to allow tokens to go through more confirmations, which would increase the workload for hackers who seek to steal them.
Besides proof-of-work, consensus can be found through proof-of-stake, where validators invest in a significant stake of the pre-mined token and keep the stake online to “validate” a node on the network; proof-of-activity; proof-of-burn; proof-of-capacity; and proof-of-elapsed time. Only proof-of-work and proof-of-stake are commonly used.
Limits of the Blockchain
Within itself, a token is useless and valueless. It is just a computer construct, supported by a sharable, storable key. It is the role these tokens play on their respective platforms that give them worth.
For a cryptocurrency-type token, for example, like bitcoin, a token conveys a value that is purely based on its demand. The token is nothing more than a unique quantity that is traded on a secondary token market.
Bitcoin, however, is not programmable; the tokens cannot take on any additional function except what is inherent to their structure. Early attempts to create programmability for bitcoin by inserting program data into the transaction message resulted in de facto centralization, as the programs needed to read and interpret the data were hosted on individual servers. Ethereum introduced the first token with scripting capability, allowing developers to design and implement “decentralized applications” or applications that are stored on the blockchain itself and ran using the blockchain’s operating software on the respective nodes. In exchange for running the “dapp,” the node is paid “gas” or an operation fee for the program.
These “dapps” allow users to engage into “smart contracts” or self-executing, self-enforcing contracts that does not need a third party to satisfy the terms of them. “Smart contracts” allow blockchains to engage into transactions without the need of a moderating party. In a sense, a “smart contract” can function like a virtual vending machine that can restock, deposit funds, and service itself without the need of another party. The user can make his/her purchase and take possession of the goods while knowing that no one else is or will be involved in the transaction. This means that transactions are inherently private and secure.
The potential of this has made blockchain an attractive solution for retail operations, supply chain tracking, cloud-based record-keeping and retrieval, real-time money settlement, credit management, and several other problems. Blockchain and smart contracts create a system that replaces the need for entire IT departments, placing the potential of enterprise-level databasing and real-time ledger resolution in the hands of businesses and individuals of all stripes and sizes.
All one has to do to unleash this potential is to program a ledger, a token, and a smart contract.