Geoprise Technologies - Blockchain

What? Another General Ledger Application?

admin — Wed, 12 Dec 2018 07:24:01 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

On November 30th, 2018, Geoprise Technologies released a brand-new General Ledger subsystem. It’s the first of four new financial applications we are adding to the GM-X ERP for Blockchain application suite. We’ll be adding Accounts Receivable, Accounts Payable and Fixed Assets subsystems soon.

The sceptics out there (and the world is full of sceptics) are already asking, “What? Another General Ledger Application?” If you are one of them, this blog post is for you.

Here I shall focus on what makes our General Ledger subsystem different from all the other accounting software on offer these days, and why those differences are important.

It Runs on the Blockchain

The GM-X General Ledger subsystem is the world’s first and only fully-functional financial application to run on blockchain technology, out of the box. Our nearest competitors are still in the proof-of-concept phase. Don’t expect to see fully-functional, enterprise grade applications from them until 2022 (at least).

Why is this important? Forget about paying suppliers in cryptocurrency, and using artificial intelligence (AI) to seamlessly execute “smart contracts” with trading partners. These are indeed bold, exciting and forward-thinking ideas, but way out in front of what matters today to every Chief Financial Officer (CFO) I know. Instead, focus on just one pressing concern: security.

Nearly a year ago, when Geoprise first published its GM-X ERP For Blockchain White Paper (PDF), I wrote:

As hacking by cybercriminals and state sponsored entities grows ever more frequent and sophisticated, ‘hardening’ existing systems has become a never-ending, costly and ultimately futile effort. Businesses and consumers no longer trust the patchwork approach to adequately protect their information assets.

In October 2018, Bloomberg BusinessWeek reported how operatives of China’s People’s Liberation Army inserted tiny microchips into server motherboards to infiltrate America’s top companies, among them Amazon Web Services (AWS) which dominates the market for cloud infrastructure services. To be fair, Amazon (and Apple, which was also named in the report) immediately denied that their servers were compromised, but Bloomberg BusinessWeek continues to stand by its story. Still, intellectual property theft remains a major issue in the ongoing trade dispute between the U.S. and China which has roiled world markets in recent weeks.

For today’s CFOs the stability of capital markets, and managing information security as well as intellectual property risks, are much more urgent concerns than figuring out how to receive payments in Bitcoin. Recent news from the information security front is reinforcing their widely-held belief that mission-critical financial applications must remain on company premises, under lock and key, even if it were less expensive to run them on cloud services.

An enterprise, like Geoprise, which operates from several locations around the globe, can keep its information assets completely secure by running the GM-X General Ledger (along with other integrated GM-X ERP subsystems) on premise at each location. Journal entries created within those organizations are posted immediately to the local GM-X ledger, and are also passed immediately and automatically to the headquarters organization over a private blockchain network, where they are posted again to the global GM-X ledger which runs on premise at the headquarters office. This gives both the local and headquarters organizations instant visibility of their current financial position.

This solution is completely secure because:

It runs completely on premise. Each of the local GM-X applications, and the global GM-X application, are accessible only from trusted corporate networks situated behind internal firewalls.
Everyone on the blockchain is trusted. The only participants in the private blockchain network are the headquarters organization and its subsidiaries, so all participants are trusted.
Only headquarters can unlock the data. Although each participant has a complete copy of the blockchain database, each local GM-X application encrypts every journal entry before adding it to the blockchain, and only the headquarters organization is given the decryption key. Confidentiality is preserved because the remaining subsidiaries cannot read or post these journal entries to their local GM-X ledgers.
Data in transit can’t be hacked. Even if the blockchain propagates over the public Internet, no one other than the headquarters organization can read the journal entries because they are encrypted end-to-end. Any attempt to tamper with the blockchain database will be immediately and automatically rejected by all participants because, by its very design, a blockchain database is permanent, tamper-proof and verifiable; and cannot be hacked.

You Can Run It on Your Smartphone (If You Want)

The GM-X ERP for Blockchain application, including our new General Ledger subsystem, is the first and only full-fledged ERP application in the world that you can run completely from your smartphone.

SAP enthusiasts will say that SAP Fiori®, which runs in front of the New General Ledger available with SAP S/4HANA®, delivers a “mobile first” user experience which is both responsive and adaptive (depending on the use case). But SAP’s Help documentation for displaying general ledger account balances says that this application runs on desktops only. Not so with GM-X General Ledger, which you can run on any device in any orientation.

Now, there are many reasons why users will continue to prefer their desktop and laptop computers over their smartphones, particularly when entering lots of data, but seeing today’s general ledger account balances is something a busy CFO just might want to do from a smartphone.

My point here is not to disparage SAP® software, but rather to prove our claim that the GM-X is the first and only full-fledged ERP application in the world that you are free to run completely from your smartphone ― or your tablet, laptop or desktop PC.

It’s A Modern, Perpetual General Ledger Built for The Age of Big Data

Let’s face facts: most general ledger applications in use today were designed a quarter-century ago, or even earlier. That takes us back to the dawn of the Internet.

Greybeards like me still remember when “perpetual” inventory systems replaced old-fashioned “periodic” inventory control. Back in the day, you had to roll closing inventory balances over at the end of each month to create opening balances for the next month, and people couldn’t use the system at all before this was done. Actually, old-fashioned general ledger systems used to work the same way, and only kept one or two years of history online.

These limitations existed for a very simple reason: online storage was scarce, and extremely expensive. In 1981, when I designed and built my first ERP system, an 80 megabyte hard drive cost today’s equivalent of about USD 70,000!

But fast forward to today, and you’ll find that all of the world’s popular general ledger systems (except GM-X General Ledger) require organizations to run some sort of procedure at year end which carries closing account balances forward to the next fiscal year. Until that happens, users (including the CFO) will not be able to see the closing balances for the previous year. Yet in this day and age there is no economic or technical reason why this needs to be done.

