Blockchain basics: technology

Online commentary about blockchain and distributed ledger technology first began to proliferate a little over 10 years ago. But for many, the language and underlying concepts in this area still retain an aura of mystery. This article gives a brief account of some of the basics.

---

Before we begin, we offer two warnings.

• This is an area with a language all of its own, and the meaning of some of the terms that are used is contested. Some terms are given different meanings by different writers and others are the subject of intense, quasi-philosophical debate. We have tried to steer clear of all this—without intending by doing so to take any express or implied position in such controversies as whether “blockchain” should be preceded by “a” or “the”, or spelt with a capital “B”. We have also simplified our description of the technology and of many of the individual projects we refer to in the interests (we hope) of readability. For those who want more detail, our text provides numerous hyperlinks to more information and comment.
  
• A glance at the “White Paper” documents produced by many blockchain-based businesses reveals disclaimer language that seems to be informed by more than a lawyer’s usual caution. Everything that they say is a “forward-looking statement” based on “current beliefs”, rather than a fact; actual results may differ materially from the business’s current expectations, which should not be relied on for making financial decisions, and so on. We are lawyers rather than technologists, but our sense is that the health warnings should generally be taken at face value: many of these projects may well take longer to mature and in the first instance may well deliver slightly less than their authors appear to hope.

Distributed ledgers

The starting point is a concept whose name may not immediately sound very exciting: distributed ledger technology (DLT). At present, all sorts of quite simple transactions that are carried out in bulk require a number of different parties (e.g. buyers and sellers, and their respective banks) to keep their own records of each transaction or to verify those kept by others (e.g. by means of an audit). These records are often generated separately from whatever contractual framework governs the transactions in question, and from the systems under which they are paid for. Opportunities abound for inconsistencies to arise by accident, or for deliberate fraud to occur. In some cases, these problems are controlled (and costs added) by building systems around a central, trusted party.

The basic proposition of DLT is very simple. If all parties are operating from a shared set of records—the distributed ledger—and this is constructed in such a way as to reduce or eliminate the introduction of false entries, and does not need to be kept by a central authority, then, at the very least, transaction costs could be materially reduced. Moreover, if a DLT system were sufficiently powerful in processing terms, it could help underpin the much-anticipated “Internet of Things” (IoT) and other forms of transaction between machines. This is because one aspect of IoT is likely to be a huge increase in the number and frequency of transactions being entered into by machines with each other. In some sectors these transactions may have low individual values, but together they may account for a significant share of the market.

A distributed ledger, then, is conceived as a way of storing and transmitting data, such as records of transactions, in a way that is cheap and decentralized. In principle, this is shared among a network of participants, each of which is known as a “node,” that send and receive data to each other in such a way that each participant has an equally up-to-date and valid copy of the resulting ledger.

This brief description of DLT immediately raises a number of questions. Does every participant need access to a record of every transaction? Why do the participants trust each other and the data provided? Is the technology anything more than a glorified shared database / spreadsheet? To begin to answer these questions, we need to consider the context in which the technology has developed.

Blockchain – what’s in a name?

Blockchain is a particular version of DLT whose name is used, not strictly accurately, as a way of referring to that technology more generally. This usage partly reflects its role in supporting bitcoin (see below). It also helps that the name itself offers the non-technically-minded a reassuringly physical metaphor for conceptualizing how the underlying technology works.

Blockchain’s distributed ledger is built up of a series of “blocks.” Each block contains details of timestamped batches of validated data (typically representing a series of transactions), and “hashes” (cryptographic “digital fingerprints” or unique identifiers, in which input messages of any size are converted into outputs of a fixed size, and it is virtually impossible to determine the input from the output). The hashes link each block to those that come immediately before and after it in such a way as to prevent them from being altered, or a new block from being inserted between existing blocks. There is no way to alter an entry that has been made: it can only be reversed, and those reversals should only happen under rare circumstances. Accordingly, distributed ledgers are sometimes said to be “tamper-evident” rather than strictly “tamper-proof.”

Before a block is added to the chain, the individual data entries of which it is made up and the block itself are subject to a series of authentication and validation processes.

• Each message is protected by digital signatures: it has a private key (known only to the sender) but also a paired public key (the recipient and anyone else with access to this can verify the message).
  
• Before a transaction is submitted for inclusion in a block it is verified by the initiating node, which has selected the transaction from a pool of waiting transactions, and others in the network.
  
• The creation of the blocks themselves adds a further level of security, and secondary verification of the transactions in each block takes place before it is added to the chain.

These verification processes may take a number of different forms, but all depend on there being a consensus between participants as to the criteria to be satisfied before authentication or validation takes place. They may, for example, be based on the equivalent of a majority vote (e.g. the agreement of participants holding a certain share of total network value), or on the operation of a dispute resolution algorithm that is activated when one node generates a different output from others in the network. The key point is that, once the technology has done its work, every participant’s separate copy of the ledger will be equally valid: the ledger is “distributed” because there is no central master record.

Public / private, permissioned / permissionless: different varieties of blockchain

There are a number of variants on this basic structure. In particular, a blockchain may be “public” (open) or “private” (closed)—or possibly somewhere in between—and in either case it can be configured to be “permissioned” or “permissionless”.

• In a fully public blockchain, anybody can participate (sending and receiving data, and being involved in consensus processes), subject only to the controls imposed by the consensus mechanisms. At its most basic, the integrity of the system is guaranteed by its size and the apparent impossibility of anyone having the computing power necessary to falsify a majority of copies of the ledger. Access control rules may be applied to limit the “read” and “write” privileges of participants so as to protect commercial confidentiality. (Anonymity or participation on a pseudonymous basis may also provide some protection in this regard.) Different nodes may have different roles by virtue of the software they run—for example, in relation to bitcoin (see below), the whole group of users is a much larger class than the miners who make the blocks.

• In a fully private blockchain, the participants are likely to be either members or customers of a single organization: access is more tightly controlled and governance much less decentralized. Digital certificates and policies are used to control access. It is likely that only one organization will be able to write entries and have access to all the information in them, using a “private key,” while, for other participants, permission to read them (or parts of them) will also be restricted (e.g. to those involved in a given transaction, using a “public key”).

• Halfway between the completely public and completely private blockchains is what is sometimes called the consortium model—for example, a network might be run by a group of financial institutions that reserve to themselves the ability to write data entries (subject to, e.g., a majority-based consensus mechanism) and operate nodes (improving overall network costs and the speed of validation activities), but who allow all their customers, or any third party, to read data entries (subject to certain limitations, as in a private network).

• The terms “permissioned” and “permissionless” are sometimes used almost interchangeably with “private” and “public” and, when they are not so used, they are not always given the same meanings. One distinction that the use of these terms can draw is in relation to who can validate a transaction: for example, in a permissionless public blockchain, anyone can download the protocol to do this; in a permissioned public blockchain, a prospective validator of transactions must first meet specified criteria. In the consortium context, “permissioning” may refer to the kinds of transaction that a participant in the network is and is not permitted to initiate without reference to one of its controlling organizations.

Which is best?

Public / permissionless blockchains rely more heavily on algorithms and iterative computer processes to determine whether a transaction is validated: they are often said to be “trustless” systems because the participants are, in effect, relying on the technology rather than any knowledge about or prior contractual relationship with each other as the basis on which they “trust” each other.

It is a matter of debate which approach provides more security, and which kind of network participants prefer will depend on what they want to use the technology for. Some may find an arrangement where users know who their counterparties are inherently more secure, pointing towards permissioned or private systems. Others point out that, in a permissioned or private network, security may be more easily and seriously compromised by hacking just one participant who has all the key access rights or permissions, suggesting that public blockchains can have advantages from a security point of view. However, the anonymity of participants—or use of pseudonyms to identify them—that often feature in public blockchains, is clearly inappropriate for commercial contexts where businesses involved will often be subject to “know your customer” (KYC) requirements for regulatory purposes such as the control of money laundering. Some projects envisage combining a public blockchain for transactions with a separate administrative or “side” chain that is private or permissioned to manage, e.g., access rights.

Another question to be asked in relation to any very private blockchain project is to what extent it represents an improvement over existing computerized transaction systems built around a single organising entity. Such a blockchain could be said to lack the defining DLT feature of decentralization, and it may be thought that there are other, and perhaps better, ways of running a network that has a single, trusted organization at its center.

Equally, a public blockchain with a large number of nodes may raise questions about whether it is necessary, useful or efficient to have the same large amounts of data held in multiple places. Moreover, since most of the information concerning past transactions will be only of historical importance and will not need to be actively used, the system may be unnecessarily slowed down by the need for any new or restarted node to synchronize with the whole chain (and exchange and validate huge numbers of blocks). Such considerations may point towards the desirability of fragmenting the blockchain so that “historic” and “live” transactions are treated in different ways.

Corda — an example of a “consortium blockchain”

As compared with a fully private network, the consortium model appears to exhibit more of the benefits of using blockchain with fewer of the perceived downsides of a fully public network. Purists may be disturbed that the blockchain in such a model is not democratically controlled by all users but, for many, it may offer the best of both worlds. One of the prime examples of the consortium approach, Corda, put together by a number of banks and financial institutions and software firm R3, is instructive in this context.

In its own words, R3 was “born out of a common frustration with multiple generations of disparate legacy financial technology platforms that struggle to interoperate, causing inefficiencies, risk and spiraling costs.” However, according to R3, Corda is not merely “not Blockchain”, but not even DLT. As Corda’s FAQs explain, its transactions are not aggregated into blocks, and its ledger is said to be “shared” rather than “distributed.” At a relatively early stage in Corda’s development, its Chief Technology Officer pointed out that, on the face of it, blockchain was not well suited to the world of banking. However, its key achievement was “the emergence of platforms, shared across the Internet between mutually distrusting actors, that allow them to reach consensus about the existence and evolution of facts shared between them.” In the same article, he went on to explain what Corda takes from each of the key elements that have enabled blockchain to create such platforms.

• The “shared facts” that matter in dealings between banks are essentially financial agreements (Bank A owes $X million to Bank B, Banks X and Y are parties to a credit default swap on certain terms, and so on). Currently, the parties record details of agreements, and updates to them, on different systems, and inconsistencies arise in their records of the same agreement.

• If the parties are using the same system, the costs and difficulties that currently arise can be avoided. But only the parties to a given agreement (rather than all participants in the network) need to be able to see the system’s records of it: “the only people who need to be in agreement about a fact are the stakeholders to that fact.” Consequently, users can “write their validation logic in time-tested industry-standard tools” and Corda defines “who needs to be in agreement on a transaction’s validity on a contract-by-contract basis.”

• As with other DLTs, Corda seeks to avoid two valid but mutually incompatible transactions being active on the system at the same time, but the “traditional blockchain” approach to this is only one of a number of “uniqueness service” implementations it uses. Corda also takes a traditional blockchain approach to authenticating transactions and ensuring their immutability.

• Corda stresses that it is a system designed to deal with agreements, or what it calls “state objects governed by contract code and associated legal prose” and acknowledges that as such the system will not be able to resolve all potential disputes between participants by itself.

In short, what Corda promises is to deliver, in a form that is the best adapted to the needs of business (or more specifically financial institutions), all the things that blockchain generally promises: disintermediation and the driving out of paper / paper surrogate communications like email: the collapsing of multiple steps of transaction and settlement processes into a single process, and increased security and transparency (including to regulators, who can be given privileged access to the blockchain)—all saving costs and time and reducing risks.

Cryptocurrencies

Blockchain itself (with a capital “B”) is indelibly associated with Bitcoin (BTC), the cryptocurrency for which it provides a ledger. What is a cryptocurrency? The online Oxford English Dictionary defines it as “a digital currency in which encryption techniques are used to regulate the generation of units of currency and verify the transfer of funds, operating independently of a central bank.” (This is a very fair starting point, although it should be noted, by way of immediate qualification, that central banks could start to issue their own cryptocurrencies so as to give non-banks access to central bank “digital money,” and, in the view of some commentators, enable central banks themselves to understand their economies better and reduce systemic risks within them.)

