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
Industry leaders gathered at Prove's Improve Connect summit to discuss balancing frictionless digital experiences with the threat of AI-powered fraud. Experts from companies like Coinbase, Bluevine, and Google shared insights on navigating the challenges and opportunities of emerging technologies.
Digital identity theft is the new frontier of crime, where criminals steal our online "keys" to unlock financial accounts, social media, and even medical records, causing widespread damage and eroding trust in the digital world. Companies inadvertently contribute to this problem by failing to adequately protect user data with secure software development practices.
As organizations in the UK prioritize business growth through online transactions, establishing trust & safety with users is rapidly becoming the critical element that offers a competitive advantage.