For this reason, the GM-X General Ledger subsystem only has one set of opening account balances. These are the initial opening balances created when migrating from a legacy application to the GM-X General Ledger subsystem. From that point in time forward, the system automatically calculates opening and closing balances on-the-fly (including the accumulation of profit and loss balances into retained earnings) for whatever time frame is of interest ― be it the current month, current quarter, current year-to-date, quarter-to-date last year, year-to-date last year, or any other time frame for that matter.

And, because the GM-X General Ledger subsystem keeps a full history of journal entry details alongside the original business transactions and historical account balances, CFOs can instantly drill down to individual business events ― shipments, invoices, payments, inventory movements, expense reports and so on ― no matter when these events occurred.

I invite you to explore the many features and functions which our new GM-X General Ledger application delivers. You will see that it has all the multi-company, multi-currency and multi-language capabilities you would expect from a robust, enterprise-grade application; but it should be clear at this point that a simple feature comparison isn’t the whole story. Thanks to its use of secure and proven blockchain technology, mobile-first design and perpetual general ledger built for the age of big data, it’s a product which delivers value that no other application on the market today can match.

Is Blockchain's Capacity Limited To 7 Transactions per Second?

admin — Wed, 08 Aug 2018 22:03:15 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

I was recently asked to confirm if “the maximum theoretical processing potential of blockchain is 7 transactions per second.”

Claim: Blockchain’s capacity is only seven transactions per second.

Rating:

Origin

Numerous Internet postings and articles state that bitcoin’s capacity is currently seven transactions per second.

Bitcoin is far and away the largest cryptocurrency by market capitalization. It utilizes a blockchain, invented by the creator of bitcoin, which arranges transactions chronologically into blocks not exceeding one megabyte (1 MB, or 1,000,000 bytes) each. Blocks are confirmed by “miners” using a proof-of-work (POW) system which makes it computationally impractical for an attacker to reverse transactions when honest participants control the majority of central processing unit (CPU) power on the bitcoin network.

Currently, the bitcoin protocol targets a ten-minute interval between block confirmations which reflects a tradeoff between confirmation waiting time on the one hand, and waste of POW effort on the other. According to the Bitcoin Wiki:

After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.

The minimum bitcoin transaction size is 166 bytes; however, the Bitcoin Wiki says:

Users can also combine their transactions to make them slightly smaller … multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes … Using this technique aggressively results in 156 byte average transactions … A reasonable, conservative, assumption is … that every transaction requires two outputs, including change, and two inputs, consuming change … [giving] us 322 byte transactions .... Actual real-world rates will likely be somewhere between those numbers.

Consequently, if each transaction requires 156 bytes, then a single block can store up to 6,410 transactions (1,000,000 bytes ÷ 156 bytes per transaction), meaning that 6,410 transactions can be confirmed every 10 minutes (600 seconds). That’s 10.7 transactions per second on average. On the other hand, if each transaction requires 322 bytes then a single block can store up to 3,105 transactions and throughput falls to 5.2 transactions per second. Splitting the difference (and taking the integer portion only) works out to 7 transactions per second which “is commonly quoted as a ‘ball-park’ approximation in discussions of the blocksize limit,” according to the Bitcoin Wiki.

So, bitcoin’s maximum theoretical throughput is actually 10.7 transactions per second, not seven.

Bitcoin and blockchain are not the same thing

Moreover, bitcoin is a cryptocurrency whereas blockchain is a system for keeping electronic transaction ledgers. Bitcoin’s capacity is limited by constraints imposed to keep the cryptocurrency efficient yet secure by design; specifically, POW consensus, the ten-minute target interval between block confirmations and the 1 MB maximum block size. These constraints are needed because bitcoin’s ledger is a public, permissionless blockchain which anyone can join, including nefarious as well as honest actors.

Blockchain technology is useful not only for cryptocurrencies, but also in any situation that requires arm’s length parties to exchange information in a way that is permanent, tamper-proof and verifiable. When those parties belong to a private, permissioned blockchain, POW is a useless waste of CPU resources and is therefore not needed at all. As a result, because there is no POW effort to waste, there is no need to enforce any minimum time interval between blocks; network speed becomes the limiting factor.

The maximum block size of the blockchain bundled with the GM-X ERP software is 1 GB (1,000,000,000 bytes). As a result, based on the smallest possible bitcoin transaction size, its maximum theoretical processing potential is 6.4 million transactions per block, which would require no fewer than 80 seconds to transmit over Fast Ethernet (12.5 megabytes per second, or MB/s), equivalent to 80,125 transactions per second – well over 7,000 times bitcoin’s maximum theoretical throughput. Gigabit Ethernet would be ten times faster still.

In reality, our tests reveal throughputs up to 1,000 transactions per second under ideal conditions over a network of mid-range servers. Average conditions are more like 600 transactions per second. That’s anywhere from roughly 50 to 150 times bitcoin’s maximum capacity, and well beyond the capacity required for even the busiest of enterprise applications.

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

Blockchain Technology for Pharmaceutical Records

admin — Tue, 27 Feb 2018 04:41:00 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

The marketing, sale and distribution of drug products are regulated in most countries, and fully one-quarter of them uphold very robust regulatory regimes. They include the US and all the European Union (EU) member states as well as Argentina, Australia, Canada, Hong Kong, Iceland, Indonesia, Iran, Israel, Japan, Liechtenstein, Malaysia, Mexico, New Zealand, Norway, Singapore, South Africa, South Korea, Switzerland, Taiwan, Thailand, Turkey and Ukraine which collectively account for over 80% of global demand by revenue. The US alone generated about 45% of worldwide pharmaceutical revenues in 2016.

At the opposite end of the spectrum, just over another quarter of the world’s nations lack any regulatory regimes at all. They are concentrated in Africa, Asia, the Caribbean, Central America and the Pacific Islands. All of them are small, poor or isolated, and account for only a sliver of the worldwide pharmaceutical market.

