Blockchain, Relational, or Unstructured: A CIO Guide To Databases In The Bitcoin World

If you’re a CIO, the Bitcoin craze has likely bitten your colleagues in such a way that you’re being asked about cryptocurrency and when you’ll start using Blockchain. After all, it will “give rise to the new internet era” and “transform the financial system.” It is “the disruptor of every industry” and could “change the world.” Benefits are said to include lower cost, risk, and capital requirements, faster transactions, more transparency and reliability, improved privacy, and unparalleled security, to name a few. Not bad for an idea that’s only eight years old.

Each blockchain platform (e.g., Bitcoin, Ethereum, Hyperledger) is a distributed, immutable ledger of economic transactions with a scheme for verifying and recording transactions (e.g., Proof of Work, Proof of Stake, Proof of Time and Space, etc.). These schemes help to ensure the security and immutability of every entry. While most uses of blockchain are public, blockchains can be public, permissioned, or private, each of which has distinct advantages and constraints.

For comparison, the centralized database is both the traditional method of managing data today and the primary alternative to blockchain. A database can be relational (e.g., Oracle, SQL Server) or unstructured (e.g., Hadoop, MongoDB). Both types are capable, robust, and scalable, and in the near-term should be the default choice for many enterprise data management use cases.

It is important to recognize that Under the right circumstances, blockchain could be transformative, but without careful planning it could also become a costly misadventure.

As with most technology decisions, the blockchain question introduces a series of trade-offs. Understanding that blockchain is not the ideal solution to every data problem; it is a different rather than a better way to address data or transaction management, we can evaluate the criteria that matter for enterprise data or transaction management. These are what I see as the key trade-offs organizations should pay attention to when evaluating Blockchain against centralized databases:

Transaction Speed: Slow is smooth, smooth is fast?

Today, blockchain is slow. Bitcoin’s capacity right now is seven transactions per second. For comparison, Oracle’s database can scale to 25,000 transactions per second, and the global financial network SWIFT today manages just shy of 329 transactions per second. So while blockchain has been proposed for many use cases with real-time transaction requirements, from IoT applications to battlefield communications, the scale of the system is very low.

The transaction speed problem comes from running Proof of Work (PoW) or Proof of Stake (PoS) consensus schemes. Permissioned / private blockchains may be faster than public options, but are still slower than what enterprise databases can achieve.

While the issue of raw transaction speed is being addressed, the benefit to blockchain today is in improving the business process of comples, multi-stakeholder transactions using digital contracts in blockchain. Faster transactions would not be enabled by the technology per se, but by new processes that make use of blockchain’s architecture and features (e.g., transparency, immutability, traceability, etc.). Prime examples are real estate and intellectual property transfers and some financial transactions, where changes must be verified by numerous parties across siloed systems, thus taking a long time to execute. But digital contracts will depend on trusted, online proof of assets changing hands, and on the ability to support claims through the legal system.

Smart contracts could further improve transaction speeds for programmable, rules-based interactions. This could be a source of time, weather information, or sensor data (showing a certain amount of electricity being delivered to a house, or a car arriving at a particular location). If security concerns (see below) can be addressed, smart contracts could be a significant opportunity in the future.

Security: Immutable but widely visible

“Blockchain is immutable.” While this reads like dogma, it is a valid statement. Blockchain’s structural security and immutability have been discussed at length, and appear to offer real advantages over traditional datastores. High-profile hacks of blockchain systems have been attributed to the applications running on the blockchain rather than the architecture itself. Hybrid architectures, utilizing blockchain in combination with robust relational databases, appear even more promising, such as the keyless signature infrastructure used by the Estonian government.

However, vulnerabilities at the application and user levels can diminish blockchain’s security improvements. In many organizations, the biggest vulnerabilities may be poorly-designed applications, phishing attacks against untrained users, or unpatched firmware on edge devices (picture medical devices in hospitals or smart sensors on an electrical grid). In these cases, blockchain may provide advantages without improving the security of the system as a whole. After all, the strongest lock does nothing if a window is left open or a thief is handed the key.

