Understanding Blockchains (and Bitcoin) – Part 1: Concepts

It is the rare person these days who has not heard of blockchains, if only vaguely and very likely in connection with its implementation in that sensational crypto-currency Bitcoin.  While Bitcoin has been around since 2009, its recent valuations and the speculative market around it have motivated many to try and better understand its inner workings and possibly mimic those to create alternative crypto-currencies. Having missed the Bitcoin boat, entrepreneurs and speculators hope they can get an early start on the next big thing.

The Bitcoin market momentum has led, in recent years, to a great deal of interest in the underlying technology – the distributed ledger called a blockchain, and the eco-system of peer entities that verify, maintain and grow it. Leading companies from different industries as diverse as banking, entertainment, transportation, education, government and many others have started to find in blockchains something that they can use to improve operational efficiency while cutting intermediary costs.

Recent news on the use of blockchains in the medical domain have caught our attention. We suspect many readers of the LuxSci FYI blog have also had their interest similarly piqued. However, such news items are almost always high level and offer very little insight into what is actually being done. To probe further requires understanding something about blockchains through its recent manifestations, particularly the version used in a system called Ethereum. (Ethereum, as we shall see in a later post, is an advance over the Bitcoin ecosystem, borrowing many of its architectural principles while expanding on the usage scenarios.)

To help our readers make sense of such news, particularly those related to the use of blockchain technology in a medical setting, we are providing a multi-part series of blog posts describing the blockchain, using examples of crypto-currencies such as Bitcoin and Ethereum to illustrate how it maintains an immutable record of the states of a system over time, and how new applications can be built on top of such systems.

At the end of this series of posts, having exposed the basic technical foundation, we will describe how blockchains are being used in various industry scenarios, especially medical ones as well as related areas such as identity management, auditable record keeping and data sharing. We hope that after reading these posts, our readers will be able to make better sense of news articles of the sort we referred to earlier.

This first post will describe the concepts behind a blockchain, using Bitcoin as the example. We will explain at a conceptual level, avoiding detailed technical descriptions in this post unless absolutely essential. The next post will fill in all the technical details.

What is a blockchain?

The easiest way to get started with this subject is to take some familiar concepts and see how blockchains differ from these. Almost all descriptions of a blockchain use some variant of the following words: a decentralized ledger maintained in a peer-to-peer network and providing immutability of the records against malicious actions or untrusted peers. Let’s pick apart these words and expose what is meant by each term – ledger, decentralized, peer-to-peer and immutability.

Ledgers

A ledger is a familiar concept from finance: a record of who owns what assets, and transactions related to these assets – the amount and nature of the assets transferred from one party to another. (Every industry has its own concept of a ledger, recording facts of interest to that domain. A ledger for a medical practice might contain records of patient visits, the attending doctor, the treatments received, payments made, and so forth.) It all cases, some trusted party owns and maintains the ledger and ensures that entries are authorized, verifiable, accurate and cannot be changed retrospectively. You can record your checking account deposits and payments in a book, but the bank keeps the definitive state of your balances and transactions at all times.

Technically, one can think of a ledger as a distributed relational database maintained at a central site (likely replicated at several for resilience) under the control of some trusted authority whose view on the state of that database is considered the definitive one.

Similarly, a blockchain is also a ledger, with its own format for recording the items of interest in the domain in where it operates. Bitcoin’s blockchain, for example, is a set of ever-expanding record of transactions, each noting the transfer of a particular group of bitcoins from one account to another. (There’s a bit more to it than that, of course, as we shall explain later, owing to the peculiar properties of this asset which makes it different from normal currency – the need to provide proof that the sender is indeed the owner of the bitcoins, and the conditions that the receiver must meet to spend it in a future transaction.)

Open

Unlike the bank’s ledger, though, the Bitcoin blockchain is open (accessible to anyone with the appropriate software) and transactions can be viewed (without any credentials) by anyone and added by anyone (assuming that the transaction is valid, of course, and certain processing steps taken; but more on how that’s done later). Its software is open sourced and freely downloadable.

Bitcoin’s ledger is what is now called permission-less, meaning that you do not need any special rights to be able to access and use it. Ethereum is another example of a permission-less blockchain. This is in contrast to the use of blockchains in other industry verticals, who have borrowed the underlying concepts but created their private blockchains for access by and use within a walled garden of known participants. Such blockchains are called permissioned blockchains. For example, the Hyperledger is an open source project that allows different industries to create private blockchains for their specific needs. Many of the key aspects that make up blockchains (i.e., the protocol mechanisms) remain hidden in such private implementations. Also, such blockchains are simpler as aspects related to maintaining anonymity or circumventing bad behavior amongst participants are not needed or greatly reduced.