In between, nearly half the world's nations enforce basic laws and regulations within their domestic markets, which together account for less than 20% of global demand. They include the BRIC countries (Brazil, Russia, India and China), of which India and China are also emerging as key exporters to other markets all over the world.

Documentation and Recordkeeping Mandates

In addition to setting strict standards for proving the safety, effectiveness and shelf life of medicines through clinical trials and stability tests, and licensing the marketing of proven products within those countries, robust regulation makes it mandatory for manufacturers and distributors to follow good manufacturing practice (GMP) or good distribution practice (GDP) standards, procedures and controls to:

Protect patient safety;
Provide quality assurance (conformance to specifications);
Control the flow of, and fully account for, all quantities of regulated drug products that are procured, received, converted, dispensed, consumed, made, sold, shipped, returned or disposed; and
Prevent the introduction of falsified or counterfeit products.

GMP and GDP standards, in turn, require manufacturers, contract manufacturing organizations (CMOs) and distributors to keep detailed documentation and records which prove their compliance with these regulations. Authorities have the power to conduct unannounced inspections and can issue warning letters, seek court orders, initiate product recalls and even revoke licenses to operate when records are found to be poor or incomplete, written procedures are inadequate, or systems are not controlled enough to prevent deviations from good practices. They can conduct these inspections not only within their own countries, but also reach beyond their borders to exporters whose products are imported into their domestic markets.

Mandates for Electronic Records and Signatures

Pharmaceutical manufacturers, CMOs and distributors, therefore, must shoulder a significant recordkeeping burden in order to legally serve the vast majority of their market. Although existing regulations do not preclude them from keeping documents and records on paper, a growing number rely on their enterprise resources planning (ERP) systems, manufacturing execution systems (MES), warehouse management systems (WMS), laboratory information management systems (LIMS), computerized maintenance management systems (CMMS) and document management systems (DMS) to do the job electronically.

In the US, electronic records have been regulated since 1997 under the Code of Federal Regulations Title 21 CFR Part 11. This defines criteria which electronic records, and also electronic signatures, must satisfy to be considered trustworthy, reliable, and legally equivalent to paper records. Section 10(e) states:

Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records, and to ensure that the signer cannot readily repudiate the signed record as not genuine. Such procedures and controls shall include the use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.

Section 30 sets out similar requirements for open systems, along with additional procedures and controls such as document encryption and use of appropriate digital signature standards. An "open system" is an environment, such as an application hosted by a third party, to which access is controlled by parties who are not responsible for the content of the records it holds.

A broadly similar set of regulations under Directive 2003/94/EC (GMP principles and guidelines in respect of medicinal products for human use) and related guidance (Annex 11: Computerised Systems) apply within the EU member states; however because it uses the word “should” instead of “shall”, Annex 11 Section 9 is somewhat more flexible than its US counterpart:

Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated ‘audit trail’). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.

Outside the US and the EU, another 20 countries have acceded to the Pharmaceutical Inspection Co-operation Scheme (PIC/S) which develops and maintains a GMP guide that is equivalent to EU GMP guidelines. This means there are only two sets of legal requirements which electronic records must satisfy—one for the US market, which accounts for about 45% of global pharmaceutical demand, and the other covering 48 additional markets both inside and outside the EU which account for about 35% of global demand. Manufacturers, CMOs and distributors who never intend to serve the US market would likely opt for the EU GMP guidelines, which only require them to “consider” implementing an audit trail based on a risk assessment; but anyone else—no matter where they are located—must adhere to the strictest rules which might apply and are therefore required to implement an audit trail.

Audit Trail Security Vulnerabilities

Most enterprise-grade ERP, MES, WMS, LIMS, CMMS and DMS software packages, including the GM-X ERP application, provide built-in audit trail capabilities which meet or exceed the regulatory requirements summarized above.

There is a problem, however.

All these audit trails are stored in a relational database management system (RDBMS). Although applications cannot modify them, anyone having sufficient access privileges and a knowledge of structured query language (SQL) can do so using a variety of database administration tools. This will generally include anyone having database administrator privileges.

Using database administration tools, no system controls exist to prevent someone from obscuring or deleting information that has been previously recorded. What’s more, nearly all ERP, MES, WMS, LIMS, CMMS and DMS software packages store audit trails in unencrypted form. Compared to encrypted records, it is much easier to modify an unencrypted audit trail without leaving a trace.

In most organizations, administrators gain access to the RDBMS by supplying a valid user ID and password. If these credentials are compromised—by a hacking attack, for example—an impostor could gain access to the RDBMS and alter its contents surreptitiously.

A wide range of information security practices, two-factor authentication (TFA) mechanisms and hardening techniques are available to prevent unauthorized access and tampering. But no matter how many of these defenses are employed, the best they can do is reduce exposure to security breach and consequential non-compliance risks. They cannot eliminate these risks.

Blockchain technology can.

How Blockchain Technology Keeps Audit Trails Permanent, Tamper-Proof and Verifiable

Operator identities, entries and actions that cause an ERP, MES, WMS, LIMS, CMMS or DMS application to create, modify, or delete electronic records can be captured as individual transactions. Using blockchain technology, new transactions are batched into blocks and cryptographically hashed in a Merkle Tree using a secure hash algorithm (SHA). Next, a block hash is formed from the resulting transaction root (root of the Merkle Tree), current timestamp and the hash of the previous block, a process which inextricably links the block to its immediate predecessor, and forms a chain which is stored in a blockchain database. The timestamp proves that the transactions must have occurred by then; otherwise they could not have been included in the hash.

Even though block hashes are irreversible, each block is self-certifying because its block hash is quickly and completely reproducible from the transaction data, historical timestamp and previous hash values currently stored with the block. To verify the integrity of these data at any moment in time, a reproduction is made and then compared to the current block hash. The block is deemed acceptable only if those values match.

From this explanation it should be evident that new transactions—even those reflecting the modification or deletion of existing records—can only ever be appended to a blockchain. It is not possible to delete or rewrite existing blocks on the chain because those alterations will always be rejected. As a result, the historical audit trail is always preserved in a permanent, tamper-proof and verifiable way.

Further, unlike conventional enterprise applications, blockchain technology is decentralized and operates over a network. Each node in the network holds its own complete copy of the blockchain database. New transactions propagate to every node. As soon as one of those nodes is able to form and verify a new block from these transactions, the block is automatically broadcast in the form of a message sent to all the other nodes. This process is fault tolerant and self-correcting: if a node fails to receive a message, it will automatically request the missing block from the other nodes whenever the next message arrives.

The node's blockchain server will append an arriving block to its local copy of the blockchain database only after it deems the block to be acceptable. In this way, even if an attacker were able to break into and alter the blockchain database at one of the nodes, the other nodes in the network remain pristine because they will always reject the attacker's alterations.

The decentralized nature and self-certification capabilities of blockchain technology completely eliminate the security vulnerabilities exposed by storing audit trails in a centralized RDBMS.

For further details and an illustration of these concepts, see pages 4 and 5 of our white paper. You can also read the original blockchain specification here.

The GM-X ERP for Blockchain Solution

For manufacturers, CMOs and distributors of pharmaceutical products, GM-X ERP for Blockchain is the world's first and only total solution for maintaining electronic documents, records and signatures in full compliance with all applicable US, EU and PIC/S regulations and guidance.

Various other ERP, MES, WMS, LIMS, CMMS and DMS applications may satisfy some of these requirements, but none provide a total solution:

None of them offer blockchain technology out of the box for securing audit trails.
Other ERP software packages currently on the market do not provide any electronic document management capabilities.
DMS applications, in turn, do not keep procurement, production, control or distribution records for products.
CMMS software packages are suitable only for keeping plant maintenance logbooks.
By definition, MES software does not satisfy any documentation and record keeping requirements beyond the plant floor.
Also by definition, WMS software does not satisfy any documentation and record keeping requirements beyond the warehouse.
And finally, by definition, LIMS software does not satisfy any documentation and record keeping requirements beyond the laboratory.

In the past, pharmaceutical manufacturers and distributors wishing to keep electronic documents and records had to select and deploy separate software packages for each of these functions. Integrating and maintaining all these packages is a time-consuming and costly endeavor.

The total GM-X solution comprises the Alert, Blockchain, Content, Inventory, Order, Menu, Party, Product, Shipment, Survey, Work Effort and Workflow subsystems.

Configuring a System-Generated Audit Trail on the Blockchain

During system implementation, various Blockchain Triggers are configured using the GM-X Blockchain subsystem. Tony Marston explains how to do this in his blog post, Adding Blockchain to an ERP System.

To illustrate how this can be done for electronic records, consider the following requirement which is distilled from US Title 21 CFR Part 211, Subpart J (Records and Reports), Sections 184(c) and 188; and also EU GMP Volume 4, Chapter 4: Documentation, Sections 4.8 and 4.21:

At the time each action is taken, the system must maintain an individual inventory record of each component and packaging material batch and, for each component batch, records of material issued to production, material used in production, material destruction, returns of materials that have not been used in production to storage, and reconciliation of the use of each batch of such component. The inventory record must contain sufficient information to allow determination of any batch of drug product associated with the use of each component, ingredient or packaging material (i.e. traceability).

In the GM-X system, the material master is the Product table, and the batch master is the Lot table. All inventories (also known as “quants” in a WMS, representing the stock of any material in one container having the same batch and serial number) are recorded in the Inventory Item table, including components and packaging material.

As with any WMS, staging material from storage to the production area, and returning unused material from the production area to storage, is performed in two steps using GM-X Transfer Orders. The first step creates records in the Item Issuance table when the material is picked up, and the second step creates records in the Item Receipt table when the material is dropped off. Both steps will update the Inventory Item table, but at different times. In between, the inventories are in transit and are tracked by way of the Package table. Creation of each Package will also create Outbound Package Content and Inbound Package Content records which have identical quantities, and are linked to specific Item Issuance and the related Inventory Item records. This makes it possible to reconcile material and batches sent from the pickup point with what was received at the drop-off point.

For material staging and returns, it is also possible to perform one-step material transfers without reference to a Transfer Order in the following ways:

Transfer some or all of the material in one Container to another Container. This creates records in the Inventory Item Movement table and also updates the Inventory Item table.
Move an entire Container and all its contents from one Facility to another. This creates records in the Container Movement table and also updates the Inventory Item table.
When Containers form a nested hierarchy of movable handling units, the Inventory Item table records material stored in Containers at the lowest level of the hierarchy; for example, material packed into shipping cases. When those cases are placed onto pallets, and the pallets are then placed in shipping containers, GM-X records the placements in the Container Movement table but there is no need to update the Inventory Item table because the contents of each shipping case haven’t changed.

No Item Issuance or Item Receipt records are created for one-step material transfers because no inventories have been withdrawn from or received into stock.

During weighing, dispensing, production and packing operations, GM-X handles the consumption or conversion of components (raw materials, ingredients or semi-finished products such as bulk tablets) and packaging material using Transfer Orders which create records in the Item Issuance table, deduct withdrawn quantities from the Inventory Item table, and also create corresponding records in the Package and Outbound Package Content tables. The Outbound Package Content records are linked to specific Item Issuance and Inventory Item records which identify the materials and batches which have been charged to work in process (WIP).

Upon completion of production, Transfer Orders are also used to receive finished packs and semi-finished products into stock. These create records in the Item Receipt table, add received quantities to the Inventory Item table, and also create corresponding records in the Package and Inbound Package Content tables. The Inbound Package Content records are linked to specific Item Receipt and Inventory Item records which identify the materials and batches withdrawn from WIP during the receiving process. In addition, records linking produced batches to the batches of components, ingredients and packaging material consumed in production are recorded in the Item Receipt Issuance Link table to provide traceability. This makes it possible to fully reconcile materials and batches issued to production with the use of materials and batches consumed in production.