It’s also worth noting that blockchain’s immutability means the content is protected from alteration. It is not hidden from view.

Maintenance: Help me, Rhonda!

For blockchain, the fragmented platform landscape means there is limited support for any particular platform, and no guarantee that the provider will exist in the future. There has also been less time for the support landscape to develop, including strategic advisors, systems integrators, and managed service providers. In-house talent will be hard to find, and all the more important given blockchain’s inherent complexity. Contrast this with the decades of experience of traditional database vendors such as Oracle and Microsoft, and the dichotomy becomes apparent.

Stewardship: Who owns this?

The nascent blockchain ecosystem remains fragmented, with a wide array of platforms and vendors. Even early leaders such as Bitcoin and Ethereum remain in flux, with bitter disagreements over design decisions and the direction of the platform. This creates inherent risks that must be taken into account.

Governance: Will mine work with yours?

Governance is another critical issue, particularly if control over the platform and its underlying data are held by a broader set of stakeholders or the general public. The flowcharts provided by the IEEE, IACR, and others are helpful for determining whether a blockchain is needed at all based on trust and access requirements. But even if one is needed, many questions remain: Who will fund and own the platform as well as the data? Who will ensure that it continues to meet evolving requirements? Who will be responsible for upgrades and maintenance? It is not a given that the parties responsible for writing to the blockchain and validating transactions will also ensure its continued relevance.

Cost: Oracle is expensive, but losing your data is deadly

The cost of blockchain relative to centralized databases appears to be contentious and ultimately unproven. Some industry-watchers believe blockchain can lower costs when compared with the hefty licensing and support fees charged by database giants such as Oracle. One notable example is the Depository Trust and Clearing Corporation (DTCC) moving its credit default swap platform to a permissioned blockchain, which they expect will save 20–30% over the existing architecture.

On the other hand, a business case for blockchain must account for a host of potential costs beyond hosting, licensing, and implementation. Hiring or outsourcing for talent to maintain the system could be significant. Energy costs may rise tremendously as the transaction volume increases. On top of all this, a buffer for unknown-unknowns and perhaps a “complexity premium” should be added. Small-scale prototypes or proof of concepts should be conducted wherever possible to validate expected cost savings relative to existing systems.

The Final Word: Wade, don’t dive

Experimentation is an appealing way to avoid a sense of falling behind without betting the farm. Prototypes and shadowing in-place systems may be a valuable tool in measuring trade-offs without putting critical data at risk. Participating in consortia or other partnerships may be another way to test the water. Those incremental steps may allow delay of significant investments until the technology and business environment has reached greater maturity and the potential gains become clear.

Partnering with firms using blockchain is another good way to enter the market. And yes, I’m biased. :)

About Dana Love: I am currently the cryptoeconomic advisor to two ICOs: eLocations and Intellos and president, CTO, and a founder of Radpay. First involved in blockchain work in 2011, I hold a PhD in economics (The University of Glasgow, highest honors), an MBA in marketing (Harvard Business School, Baker Scholar), and a BS in physics (University of Richmond, Phi Beta Kappa). Since I started coding as a youth in MORTRAN and ALGOL68G, I have co-founded five businesses with four successful exits, including Cisco Capital-backed Metacloud and Warburg Pincus-backed Radnet, and have led divisions of public companies including GTE (now Verizon), Prosodie Interactive (now CapGemini) and ADC. My research is in public policy, most recently the impact of blockchain and big data on emerging economies. Some of my past efforts include building the first cloud-based ERP system (in the mid 90s), development of the first carrier-grade VoIP and unified communications platforms in the world (at GTE, now Verizon), and early work in big data systems (as an Oracle partner.) My work in big data, machine learning, blockchain, and VoIP has been written about in Wired, Oracle’s Profit Magazine, the Financial Times, and Telephony Magazine.