Thus, each of these types of blockchains place a different emphasis on those aspects it considers the most critical, which in turn has a major effect on its design:

• A permission-less blockchain, such as Bitcoin that is open to all, values transparency of records and record-keeping, while ensuring the anonymity of the ownership;
• A permissioned blockchain, with known, invited participants subject to internal rules of engagement, values the efficiency of updates to records and overall transaction-handling throughput over anonymity and transparency.

For both, however, a decentralized ledger and resistance to forgery or tampering of the records are common goals.

In what follows, we will describe permission-less blockchains (and not preface it with that adjective when so doing) as this offers the fullest insights into the technology and its uses, both current and in the future.

Decentralized, and peer-to-peer

Ledgers (or databases) are maintained by certain parties, e.g., banks, insurance companies, etc., trusted within their domain of authority who ensure security of access and appropriate authorizations to make changes. Sometimes such ledgers might be replicated at several sites for physical resilience to breakdowns and attacks, but the data in each replica is always consistent with those in the others. If a replica is down, it can always download the latest version from any of its peers when back in service. This is because the replicas form a trusted, interconnected system, where consistency of the data is feasible as the number of replicas is small.

A blockchain-based ledger is also replicated at every node in the system, and these nodes could run into the thousands! One estimate is that there are ~11000 Bitcoin nodes that run the full Bitcoin protocol; but, whatever the number, each such node maintains the entire blockchain – which is the definitive ledger of all Bitcoin transactions since the first one was minted in 2009!  (There are also other simpler nodes in the system. We’ll provide details on the types of nodes and what each does in the next post.)

It is an extraordinarily difficult task to keep thousands of nodes in a consistent state, and the magic behind Bitcoin and public blockchains is how such consistency is achieved. This is particularly hard in an open system, where nodes come and go, no party is known to the other and no one trusts another. This mechanism by which nodes in an untrusted network achieve consensus on the state of a system – in this case, the decentralized ledger known as the blockchain – will be described briefly below, and more fully in our next post.

One other aspect that goes closely with decentralization is peer-to-peer networking. In such a system, no node is the superior of the other. This contrasts with the typical client-server architecture used by most enterprise applications, where clients access and manipulate logic and data held at a server. In a Bitcoin network, each node can potentially do everything the others can. (Whether they choose to do so or have the capability to do so in a timely manner is another matter.) Each node is connected to a number of its peers, and any message sent from one to its neighbors is broadcast by them to other peers these are connected to. Thus, assuming reasonable communications links, any information can be expected to have reached the farthest extremities of the network in a short time. A new Bitcoin node can (depending on the bandwidth of its connections) download the entire blockchain in bits and pieces from its peers, which it then reconstructs.

Immutability – or the chain in blockchain

If what we have described thus far is indeed a ledger, albeit with some fancy properties, why is it called a blockchain? Is it a chain of blocks? And, if so, what’s a block?

Transactions in Bitcoin denote the transfer of a certain number of bitcoins from one address to another. To make such a transfer, the transferrer has to provide the proof that it is indeed the legitimate possessor of the bitcoins in question. This is a cryptographic proof that anyone in the system can verify (remember that all transactions are open to inspection). In turn, it lays out the conditions that the receiver of the bitcoins must meet to spend those received bitcoins in a subsequent transaction. A functional view of a transaction looks like this:

In Bitcoin, proving that the amount is yours to spend means providing a signature on the transaction that can be verified as belonging to you. Setting and verifying this signature uses the well-known private/public key algorithm, and we’ll describe in our next post the details of how such keys are created and used without a central authority such as a Certificate Authority to vouch for them.

In the simplest use in Bitcoin, the rules for spending the received amount is essentially the same as that when proving that you own it. However, these rules can be made more complex in a limited way in Bitcoin through writing scripts that must be followed, such as requiring two signatures for spending. Ethereum allows for more complex scripts which can have all the nuances expressible by programming languages. That’s why many consider Ethereum as the vehicle for managing and acting on complex contracts written into its blockchain, and not merely a ledger recording crypto-currency transfers.

As bitcoins are exchanged, transactions are broadcast through the Bitcoin network. Nodes verify that the transactions are valid by checking the various conditions set therein. A node (that is willing and has the necessary computing power) collects all new and valid transactions into a group called a block, and attempts to solve a certain cryptographic puzzle on the block. This process is called mining, and the node is a miner. (This choice of name will become clearer as a bit further on.)