The foregoing discussion proves that the GM-X ERP application fully satisfies the requirement given above, but how should GM-X be configured to maintain a system-generated audit trail of these entries and actions on the blockchain?

One way is to define the Item Issuance, Item Receipt, Inventory Item Movement and Container Movement tables as Blockchain Triggers.

To maintain a single, comprehensive audit trail, each of these Blockchain Trigger configurations can publish transactions to a single data stream belonging to a single blockchain. Transactions can be distributed to all nodes in the blockchain, either in plain text or encoded (encrypted). Plain text is suitable only for closed systems, but a closed system can be configured to distribute encoded transactions to assure confidentiality. However, if any of the nodes in the blockchain qualifies as an “open system” as per US Title 21 CFR Part 11, Section 30, then the distribution must be encoded.

No Trigger Column and Trigger Value entries are required because every insert, update and deletion affecting the Item Issuance, Item Receipt, Inventory Item Movement and Container Movement tables needs to fire a Blockchain Trigger which adds a transaction to the audit trail.

The illustration below shows an example of Related Tables for the Item Receipt trigger. This configuration only needs to be done once, when the GM-X system is being implemented, and requires very little time. Our recent experience demonstrates that it takes less than two hours for a trained implementer to fully configure all four Blockchain Triggers.

This illustration also clearly shows that the resulting audit trail will tell the whole story behind each and every action. Every Item Issuance transaction will record the quantity issued, the entry timestamp and the user who entered the transaction—plus, through the Related Tables:

Who performed each role required by the action’s standard operating procedure (Organization and Item Issuance Role together with the full name and ID of the Person who performed the action).
What was issued (Lot details, including the batch expiry date; Product ID, name and unit of measure; Container ID, type and description; and visible Package ID).
Where the action occurred (Facility ID, name and type).
When the action occurred (dates in the Package Status History when the Package status changed).
Why the action was performed and for whom (Sales Order number plus the full name and ID of the external customer Organization; or Transfer Order number plus the full name and ID of the internal receiver Organization).
How the action was carried out (the Picklist Detail information utilized).

Here is another mandate distilled from US Title 21 CFR Part 211, Subpart J (Records and Reports), Section 188; and also EU GMP Volume 4, Chapter 4: Documentation, Sections 4.20 and 4.21. It requires manufacturers and CMOs to keep batch production records:

The system must keep batch production records including dates; times (when appropriate); identity of major equipment used; manufactured material number and name; manufactured batch number and quantities; batch numbers, quantities and weights of raw materials, intermediates, or any reprocessed materials used; any sampling performed; in-process and laboratory test results; actual yield at appropriate phases or times; results of release testing; all analytical records relating to the batch (or a reference that will permit their retrieval) and a usage decision, with the date and signature of the qualified person (QP) who made the decision.

Many pharmaceutical manufacturers and CMOs record this information on paper forms known as “travelers” because they move through production along with the manufactured batches. Operators write this information onto the forms and sign them by hand. In the past, they were then filed away in vaults during the required retention period.

Today, many of these organizations have found that scanning these forms, and uploading the scan copies into a DMS, is more expedient and cost-effective than deploying electronic data collection systems in production areas and laboratories. Using the GM-X Alert and Workflow subsystems, they can upload these files into the controlled GM-X document repository and then obtain the QP’s electronic signature. A Blockchain Trigger for the Alert table causes the GM-X Blockchain subsystem to publish these files on the blockchain, together with the document metadata and electronic signatures, thus forming a permanent, tamper-proof and verifiable audit trail of production batch records.

The same Blockchain Trigger configuration can also be used for static documentation such as standard operating procedures and work instructions.

Accessing and Reading Electronic Records and Signatures on the Blockchain

To facilitate inspections, all US, EU and PIC/S regulations and guidelines require electronic audit trails to be retrievable and readable by agency personnel. Pharmaceutical manufacturers, CMOs and distributions also make frequent use of these audit trails when conducting internal audits and investigations.

The GM-X Blockchain subsystem provides an interactive task for viewing electronic audit trails directly from the blockchain. Because GM-X is a responsive Web application, this task runs in any modern browser installed on a desktop or laptop computer, tablet computer or smartphone. It will automatically decrypt any data and files which are encoded on the blockchain.

The simplest blockchain network has two nodes. The primary node is connected to the GM-X ERP application where users enter transactions and upload documents that are published to the blockchain. The secondary node holds an archive of the audit trail in its copy of the blockchain database. A separate instance of the GM-X ERP application is connected to the secondary node and provides access to the viewing task. It has its own Logon screen and role-based access controls, and requires only the GM-X Audit, Blockchain, Menu and Content subsystems.

With this configuration, only the primary node can publish new transactions to the blockchain. The secondary node can receive new transactions from the primary node, and verify them, but is only permitted to read its copy of the blockchain database. Both nodes connect to one another over the organization’s private local area network (LAN) or corporate wide area network (WAN) to form a closed system.

Alternatively, the secondary node and its instance of the GM-X ERP application can be hosted in the public cloud. This node and its GM-X instance are accessed over the public Internet and form an “open system” which means that transactions and documents must be encoded before they are published to the blockchain.

Nodes can always be added to the blockchain to handle situations which are more complex. For example, many pharmaceutical manufacturers and distributors utilize third-party logistics (3PL) providers and CMOs. If some of the transactions to be recorded in the audit trail originate from third parties, each party can publish transactions at its own node, using its own GM-X instance. Similarly, larger pharmaceutical enterprises can run separate instances of the GM-X ERP application at multiple nodes. No matter where they originate, all transactions will be added to a consolidated copy of the audit trail which will be visible at the secondary node.

Extra secondary nodes can also be added to address business continuity and disaster recovery requirements.

GM-X ERP for Blockchain: Your Total Solution for Electronic Records and Signatures

Geoprise Technologies has many years of experience successfully implementing, validating and using ERP, MES, warehouse management, laboratory management and document management systems at numerous pharmaceutical sites of all sizes across four continents—including five of the world’s top 20 pharmaceutical enterprises.

