Satoshi Nakamoto’s vision of a revolutionary peer-to-peer version of electronic cash published in 2008, “Bitcoin: A Peer-to-Peer Electronic Cash System,” quickly took the developer community by storm. And while it was bitcoin and the concept of cryptocurrencies that first caught the world’s imagination, Nakamoto’s paper also described a second concept: blockchain. This ledger-based system could serve as a transport mechanism for not only bitcoin, but also for any digital object whatsoever.
But what are the best practices for creating effective blockchain applications? Simply putting data on a blockchain and manipulating it with code contained in smart contracts, a.k.a. chaincode, isn’t enough. To be successful, developers need to master a number of architectural domains and best practices. This article provides a set of key best practices that can help you create successful blockchain applications.
Leverage existing use cases
Before starting development of a blockchain application, the dev team needs to leverage existing use cases that describe best practices for the business problem they intend to solve.
At this point, it’s helpful to consider IBM’s three golden rules for blockchain:
- There must be a business problem to solve
- There must be an identifiable business network
- There must be a requirement for trust in the network
IBM also has an extensive go-to page of successful blockchain uses cases that developers can use before starting their development.
No dev team should start development without having one or more use cases as their guide. And for existing use cases, the supply chain space provides by far the most popular and successful use cases.
More information on coffee use cases can be found in “Coffee supply chains are now going the blockchain way.”
Another helpful resource is the IBM Developer code patterns for blockchain, which offer ready-to-use open source code that developers can use out of the box.
Clone an existing application
Blockchain technology is still relatively new and many dev teams may not feel comfortable working with it unless they have considerable experience. That’s why you can find blockchain apps popping up in clearly delimiting areas such as supply chain and, more specifically, supply chain for coffee. Once a dev team has achieved success in one business area, such as coffee supply chain, they will often find a number of clones popping up that adopt existing solutions to new and similar business areas, such as coffee in different geographical areas.
Since many blockchain apps are open source, especially those that use different dialects of Hyperledger such as Hyperledger Fabric, a recommended first step for a newly minted dev team is to clone an existing blockchain app and apply it to a slightly new domain. Here, blockchain apps in the coffee supply chain provide a good starting point.
And speaking of our blockchain development team — what should it look like? The team should include:
- An experienced chief architect with deep knowledge of cryptography, performance, and best practice blockchain architectures
- A domain expert, on par with the architect
- A few developers and blockchain operators
This makes for a total of about six developers to start with — a number that may well grow as the project grows. Funding is outside the scope of this article.
Understand Fabric concepts
A good overview of the basic must-know blockchain concepts embedded in the Hyperledger Fabric framework can be found in the article “Blockchain basics: Hyperledger Fabric.”
Here are the key components:
- Assets — What you put and search for on the blockchain, using smart contracts.
- Shared ledger — The ledger records the state and ownership of an asset.
- Smart contract (or chaincode) — Chaincode is software that defines assets and related transactions.
- Ordering service — The ordering service packages transactions into blocks and guarantees the transaction delivery in the network. Key ordering services are Raft and Kafka.
As I mentioned earlier, the best way for a dev team to quickly come up to speed on these concepts is to re-implement an existing open source project such as the Blockchain Bean or another successful open source Hyperledger Fabric project.
Choose the right platform
There are many platforms and development tools for creating blockchain applications. This article focuses on the following three:
- Hyperledger Fabric
- Visual Studio Code
- IBM Blockchain Platform
Hyperledger Fabric is an open source project that’s managed by the Linux Foundation. It is intended as a foundation for developing blockchain applications or solutions with a modular architecture. Hyperledger Fabric allows components to be plug-and-play. Its modular and versatile design satisfies a broad range of industry use cases, and it offers a unique approach to consensus that enables performance at scale while preserving privacy. In addition, Hyperledger Fabric comes with superb documentation.
Visual Studio Code
Visual Studio Code with Blockchain VSCode extension helps developers create, test, and debug smart contracts, connect to Hyperledger Fabric environments, and build applications that transact on your blockchain network.
After deciding on a use case, the dev team uses Hyperledger Fabric with the VS Code extension to create a blockchain application with smart contracts. The VSCode extension comes with a tutorial gallery that is easy to follow and focused on manipulating the blockchain with smart contracts.
We use the VS Code extension to create, package, install, instantiate, and submit and evaluate smart contracts.
Figure 1. VS Code extension process flow
More information on smart contracts can be found in the code pattern “Create and execute a blockchain smart contract.” Smart contracts are the primary way to create blockchain applications.
The VSCode extension tutorial gallery is the obvious place to start learning how to create blockchain applications with smart contracts in Hyperledger Fabric and IBM Blockchain Platform.
IBM Blockchain Platform
IBM Blockchain Platform is a cloud-based platform for creating and running blockchain enterprise applications on the infrastructure of your choice. You can now deploy the IBM Blockchain Platform to public clouds like IBM Cloud, AWS, or Azure — or deploy on-premises in private clouds with secure infrastructures like LinuxONE.
Although most dev teams start their development journey with Hyperledger Fabric or some other favor of Hyperledger, they will almost certainly end up deploying their apps in the cloud, either on a public cloud or in multiple clouds in different configurations.
The ledger and the blockchain
Figure 2. The heart of a blockchain system
Once they have identified a well-documented use case, the dev team then focuses on architecting a business network. The business network uses a shared ledger that’s accessible to all participants. (I mentioned ledgers in the section 3 above.) Business ledgers have been around for a very long time, as a way to manage business transactions. But traditional ledgers have always come with the need to reconcile the ledgers of each business participant with that of all others in the business network — which can be both laborious and error prone.
Doing away with reconciliation by forcing all members in a business network to use the same shared ledger is a historic innovation. Discarding reconciliation also means that consensus takes pride of place in the business network. All members in the network have to agree before any transactions can be placed on the ledger.
The ledger uses a shared blockchain with the following characteristics:
- Consensus such as Raft or Kafka, helps achieve crash tolerance for the blockchain.
- Cryptographic hashes, such as SHA256, flag any changes to transactions on the blockchain.
- Digital signatures ensure that transactions have not originated from impostors.
- Provenance traces where an item on the blockchain is coming from.
- Immutability ensures that data placed on the blockchain cannot be changed.
- Finality ensures that transactions are immediately considered finalized once they are included in a block and added to the blockchain.
For more on ledgers, read “Blockchain basics: Introduction to distributed ledgers.”
On-chain and off-chain
However, for the dev team it is not just a matter of plugging in a blockchain and starting to run. They must start by determining what data does and does not belong on the blockchain. For example, it is simply not feasible to put gigabytes or terabytes of data on a blockchain if you want to be able to do rapid searches — and searches are one of the must-have features that a blockchain provides.
Also, some data may already exist in efficient, tailor-made databases that need not be ripped and replaced. Rather than have the blockchain grind to a halt, it is better to keep key data on the blockchain with links to off-chain data as needed. The off-chain concept is key for developing successful blockchain applications. This means that your blockchain app is part of existing applications that do not need to be ripped and replaced unless absolutely necessary.
And finally, don’t forget that personal data can never be put on the blockchain without first being anonymized because of data privacy laws such as the EU General Data Protection Regulation (GDPR).
A key advantage that blockchain provides is the ability to search the chain of blocks and quickly find key data — something that is impossible with the paper records that are still, amazingly enough, often being used in many traditional ledgers. Many blockchain solutions allow businesses to digitize hard-copy forms with the blockchain supporting the evidence and digital signature of the form.
Another common use case of off-chain storage is to support a cache of the most recent values of the state of on-chain data, or to leverage fit-for-purpose technology, such as advanced search and analytics to guide the blockchain application’s interaction with the blockchain network.
Sensitive data must often be stored off-chain since, by definition, on-chain data cannot be tampered with and cannot be deleted. To learn more about this, refer to the Private Data Collections overview in the Hyperledger Fabric guide.
Off-chain and on-chain issues are the domain of the dev team architect and go to the heart of blockchain architecture issues that can make or break a blockchain application.
Smart contracts and oracles
We have already touched on smart contracts, also called chaincode, which is how developers manipulate data on the blockchain. Blockchain guarantees that no data on the blockchain can be modified or deleted without all the parties on the blockchain being immediately notified. This is an advantage that makes blockchain unique in the data world. But what about data that’s imported from the outside world? After all, blockchain must interact with the real world.
And this is where the concept of oracles comes in. Oracles are trusted data sources that provide deterministic information to a blockchain via smart contracts — deterministic is the key. For example, exchange rates change very quickly, and an outside data source can easily provide non-deterministic values such that (as happened this morning) the value of one Swedish Crown to one US dollar can be 0.11 SEK on one source and 0.10 SEK on another, depending on where you are and when you checked the value. The oracle manages the data sources that a blockchain depends on to ensure that they provide fixed values that allow the blockchain to handle the exchange rate in a deterministic way. Oracles should be architected into the blockchain solution from day one and should not be added later as an afterthought.
Hyperledger Fabric and the IBM Blockchain Platform are inherently secure. For complete security, it is prudent to use the IBM Secure Service Container for IBM Cloud Private, a software solution that hosts container-based applications for hybrid and private cloud workloads on IBM LinuxONE and IBM Z servers.
This secure computing environment for microservices-based applications can be deployed without requiring code changes to exploit the security capabilities, and provides:
- Tamper protection during installation time
- Restricted administrator access to help prevent the misuse of privileged user credentials
- Automatic encryption of data, both in flight and at rest
The dev team also needs to be aware of the Federal Information Processing Standards (FIPS). This is a set of standards that describe document processing, encryption algorithms, and other information technology standards for use within non-military government agencies and by government contractors and vendors who work with those agencies. The 140 series of FIPS are U.S. government security standards that specify requirements for cryptography modules. As of December 2016, the current version of the standard is FIPS 140-2 issued on May 25, 2001. Its successor, FIPS 140-3, became effective on September 22, 2019.
Security Level 4 provides the highest level of security. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate deletion of all plain text Critical Security Parameters (CSPs).
Security is, for obvious reasons, key to the success or failure for a dev team’s first commercial blockchain application. Few dev teams need the total security of a mainframe, but it is still good to be aware of the security solutions provided by IBM LinuxONE and IBM Z servers.
Avoid using Practical Byzantine Fault Tolerance (PBFT)
Ordering services in Hyperledger Fabric and IBM Blockchain such as Kafka and Raft provide fault tolerant services, since a typical blockchain implementation is distributed and needs to be protected from going down.
However, what happens if a business network is infiltrated by one or more malicious actors? After all, a network consists of a number of cooperating organizations, one of which could suddenly be taken over by rogue owners who could then try to take over the entire blockchain.
Well, for that case there is Practical Byzantine Fault Tolerance (PBFT). The only problem is that for a permissioned blockchain system, PBFT can be heavily resource intensive and overkill. In other words, PBFT is not necessarily the most efficient method for solving the problem of rogue actors taking over a blockchain consortium.
Permissioned blockchain systems are by definition guarded by laws and regulations that, if they are broken, can best be remedied in court and not by a resource-intensive technical solution. This is why Hyperledger Fabric does not yet support PBFT.
Enterprise blockchain in the cloud
Developing blockchain applications with Hyperledger Fabric and VS Code extension is straightforward. It is easy to spin up a Hyperledger Fabric instance and run the chaincode on the blockchain; the only limitation is that the blockchain will run on your own hardware and not in the cloud.
To run in the cloud, you can use the IBM Blockchain Platform, a cloud-based platform for creating and running blockchain enterprise applications in IBM, AWS, and other clouds. (Learn more about it here.) And in today’s hybrid cloud world, being able to run in several clouds (sometimes at the same time) is a must. Ultimately, most blockchain applications will be running in one or more clouds.
IBM Blockchain Platform console, shown in Figure 3, makes it easy to spin up an enterprise blockchain application.
Figure 3. IBM Blockchain Platform console
In addition, the IBM Blockchain Platform in the IBM Cloud comes with a rich architecture that makes it easy to create advanced enterprise applications (see Figure 4).
Figure 4. IBM Blockchain Platform architecture
Blockchain is one of the most exciting and promising new technologies to have appeared in the last decade. Developers all over the world are busy learning blockchain and applying it to problems that interest them. Getting started writing blockchain applications is easy and free with Hyperledger Fabric and Visual Studio Code with the Blockchain VS Code extension.
The key to success is to know the domain you are in, to leverage existing use cases, and to learn the blockchain programming model. And the way to quickly get started is to copy existing open source applications like the Blockchain Bean and then make successive changes on the existing code base.
It is also important to fully realize the business and organizational aspects of your new blockchain venture. Yes, you need an architect with skills in cryptography and security, as well as a couple of programmers and domain and business experts. Ultimately, you should avoid getting overzealous in your blockchain enthusiasm, but focus instead on writing an application that provides real value for your first customer. And today you will almost certainly find your customers in the supply chain market segment.
In addition, you should also be sure to read the excellent Hyperledger Fabric documentation.
These nine best practices can help you and your team get started and avoid going down the wrong path in developing your first serious blockchain applications. The rest is up to you.