All aboard the Blockchain train!

ADM: What are the basic concepts of blockchain that developers need to understand?

Little: Perhaps the biggest concept developers need to understand is that smart contracts need to be deterministic. Developers may treat a smart contract as just another service. However this "service" executes in an entirely different environment and is executed multiple times for a given request. This means that for the same world state and same inputs, the outputs and the new world state need to always be the same or deterministic. The requirement comes from the fact that smart contracts are executed multiple times for the same transaction, and to achieve consensus each execution must perform the same actions. Making the smart contracts pure functions that only depend upon the inputs and the world state is one way to ensure deterministic behavior.

Another concept that may not be completely obvious to traditional developers is that of transaction finality. Unlike current day transactional systems where transactions complete almost immediately or within milliseconds, with permissionless blockchains like Ethereum or Bitcoin it may be minutes or much longer before a transaction can be considered final. Blockchains that use Proof of Work to achieve consensus provide essentially no guaranteed transaction finality. This means as that as long as your transaction is on the longest chain and more importantly stays on the longest chain, your transaction is indelibly recorded in the ledger. However there is never a guarantee that your transaction won't somehow be undone as a result of a longer chain being discovered. Permissioned blockchains, like the recently announced Oracle Blockchain Cloud Service, use consensus mechanisms that can guarantee finality and can typically finalize a transaction in less than a second.

Only store information in a Blockchain that has to be stored there. The data is replicated, and can potentially cause an explosion in storage requirements. It's easy to fall into the trap that all application state will be stored on the blockchain and simply treat the blockchain as a distributed database. For some applications that may make sense, but don’t forget that all transactions are recorded on the blockchain, and currently those transactions are retained forever. This has significant implications for things like General Data Protection Regulation (GDPR) that may require information to be forgotten. Blockchains are currently designed to remember everything, so storing GDPR-impacted data requires careful thought and consideration.

ADM: How does the process work when programming for blockchain?

Little: Blockchain is never a standalone thing, it's always part of one or more applications. Blockchain based applications share many aspects of traditional distributed applications. There will typically be some sort of front-end, perhaps mobile or web-based, using something like Node.js. Much of the core business logic will be developed ideally as microservices, of which some will be implemented as smart contracts. Where things will be quite different is how you decide upon your services and state management. Since the state maintained on the blockchain is typically visible to multiple participants, you'll need a way of safe guarding it, or only storing information acceptable for participant viewing. In addition, there are likely multiple copies of the world state maintained in the blockchain, so storing very large items is probably best done off chain, and only a hash of the information is stored on the blockchain.

The division of microservices vs smart contract is largely a design and architecture consideration. The programming environment of some smart contracts is very similar to traditional microservices environments with a few exceptions. Most blockchain platforms provide only primitive state management, typically just a simple key/value store. For developers most accustomed to relational databases with many keys and flexible queries, this will come as a bit of a shock. It requires rethinking how the world state is organized and accessed.

The general process will be something along the lines of:

1. Business use case analysis and modeling the business processes that are to be automated by the blockchain.

2. Design, develop, and test the smart contracts containing the business logic.

3. Develop or modify the applications that will use the smart contracts.

4. Test the applications against the smart contracts.

5. Determine the business network configuration, i.e., what organization will be the network founding member, and what other organizations will participate in the network. This includes defining things such as what is required for consensus. For example, with the Oracle Blockchain Cloud Service, this will include defining the channels (individual ledgers), who participates in each channel and what endorsement policies are required for each smart contract to ensure the business trust (consensus) requirements are met.

6. Deploy the business network. For Oracle Blockchain Cloud Service this includes adding the appropriate organizations and their peers to the network, creating the necessary channels, and deploying the smart contracts to those channels.

ADM: What sort of projects benefit the most from using blockchain technology?

Little: The strength of blockchain is in distributed applications where multiple organizations or applications are involved. Blockchain allows all the organizations involved to participate in ensuring that the ledger is accurate and agreed upon. Any type of application where there is a separate reconciliation process is typically a good fit for blockchain technology due to the fact all organizations will have a common view of the ledger, i.e., a single replicated source of truth.

Even applications that currently use a central system can benefit from adopting blockchain and moving to a distributed environment. By doing so, one gains in availability due to the distributed and redundant nature of blockchain, but perhaps more importantly, it becomes much harder for an attacker to subvert the application. This is largely due to the consensus mechanism involved in blockchain that requires multiple endorsers/consenters/validators in order for a transaction to be processed. In centralized systems, the attacker may only need to subvert the security of a single system.

ADM: How is Oracle using Blockchain?

Little: Oracle is in a unique position in the enterprise software industry in that it offers complete SaaS application suites for ERP, HCM and CX, plus best-in-class database Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) from data centers throughout the Americas, Europe and Asia. In addition we have industry verticals such as healthcare, financial services, hospitality, retail, telecoms and more. We are using our domain knowledge and working with customers to identify the most beneficial places to deploy blockchain, working on prototypes, and supporting customer co-innovation projects across a wide variety of use cases. Instead of building a new version of our applications that run on blockchain, we feel the best approach is finding the areas where data needs to be securely shared across traditional enterprise boundaries. The key is to look for a narrow use case where value can be added in the short/medium term.

One promising area our customers are interested in is internal trading, particularly among large global enterprises that have multiple systems for subsidiaries or maybe acquire companies. Using a blockchain ledger, we can track intercompany activity and have a real-time and self-reconciled view of ownership, action items, regulation and compliance. We can also help manage the internal supply chain, where goods are often transported across borders and knowing where each is at any point in time is beneficial. Customers are comfortable bringing internal trading partners onto a network, proving the technology, proving the business value and then will consider adding external suppliers or customers onto the network. We are working similar examples with financial services, expense management, loyalty points schemes and many others.

ADM: What do you see blockchain replacing in 5 years?

Little: From a business perspective, blockchain will replace or significantly disrupt businesses that act as trusted intermediaries. On the technology side, many existing distributed applications rely on things like messaging to exchange state information. Unless there is some transaction coordination mechanism like a transaction manager involved there are likely to be cases where copies of state information become inconsistent. Blockchain eliminates this problem by providing facilities to ensure all copies of state are identical and that state transitions are atomic. Messaging will continue to be a major integration mechanism, however blockchain will displace many such businesses due to the improved accountability, visibility, and in particular, blockchain's ability to provide non-repudiation.