We have applied our industry knowledge and cumulative experience to build GM-X ERP for Blockchain, the world’s first and only total solution for maintaining electronic documents, records and signatures in full compliance with all applicable US, EU and PIC/S regulations and guidance.

GM-X ERP for Blockchain is also the world’s first and only ERP application to incorporate proven blockchain technology out of the box. Blockchain technology eliminates a known security vulnerability affecting conventional electronic audit trails which exposes pharmaceutical manufacturers and distributors to potentially serious non-compliance risks.

Our blockchain solution is already available, requires no complex programming effort or interfaces, and can be configured to properly maintain a full and completely secure audit trail in a matter of hours. By comparison, we know that other software vendors are only beginning to explore blockchain technology, or initiate custom pilot projects for selected clients. It will take considerable time and expense for their efforts to bear fruit. If you can’t afford to wait that long, I invite you to evaluate GM-X ERP for Blockchain now, and the Geoprise team looks forward to serving you in the near future.

Adding Blockchain to an ERP System

admin — Fri, 16 Feb 2018 09:33:37 +0000

Pictured above: a new block is added to a venerable structure with the help of a framework

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

GM-X is an enterprise resources planning (ERP) system which was first created in January 2007 and went live at the first customer in June 2008. It was designed from the ground up as a Web application comprising a group of interconnected subsystems, and was developed using the RADICORE framework which I built in 2002 and published in 2006. GM-X has been continually enhanced and new subsystems added since its debut. Today it has 17 subsystems.

Each subsystem has its own database and its own collection of tasks (user transactions). Currently there are 389 tables, 759 relationships, and over 3,000 tasks.

We recently added a new GM-X subsystem for Blockchain management, and how this came about is the subject of this article.

In mid-October 2017, Nelson Nones, the Founder of Geoprise, contacted me and asked, “What do you know about blockchains?” “Nothing” I replied. He then described an idea which he’d been mulling over for some while. His idea began to seem more plausible after he discovered a product called MultiChain which is able to send large volumes of data between nodes on a blockchain, not just financial transactions as is the case with Bitcoin. This appeared to be possible using MultiChain data streams.

Over the next few weeks we discussed what MultiChain could do and how we could use it in our ERP application. We recognized straight away that using it in a stand-alone application would be a waste of time. Any blockchain requires a network of at least two or more nodes, so we needed a use case in which many organizations need to share information with one another. Nelson immediately brought up a use case which GM-X currently addresses for a major client of ours who procures products from a network of suppliers. This currently has the following steps:

The Buyer constructs a request for quotation (RFQ) and sends it to eligible Sellers.
Each Seller examines the RFQ and, if interested in the business, prepares a Quote which is then sent back to the Buyer.
The Buyer examines the various Quotes submitted by Sellers, chooses one of them, and then raises and sends a Purchase Order (PO) to the winning Seller.
The Seller fulfils the order and sends an advance shipment notice (ASN) to the Buyer.
The Buyer receives the shipment, matches it with the ASN and books it into inventory.

Long ago this communication was done by sending letters back and forth in the post (later, emails), but is most commonly handled nowadays by the Buyer setting up a Supplier Portal Web site which each Seller can log into to transact with that Buyer. But such a system has two disadvantages. First, on top of their own ERP system most Sellers need to learn and use many different Supplier Portals, one for each customer, which often requires double entry of transactions. Second, the Supplier Portal is available over the public Internet, and although each Seller has its own unique login it is well known that any Web site which is accessible by the public can be attacked and infiltrated by people with nefarious intentions.

So how can a blockchain solve these problems? For starters, it eliminates double entries by connecting the Sellers’ and Buyer’s ERP systems directly. This is conceptually similar to old-fashioned electronic data interchange (EDI) but much simpler, faster and less expensive to implement. It is also far more secure than EDI or the Internet:

All the ERP systems remain safe and secure behind their respective organizations’ internal firewalls.
Blockchains are not accessible via HTTP or HTTPS ports and are completely private.
No one can join the blockchain at will. They must be specifically invited.
When the invitation is accepted a new node is added to the network and its credentials are shared with all the other nodes.
When a node publishes a message, it is first validated by all the other nodes before being either confirmed or rejected. Using MultiChain, the message can be a block of data up to 64 megabytes (MB) in size.
Confirmed messages are then sent to every other node on the network, and then added to each node’s copy of the entire blockchain.

Once a message has been added to the blockchain it cannot be amended, so the copy of the blockchain database at each node holds a complete audit trail of every message sent. This makes the data permanent, tamper-proof and verifiable, and eliminates the reconciliation burden for trading partners.

There now follows a list of questions we asked ourselves in order to identify the various points which need to be addressed in our solution.

How could we utilize a blockchain in GM-X?

Although each blockchain maintains its own database of all messages which are sent, this is not a relational database which can be queried using SQL statements. We decided that each node would have its own local copy of GM-X and its relational database(s), and would only use the blockchain when data from that node needs to be sent to other nodes. Upon receipt of such a message each node would extract the message and copy its contents to its own copy of the GM-X database. Some people have suggested that the blockchain database may remove the need for a relational database, but the relational database maintains the current picture while the blockchain maintains a history of changes which result in the current picture.

How could we send data across the blockchain?

For data, each message can be either plain text or binary so the possible formats can be quite varied. Having used several different formats over my long career I chose eXtensible Markup Language (XML), mainly because I have used it extensively since 2002, both in the RADICORE framework and GM-X Web services integration. A series of functions already existed which could take data out of one or more records in one or more database tables, put that data into an XML document before it is sent, extract each table’s data from the XML document after it is received, and finally apply it to the database at the receiving end. Although XML documents can be quite large, as plain text files they can easily be zipped to make them smaller.

GM-X also manages documents and other multimedia content which is stored in files (for example, PDFs) instead of tables and records in a database. For these, the file contents will be placed in the XML document along with its metadata.

