While blockchain holds tremendous potential for creating new financial, supply chain and digital identity systems, it’s often erroneously seen as a panacea for business problems.
The myriad of pilots and proofs of concept by large corporations and government agencies are showing real promise, but those projects don’t always lead to obvious business cases that justify doing something differently. Sometimes a tried and true technology like a relational database can perform the task much more efficiently than a distributed ledger based on peer-to-peer technology that will require complex governance and rules.
For example, a blockchain that offers full visibility across an entire value chain may make a ton of sense, but when you weigh the costs for setting up that ecosystem and building out that blockchain, it may not make fiscal sense.
“Who is going to pay for it, and how will the benefits that make so much intuitive sense accrue to the participants? If the costs are shared, are they shared by outcomes? By return on investment? These are knotty issues that often get bigger as pilots move to production,” said James Wester, research director for IDC Worldwide Blockchain Strategies. “In other words, the pilot proved the concept works, but at scale, the costs and considerations become much bigger.”
Part of problem has to do with the way blockchain projects have been funded. Pilots and PoCs tend to come from innovation or R&D budgets, but once they go to production, the costs have to hit a business unit or company. And when blockchains involve partner companies working together on an open ledger, the partners must agree on complex rules and how the project is funded.
“Without a compelling business case, those costs may be less attractive. And given the distributed nature of blockchain, if one party decides not to participate, the whole thing can fall apart,” Wester said.
Here are the top problems companies are likely to encounter with blockchain:
While the first distributed blockchain was conceptualized in 2008 by “Satoshi Nakamoto” (a pseudonym), real-world applications for the technology are only a few years old.
The two most prevalent blockchain platforms, Hyperledger and Ethereum, lack maturity, which could present unforeseen problems in deployment. CIOs and their teams should consider the potential discovery of serious bugs in the software, said Martha Bennett, a principal analyst at Forrester Research. They might even need to scrap a blockchain project and begin again after running into software glitches.
For example, Ethereum’s script for executing smart contracts — Solidity — doesn’t currently support the use of decimal points, which would require developers to create a workaround or start over.
“I have seen that happen on a number of occasions,” Bennett said. “When I talked to people working on projects — and they are working on big, serious projects — they will also say the longer they work with the technology, the more they realize just how immature it is.”
What has changed is that startups and leading enterprise technology vendors, such as IBM and Oracle, have been working steadily to provide tools that abstract away from the underlying complexity of specific programming environments, along with “smart contract scripting languages that provide appropriate guardrails,” Bennett said.
“Overall, it’s worth pointing out that not only tooling is improving, but there are now also quite a few services that make it easier for companies to get blockchain networks up and running,” Bennett noted.
Blockchain is often used as shorthand for a host of accompanying technologies, architectures, use cases and even philosophies.
At its most basic, it’s a peer-to-peer-based distributed ledger or database organized by a set of protocols combined with a blockchain, meaning a series of encrypted sets of data that record immutable changes over time. While that may be relatively straightforward, depending on how the technology is being implemented, the definition can become convoluted.
Wester is often tasked with defining blockchain along with a “basket of technologies” that fall under the general heading of “blockchain,” including tokenized assets, cryptocurrencies, crypto wallets, distributed ledgers, smart contracts, and self-sovereign identity; all of the latter group are applications or architectures that can run on top of a blockchain network, but are not a native part of the technology.
“We are still in the stages of explaining how the technology works,” Wester said. “Additionally, it’s possible to have relatively smart discussions about the technology without actually knowing some of those differences, so many semi-informed people don’t even bother to learn the terms and technology.”
One of blockchain’s greatest assets is its write-once, append-many distributed nature; it can be easily deployed across disparate nodes on the web, and yet each record contains its own hash, making it immutable.
A distributed ledger via a blockchain-based network can provide a richer, more comprehensive transaction history than the selective view users may get if they’ve only got internal systems and maybe some blacklists to review.
However, that doesn’t mean data related to transactions must be part of that chain.
For example, if blockchain users include images as part of their transactions, the data volume would quickly grow — as would network overhead, given that an append-only data store gets bigger and bigger over time. Because of blockchain’s distributed nature, all data must be replicated to all nodes in the chain, Bennett explained.
It’s better to use a relational database with separate networked storage for some transactional tasks than to grow a blockchain out of control. “Rule of thumb: don’t ever, ever go for a blockchain-based architecture when a relational database will do the job,” Bennett said.
While not all blockchain frameworks require full replication of data across nodes, all systems need to be very carefully architected to take into consideration regulatory requirements, the need for confidentiality, and the potential latency issues, according to Bennett. “That determines what goes on chain and what doesn’t,” she said.
One of the major issues facing blockchain involves scalability, or its ability to grow without consuming increasingly vast amounts of CPU capacity and to complete transactions in near real time, such as clearing payments via credit cards. Visa says its network — VisaNet — handles up to 65,000 transactions per second.
Due to its chain nature, each new record inserted into a blockchain has to be serialized, which means that the rate of updates is slower than with traditional databases, which can update data in parallel.
While blockchain consortiums and startups alike are piloting blockchains that can handle ten thousand transactions per second or even greater capacity than VisaNet’s network, most are still hampered by scaling issues. Popular blockchain protocols such as bitcoin support just three to five transactions per second, while Ethereum can support about 20 per second.
The degree to which scaling remains an issue differs between frameworks and governance models. For example, the Ethereum Foundation is working on using a proof of stake consensus model as well as techniques such as sharding to increase its protocol’s performance.
“How you architect the network also matters — latency can be more of a challenge than compute power,” Bennett said. “For example, I’ve seen very impressive test results, but they’re meaningless if they’re achieved by renting a huge AWS cluster for your test.”
Avivah Litan, a Gartner vice president of research, said scalability is more of a governance issue today than a technical one.
“With permissioned blockchain, the whole concept of [a zero trust model] falls apart,” Litan said. “You have a limited number of witnesses operating the nodes and the consensus [process], so you really need to trust those parties, and you need legal frameworks for if they do anything wrong. To me that’s not really scalable.”
In the context of blockchain, the oft-used metric “transactions per second” is also relatively meaningless, Bennett argued. “Firstly, how do you define ‘transaction’? And secondly, just processing lots of transactions is beside the point if you can’t finalize them,” Bennett said.
Blockchain does not inherently eliminate central authorities; it substitutes one type of authority or trust model for another, according to a recent report by the Federal Reserve Bank of Minneapolis.
“Instead of placing trust in a central authority such as a broker or a central bank to facilitate an exchange, participants must trust in the blockchain system design and technology, and the network rules,” the report stated. “It does not eliminate the need for some form of governance authority to establish, implement, and enforce the rules and to respond to unexpected system challenges and exceptions. While members of such a governance body may be distributed or decentralized, a point of governance is still needed to address operational issues.”
Dispute resolution, or how to come to an agreement when something goes wrong, also remains a key governance issue, Bennett said.
For example, blockchain participants need to agree on how they’ll abide by the way a smart contract operates, and what happens in the case of a disputed contract.
“If something happens that you forgot to code into it, there needs to be an off-chain way of coding it in, or a ‘kill switch’ if it starts acting in a way that was not intended,” Bennett said.
Public blockchains — the most prevalent form — are open and transparent, meaning anyone on the chain can see every transaction. That’s the case with bitcoin.
Public blockchains also have the nascent ability to be the more tamper-proof because they can grow to thousands (hypothetically, even millions) of nodes, like an enormous distributed computer. The more nodes, the more difficult it is for a bad actor to take control of a majority of the compute power and either prevent new transactions from gaining confirmation or create and confirm their own entries; being able to do that would enable nefarious behavior, such as double spending bitcoin or other cryptocurrencies.
When you’re working in a commercial environment, on the other hand, complete transparency isn’t typically a good thing. For example, if blockchain technology is being used as part of a stock trading platform as a mechanism for instant settlement, each participant in the chain can see what every other user is doing; that would allow one user to trade against another in real time.
In another example, if a manufacturer is using blockchain as an open ledger for its suppliers, it would allow one contractor to see all other subcontractors in the chain.
“I might not want my customer to see who all my subcontractors are, even though you may want a particular transaction flow on the chain,” Bennett said. “So, you immediately get into how to decide how… you keep transaction data confidential.”
There are methods for creating exclusivity on blockchains so that only some users can see confidential or sensitive data. For example, Hyperledger, an open-source blockchain project under the Linux Foundation, uses “channels” or sub-chains to ensure that only some authorized users can see sensitive information.
As mentioned above, there are two general types of blockchain, public and private. Public blockchains allow anyone to join; bitcoin is a good example of a public blockchain where anyone who wants to purchase the cryptocurrency can join in the chain. It’s open and transparent, meaning everyone in the chain can see all the transactions. If one or even many participants attempt to game the system, they will be overwhelmed by the majority of users who have to validate new transactions.
“The bottom line is you don’t have to trust your peers in a large public blockchain network. That’s the Byzantine General’s problem that’s solved by public blockchain,” Litan said.
Conversely, private or permissioned blockchains are centrally administered and require permission to join; they are suited for use within a single organization or among partner organizations. Only authorized users can join.
Both public and private blockchains are natively secure because they’re immutable (i.e., each record or block is unchangeable and tied to all others), and to add new blocks requires a consensus among users; how large that consensus must be is dependent on the blockchain in use. For some, it’s 50%; for others, it’s more. The immutability and consensus requirement of blockchains make them natively more secure than most other networking technologies, but depending on the architecture and who’s running the nodes and where, blockchains are vulnerable to attack, as has been seen time and time again.
While blockchain provides security relative to the integrity of the data recorded on a blockchain, the blockchain alone, without additional technologies or systems, cannot protect against unauthorized access, such as a data breach, according to the report from Federal Reserve Bank of Minneapolis.
For example, a recent “51% attack” on the Ethereum Classic token exchange showed why even blockchain is not impermeable to gaming. A 51% attack refers to a bad actor who gains control of the majority of CPUs in a cryptocurrency mining pool. Such attacks are generally limited to smaller blockchains with fewer nodes, because they’re more susceptible to a single person seizing control based on a Proof of Work (PoW) consensus mechanism.
Data transparency, or the ability for all parties on a blockchain to view transactions, is part of its appeal in that bad actors can quickly be identified if they attempt to add unverified data. Transparency of data, however, can also be a threat. For example, in a settlement or clearing system for financial institutions where confidentiality may be a key component of security, system data transparency is a security risk, the Federal Reserve’s report noted.
“Where transparency is present, but confidentiality is needed, either encryption of the data on the chain or strong authentication access is required,” the report stated. “Confidentiality and access control can be built into a blockchain, but are not inherent attributes. The blockchain itself also does not provide authentication.”
In other words, don’t assume because one blockchain design implementation includes a particular feature, such as privacy, transparency, or strong user authentication, that others will also have that feature.
Systems that provide information to blockchains, such as smart contracts, can also be attack vectors because they are not decentralized but are single points of failure, Bennett noted.
Smart, or self-executing, contracts are a business automation tool built atop blockchain. They are one of more attractive features of the technology in that they’re able to remove administrative overhead. Essentially, once certain conditions of a contract are met, receipt information, money, property or goods are released automatically.
For example, an insurance company could use smart contracts to release claim money based on events such as large-scale floods, hurricanes or droughts. Or, once a cargo shipment reaches a port of entry and IoT sensors inside the container confirm the contents have been unopened, stored at proper temperatures, and so on, a bill of lading could automatically be issued.
Bennett, however, argued that so-called smart contracts are neither smart nor contracts in the legal sense. Combined with a lack of blockchain scripting language maturity, there’s intrinsically a steeper learning curve for programmers that could lead to bugs or vulnerabilities.
While a smart contract is only as good as the rules and software used to create automated processes, that is becoming less of an issue, according to Bennett.
“We’re even beginning to see tools that allow businesspeople to pull together the basics of a smart contract,” she said. “That’s only the beginning, though — as some companies have already discovered, it can be a challenge to ensure that every network participant runs the same version of a smart contract.”
Other challenges include ensuring that no security issues arise from smart contracts themselves, Bennett added, and making sure that any external inputs to the smart contracts are valid and correct.
“As I keep saying, just because it’s on a blockchain doesn’t mean it’s true,” Bennett said, referring to ensuring that data input is accurate and verified at the source. “A smart contract will only ever be as good as the rules that teams put together for automating processes, and also depends on the quality of the programming.”
Blockchain participants also need to agree on how they’ll abide by the way the contract operates, and what happens in the case of a disputed contract. Creating a new business process also requires agreement on those conditions between disparate users, and there are already instances of blockchain projects being held up because people can’t agree on the conditions under which they should be operating. So, as much as blockchain is about IT, it’s also about contractual agreements.
“As someone recently said to me, blockchains are 80% business and 20% technology,” Bennett said.
Additionally, while blockchains may be decentralized across dozens or thousands of nodes, smart contracts are not. That means the blockchain nodes have no visibility into how the smart contract works; in other words, a consortium of companies who are a part of a blockchain network must rely on one entity for the information being fed into the smart contract — an oracle.
Blockchain networks use centralized software agents called oracles to find and verify that real-world events have taken place, which then triggers a smart contract to act based on predefined conditions. So, for example, the temperature of pharmaceuticals being shipped from California to Denmark could be monitored by an IoT sensor in the shipping container. The sensor information is collected by the oracle software and then sent to the smart contract, which, if the temperature ranges were met throughout the journey, can trigger an event through the blockchain, such as issuing a bill of lading or release of payment for the shipment.
If your company is part of a blockchain consortium — a supply chain, for example — it has no way to know what’s running in the smart contract. There’s no verifiability. Essentially, you have to take the word of the company running the server on which the oracle and smart contract reside for the information being fed to the blockchain.
“You have to go to one source, one table, one oracle for that data. There’s no standard processes to verify the data is what is says it is and it’s coming in properly. It’s a central point of failure,” Gartner’s Litan said.
“It’s not mature yet,” Litan continued. “I’ve talked to companies participating in a consortium and asked them, ‘How do you know what the smart contract is doing?’ and they say they don’t. If you have a contract running your life, wouldn’t you want to know what it’s doing?”
This article was originally published in November 2017 and updated in July 2019.
