Key Takeaways
- People generally first hear about blockchain through cryptocurrencies such as Bitcoin. However, blockchain - the distributed ledger technology that underpins Bitcoin - has been increasingly adopted by businesses for a wider range of uses beyond digital currencies.
- The requirements of blockchain for business are largely different to the public variant: the identity of participants must be known; permissioned blockchains require no "proof of work"; and the scope of permissioned blockchains is also different.
- Enterprise blockchain applications can be described in terms of the assets, participants and transactions that are to be shared in the business network. Taken together, these components run on distributed processing systems, known as a fabric, that governs how blockchain applications run.
- Smart contracts - the codification of the business rules that implement transactions - are effectively stored procedure calls that are run in multiple nodes on a network and whose outputs are agreed upon by all network members through a process of consensus.
- There is a challenge in mapping the assets, participants and transactions of a blockchain solution to the technical realities of such a blockchain processing system. Hyperledger Composer, one of the Hyperledger projects hosted by The Linux Foundation, aims to solve this problem.
- To illustrate the use of Hyperledger Composer, we will use it to create an instance of a car auction on a blockchain.
People generally first hear about blockchain through cryptocurrencies such as Bitcoin, the peer-to-peer payment system which is largely unregulated and resistant to single points of control. In recent years however, blockchain – the distributed ledger technology that underpins Bitcoin – has been increasingly adopted by businesses for a wider range of uses beyond digital currencies. In this article, I will take you through what businesses look for when considering blockchain’s role in their organization and how the Linux Foundation's Hyperledger Composer can help application developers easily create compelling blockchain solutions for the enterprise.
The Growth of Blockchain for Business
Bitcoin was the first mainstream application of blockchain and was introduced in a 2008 whitepaper by Satoshi Nakamoto. Since that time, use of blockchain has increased dramatically and the term has somewhat evolved into a catch-all term for distributed ledger applications, which is the definition I will adopt here.
Blockchain applications have grown in popularity – both public (usually anonymous) networks and permissioned (business) networks. While both frameworks have valuable uses, the requirements of blockchain for business are largely different to the public variant, for three broad reasons:
1) Businesses tend to operate in regulated environments, and requirements such as Anti Money Laundering (AML) and Know Your Customer (KYC) require that businesses understand the identity of the participants with whom they are transacting. While Bitcoin is all about anonymity (or rather, pseudonymity) where you can see the set of transactions but it is nearly impossible to infer who was involved in them, businesses usually require the total opposite: privacy, where users know and can trust the identity of participants in the network, but not necessarily the transactions that were completed.
2) In pseudonymous blockchains, it is important to prevent untrusted participants from corrupting the network. Today, Bitcoin and other public blockchains typically use a concept called "Proof of Work" to remove incentives for fraudulent behaviour by adding an artificial cost to transactions, which is represented by electricity consumption. Transaction validators prove they are genuine by revealing to the network their answer to computationally difficult cryptographic puzzles, which is a somewhat intelligent solution to the problem of trust but a hugely inefficient use of processing capability. Permissioned blockchains require none of this, because participants are known and trusted. Business network participants stand to lose either reputationally or financially if transactions turn out to be invalid.
3) The scope of permissioned blockchains is also different. Public blockchains such as Bitcoin were originally designed around the peer-to-peer payments use-case, but businesses require ledgers that can be used to describe anything of worth. Business networks also tend to be smaller, closed systems (think about the scope of a supply chain network, for example). This is different from non-business blockchains, which are typically open to anybody with a computer.
It is possible to illustrate these requirements by looking at the way business networks operate today. Wealth is generated by goods and services that flow over a business network, with the transfer of these goods and services recorded as a sequence of transactions on a ledger. Ledgers are extremely useful systems of record, as they describe all inputs and outputs of a business and consequently, their financial position. Ledgers have been around in various forms since the 1400s or even earlier.
Blockchain for business aims to model these basic tenets of business. Today, organisations own their ledgers and the business rules that dictate the flow of goods and services around the network. With business blockchains, both the ledger and the business rules are shared within the business network, thereby removing much of the friction (and therefore cost) associated with doing business.
Assets, Participants and Transactions
Enterprise blockchain applications can be described in terms of the assets, participants and transactions that are to be shared in the business network:
- Assets can be anything of value that can be shared or transacted, from tangible assets such as cars, houses or diamonds, to intangible assets such as securities, intellectual property or even reference data. Cash is also a type of asset.
- Participants are the actors in a business network who need to share transaction information. Participants are usually businesses but could also represent people, regulators or other stakeholders.
- Transactions describe what can be done to the assets as they move around the business network.
Taken together, these components run on distributed processing systems, known as a fabric, that governs how blockchain applications run. Smart contracts - the codification of the business rules that implement transactions - are effectively stored procedure calls that are run in multiple nodes on a network and whose outputs are agreed upon by all network members through a process of consensus.
There is a challenge in mapping the assets, participants and transactions of a blockchain solution to the technical realities of such a blockchain processing system. It can manifest as a high cost of implementing a blockchain application, given that significant effort needs to be spent implementing the logic that defines the business objects and smart contracts in a form that makes adequate use of the services that blockchain provides.
Hyperledger Composer
Hyperledger Composer, one of the Hyperledger projects hosted by The Linux Foundation, aims to solve this problem by making it easy for blockchain developers to model business assets, participants and transactions and to turn these models into viable blockchain applications. Hyperledger was set up in December 2015 as a collaborative effort to advance cross-industry open-source blockchain technologies for business. It is the fastest growing project in Linux Foundation history and the Hyperledger umbrella currently includes several technologies, from blockchain frameworks such as Hyperledger Fabric and Hyperledger Sawtooth to tools that provide services such as monitoring, identity, development and deployment. Hyperledger Composer is one of these tools.
As with all Hyperledger offerings, Hyperledger Composer is fully open source and has an open governance model which allows for anybody to contribute and influence the direction.
Hyperledger Composer introduces a simple domain-specific language for modelling assets, participants and transactions, and JavaScript for giving developers the ability for developers to write methods that implement transaction logic. These files can be written in whatever development environment you choose (there are plugins for major editors), a web-based "playground" that can assist in the development, packaging, deployment and testing of these projects and a command-line utility for scripting. Applications can be deployed to instances of Hyperledger Fabric or simulated locally in the web browser.
Hyperledger Composer also includes the ability to generate skeleton command-line or Angular2 applications off the back of these assets, and Loopback support which allows for RESTful interactions with the application; this enables blockchains to connect to existing systems of record, optionally via integration middleware such as Node.RED or IBM Integration Bus.
Designing a Blockchain Car Auction
To illustrate the use of Hyperledger Composer, we will use it to create an instance of a car auction on a blockchain. It's a good blockchain use case because there is a well-defined business network, a high-value asset type and a need for irrefutable trust - to know unambiguously who (a) owns a car at a given point in time, and (b) the cash balances of the participants. It's also easy to see how such an application could be extended to cover any other high-value asset type.
To begin with, let's consider the assets, participants and transactions that form this business network:
- Assets: There are two asset types to consider: The Vehicle, which is a digital representation of a vehicle whose ownership is being tracked, and a Vehicle Listing, which describes a car that is (or has been) for sale along with any offers it received.
- Participants: Members are the people or organisations who are either the owners or buyers of vehicles, and will have a balance of currency. There could also be an Auctioneer who has the ability to close the bidding on an item. One could also expand the network in time to include insurers or a regulator.
- Transactions: There are two important transaction types: one to put an offer on a vehicle, and one to close the bidding.
[Click on the image to enlarge it]
Figure 1 - The assets, participants and transactions of a car auction
These define the types that will form part of this blockchain solution. In order to test our blockchain solution, we will create instances of these types that will be stored in registries, which is another concept integral to Hyperledger Composer. We will populate vehicle, vehicle listing, member and auctioneer registries as well as have the ability to submit transactions of the two types we defined. All instance and transaction data will be stored on and accessed through the blockchain, which allows it to be shared and trusted by the network participants. The solution developer can implement access control lists to determine which participants can see which assets.
Modelling the Blockchain Car Auction
All aspects of Hyperledger Composer can be downloaded and run locally, and there is also an online version of the playground that you can use without any installation at all. To get started with a local copy, follow the quick start instructions on the Hyperledger Composer page. To follow along in the online playground, simply go to the Hyperledger Composer Playground page.
When you start the playground for the first time and dismiss the welcome screen, you will see a screen similar to this one. (As with any project under active development, this is subject to change!)
[Click on the image to enlarge it]
The left-hand side of the page shows you the files that form your blockchain project:
- An About file - a readme in markdown format; this is the file whose contents is shown by default
- A Model file - the definitions of the assets, participants and transactions in this project
- A Script file - the JavaScript implementations of the transaction logic
- An Access Control List - specifies which participants can see which assets
- An Add button - to add additional files to the project if necessary.
- A Deploy button - which makes any edits to your project active on the currently connected blockchain instance or simulation
- Import capability to replace the contents of playground with another
- Export capability to package the solution into a file that can be carried into another environment
Elsewhere on the screen, the main area shows an editor or viewer for the file that has been selected. Also, the Define/Test tabs at the top allow you to switch between development and testing respectively. Finally, the top right of the page allows you (in the local version) to assume the identity of a different blockchain user, connect to your own live blockchain instances, or start simulation in the web browser. The online playground currently only works in simulation mode.
We will begin by replacing the files in the playground window with the ones that will implement our car auction. We will use a pre-built sample. For developing your own networks, it is usually best to import a sample template to get started too.
Click the 'Import/Replace' button. You will first be asked to authenticate with GitHub, as the available samples will be downloaded directly from the online repository; you are welcome to contribute your own networks back if you wish. Select 'carauction-network' and click Deploy to replace the files in the playground with the Car Auction project.
Selecting the model file (model/org.acme.vehicle.auction.cto) will reveal the definition of the assets, participants and transactions. Similarly, the script file (lib/logic.js) contains the JavaScript implementation of the two transaction types.
Importantly, in just 50 lines of a simple domain specific language and 100 lines of JavaScript we can define all the elements we need to implement a blockchain solution.
Testing the Blockchain Car Auction
Clicking on the 'Test' tab at the top of the playground allows you to interact with the participant and asset registries and submit transactions to the blockchain. Everything on this tab is dynamically derived from the model file.
Start by creating a few participants in the 'Member' registry: give them a starting balance (implemented here as a simple integer), an email address that uniquely identifies them, a first name and a last name.
Then create a vehicle in the Vehicle registry; the vin (vehicle identification number) is a unique identifier string, and the initial owner should be the email address of one of the owners already created (because the model defines the email address as the unique identifier).
Finally, create a Vehicle Listing: give it a unique listing ID, reserve price and description. The state should be "FOR_SALE", and I suggest clearing the array of offers ("offers" : []). The vehicle field should contain the vin string of the vehicle you created, again because the model defines the vin field as the unique identifier.
One the registries have been populated, you can then submit transactions to add offers on the vehicle. Click 'Submit Transaction', select the transaction type to 'Offer' and fill in the bid price, listing (the unique listing ID entered earlier) and the member (the email address of the participant putting in the offer). This will cause the JavaScript associated with the Offer transaction to be run, which simply adds the new offer to the array of offers for the associated listing.
Once you've added a few offers, try closing the bidding. Submit another transaction, but this time select the transaction type to be 'CloseBidding'; you just need to specify the unique listing id. Submitting this will cause the JavaScript associated with the CloseBidding transaction will be run. This will look for the highest bid above the reserve price, add the balance of the seller by the winning amount, subtract the balance of the buyer and transfer ownership of the vehicle. If you switch back to the appropriate Vehicle and Member registries you can see that these actions will now have been completed.
Next Steps
By following these steps, you can see how, in just a short amount of time and using a small amount of code, you can develop a compelling blockchain prototype. If you want to apply the concepts we've discussed here to your own blockchain projects, the approach to getting started is roughly the same. Start by identifying a real business challenge that blockchain can address: a business network is a must, with a need for mutual trust among the participants. Then think about the assets, participants and transactions that define that problem. Try modelling them in Hyperledger Composer, then testing and iterating.
Of course, the real value is in the end user application that is able to submit and query real business transactions. To get started with writing one of these, check out the starter application generator in Hyperledger Composer. This takes the business network archive and generates a sample Angular2 or command-line application. It won't give you a finished application by any means, but it allows you to focus your efforts on developing the end-user application logic rather on the blockchain interactions.
The advantage of Hyperledger Composer is not only in the speed of developing that blockchain solution, but also how it allows you to quickly iterate to meet additional requirements, and provides a vocabulary that allows you to describe simply to others what is happening.
Hyperledger Composer is a community project, and its success depends on an active community of developers. If there is something there you particularly like or dislike, do let the team know. And if you can, do get involved: the Hyperledger website shows you how.
Wrapping up: The Potential of Blockchain
Blockchain has a huge amount of potential. IBM believes that blockchain can do for transactions what the internet did for communications and information flow, and therefore, we expect the effects on business will be profound and positive. And as blockchain practitioners, we can make this happen!
About the Author
Matt Lucas is part of IBM’s global blockchain enablement team. His role is to help clients understand and apply blockchain technologies and works closely with emerging blockchain frameworks such as Hyperledger Fabric and Ethereum as well as blockchain tools such as Hyperledger Composer. He is based in IBM’s development laboratory in Hursley and has worked with IBM for 20 years on a variety of integration middleware technologies. Most recently he spent several years working on IBM Integration Bus in the product architecture and offering management disciplines. You can contact Matt on Twitter using @mqmatt, or via e-mail at lucas@uk.ibm.com.