WEF releases framework to assist business decisions regarding blockchain adoption
The World Economic Forum (WEF) has released a white paper, presenting a practical framework designed to assist executives in understanding whether blockchain or distributed ledger technology (DLT) is an appropriate and helpful tool for their business needs.
The toolkit is based on real-world experience of blockchain in a variety of projects across a variety of industries that have been analysed by Imperial College London to develop an initial framework. The framework has been reviewed and further developed by members of the 2017 World Economic Forum’s Global Future Council on Blockchain and has been trialled through a variety of means, including with global chief executive officers (CEOs) at the World Economic Forum Annual Meeting 2018 in Davos-Klosters.
Over the coming months, the World Economic Forum’s Center for the Fourth Industrial Revolution, in partnership with various institutions, plans to release customised versions of this toolkit focused on specific sectors and use cases.
The report emphasizes the importance of not being swayed by the hype surrounding blockchain and notes that the decision that the decision whether to adopt blockchain is not merely a technological decision, it is also a business decision. Good use cases would solve real problems for organisations, while great use cases solve real problems at a cost that is significantly lower than the benefits.
The document classifies DLT systems into three major categories: permissionless, public systems; private, permissioned systems; and hybrid systems.
Permissionless, public, shared systems allow anyone to join the network, to write to the network and to read the transactions from those networks. These systems have no single owner and everyone on the network has an identical copy of the “ledger”. The most common examples are cryptocurrencies, like bitcoin and ethereum. To counter malicious actors these systems add an extra component such as proof of work, proof of stake or proof of authority. Proof of work is computationally expensive, uses a significant amount of electricity, does not scale well and requires large numbers of network participants to be able to generate “trust”. However, the approach allows large numbers of participants to collaborate based on the codes only in a decentralised manner.
Permissioned, public, shared systems are a form of hybrid system that provide for situations where whitelisted access is required but all the transactions should be publicly viewable. Government applications are an example, where only certain people should be able to write to the network but all transactions can be publicly verified.
Permissioned, private, shared systems are those that have whitelisted access. In these systems, people with permission can read or write to such systems. They may have one or many owners. Often consortia are formed to manage the ownership.
The toolkit presents a decision tree with the following sequence questions to decide whether blockchain is an appropriate technology solution and what form of blockchain would be best-suited to solve the problem on hand.
A. Are you trying to remove intermediaries or brokers?
The organisation needs to answer questions such as would it be cheaper to collaborate directly with suppliers/competitors rather than use a clearing house? An example is the banking industry using a solution such as CORDA to manage remittances between, allowing them to deliver services faster, securely and more cheaply than with existing technologies.
B. Are you working with digital assets (versus physical assets)?
Blockchain needs “digitally native” assets, that can be successfully represented in a digital format. If an asset has a physical representation that can change form, then it is difficult to effectively manage that asset on a blockchain. An example would be tracking and tracing food production on a blockchain. If a company wishes to track and trace wheat across the entire supply chain as it becomes bread, it is difficult to use blockchain to manage its transition from wheat, to flour, to bread.
C. Can you create a permanent authoritative record of the digital asset in question?
The toolkit highlights this as perhaps the most critical question, since a blockchain needs to be the source of trust. If there are multiple sources of trust regarding the state of an object, then the object cannot be effectively stored on the blockchain.
IF a permanent record can be created, it is important for all parties with the responsibility for the state of the digital asset in question to agree how that state will be handled/managed in the new business process prior to any development occurring.
A second and separate question is whether a permanent record is desirable or now? For instance, blockchain would not be an appropriate solution where there is a need to delete information.
D. Do you require high performance, rapid transactions?
If the business process needs transactions to be completed in milliseconds, blockchains are unable to handle this effectively yet. As of now, it would be advisable to work with either existing technologies or wait until blockchains can handle such transaction speeds. The document notes that as of April 2018, various forms of DLT carry between a two- and 10-minute processing time.
E. Do you intend to store large amounts of non-transactional data as part of your solution?
According to the toolkit, it is currently not advisable to store non-transactional data on a blockchain. If, however, the trust in question is related to transaction records, rather than the underlying data itself, then a blockchain may be applicable. Any private information or any data that may be covered by local and global data-protection regulations, such as the European Union’s GDPR (General Data Protection Regulations), should not be stored on the blockchain.
F. Do you want/need to rely on a trusted party?
If an industry requires the use of intermediaries or trusted partners, for compliance or liability reasons, then deploying blockchain might be complicated, even if there are other benefits of use. In heavily regulated sectors, it may be necessary to include regulators in the project and deliver means by which the regulators can ensure compliance with laws, such as antitrust and environmental law. It is also possible that each regulator requires visibility into a different aspect of the transaction data, and the issuer does not seek to display the entirety of the transaction data to any one regulator for legal or other reasons.
G. Are you managing contractual relationships or value exchange?
The toolkit highlights that a blockchain looks at managing transactions around digital assets. If a business problem is not really about managing contractual relationships and value exchange, then a different technology could probably solve that problem more effectively.
H. Do you require shared write access?
If there is no need for some/all of the members of the network to have the ability to write transactions, then another technology will probably provide a better solution.
I. Do contributors know and trust each other?
If the actors/entities already know one another and trust one another, there is probably no need for blockchain. But if they do not know or trust one another and/or have misaligned interests, there may be a good reason to use blockchain.
J. Do you need to be able to control functionality?
If the ability to change the functionality on a blockchain (e.g., node distribution, permissioning, engagement rules, etc.) without having a detailed discussion across the large open-source forums for blockchain is desirable, then a private, permissioned blockchain might be the correct choice.
K. Should transactions be public?
If transactions need to be kept private, then a private, permissioned blockchain would be appropriate. If not, then a public, permissionless blockchain may be used.
The document goes on to provide a walkthrough for a few use cases. For example, a company with software that produces special effects for movies and is used by more than 7 million game developers and industrial designers, faced the challenge of providing large-scale graphics processing units (GPUs) to render customer projects. The major centralised cloud providers have not been able to provide sufficient capacity. The chronic GPU shortage and lack of economies of scale make GPU cloud rendering unaffordable for the majority of users. Here a public, permissionless ledger could allow distributed GPUs to be shared across the globe, reducing costs, reducing waste from underutilized GPUs and creating an efficient use of distributed computational power.