Geoprise Technologies - MultiChain

Blockchain for Blockheads

admin — Thu, 05 Jul 2018 15:44:00 +0000

By: Tony Marston, Director, Research & Development, Geoprise Technologies Licensing

Ever since I added blockchain capabilities into an ERP application (refer to Adding Blockchain to an ERP System for details) I have been monitoring the Internet to see how others are dealing with this opportunity, and I am quite amazed at what I have read. Some think that blockchain is nothing but Bitcoin, some don't understand how blockchain can be used outside the cryptocurrency field, some think that a blockchain database will replace the relational database, while others think that blockchain will totally replace an ERP system. This tells me that a lot of people are still in the dark about what blockchain is and how it can be used.

I recently had a conversation with someone from the academic world who thought that integrating blockchain into business applications such as ERP systems would involve nothing more than the transfer of financial data, and that conversation prompted me to write this article in the hope that I can shine a light into the darkness. I shall stick to high level facts and avoid the low level details.

What is blockchain?

Here is the most simple of definitions that excludes any techy buzzwords:

Blockchain is a tamper-proof system for logging messages chronologically. A message sent to one node in a blockchain network will be replicated across all nodes in that network.

Here are some deeper explanations:

A blockchain consists of a two or more nodes in a network. Less than two nodes would not constitute a network and would be pretty useless.
Blockchain software passes messages between nodes. In its most basic form, it does not generate messages nor process them, it just passes them around as if they were sealed packets. Additionally, some blockchains can process messages using logic contained in smart contracts which may be applied to those messages.
Each node has blockchain software and its associated data store, plus an external application (a separate piece of software) which handles the generation and processing of these messages.
When a message is sent to a node by this external application the blockchain software will add that message to its own data store, then send it to all the other nodes in that network who then add it to their copies of the data store.
There is no central copy of the blockchain data or central control of this data. The data store at each node is an exact duplicate of every other node’s data store.
There is some under-the-hood verification processing which causes each message to be authenticated before it is accepted as a valid message.
When a message is received at a node the blockchain software will send it to the external application which processes it as it sees fit.
The data store at each node is tamper-proof as it allows messages to be written and read, but never updated or deleted. This data store is actually a chain of blocks (hence the name ‘blockchain’) where each block of data has a unique key derived from the transactions it contains, and also the unique key of its predecessor on the chain. For this reason, new blocks can only ever be added to the end of the chain.

Aren’t Bitcoin and blockchain the same thing?

No. Bitcoin is an implementation of blockchain, but it is not the only implementation. It would be like saying “chalk is a rock, therefore all rocks are chalk”. Bitcoin, and all other cryptocurrencies, are distinguished by the contents of the messages that they pass between nodes, such as “Take X amount of funds from account Y and put it into account Z”.

There may be other implementations out there, but their capabilities will be limited by the structure of the messages that they send and receive.

What are the main types of blockchain?

Blockchains fall into two major categories:

Public, permissionless and untrusted
Anyone can join without the need for an invitation and can send and receive messages immediately. The lack of trust requires that each message goes through a complex and expensive validation process. For Bitcoin and many other cryptocurrencies, validation or mining uses a proof of work protocol. Cryptocurrencies such as Bitcoin are prime examples of this type of blockchain.
Private, permissioned and trusted
An organization creates a blockchain and invites other organizations to join that chain so that they can exchange information in the form of electronic documents. After joining they are given a set of permissions, such as being able to read messages but not send them. It is not possible for uninvited or unauthorized parties to break into the blockchain and read messages or send messages of their own. Due to these access restrictions the method of validating or ‘mining’ each new block can be far less expensive and time-consuming than a proof of work protocol. The product provided by MultiChain is an example of this type of blockchain.

Can blockchain be used for more than financial transactions?

Most certainly. A lot of people read the term distributed ledger in the description of blockchain and automatically associate the word “ledger” with an accounting system, which then leads them to believe that blockchain can only be used by accounting or financial systems. The correct term should be “distributed message store” as each node maintains its own copy of every message sent across that blockchain.

Notice that I did not use the term distributed database as the data store at each node is nowhere as sophisticated as a fully-fledged relational database (RDBMS). All it does is store packets of information without knowing the contents of each package.

Will a blockchain database replace a relational database?

Definitely not. A relational database holds data which is arranged into tables and columns with primary keys, unique keys, indexes and relationships. Its associated application allows particular pieces of information to be inserted, viewed and modified in sophisticated ways. A blockchain data store has no structure apart from a chain of blocks each of which holds a message. Each message holds a packet of data, but the structure of that data is unknown to the blockchain.

Will blockchain replace ERP applications?

Definitely not. ERP applications will continue to exist either with or without blockchain technology. However, if an organization wishes to exchange information with other organizations it can utilize a blockchain in order to perform this exchange in a more secure manner. It can create a private blockchain, invite specific organizations to become nodes, then exchange information with those nodes sure in the knowledge that no-one can break into that blockchain and either read private messages or send bad messages of their own.

The type of information which can be exchanged is unlimited. The MultiChain software allows messages of up to 64MB in size with no particular format, which means that I can send whatever data I want in whatever format I want. I can send text files or I can send binary files such as images, videos, spreadsheets or PDF documents. The GM-X ERP application has a relational database containing hundreds of tables coupled with thousands of Web forms which allow an enormous volume and variety of data to be input, maintained and viewed. Each discrete set of data can be considered as an electronic document where each document, be it a purchase order, sales order, shipment, invoice or inventory item, consists of data which is held in one or more records in one or more tables in that relational database. A relational database is infinitely customizable, therefore the number and type of electronic document that it may hold is also infinite.

The blockchain data store, on the other hand, is not infinitely customizable and it can only deal with things called messages. It has no concept of columns, tables and relationships, just packets of information known as messages. It is up to the external application to extract the data for a particular document, such as ‘Purchase Order #27’ or ‘Invoice #301’ or ‘Shipment #1024’, put that data into a single message, then send that message to the local blockchain software which will then send it to all the other nodes in the network.

If the message does not have a fixed structure then how can the receiving node possibly process it? The structure of each message is not known to the blockchain software, but it is (or should be) known to the external software which both constructs and deconstructs each message. The trick is to use a message format which can preserve the structure of the data as it resides in the application database with its tables, columns and relationships, so that when the data is deconstructed by the receiving node it puts that data into the correct columns of the correct tables in its own database. Fortunately such a format has existed for decades, and it is called XML. Although each XML document is a file containing human-readable text, it is possible to embed binary data into this text using a method of binary-to-text encoding. It is therefore possible for an XML document to contain an image as well as metadata which describes that image. That image could be a picture of an item, or a document that contains someone's signature. The possibilities are endless.

References

The Inside Story of GM-X ERP for Blockchain

admin — Wed, 10 Jan 2018 14:00:00 +0000

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.

Geoprise Technologies - MultiChain

Blockchain for Blockheads

Tags:

The Inside Story of GM-X ERP for Blockchain

Tags: