The Case For Blockchain Query Language - BQL

This post was originaly published on Let's Talk Payments portal where I regularly contribute thought leadership pieces and since it was very well received I have decided to share it with Finextra community as well. It is in my opinion very relevant and improtant topic which deserves to reach as wide audience as possible in hope that it will influence blockchain industry players and refocus some of their efforts toward standardizing the APIs for interacting with blockchain 'databases' and ensure much wider enterprise adoption that what's the case today. Hope you enjoy reading and as always, the main purpose of these articles is to trigger wider brainstorming and discussion, and not neccessarily to provide final answers.  

The key innovation of blockchain is that it represents the new data architecture framework and platform of decentralized trustless transactions, allowing the disintermediation and decentralization of those transactions between all parties. Every blockchain technology framework is based on a trusted and immutable decentralized transparent ledger of transaction records, supported by cryptographic protection of underlying data structures with proprietary rules for its underlying storage mechanism and decentralized manipulation and synchronization. Such a “database” is immutable and shared by all participating network nodes, updated by miners, monitored by everyone, owned and basically controlled by no one. 

Although most of today’s enterprise PoC experiments are usually based on bitcoin, Ethereum or Hyperledger frameworks, there is already a plethora of new and potentially interesting blockchain platforms (like KrypC platform, for example). All of these platforms have different proprietary consensus algorithm implementations and performance targets and use different underlying digital currencies and data storage and persistence mechanisms. 

Due to differences in their internal implementations, each of the current platforms is exposing different low-level proprietary APIs for accessing, manipulating and interacting with the internal data structures. This seriously limits the developer’s ability to easily experiment and innovate with blockchains from different platform providers. The current state of the blockchain art forces solution architects, developers, testers and business users to choose and specialize in one (maybe two) of the available platforms upfront, thus seriously reducing corporate innovation agility and increasing risks of choosing the wrong platform and not be able to easily replace it with potentially better one.

In my opinion, because of the existing challenges and relative immaturity of the existing blockchain implementations, there is an urgent need to refocus the blockchain community toward standardizing blockchain technology APIs for the application development. Blockchain startups, consultants and vendors must provide enterprise development teams with the ability to experiment with underlying blockchain platforms without the need to learn new APIs and rewrite their application level code, every time they want to try, play and plug-in new blockchain subsystem. Otherwise, enterprise adoption will continue to be slow and painful, filled with skepticism and legitimate corporate resistance. 

In other words, blockchain technology needs to be made much more developer-friendly and consumable by the corporate development teams that are eagerly looking for ways to leverage it. Therefore, we need to quickly find ways to enable much wider enterprise adoption with the ability to easily troubleshoot and support the blockchain-based systems while in development, testing and production in standardized ways.

The blockchain data layer shall ideally be seen as a viable alternative to the current relational databases for distributed storing, manipulating and sharing information. As such, it shall behave almost the same way in order to have a real chance to effectively compete and eventually replace the incumbent data layer platforms anytime soon.

One way to achieve such standardization goals would be to look back at the design of the existing relational database systems that we want to replace with blockchain. Why not try and use those as an example of how to design standard and reusable interfaces between application layers and the underlying blockchain data frameworks that are easy to understand, learn and use? Why not model BQL based on SQL then?

That would mean standardizing BQL operations with underlying data types and overall syntax, regardless of the underlying internal implementation of any particular blockchain solution. For example, at the highest possible level, we may want to have to CREATE, INSERT, SELECT and VERIFY BQL commands for, let’s say, creating the block, inserting block into the blockchain (including reaching consensus), selecting transactions from the blockchain which satisfy certain selection criteria and verifying the block’s consistency. These are just quick suggestions; the real final language standard may choose to enforce different semantics for these or similar commands.

The syntax for underlying payloads, which would be stored inside blocks (i.e., descriptions of transactions for assigning and transferring digital assets between public key addresses) shall also be standardized and combined seamlessly within encompassing BQL commands. Supporting necessary cryptographic operations and syntax, together with authentication and authorization capability, would be included in the BQL standard as well.

Obviously, the possibilities would only be limited by the BQL designers’ imagination and complexity of the underlying developer tools and required compiler infrastructure that would need to compile application-level BQL commands into proprietary vendor low-level APIs (like “R” or something else).

Similar to the existing SQL language, the BQL would be possible to be used in static (pre-compiled) or dynamic ways in applications. There should be bindings for all major programming languages in widespread usage today like Java/JavaScript, Python, C/C++, C# and yes, even Cobol to name a few.

Something like this may be the necessary condition for the rapid growth of the skilled corporate blockchain development community and enabling true competition between BQL-compliant blockchain implementations. That could also enable a whole new potential for software development vendors to offer innovative blockchain-based functional component frameworks and libraries for various industry verticals, which would be independent of the underlying blockchain platform. Let’s hope the blockchain industry is listening and is serious about enabling wider adoption.