ClickCease

WANTED: Blockchain Query Language (BQL)

Prove
October 6, 2021

The critical 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 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 exciting blockchain platforms (like the KrypC platform, for example). 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 exposes different low-level proprietary APIs for accessing, manipulating, and interacting with the internal data structures. This seriously limits the developer’s ability to experiment with blockchains from different platform providers easily. 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 replace it with potentially better one easily.

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 application development. In addition, blockchain startups, consultants, and vendors must provide enterprise development teams with the ability to experiment with underlying blockchain platforms without learning new APIs and rewrite their application-level code every time they want to try, play, and plug in a 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 troubleshoot and support the blockchain-based systems while in development easily, 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. It shall behave almost the same way 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 a block into the blockchain (including reaching consensus), selecting transactions from the blockchain which satisfy specific selection criteria and verifying the block’s consistency. But, of course, 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. In addition, supporting necessary cryptographic operations and syntax, together with authentication and authorization capability, would also be included in the BQL standard.

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 could 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, independent of the underlying blockchain platform. Let’s hope the blockchain industry listens and is serious about enabling wider adoption.


Keep reading

See all blogs
Be Part of the Future of Fraud and Digital Identity at Prove’s improve 2024 Featuring Fraud Fight Club

Prove is hosting a digital identity summit – improve 2024 – with the help of Fraud Fight Club, in Charlotte, NC, on Thursday, April 25, 2024 - an exclusive gathering of top minds in fraud, risk, and identity.

Kelley Vallone
March 18, 2024
What Steph Curry Can Teach Us About B2B Onboarding

Just as every system needs a catalyst, Curry provides that for the Warriors. Identity verification is the catalyst for your B2B onboarding.

Kelley Vallone
March 13, 2024
Prove’s Tom Hill Provides Critical Identity Verification Considerations for Online Gambling Companies

Prove’s Tom Hill explains why creating an easy-to-use and engaging user experience will be critical for gaming organizations to rapidly onboard new customers.

Kaushal Ls
March 11, 2024