Ideas & Updates

Distributed Ledgers: Looking Past the Hype

© © Better Than Cash Alliance

Blockchain Series: Blog 2

May 15, 2019

Distributed Ledger Technology (DLT), often referred to as blockchain, has garnered a lot of attention in the past few years. Is it just “a solution in search of a problem” or, does it offer answers for real-world policy questions such digital identity and remittances? This six-blog series, by Rodrigo Mejia Ricart and Camilo Tellez, aims to foster a better understanding of the technology. The first three blogs discuss what is DLT, the debate around key stated benefits and the evidence around different use cases. The last three blogs discuss DLT for digital identity, supply chain and remittances in detail.

The benefits of distributed ledgers have become a hot topic of discussion and debate in the technology and payments arenas. Proponents argue that they are transparent, faster, cheaper and more secure than other systems. While all these assertions may have some truth in principle (depending on the use case), a deeper dive reveals a set of more complicated issues and qualifications and, in some cases, issues of legality. Distributed ledgers may run on very different protocols, or rules. Different governance ultimately means that these ledgers have very different characteristics and ways of operating. In addition to this, some of the advantages of distributed ledgers at the same time present disadvantages. Below we unpack a few key questions.

Large © © WFP

Are distributed ledgers transparent?

In principle, yes, but not necessarily. The first known blockchain application, bitcoin, was intentionally designed so that all participants could verify and validate transactions, while personal information remained private. However, this isn’t a universal trait of all distributed ledgers. Transparency is not in fact, built in by default in all digital systems. Transparency is best achieved when it is defined and designed for in any given application. Information can be encrypted or simply not shared with relevant stakeholders. A number of private, permissioned DLTs do not share whole copies of the ledger with all members of the network. For instance, the Bank of Canada’s Project Jasper used a solution for interbank payments (as a proof of concept) in which transaction data was visible only to the parties involved in the transaction. In this model, the notary[1] alone had a consolidated view of the ledger. In other cases of permissioned distributed ledgers, participants might simply store encrypted information to support the resilience of the ledger, but not be able to decrypt the whole ledger. An important part of the work that lies ahead as the world becomes increasingly digital in its interactions is carefully examining the values and objectives that are, or should be, embedded into deployed technologies.

There is preliminary research suggesting that illicit flows in terms of money laundering and financing of terrorism on the bitcoin network tend be much more limited than many imagine them to be (less than 1% of all exchanges’ transactions). However, some digital currencies have been intentionally designed to recreate the anonymity of cash, making them a medium of choice for money laundering, financing of terrorism and dark web marketplaces such as Zcash and Monero. These are clearly illegal and inappropriate uses of the technology.

In other cases, very sensitive information has been stored in a public ledger, giving rise to severe violations of privacy. The most commonly used protocols make it extremely hard to correct these situations due to the near impossibility of changing or editing the ledger once data in it has been stored (i.e., the ledger’s characteristic of immutability).

As a consequence, ledgers are most effective when their design is informed by a clear idea of which information needs to be transparent and which doesn’t. This requires particular attention to data governance and architecture. Given the potential rigidities that DLTs introduce in a system, such as ledgers that can be extremely hard to change, DLT-based solutions and their users are well-served by a clear, upfront definition of transparency and careful testing to avoid unintended consequences.

Are distributed ledgers more efficient?

Potentially but not necessarily. Most DLT-based solutions claim to be faster and cheaper than centralized systems. These efficiency gains are most often expected to come from disintermediation (that is, central authorities are no longer needed to perform a coordinating role) and savings in reconciliation (that is, the need to reconcile balance sheets kept by two different institutions). However, these benefits depend on how costs are assessed, and are also highly dependent on the use case.

To validate transactions without a central authority or trusted third party, permissionless distributed ledgers need a consensus mechanism. Bitcoin’s consensus mechanism (known as “proof of work”) requires massive computational power. At its current scale, bitcoin annually uses almost as much energy as Portugal. By the same estimate, a single bitcoin transaction consumes enough energy to power 15 U.S. households for an entire day. Clearly both the financial and environmental costs of bitcoin’s energy use present significant challenges and if these costs were priced, it would more accurately reflect product’s true efficiency.

4,288 kilometers One single bitcoin transaction produces as much CO2 as running a new car for 4,288 kilometers.

Bitcoin mining—that is, the process by which transactions are validated and bitcoins are created—is concentrated in regions with cheap and often coal-based energy production, such as China, thus increasing the environmental footprint of the bitcoin network. It has been estimated that bitcoin’s carbon footprint per transaction is as high as 506 kg of CO2 (accessed in June 2018). For reference, the average emissions of a new car in 2017 is 0.118 kg of CO2 per kilometer. This means that one single bitcoin transaction produces as much CO2 as running a new car for 4,288 kilometers.