At any time, nodes are aware, through the peer-to-peer mechanism we mentioned earlier, of which is the latest valid block in the system. They can compute a fingerprint of that block, by computing its hash. You may remember that a hash function is a cryptographic one-way function that is almost impossible to reverse. Thus, by taking a block of transactions as an input to the hash function, the output is a small alphanumeric value that is unique. The figure below shows a hash computed for the last valid block in the system. For reasons that follow, the fingerprint of the last valid (“mined”) block includes the fingerprint of its predecessor “mined” block, as shown in pink below.

The cryptographic puzzle referred to in the previous paragraph is to find an input number (called a “nonce”) which, together with the new set of transactions and the fingerprint of the last accepted and valid block, hashes into a result which starts with a specific number of zeroes.

Creating a hash is easy, but achieving a hash with a certain number of leading zeroes is what leads to the difficulty of the puzzle, and hence its computational burden. Thus, this technically simple puzzle consumes time and computational power (which translates into real energy) as the nonce is repeatedly varied and the output checked. At this time, the Bitcoin system has been tuned so that it takes almost ten minutes to “solve” this puzzle for a block containing somewhere between 1000 to 2200 transactions.

Once the puzzle is solved by a node, it announces this to the peer-to-peer Bitcoin network. All other nodes working on “mining” their current block and puzzle abandon their efforts, verify the answer to the puzzle for the received block, and resume gathering up transactions into new, to-be-validated blocks and start the process again.

To motivate nodes to gather new transactions into blocks and solve this puzzle so that new blocks may be added to the blockchain, such winning nodes are paid with newly minted bitcoins. Such nodes are called “miners”, as they mine for their reward in bitcoins. At current bitcoin valuation, this is a non-trivial sum, although a portion of it is taken up with the purchase and maintenance of ever-expanding computing equipment and electricity costs (for running and cooling these).

The new block, after validation, is appended by each node to the end of the set of previously accepted blocks. As each new block is cryptographically bound to the last one through its fingerprint, we have a sequence of blocks chained to each other – hence blockchain, an ever-expanding set of blocks of valid transactions since the start of Bitcoin. The blockchain conceptually looks like this (with the end of the chain at the right-most block):

The immutability of transactions, that is the inability of a malicious actor to change a previous transaction which forms the basis for any trusted ledger, is assured through the computational effort needed to create valid blocks as well as this chaining technique of tying every newly mined and validated block to its predecessor in the blockchain.

To change a previous transaction already ensconced within a block, the perpetrator would have to redo the cryptographic puzzles for all the blocks going forward from that point onwards so as to have a valid chain that is at least as long as the currently accepted one. This requires an extraordinary amount of computational power and would also raise concerns from honest nodes which might question a new, long chain without any antecedents. In a sense, the financial motivation of honest nodes to try and obtain new bitcoins through regular “mining” ensures that they cooperate to ensure that the system is not corrupted by individual rogue behavior. (In our next post, we’ll touch on opportunities for misbehavior and how these are mitigated.)

Summary

Let us collect together some essential points raised in the previous sections to illustrate the essential properties of public blockchains, used by crypto-currencies such as Bitcoin and Ethereum.

• For a variety of reasons, there is a need to create a system where a ledger of transactions is maintained in an open manner, without reliance on any specific party. In such a system, transactions occur directly between the parties concerned, and a record of it is made in a public decentralized ledger.
• In addition to an open ledger, an open system that does not rely on third parties for communications (e.g., telcos, ISPs, etc.) between the participants needs a peer-to-peer architecture overlaid on the internet. Peer-to-peer protocols ensure that all members of the network reach the same state of the ledger within a reasonable time.
• As none of the parties in an open system have any prior knowledge of or relationship to each other, trust has to arise from within the workings of the system itself rather than through reliance on outside party (e.g., a bank, the government, etc.) to broker it.
• Transactions are individually validated using various cryptographic techniques to ensure that the parties taking part in it have the appropriate rights and credentials to do so.
• The ledger created by a blockchain is a series of records or transactions bound together into blocks, with each validated block cryptographically linked to the previous one. This cryptographic chain ensures that prior transactions cannot easily be reverted, so that, in effect, the ledger is immutable.
• The task of creating valid blocks and a chain of blocks is time and energy intensive, which prevents a malicious user from illicit acts. Any changes to the consensus chain of blocks would require enormous amounts of resources, which, together with the need to convince all peers of its validity makes it hard, if not impossible to achieve.

In our next post, with the concepts having been laid out here, we’ll dive into these points at a more technical level.

Have a question?  Ask Erik