How could we ensure that only selected nodes could read a particular message?

As noted earlier, every node in a blockchain receives a copy of every message. This means that every node can read every message, which is a problem whenever a message is private and confidential. Fortunately, MultiChain provides a mechanism for protecting confidentiality which ensures that each message can only be read by authorized nodes. This uses two additional data streams, one (“public keys”) to hold each authorized node’s public key, and the other (“access”) holding the password for a particular message. There is a separate entry on the “access” stream for each combination of recipient node and message. Each of these entries is encrypted with the receiving node’s public key so it can only be decrypted with that node’s private key. Private keys are NEVER published on the blockchain (or anywhere else for that matter) so confidentiality is assured.

How could we know when to send data over the blockchain?

Changes to the database are made using a SQL query containing an insert, update or delete operation on a table. It is not necessary to send every database change over the blockchain network, so what’s needed is a signal which means, “When an insert, update or delete operation is performed on table X then send a blockchain message”.

Instead of inserting code into individual application components to identify when a message needs to be sent and what it should contain, we decided instead to build a separate Blockchain Trigger class which the RADICORE framework could automatically examine whenever an insert, update or delete operation is performed. This allows us to configure the signals which cause blockchain message to be sent, without amending any application code.

How could we know when to send data from related tables as well as the target table?

In some cases, like simple lookup tables, it is only necessary to send data from a single table across the blockchain network. Most of the time, however, the data is spread across several related tables whose contents are maintained by several other tasks, so we needed a mechanism to identify which additional tables to include in the blockchain message, even if they were not amended during the same task.

We decided to build a Related Tables class associated with the Blockchain Trigger class which identifies all the additional tables (if any) required for the data extract.

If related tables are involved, how could we delay the blockchain message until the collection of data is complete?

An entity such as an RFQ is not restricted to a single record on a single table. Each RFQ has one or more line items, and each of those line items has a foreign key to a record in the Product table which needs to be included as well. In situations like these the message shouldn’t be sent until the entire collection is complete.

In such cases the relevant “header” table in the GM-X application always has a status which starts off as “Pending” and can progress through any number of other states such as “Approved”, “Sent” and so on. We therefore decided to include a mechanism which postpones the sending of messages until the specified status is attained. This type of trigger isn’t fired with an insert or delete operation, only an update.

How could we identify the blockchain address for each node in the blockchain?

Each node in the blockchain is identified by a 38-character address. Each node is also a separate organization, so it has its own entry on the Organisation table of the GM-X Party database. Each party, in turn, can have any number of Contact Mechanisms of different types representing postal addresses, telephone numbers and email addresses, so we decided to add a new type which identifies blockchain addresses.

How could we identify which nodes should receive the key to unlock each message?

It is rare to want to send a message to every node on the blockchain, so for each message we needed a mechanism to identify the list of authorized recipients. Where GM-X already had a table identifying a list of valid parties, we amended it to hold each party’s blockchain address. Otherwise we had to create new tables for these data, and make the application aware of them, but this was relatively painless using the RADICORE framework.

How could we ensure that data which uses technical keys generated at one node does not conflict with similar data generated by other nodes?

Each node in the blockchain has its own copy of the GM-X application and database(s), with certain tables having primary keys which are supplied from running number sequences. These are known as technical or surrogate keys. As a result, it is possible for different nodes to send messages having conflicting primary keys. For example, when different Sellers independently generate the same quote number for different Quotes, how is it possible to avoid a collision at the Buyer’s application?

Geoprise was already well-versed in standards, such as GS1, for assigning globally unique identifiers to a wide variety of business objects. All these standards incorporate a globally unique company prefix, so we decided to change our primary keys from a simple 10 digit running sequence number to a 38-digit number which has two parts—a leading 12-digit company prefix followed by a 28-digit running sequence number. Why 38 digits? If we have to change the database then go straight to the biggest number available and so avoid having to increase it again at some point in the future.

After analyzing the various points which our solution needed to address, next came the tricky part—actually implementing a solution as Proof of Concept (PoC).

Starting late November 2017, I downloaded the MultiChain software and installed it on two workstations connected to the same local area network (LAN). I also downloaded the MultiChain Web Demo which is written in PHP, the same language as GM-X. This gave me valuable information on how to use the various JSON-RPC API calls which allow the GM-X application to communicate with MultiChain. My next step was to create two new PHP scripts—one acting as the client to send messages out, and another acting as the server to receive messages at the other end. I did this to test the code dealing with public keys and access streams which is responsible for encrypting and decrypting messages. This involved using the PHP OpenSSL and Bzip2 extensions. I used these two scripts to send an encrypted message from one workstation, then show the decrypted message on the other. At this point each message was constructed manually as I had yet to write the code to extract data from the GM-X database.

Having successfully completed the PoC, we decided to develop a working prototype using three GM-X servers. At least three servers were needed in order to demonstrate sending messages to all nodes as well as a selected node. The goals were to:

Send changes to a single table;
Send changes to a group of related tables; and
Send a disk file along with data from a database table.

My first step was to build the Blockchain Trigger and Related Tables classes as well as the tasks to maintain them.

This is what the Update Blockchain Trigger task looks like:

In this example, a blockchain trigger has been set up for the order_header table with reference to the Alias order_header_p which is for purchase orders.

The Trigger Column and Trigger Value entries work together as follows:

If both are empty the Blockchain Trigger will be fired on every insert, update and delete affecting Table Id;
Otherwise it will only be fired on an update, when the Trigger Column contains the Trigger Value (‘Sent to Supplier,’ in this example).

The Distribution Table entry must be empty unless ‘Database table’ is selected from the Distribution Type dropdown, in which case the Distribution Table is either the Table Id, or a table which is directly related to the Table Id.

This is what the Update Related Table task looks like:

Here the term “Node Id” doesn’t refer to nodes (addresses) within a blockchain. It is the node in a tree structure where a senior node can have any number of child nodes in a hierarchical arrangement.