The computational requirements of the consensus mechanism also limit the system’s ability to process transactions to around 6 per second (compared with 193 for PayPal and 24,000 for the Visa network). These characteristics significantly constrain bitcoin’s scalability and make it a highly inefficient system, even if the cost is to a significant extent not borne by those participating in a transaction.

However, this is not true for all DLT solutions. Ethereum, a blockchain-based platform supporting the development of new applications, uses a proof-of-stake consensus mechanism that does not have the same energy requirements and is able to process 20 transactions per second. XRP, a digital asset used in some of Ripple’s products, uses another consensus mechanism that is much more efficient in its energy consumption, is able to process 1,500 transactions per second and can be scaled up to handle as many transactions as Visa.

It is also important to consider that efficiency in solving problems is not the only reason for the existence of an institution. In many instances, efficiency is not even a primary consideration, but rather is secondary to other factors such as accountability, coordination capacity, legitimacy in the eyes of constituents and stakeholders, and flexibility to changing social conditions and evolving policy aims. Entrusting funds to a financial institution, for instance, creates liabilities for that institutions. Of course, legal or other redress is usually available against financial institutions in the case of a system malfunctions, and policymakers often require system adjustments in order to comply with legal and regulatory frameworks that protect consumers. By contrast, the absence of a central authority in DLT solutions raises several questions in how these factors would be addressed or managed.

Designing an effective distributed system that can adjust to changing conditions requires building in governance mechanisms that allow protocols to be updated in ways that are transparent and easy for users to understand. It is also important that such mechanisms are perceived as fair and not disproportionately or unjustifiably beneficial to certain groups, for example those who hold the most currency or have been using the system the longest.

Are distributed ledgers more secure?

In principle, yes, but not necessarily. The idea of a tamper-proof, immutable registry has tended to promote the misconception that distributed ledgers are not vulnerable to security risks. While it is true that there is no known example of a public, permissionless DLT that has been successfully tampered with, it is important to remember that a DLT is always connected to other systems that are not part of the ledger, such as digital wallets, bank accounts, currency exchanges or others. Indeed, there are very well-known cases of hacks and large-scale thefts through exchanges and digital wallets.

$145 million worth of bitcoin and other digital assets were lost after the death of a crypto exchange CEO

Not only are all these adjacent systems vulnerable to hackers, but in certain cases private keys are designed such that if they are lost, the user has no assurance and often no means at all of accessing their funds. In the case of bitcoin in particular, the loss of the private keys will permanently prevent the user from accessing their account and funds. The implications of this flaw can be dramatic. Recently, the death of a cryptocurrency exchange CEO left over 100,000 customers without access to nearly $145 million of bitcoin and other digital assets they own. Further, most distributed ledgers used for payments currently lack any method of user recourse, despite the inevitability of human error. This has tended to undermine the actual and perceived security of DLT.

An important reason DLTs tend to be secure is that their data is distributed, encrypted and synchronized. Concretely, this means that they lack what is known as a single point of failure, as is characteristic in centralized systems. In a centralized system, hacking one computer would allow you to change the content of a database. However, this security element, the absence of a single point of failure, may be hindered in the case of permissioned ledgers. Permissioned distributed ledgers have one or a limited number of notaries—that is, participants in the network that have particular powers. Questions remain about what happens if a notary is hacked. Private and permissioned blockchains are also substantially more vulnerable to collusion among participants.

None of these above challenges and vulnerabilities, however, invalidates the potential of distributed ledgers. For most of these challenges, there are no known technical impediments for improvement and innovation. Enhanced practices in terms of data governance can be expected to emerge, along with enhanced consensus mechanisms that allow for greater scalability and faster processing of transactions. Many startups are focused on finding algorithmic solutions to the consensus mechanism scalability challenge. Similarly, there is nothing to prevent distributed ledgers from adopting protocols that allow for user redress and ensure that users can regain access to their accounts, in the event of malfunction, malfeasance or user error.

What these challenges do reveal, however, is that the benefits of technologies should be closely examined and should not be considered in isolation from costs and associated vulnerabilities. Ultimately, DLTs viability depends on the use case being pursued. The best systems are designed to meet users’ needs and with a clear definition of the technical requirements needed to solve a specific problem. The points raised above also illustrate how DLT is still a maturing technology. As a result, the technology is still striving to achieve the specialization required to meet the specific needs of different use cases. For most use cases, issues such as scalability, sustainability, efficiency, governance and effectiveness are yet to be proved.

[1]: The party granting permissions within a permissioned network.