By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation
I recently co-authored a book with Dr. Janson Yap, “Wow! How Did You Know That?” (Chatswood, Australia: Gadwise; 2017. 275 p. ISBN 978-9811156618.). If you're interested in reading it, head over here where you can order a copy.
What's this got to do with the inside story of GM-X ERP for Blockchain? Plenty, as it turns out.
Spark of Inspiration
Dr. Yap is a recognized Innovation Leader in the Asia Pacific region, and has been a friend and professional colleague of mine for over 20 years. Our book focuses on the theory and practice of risk intelligence, including threats and opportunities posed by new technologies. Naturally, blockchain technology figured prominently in Dr. Yap's vision for the book project, so at his suggestion I took this topic on board about a year ago. You can read the outcome in Chapter 12 ("Get SMART"), pages 209-212, which I completed in May 2017.
To be perfectly honest, I didn't know much at all about blockchains at the outset, beyond the fact that they underpin today's cryptocurrencies. A great deal of research was required before I was able to write something worthy of inclusion in the book.
After that, at the very instant I stood back to view my work as a whole, the light bulb went on.
The Proof of Identity Dilemma
Nearly twelve years before, I had written a series of blog posts about security and privacy concerns which I thought would obstruct software-as-a-service (SaaS) offerings from gaining traction in the marketplace—particularly SaaS offerings dealing with sensitive information such as personal and financial data. I stated the basic problem in On Identity, Part 1:
A bilateral trust model ... puts absolute enforcement power in the hands of the respective parties according to the terms of a mutually-agreed contract ... [which] might give you the right to declare certain information ‘private,’ after which the service provider has no right to see or retain it in its domain without your explicit permission, obtained according to your rules. You can enforce your rights by encrypting this information, and issuing the [decryption] key only when you’ve authorized someone to see it.
Proof of identity is of course the crux of any bilateral trust model. That’s because each party's ability to enforce its end of the contract depends, in turn, upon its ability to tell the difference between a legitimate representative of the other party, and an impostor.
In On Identity, Part 3, having demonstrated that none of the authentication standards then in use are appropriate ways to implement a bilateral trust model, I examined several competing federated identity frameworks as well as proprietary networks, and then peered into the crystal ball:
This leads me to the Universal Private Address, [a] federated identity framework put forward by [the Organization for the Advancement of Structured Information Standards (OASIS)] and Advanced Micro Devices (AMD). It is a new type of abstract address that uses an OASIS XRI (Extensible Resource Identifier) and protocol known as XRI Data Interchange (XDI).
What intrigues me most about the Universal Private Address is that it specifically targets the need for bilateral trust that I believe is key to future marketplace acceptance of ‘on demand’ software. This is because the link between any two Dataweb pages is a pipe for pushing or pulling data in either direction, under the control of automatic ‘valves’ at either end known as ‘XDI line contracts.’
Will Universal Private Addresses take off?
In hindsight, Universal Private Addresses never went anywhere—nor did any competitors I considered (except, arguably, Shibboleth in academic circles). Today, the overwhelming majority of commercial SaaS offerings in the public cloud still rely on User IDs and passwords to identify people. According to SkyHigh Networks, just 1.1% of cloud providers support tenant-managed encryption keys. The rampant pandemic of security breaches, identity theft, ransomware and “fake news” plaguing the world today should come as no surprise to anyone.
Inability to assure even the most rudimentary proof of identity is precisely what enabled Russian entities to buy advertising, post memes and organize political rallies during the 2016 U.S. Presidential campaign using fake Facebook® accounts, in an attempt to trick prospective U.S. voters into believing this content came from credible and legitimate domestic sources.
Geoprise, meanwhile, tried to hop onto the SaaS bandwagon in 2007. We introduced a product known as GeoBooks On Demand, but we should have known better considering our warnings just two years before. GeoBooks On Demand flopped. The main reason: enterprises—particularly those located in Asia—were loathe to store their financial data in the public cloud. “We won’t put our data anywhere the government could see it without our knowledge” was the usual objection. So, it seemed, our original warnings were spot on.
Readers who are at all familiar with how blockchains and cryptocurrencies work can be forgiven for wondering how this technology comes anywhere close to establishing the proof of identity needed to create and sustain bilateral trust. After all, most cryptocurrencies are pseudonymous, in the sense that account owners can choose to remain completely anonymous by changing their blockchain addresses (identities) with each transaction. And their proof of work (POW) mechanism for validating transactions operates according to a “trustless consensus” principle which assumes that no one on the network can be trusted at all.
But blockchains have another important property: they are federated. Account owners keep, and verify, their own copies of the blockchain instead of relying on an intermediary to maintain a single, centralized database. In addition, blockchain transactions are self-certifying which makes them permanent, tamper-proof and verifiable (see our white paper, pages 4 and 5, for details and a demonstration).
It suddenly dawned on me that blockchain technology fully satisfies one of the essential requirements for establishing bilateral trust: it gives individual participants complete and exclusive control over the data they own, the assets those data represent, and even their identities. No other technology platform which purports to satisfy this requirement has ever come close to gaining such widespread acceptance in the world of commerce, and for this reason none are as battle-tested in the wild.
This realization was the spark of inspiration.
The Confidentiality Quandary
But there was a problem. At first glance it would appear that blockchains are incapable of protecting privacy, because they keep a ledger of all verified transactions, and those transactions are visible to everyone. From the research I'd already conducted, it didn't appear that a blockchain could perform anything resembling an “XDI line contract” like the Universal Private Address.
So, I continued my research. Eventually I found this blog post by Dr. Gideon Greenspan, CEO and Founder of Coin Sciences Ltd in which I found:
The first idea that we (and many others) started with ... inspired by bitcoin directly, was that private blockchains (or ‘shared ledgers’) could be used to directly settle the majority of payment and exchange transactions in the finance sector, using on-chain tokens to represent cash, stocks, bonds and more.
This is perfectly workable on a technical level, so what’s the problem? In a word, confidentiality. If multiple institutions are using a shared ledger, then every institution sees every transaction on that ledger, even if they don’t immediately know the real-world identities of the parties involved. This turns out to be a huge issue, both in terms of regulation and the commercial realities of inter-bank competition. While various strategies are available or in development for mitigating this problem, none can match the simplicity and efficiency of a centralized database managed by a trusted intermediary, which maintains full control over who can see what.
Why is this an issue? According to Dr. Greenspan:
In a nutshell, concentration of control. By putting so much power in one place, we create a significant security challenge, in both technical and human terms. If someone external can hack into the database, they can change the ledger at will, stealing others’ funds or destroying its contents completely. Even worse, someone on the inside could corrupt the ledger, and this kind of attack is hard to detect or prove. As a result, wherever we have a centralized ledger, we must invest significant time and money in mechanisms to maintain that ledger’s integrity.
So far, this seemed like yet another problem begging for a solution. But further exploration led me to a subsequent post from Dr. Greenspan which described a solution:
As I’ve discussed previously, confidentiality is the biggest challenge in a large number of blockchain use cases. This is because each node in a blockchain sees a full copy of the entire chain’s contents. Streams provide a natural way to support encrypted data on a blockchain, as follows:
- One stream is used by participants to distribute their public keys for any public-key cryptography scheme.
- A second stream is used to publish data, where each piece of data is encrypted using symmetric cryptography with a unique key.
- A third stream provides data access. For each participant who should see a piece of data, a stream entry is created which contains that data’s secret key, encrypted using that participant’s public key.
This provides an efficient way to archive data on a blockchain, while making it visible only to certain participants.
To me, this looked a lot like the concept of “a pipe for pushing or pulling data in either direction, under the control of automatic ‘valves’ at either end” which I had described 12 years before. It's why the GM-X ERP for Blockchain solution we are announcing today calls them “data valves”.
At last, a solution that performs the equivalent of an “XDI line contract” appeared to exist that, in tandem with blockchain technology, was sufficient to establish and sustain bilateral trust.
Proof of Identity, Revisited
It was by now clear to me how blockchain technology could dissolve the concentration of control that is inherent in centralized systems, and enables bad actors to flourish by stoking today’s security breach pandemic.
It was equally clear how streams and encryption technology could overcome the confidentiality quandary inherent in blockchains (see our white paper, page 6, for a demonstration).
Still, none of these solutions is capable of proving identity. When I transact with someone over a blockchain, how can I “tell the difference between a legitimate representative of the other party, and an impostor”?
This is where the distinction between public, “permissionless” versus private, “permissioned” blockchains enters the picture.
Cryptocurrencies like Bitcoin are public: in theory, anyone can create a cryptocurrency account, anyone can engage in mining (transaction validation), and all these players can choose to remain anonymous. In conditions like these, nothing short of a “trustless consensus” mechanism will do.
But membership in a private blockchain is conferred by invitation only. As our white paper says on page 18, “a private or permissioned blockchain is not a trustless environment; even if the participants ... don’t fully trust one another, they must nevertheless be accredited or trusted enough to have been invited in the first place.” This is certainly the case for nearly every business-to-business (B2B) collaboration scenario I've ever encountered during my 37 years in the ERP field.
Technically, it is much simpler to prove an enterprise's identity than it is for individual consumers because well-accepted standards and services for doing so already exist. The most common standards are D-U-N-S® numbers, issued by Dun & Bradstreet, and GS1® global company prefix (GCP) numbers. You may have heard of D-U-N-S numbers before—especially if you work in the U.S.—but if you think you’ve never heard of GCP numbers before, think again. They are embedded in each and every one of the barcodes that are scanned at the checkout lines in millions of retail stores across the globe; the GS1 standards even provide a place for International Standard Book Numbers (ISBN).
In order to get a D-U-N-S number or GCP, enterprises must apply to Dun & Bradstreet or a GS1 Member Organization (MO) as explained on pages 18-20 of our white paper. The vetting process for those applications has nothing whatsoever to do with blockchain or encryption technology, and everything to do with good old-fashioned due diligence. What's more, the outcome is an identification number that is globally unique, and freely verifiable over the public Internet.
It's important to note that the sponsors of a private blockchain don't have to mandate the use of D-U-N-S numbers or GCPs to establish proof of identity. The blockchain's initial sponsors and current members are, in fact, free to choose whatever accreditation protocol they deem fit for purpose, no matter how strict or lenient. But the fact that well-accepted standards and protocols exist which provide globally-unique and trustworthy identities for individual enterprises, and participants can refuse membership to applicants who fail to accredit or comport themselves satisfactorily, resolves the proof of identity dilemma for B2B collaboration scenarios.
A happy consequence is that the POW (mining) required for “trustless consensus” is no longer needed and, in fact, is a needless waste of resources. As a result, the MultiChain blockchains described by Dr. Greenspan are capable of processing up to 1,000 transactions per second on networks comprising mid-range servers, and our initial tests revealed that new transactions propagate through a MultiChain network instantaneously.
Proving the Concept
In mid-October 2017, I discussed my findings at length with Tony Marston, our R&D director. Like me at the start of the 2017, Tony professed very limited knowledge of blockchain technology but he immediately agreed to put MultiChain to the test.
It took Tony just under two months to build and successfully deploy a proof of concept using MultiChain.
The outcome of all this work was the partnership with Coin Sciences, Ltd that we are announcing today.
Designing and Building the GM-X Blockchain Subsystem
During the proof of concept phase, Tony and I also invested considerable time in discussions—and a few very lively debates as well—on the best way to integrate our GM-X ERP application with the MultiChain blockchain server. The outcome of these discussions is described on pages 16-24 of our white paper.
Our design required just three key GM-X enhancements:
- Developing the GM-X application program interfaces (APIs) which send GM-X transactions to a blockchain ledger, and retrieve new transactions from a blockchain ledger. See pages 5 and 6 of our white paper which illustrates the messages which are sent, stored in the blockchain, and received. This work is complete and has been extensively tested.
- Creation of a new GM-X Blockchain Subsystem to configure and manage the data items which each participant publishes from its instance of the GM-X ERP application, the blockchains to which these data items are published and the distribution policy for each of these data items. Every participant runs its own instance of the GM-X ERP application, and can maintain its own private data in addition to the data it chooses to share with one or more of the other participants. See pages 21 and 22 of our white paper for further details. Tony completed the development and initial testing of the new GM-X Blockchain Subsystem in about 3 weeks.
- Enhancement of most GM-X auto-incrementing primary keys to guarantee that data items created independently by each blockchain participant will mesh properly, without any collisions, when published to a common blockchain ledger. See pages 17 and 18 of our white paper for further details. This work is ongoing and currently supports 3 of the 11 GS1 Class 1 Identification Keys standards. We expect to complete this phase of work during the first quarter of 2018.
I am enormously proud of what our team has accomplished so far, and am absolutely certain that our GM-X ERP for Blockchain solution will prove just as revolutionary for the world of ERP as the introduction of client-server computing a quarter-century ago.
My aim in telling our inside story is to make it clear that Geoprise isn't taking opportunistic advantage of all the hype about blockchain technology to flog yet another half-baked solution in search of a problem. On the contrary, in partnership with Coin Sciences Ltd, our solution has been many years in the making, and offers a solid and proven way for enterprises who depend upon B2B collaboration to counter today's alarming and rapidly escalating information security threats.
Acknowledgments
I gratefully acknowledge the inspiration and contributions provided by Dr. Janson Yap, Dr. Gideon Greenspan and Tony Marston.
I also thank David Shultz, Will Shultz, Jeff Khoury, Chris Will and Randy Spiess for your critical and constructive reviews of our design thinking and white paper.