The validation rules for this table are made easy simply because of the way in which the application components are arranged, which in turn is determined by the RADICORE framework. Every GM-X subsystem has a Subsystem Directory as well as a database comprising a set of tables, each having a unique Table Id. Each table in the subsystem’s database has its own class. In some cases, a table class may have several subclasses, each having a unique Alias such as order_header_p for purchase orders (illustrated above), or order_header_s for sales orders.

When a table class or subclass is instantiated into an object it provides the following information:

Field specifications for every column in that table.
Options, if a dropdown list is specified for the field.
Child (junior) tables, identifying the Table Id, Alias (if any) and the Column names which link the two tables.
Parent (senior) tables, also identifying the Table Id, Alias (if any) and the Column names which link the two tables.

This means, for example, that the dropdown list of tables within a subsystem can be populated as soon as the user identifies a Subsystem Directory. Likewise, as soon as the user identifies a table, the dropdown list of Trigger Column values is populated (but may be left empty); and the dropdown list of Trigger Values is populated as soon as the user identifies a Trigger Column. If the ‘Database table’ option is selected from the Distribution Type dropdown, then the Distribution Table dropdown is populated only with tables that have a Contact Mechanism column representing blockchain addresses.

This design makes it possible to construct a hierarchy of related tables which are to be extracted similar to what is illustrated below:

Note here that a Party may be either an Organization or a Person, so only one of these child tables will actually contain data. This is an implementation of Silverston's Universal Data Model for parties.

This takes care of identifying which tables will be the subject of data extraction when a Blockchain Trigger is fired, but the next step is to actually fire the trigger when the relevant table is modified. Again, the RADICORE framework made this process surprisingly easy:

Each table in the database has its own table class, which may have subclasses.
The table class and any subclasses are specializations of a single abstract table class, and inherit methods from the abstract table class which perform the insert, update and delete operations.

It was therefore easy to amend the abstract table class to call a new function at the end of each of those methods to check if a trigger could be fired. The function is passed the following parameters:

The method name (‘insert’, ‘update’ or ‘delete’).
The current Table Id.
The Alias name (if applicable).
The current data for this table in an associative array.

Using this information, it is straightforward to perform a lookup on the Blockchain Trigger table to see if it contains a record which matches the current information. If it does then the following data is stored in a global variable:

The Trigger Id.
The method name.
The primary key of the affected record.

Note that the trigger is not actually fired at this point as the operation is within a database transaction. If there is a failure down the line then the transaction is rolled back and the trigger never fired. It is only when the transaction is eventually committed that the trigger is actually fired.

blockchain_send.php

I had originally thought I could execute the necessary code as part of the online transaction but eventually decided to launch a background task instead as this avoids any delay in processing the online task. I therefore extended the code I had built earlier for the PoC, to read the Blockchain Trigger table as well as the application table that was just modified. As it is passed the primary key of the affected record it knows which one to read. It then starts building the XML document which will be published on the blockchain using the following format:

The method is either ‘insert’, ‘update’ or ‘delete’ and table is either the Table Id or its Alias (if applicable). Then follows an element for each column in that record with its value.

If that table has any related tables which should be included in the extract it will also contain one or both of the following elements:

Note that each parent_tables or child_tables element can contain any number of records from any number of tables. Each of those records can, in turn, contain their own collections of parent and child records. This is a fully recursive process, so it processes all the Related Tables until there is nothing left.

For delete operations, there is no need to supply any data other than the primary key of the trigger table. Any cascade deletes will automatically be performed when the message is processed at the receiving node.

If any record refers to a file then its contents are inserted into the XML document after being base64 encoded.

blockchain_receive.php

The last step was to execute a script at the receiving node in order to extract a message and process its contents against the local GM-X database. MultiChain provides a mechanism called walletnotify to run an external program upon receipt of a message. I created a new script called blockchain_receive.php by extending the code I had built earlier for the PoC.

This script does not need to use the Blockchain Trigger class because everything it needs is contained within the XML document. The root node identifies both the starting table and the method, so it is a simple process to navigate through the XML document and process each record one at a time. The table value identifies which table class needs to be instantiated into an object, then that table’s data is passed to that object using the specified method.

For insert and update operations, a special “insert or update” method is actually used which will check if a record with that primary key exists before performing the insert or update operation as appropriate.

Note also that if a record contains any entries in parent_tables then these will be processed before the record itself. Any child_tables entries will be processed afterwards before moving on to the next record in the XML document.

After completing the coding and testing I then uploaded everything to the GM-X servers, and just before New Year’s Eve I demonstrated the results to the Geoprise stakeholders. I showed that I could update a record on one node and propagate it to one or more of the other nodes. I further showed that I could send data from a collection of related tables, and also that I could send files as well as data. Whilst building the working prototype I also managed to change some technical primary keys from 10 to 38 digits to demonstrate that using a leading 12-digit company prefix followed by a 28-digit running sequence number was a practical proposition. (Note: as of February 2018, all sharable GM-X technical primary keys have been changed in this manner.)

All the Geoprise stakeholders were impressed that I could accomplish so much is so little time, but this was only possible due to the design of the RADICORE framework which is centered around performing standard SQL operations on database tables. It was therefore a relatively simple process to identify when a particular operation was performed on a particular table, extract that data into an XML document, and then send that document to a blockchain. At the receiving end a script would extract the XML document from the blockchain database, then send each table’s data to the object which dealt with that table.

Because the sending of messages containing application data over the blockchain can be configured and managed within the framework and without having to modify any application components, this provides a simple yet flexible and powerful solution to a complex problem. As a follower of the KISS Principle this seemed the right thing to do.

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 - Blockchain

What? Another General Ledger Application?

Tags:

Is Blockchain's Capacity Limited To 7 Transactions per Second?

Tags:

Blockchain for Blockheads

Tags:

Blockchain Technology for Pharmaceutical Records

Tags:

Adding Blockchain to an ERP System

Tags:

The Inside Story of GM-X ERP for Blockchain

Tags: