3 challenges of blockchain adoption for enterprise developers

Blockchain’s been a hot topic for a few years, starting with the tidal wave of the Bitcoin hype and gradually coming into its own. By the end of 2019, it’s already been the keystone of IT conferences, the buzzword of the marketing machine, and the target of some backlash (mainly in regards to cryptocurrencies).

While the general idea of blockchain as the next big IT thing is quieting down a bit, the notion of the sector-specific distributed ledger technology (DLT) use is on the rise.

What this means is that we’re on the verge of mass business adoption of blockchain, starting with enterprises.

Still, the technology is young and use cases are not nearly extensively explored, so there’s much to learn as you go. Even if the researchers and strategists at your company did their homework, at some point the development team will likely have to address the following three issues when working with enterprise blockchain.

Scalability and transaction speed

Scalability is both the Achilles heel and holy grail of blockchain development. To put this into perspective: Visa supports around 2,000 transactions per second. Bitcoin’s top speed is about 5 transactions per second; Ethereum’s—15.

While small and medium DLTs are quite fast, thousands of nodes trying to perform high-volume transactions can slow down a network severely. At the moment, scalability and transaction processing speed (TPS) are the major bottlenecks standing between blockchain and its mass commercial adoption.

There are several forks and workarounds addressing some of the possibilities to improve blockchain TPS. Here are the most prominent of them:

• Batching multiple low-level transactions into one (for example, several payments into one blockchain transaction). The pros are that this approach allows more individual transactions per block and per second due to the reduced size of the overall transaction record. The cons include increased privacy risks as well as security limitations.
• Forking and increasing the block size. An example of this would be Bitcoin Cash: a fork of Bitcoin with an 8x larger block size. The pros in this scenario are obvious: by upping the block size, you get a higher TPS. However, you can’t increase the block size indefinitely, and the boost in speed is still not enough, compared to conventional large databases. In comparison to Visa’s 2,000 transactions per second, Bitcoin Cash’s 40 transactions are plainly inadequate.
• Off-chain transactions. These are also referred to as second-layer solutions, which are transactions happening privately, outside the base blockchain, and thus not recorded there. This is made possible with the aid of platforms and protocols on top of the initial blockchain, and can drastically improve the speed of transactions. It also poses obvious risks and fundamentally breaks the main principle and selling point of blockchain technology: all the information, with all the changes and its complete history, will no longer be kept intact.
• Global technology-agnostic solutions. One example is bloXroute: the project using high-speed content delivery networks and transposing them onto blockchains to solve the scalability vs speed issue.
• Centralized high-performance blockchains. Although considered by some to be but glorified cloud computing services, centralized blockchains are worth attention. Often recommended for enterprise development by blockchain experts from Itransition, centralized blockchains provide desirable speed while being tried and tested solutions. The tradeoffs are the presence of control, censorship and interference mechanisms, so they are obviously not ideal for public projects.

SEE ALSO: True reliability requires self-healing nodes and infrastructure management

Decentralization vs. centralization and security issues

One of the greatest strengths of conventional public blockchains is their decentralization. Since one of the ways to compromise data within a decentralized ledger is to literally seize control of more than half of the nodes in the system, the more decentralized and spread-out the blockchain, the better.

In an enterprise setting, however, the directive is often not to decentralize the blockchain but instead to keep it in-house: fully or partially centralized, under the control of a corporate entity, often aimed at inner operations and thus open for selective edits and revisions.

With private, or federated, blockchain development, there are opportunities for greater flexibility and customization. However, if decentralization is limited or isn’t a part of the plan at all, the absolute priority here should be security. It’s better to err on the side of caution: to double down on encryption as well as other means of protection to eliminate 51% attacks, and carefully consider the vulnerabilities posed by your particular blockchain’s use cases.

Interoperability challenges

Speaking of vulnerabilities: apart from centralization making blockchain faster but less secure, there is another potential weak spot—contact points with external systems. The security, privacy, and incorruptibility of blockchain ends the moment it connects to a legacy database or otherwise gets new data from external sources.

Providing a blockchain is not compromised, the data and transactions it generates within itself is always protected and verified. In theory, it’s not much of a problem, but when applied in the real world, the idea quickly becomes unsustainable.

For example, a blockchain-based supply chain monitoring and management solution would constantly need to absorb external data, and would be unable to extend its safety and quality-assuring protocols simply because of the lack of control over third-party data. And since we’re moving toward what looks like many interconnected private blockchain solutions in various sectors, the problem of missing standards and regulations is only going to become more pressing.

At least until there aren’t comprehensive interoperability standards enforced upon all involved parties, this problem can’t be decisively solved by developers. Still, it’s crucial for blockchain project owners and strategists to stay aware of the issue, working to identify potential weak points of this kind.

SEE ALSO: The trendy five: GitHub repos to be thankful for in November 2019

The bottom line

Blockchain is finally at the point of entering both the programming and big investment worlds beyond just cryptocurrencies. As sector-specific demand for skilled professionals grows, now is the right time to get into blockchain development. But whether you are on the side of software engineers or business executives, be mindful of both possibilities and limitations, and get ready to face challenges of enterprise adoption.

The post 3 challenges of blockchain adoption for enterprise developers appeared first on JAXenter.