A cryptocurrency is also a species of “virtual currency” within the meaning given to that term by the Financial Action Task Force in a report of 2014: virtual currencies, like “fiat currencies” (i.e. “real money”, such as dollars, euros or yuan) function as a medium of exchange, unit of account and store of value. However, unlike fiat currencies, they do so only by agreement within a community of users and not as a result of any action by a state. They are distinct from “e-money”, which is simply a digital representation of fiat currency that is used to transfer value electronically. To the best of our knowledge, they are not legal tender (defined as a something that automatically constitutes valid and legal offer to pay, when tendered to a creditor) in any jurisdiction.

On the other hand, some businesses will accept them as payment for goods supplied to customers. In the absence of regulation to the contrary, there is no legal reason why, as a matter of private contract, two parties should not agree that payments between them are to be made in a cryptocurrency, or why the failure of one party to make a contractually required payment should not be enforceable as a debt claim through the courts or a contractually agreed alternative dispute resolution mechanism by the other party. Existing dispute resolution mechanisms may need to be adapted to cope with cases where one party does not know the identity of the other, or one or both “parties” are machines acting in some sense autonomously, rather than as the agents of identified human / corporate contracting parties. On the other hand, a blockchain purist solution would be to leave everything to be finally decided by an algorithm on the principle that “code is law”.

Bitcoin

Bitcoin is one of many cryptocurrencies, each supported by some form of blockchain. As a medium of exchange and a store of value, they all tend to have similar advantages and disadvantages.

• Among the advantages are said to be transaction speed and low barriers to entry (although the first of these may depend to some extent on your point of comparison). In the words of the alleged, pseudonymous, creator of the bitcoin protocol, Satoshi Nakamoto, in one of the earliest (2008) expositions of how it would work, because cryptocurrencies are “based on cryptographic proof instead of trust,” they allow “any two willing parties to transact directly without the need of a third party [such as a bank]”. As a result, users are said to benefit from not incurring many of the costs and other burdens typically associated with being a customer of a bank or using a conventional payment system, or the exposure to political and macroeconomic risks associated with all fiat currencies to some extent (and with some fiat currencies to a very large extent).

• Among the disadvantages of cryptocurrencies are that some are not built to deliver fast, cost-effective payments and that they tend to undergo significant and unpredictable fluctuations in value. This volatility presents a problem for users, not least because most potential counterparties still do not accept bitcoin as a means of payment (so that they must first be converted into fiat currency — which may not be straightforward — to be economically useful). It also somewhat undermines one of the claimed advantages of cryptocurrencies over fiat currencies—although, as we will see, some have proposed to compensate for cryptocurrency volatility by creating cryptocurrencies backed with commodity values (including energy commodities) in a manner reminiscent of the historic backing of paper money with gold. A further drawback in some cryptocurrencies and token programs (on which see below) is a tendency to favor / potentially over-reward early adopters / insiders, for whom a significant proportion of the capped total amount of the currency / tokens is reserved.

• One holds bitcoin by means of an address and a key: two numbers, the second of which associates the bitcoin uniquely with its owner. Keys are kept in a “wallet,” which may be either “hot” (i.e. running on a computer linked to the Internet) or “cold” (any other method of recording the keys, including writing them out on a piece of paper). If you lose the key, you lose the bitcoin and there exists no recourse mechanism for getting it back.

Bitcoin enjoys a degree of notoriety for a number of reasons. In addition to the recent volatility of its exchange rate with fiat currencies, it appears to be well suited to, and in some cases to have been used for, facilitating illegal or morally questionable transactions. Moreover, the process of “mining” bitcoins relies on “proof of work” that takes the form of solving complex mathematical problems. By deliberate design, this is in large measure a process of trial and error. It takes a lot of computing power, and therefore also consumes large amounts of electricity. In effect, “miners” are competing to embed validated transactions into blocks and so write the distributed ledger, and they are rewarded for creating a new block in the chain by receiving a certain quantity of bitcoin (this decreases over time, but is currently 12.5 BTC, or more than US$110,000 at the time of writing (mid-June 2020)).

Estimates suggest that all bitcoin mining activity globally consumes more electricity than many countries. It has been calculated that each bitcoin transaction consumes as much energy as 200 washing machine cycles (or enough to heat a house for a month). In Canada, there has been controversy over proposals by Hydro-Quebec to limit supplies of power to bitcoin-mining customers. Since more than half of all bitcoin mining is done in China, where coal is the dominant fuel for electricity generation, there are legitimate concerns about the environmental, as well as economic, impacts of cryptocurrency mining activities.

Although the bitcoin system is meant to be a world without banks and the transaction costs that come from dealing with them, the reality is not so straightforward. Since the mining process is competitive, users pay fees to get their transactions processed and those fees will typically be higher if the user wants the transaction to be processed more quickly. Like the value of bitcoin, the level of fees charged by miners fluctuates over time — although, in principle, competition among miners should exert a downward pressure on fees.

Moreover, in comparison with other payment systems, bitcoin works quite slowly. The “average confirmation time,” which varies with market conditions, appears never to have been less than five minutes, to be frequently more than 20 minutes, and on a number of occasions to have been several hours (see graph). Taking another measure of transaction speed, it appears that PayPal can process more than 10 times as many transactions per second, and Visa several hundred times more. However, research by the European Central Bank and the Bank of Japan has found that DLT-based solutions could at least meet the performance needs of a Real-Time Gross Settlement system, and blockchain-based platforms such as Stellar, whose currency is the Lumen (XLM) have already improved dramatically on the transaction speeds of bitcoin.

Finally, although bitcoin exchanges solve some of the problems of securing one’s own bitcoin wallet, they are often not regulated or insured and, while blockchain itself may so far have proved unhackable, bitcoin exchanges have not: at least two of them (Mt Gox and Coincheck) have suffered significant and costly hacking attacks. Customers are used to having recourse through their banks, the traditional payment systems, or an Ombudsman: a true “buyer beware,” “code is law” based system is daunting and likely to have limited appeal to many consumers, or commercial participants, outside the ranks of “true believers” in code. The potential adverse consequences of a strict “code is law” approach are illustrated by the failure to take corrective action in the case of the DAO hack.

ICOs and tokens

Cryptocurrency is a large subject in its own right, and the debates around it are becoming, if anything, more complex, fueled in part by the increase in volume of initial coin offerings (ICOs). ICOs are an (often) unregulated hybrid of IPO and crowdfunding that are associated with the launch of new blockchain-based ventures that are known as dapps (pronounced “de-apps”) provided that they meet certain formal criteria. ICOs are increasingly favored by tech startups, who use them to allocate “tokens” to investors (hence also “initial token offerings” or ITOs), usually in exchange for cryptocurrency rather than fiat currency. Holders of the tokens are then eligible to exercise rights and/or receive rewards that relate to the underlying product or service that the business is promoting (making the token in effect a kind of “smart contract” — on which see further below).

The precise definition of these rights may give them characteristics more or less similar to those of a conventionally issued debt or equity security. However, owning a token tends to carry risks similar to those associated with holding a conventional equity share but without conferring any comparable right to participate in the governance or, in many cases, the profits of the company. And compared with issues of debt security in conventional capital markets, or non-blockchain crowdfunding platforms, many token programs have a less robust legal base and a higher level of commercial risk.

For some participants, these drawbacks may not matter. Some businesses reserve a significant proportion of tokens for a privileged group of individuals, such as founders and other employees, who do not have to pay for them. And early investors in some cryptocurrencies have made such spectacular “virtual” gains that their attitude to investing amounts of those currencies may be rather different from how they might approach an investment of a comparable value of fiat currency. If you bought 10 BTC when they were worth a few US$ each and they are now worth several thousand US$ each, but you find it hard to sell them, either for practical or for emotional reasons (the value may rise still higher), using one or two of them to buy tokens in a promising ICO is likely to be psychologically much easier than investing the currently equivalent amount of fiat currency in that ICO.

We will look further at cryptocurrencies and tokens in connection with specific energy sector examples later in this volume. For the moment, however, it is enough to note two points. First, the potential drawbacks of cryptocurrencies are in a sense a consequence and another aspect of the downsides of public blockchain. Second, there is nothing inevitable about the linkage between distributed or shared ledgers and cryptocurrencies. There is no need to integrate payment processing into a blockchain whose primary purpose is simply to communicate data or synchronize records: payment can be handled separately, without blockchain participant accounts becoming accounting units. Moreover, at least for transactions that take place in private or consortium model networks, if the participants would prefer to use fiat currencies, they can: they will just need to make the usual, separate arrangements for payments to be sent and received.

Hot topics

Blockchain and cryptocurrencies are a constantly evolving field. The more uses are proposed for these technologies that go beyond the original role of blockchain as the infrastructure supporting bitcoin, the more the vision of entrepreneurs runs ahead of what the technologies can currently deliver. For a frank summary assessment of some quite fundamental areas that remain under-explored, see the R3 December 2017 report, Top Ten Obstacles Along Distributed Ledgers’ Path to Adoption. The author’s open-minded approach can be seen from the contents page: “10. Usability: Why use distributed ledgers? 9. Governance: Who makes the rules? 8. Meaningful comparisons: Which is better? 7. Key management: How to transact? 6. Agility: Which algorithms do we use? 5. Interoperability: How to talk to each other? [There are a number of R3 papers on this, including one with the title The Myth of Easy Interoperability. With a nod to The Lord of the Rings, this issue is sometimes referred to as the problem of whether there can or should be “one blockchain to rule them all”.] 4. Scalability: Why store every transaction? 3. Cost-effectiveness: What is the cheapest way? 2. Privacy: How to protect data? 1. Scalability: Do we need full agreement?”

It is worth noting, however, that the above list of “obstacles” is one prepared from a blockchain developer’s point of view. A useful point of comparison is the list of “hurdles to adoption” in a February 2016 paper by Euroclear and Oliver Wyman, Blockchain in Capital Markets: The Prize and the Journey. Although scalability features on both lists, the latter reflects the kind of issues that potential users of blockchain, particularly those operating in regulated industries, will need to see addressed further before adopting the technology: “regulation and legislation: fitness for purpose”; “the need for a robust cash ledger”; “common standards and governance”; and “operational risks of transition; managing anonymity”.

A further illustration of the developing state of the technology is Direct Acyclic Graph (DAG) networks, also known as Tangle. One feature of the classic blockchain / bitcoin system is that only one block can be created at a time, and each block contains a number of transactions which are likely to have no connection with each other except having been generated at about the same time. DAG / Tangle offers an alternative approach. This was first exploited simply as a development of the idea of “side chains” that allow different kinds of transactions to be created on different chains simultaneously, but a number of projects now envisage taking it further to provide a “blockchain without the blocks”—and without the miners and the somewhat slow transaction processing speeds of classic blockchain.

These features have led to claims that DAG / Tangle has the potential— which classic blockchain currently appears to lack—to cope with the huge number of small value transactions that would be unleashed once the IoT takes off. Consequently, among DAG / Tangle-related ventures one finds names like IOTA and IoT Chain. A number of authors have identified DAG / Tangle as “Blockchain 3.0”—on the basis that the improvements in blockchain associated with Ethereum, such as sharding (which involves splitting the blockchain in various ways) can be seen as “Blockchain 2.0”. Needless to say, there is no shortage of other competitors presenting themselves as “Blockchain 3.0” or speculation as to what “Blockchain 4.0” might consist of.

Suggestions for further reading

There is a huge amount of online and e-book writing about blockchain—and a few titles are also available in old-fashioned paper-based form as well.

Readers looking for a more nuanced and detailed account of many of the topics touched on in this article, further background, and some consideration of security issues and the wider economic significance of the technologies concerned, may find useful two reports by analysts at Credit Suisse, The Trust Disrupter (August 2016) and Blockchain 2.0 (January 2018). The risks and opportunities for systems using blockchain and smart contracts are explored in a very balanced report of the same name published by Data 61 (CSIRO) in Australia.

Finally, if you either find yourself becoming obsessed by blockchain and wondering if there is no commercial problem it cannot solve, or have already formed the view that it all sounds too good to be true, but can’t quite put your finger on why, you may wish to test your faith or feed your prejudices, as the case may be, by turning to David Gerard’s entertaining and well-researched July 2017 book, Attack of the 50 Foot Blockchain for a bracing dose of skepticism about all things blockchain.