The Hyperledger Project is a Linux Foundation initiative to develop an open source ecosystem of blockchain development. The Linux Foundation aims to create an environment in which communities of software developers and companies meet and coordinate to build blockchain frameworks. Hyperledger itself is not another cryptocurrency, but rather an open hub for enterprise-grade blockchain projects to incubate and mature through all stages of development and commercialization. In this chapter, we talk about the current state of the Hyperledger Project, with a focus on the currently incubating projects, a summary of the project scope being implemented, and a review of the comprehensive set of technologies involved in creating an open source enterprise-grade blockchain.
Current Status
Under the Hyperledger Project, eight projects are currently incubating: There are five frameworks in the pipeline, and three development tools that go with those frameworks. In this section, we will first provide a brief summary of all eight projects, and then focus on two specific blockchain platforms - Fabric and Sawtooth. Let's begin with an overview:
• Sawtooth: This is an Intel effort to create an open source blockchain. Hyperledger Sawtooth is a modular platform for building, deploying, and running distributed
ledgers. It includes a new consensus algorithm called Proof of Elapsed Time
(PoET), which targets large distributed validator populations with minimal resource
consumption. It allows both permissioned and permissionless ledgers to be
deployed on a large scale.
• Iroha: This is a coherent set of libraries and components that will allow adoption of distributed ledger technologies into existing infrastructure. There is a heavy focus on mobile libraries and mobile applications. Data storage and synchronization done
off-device and a default reputation system are implemented network-wide to ensure
validated nodes.
• Fabric: This is a blockchain development framework for developing enterprise applications with a modular architecture. It is intended to be a component-based
system with an emphasis on plug-and-play features such as pluggable consensus,
and unique membership services for different user roles.
© Vikram Dhillon, David Metcalf, and Max Hooper 2017
139
V. Dhillon et al., Blockchain Enabled Applications, https://doi.org/10.1007/978-1-4842-3081-7_10
Chapter 10 ■ the hyperledger projeCt
• Burrow: This permissioned blockchain node executes smart contracts in a similar manner to the EVM. Burrow is built to be executed in a multichain environment with
application-specific smart contracts. A Burrow node can provide contract execution
services to multiple connected blockchains compatible with each other but running
a different domain. A Burrow node has three main components: the consensus
engine, the permissioned EVM, and a remote call gateway to execute contracts.
• Indy: This is a Hyperledger software development kit (SDK) that allows self-sovereign identity to be built into distributed ledgers. This SDK provides wrappers for many
languages to add new features and build better decentralized identity managers.
• Composer: This is a Hyperledger front-end interface to build and deploy simple blockchain networks for specific use cases. Hyperledger Composer allows us to write
simple smart contracts and deploy them to an internal blockchain network. In a large development setting, only a few core users would update the code for a ledger such
as Fabric. Most users would be working within Composer to access the blockchain
and carry out the daily activities of accessing and updating the blockchain.
• Explorer: Similar to any traditional blockchain explorer, Hyperledger Explorer allows a user to query blocks, search through transactions and associated data, network
health and information, types of smart contracts being executed, and transaction
families stored in the ledger. This project will be compatible with any blockchains
deployed with Hyperledger, so new projects do not have to design a new explorer
module.
• Cello: This is a management tool for deployments of blockchain-as-a-service instances. Cello simplifies the process of creating blockchain instances and reduces the effort required for creating, managing, and terminating blockchains. It provides a containerized blockchain service that can be deployed to existing infrastructures on the cloud, bare metal, virtual machines, or special container platforms.
Governance
These eight projects are all under the umbrella of Hyperledger, and hosted by the Linux Foundation. How does the Linux Foundation support the Hyperledger Project as a parent organzation? It helps by providing governance, both technical and legal governance. The Linux Foundation has a deep understanding of how to build open source communities, and as the incubating projects mature, they need dedicated help in terms of community organizing, legal work, and marketing. That's where the Linux Foundation steps in, by building a technical community and an ecosystem for blockchain development, along with auxiliary support for legal and branding work. Figure 10-1 shows the Linux Foundation umbrella and how the Hyperledger Project is organized under it.
140
Chapter 10 ■ the hyperledger projeCt
Figure 10-1. How the various Hypleredger projects and technologies fit under the larger umbrella of the Linux Foundation
The technical governance in Hyperledger is provided by the Technical Steering Committee (TSC). The TSC is an implementation of Open Governance, whereby major technical design decisions are made by a group of community-elected developers drawn from a pool of active participants. Hyperledger recently had the 2017-2018 TSC elections by following the ABCs of Open Governance: Actively participating contributors are eligible to participate in the election, Bring your nominations for the committee, Cast your vote through a secure channel. In the context of Hyperledger, this mechanism of a developer-led committee to make long lasting design decisions is close to the ideal of a technical meritocracy followed in most open source projects.
Fabric and Sawtooth
Hyperledger Fabric is a modular implementation of the blockchain architecture with pluggable functions including consensus, private membership, and transaction functions. In this section, we take a closer look at three particular features of Fabric: chaincode, types of nodes, and private channels. Fabric blockchain runs smart-contracts in the form of programs called chaincode and the only mechanism of interacting with a chaincode is through transactions. All transactions on the network have to be endorsed, only endorsed transactions can be committed to the blockchain and update the global state. Chaincode can be referenced by two types of transactions:
• Deploy transactions: Allow new chaincode to be created, take the program as a parameter. When the transaction has been validated and executed successfully, the
chaincode is considered to be installed on the blockchain.
• Invoke transactions: Allow a chaincode program to be executed on the blockchain.
An invoke transaction calls a specific function from a chaincode that the client
requested to execute. It must be noted that invoke transactions only work
successfully in the context of a previously deployed program. The result of an invoke transaction is successful execution of chaincode and ultimately, modification of the local/global state with a returned output.
141
Chapter 10 ■ the hyperledger projeCt
In Fabric, transactions can be made private and to enable this setup, miners/nodes have to be verified on the network. Unlike Bitcoin, here, sacrifice of identity is acceptable because all parites involved in the network have a common goal. To enable private transactions, the nodes have to be updated significantly, adding new features to interact with the various entities on the network. Here, we describe three such fundamental entities:
• Client: An entity that acts on behalf of an end-user to create a transaction (deploy or invoke transactions) or broadcast transactions to the network. The client must
connect to a peer for establishing communicatation with the blockchain. It often
interacts with the ordering service and endorsers.
• Peer: A node that commits transactions to the blockchain, maintains state updates and retains a full copy of the ledger. Some nodes have an additional ability to play the role of an endorsing peer. The purpose of an endorsing peer is in the context of endorsing a create-chaincode transaction before it is committed to the blockchain. A chaincode can specify conditions necessary for being endorsed (called endorsement
policy) referring to a known set of peers that can validate the create-transaction,
except in the case of a deploy transaction (handled by the global or network-wide
chaincode endorsement policy). This usually corresponds to receiving signatures
from all the endorsers.
• Ordering service: A node running the communication service that implements a publish-subscribe messaging routine to perform functions such as network-wide
message broadcasting, fail-safe message delivery, and private channels. This
ordering service implements the communication protocol in a distributed fashion
and gurantees the order of transactions, and the sequences of messages within those
transactions is preserved. The communications layer is available to all clients and
peers on the network for broadcasting candidate transactions (containing messages)
for verification and finalized transactions that can now be appended to the
blockchain. Broadcasting is done in a fairly standard manner over shared channels
and here's how it works: Clients connect to a channel where peers are listening, and broadcast a message which eventually gets delivered to the appropriate peers.
There are two features of channels (enabled by the ordering services) that we want to discuss here, atomic delivery and partitioning for private channels. The idea behind atomic delivery is to allow message-based communication with order preservation and delivery reliability. In a channel with atomic delivery, transactions are broadcasted and delivered to all connected peers in the same sequence as they arrived. This maintains the consensus of messages contained within those transactions. If the sequence of messages is preserved, once the messages are applied to the blockchain state, the blockchain state update happens in a deterministic fashion (which is desirable). The second feature is partitioning which creates private channels.
The ordering service allows mutliple channels to be created, and clients can connect to any channel in a publish-subscribe manner. A client can also broadcast messages under the appropriate permissions to a given channel. Some nodes may create private channels that require permission or prior keybased approval to enter. The ordering service creates channels in such a manner that a client will not be aware of the existence of other channels, even though it can connect to multiple channels. A brief summary of the features available in Fabric is shown below in Figure 10-2.
142
Chapter 10 ■ the hyperledger projeCt
Figure 10-2. A brief summary of the main features offered by Fabric
Now that we have talked about Fabric in detail, let’s briefly discuss Intel’s approach to blockchain: Sawtooth. Intel describes their effort as:
Sawtooth Lake is a modular platform implemented in Python with C/C++ crypto
acceleration, intended for building, deploying, and running distributed ledgers. The platform is modular and extensible, supporting a range of plug-and-play components enabling organizations to rapidly prototype and experiment with various forms of blockchain deployments.
Sawtooth has a variety of usecases such as compatibility with IoT devices for live data-streams, enterprise-grade customer load, and hardware based security. Here's Intel describing their choice for consensus algorithms:
Some use cases may require high transaction rates among a few participants, while others need to support many participants. These diverse environments require different methods of identifying who adds the next block to the chain. We have provided two distinct consensus algorithms to choose from within Sawtooth Lake. For distributed consensus, we have implement a Proof-of-Elapsed-Time (PoET) algorithm, which uses a trusted execution environment to generate fair and efficient leader election to reduce the computation and energy cost while delivering a fair distributed consensus.
143
Chapter 10 ■ the hyperledger projeCt
The new consensus algorithms have another advantage to Intel because PoET was designed to run on Intel chips and take advantage of the software guard extensions (SGXs) - an instruction set that creates enclaves to prevent sensitive data access to software-level, and dramatically improve transaction processing times. This hardware acceleration is being used on the consumer side to power a large throughput. The hardware security module in Sawtooth has brought up a very interesting partnership in healthcare with PokitDok announcing Dokchain built on top of Sawtooth. Using SGX allows the blockchain built on top to increase privacy and security, both of which are strong requirements to be HIPPA-compliant. The encryption and security features protection patient privacy make SGX and Sawtooth a very powerful platform for healthcare. Additionally, Dokchain also has adjudcation features whereby once the actors are identified, machine-to-machine payments can happen almost instantaneously. This will significantly reduce the billing cycle for providers and make blockchain-based claims processing more lucrative.
Decision Models: Do You Need a Blockchain?
The hype of blockchain technology has spread like wildfire through the corporate world. All sorts of enterprises and companies have created small blockchain development teams to investigate how they can benefit from using the blockchain. Beneath the hype, there are signs of very serious technological development in the blockchain world, many of which are catalogued in this book. However, we are still in the nascent stages: The reality of business advantages from blockchain-enabled applications is to simplify business processes and reduce friction significantly. In this section, we present three decision models that can help you critically analyze whether integrating a blockchain into your project or company is indeed the appropriate technical solution.
• IBM model: This blockchain model highlights how the key features of the blockchain fit into business processes and applications.
• Birch–Brown–Parulava model: This model helps you pick between a permissioned and permissionless implementation of a distributed ledger. It was designed by
developers at Consult Hyperion.
• Wüst–Gervais model: This simplified model, sesigned by two researchers from ETH
Zurich, combines the best from both the previous models.
■ Note Why did we pick these three models? there are several comprehensive decision trees available online to help a business decide which application scenarios would require a blockchain. In this section, we picked the simplest models to illustrate the more important design principles of integrating a blockchain into existing infrastructure.
144
Chapter 10 ■ the hyperledger projeCt
Before we dive into the specifics of each model, what general principles are shared by all three? You can use the shared designs as criteria to evaluate your business needs, and create a model specific to your business based on a few simple ideas and questions.
• Database: You need to begin by understanding why your business is using a database. Blockchains use a shared database that is visible to all the participants.
Are you comfortable with using a shared ledger for your application? The database
is constantly updated by transactions that happen over the network. Can your
application interface with a database that is constantly updated?
• Writers: The database is updated by multiple transactions writing to it. Blockchain is designed to have multiple writers; that is, multiple entities that are generating and verifying the transactions that are published to the ledger.
• No trust: Does verifying the identity of writers matter for your application? This could change the ledger implementation that you deploy. The default setting for
a blockchain is no trust between parties writing to the ledger. Is that sufficient for your application? Do the parties on your network have competing interests or
similar motivations? If they have similar interests, some of the blockchain constructs managing trust can be safely removed.
• Disintermediation: Blockchains remove a centralized authority from the network, and the transactions are therefore considered decentralized. These transactions
are independently verified and processed by every node on the network. Do you
want or need this disintermediation? Given your application-specific use case, are
there any significant shortcomings to having a gatekeeper? Good reasons to prefer a
blockchain-based database might include lower costs, faster workflows, automatic
settlements, or regulatory influences.
• Transaction interdependence: A blockchain is best for handling transactions that build on each other, as they are published to the blockchain by writers. The
interdependence part refers to transaction clearing. For instance, if A sends funds
to B, and then B sends funds to C, the second transaction cannot be cleared until
the first one passes through. Blockchain ensures the orderly and rapid processing of transactions published by writers. In other words, a blockchain truly shines when
keeping a log of transactions with a long history involving multiple users.
145
Chapter 10 ■ the hyperledger projeCt
Let’s start looking at decision models. The first one is shown in Figure 10-3.
Figure 10-3. The Birch–Brown–Parulava model
This model walks a user through making the decision of whether to deploy a permissioned ledger or a permissionless ledger. This could lead to profound changes for deciding the software base, for instance, between Ethereum and Quorum.
The next model is by IBM, shown in Figure 10-4.
Figure 10-4. IBM's decision chart for when to use a blockchain
146
Chapter 10 ■ the hyperledger projeCt
An important feature to highlight in this flowchart is how certain decisions are associated with features inherent to the blockchain. For instance, contractual relationships can be handled well on the blockchain using smart contracts. This chart can become a decent preliminary check for blockchain compatibility with your project and the features that are enabled by the blockchain.
The final decision model that we consider here is shown in Figure 10-5, which was created by Wüst and Gervais in a paper titled “Do You Need a Blockchain,” and for us, it sequentially integrates concepts from both the previous models.
Figure 10-5. The Wüst–Gervais model
This model tries to answer for both deployment options and whether you should be considering a blockchain or not. The concepts are similar to the previous models, but the flow is slightly different to allow for additional options.
Rapid Prototyping with Hyperledger Composer
Hyperledger Composer is a suite of high-level application abstractions to model your business. Once you decide that your business might benefit from using a blockchain, you can use Composer to create a blockchain-based prototype of your application. The following is an outline of the process involved in making a prototype:
• Install Hyperledger Composer Tools or try Composer online in the Playground.
• Define Business Network, Assets, and Transactions.
• Implement any transaction processors.
• Test the business network within Composer-UI.
• Deploy the business network to a live Hyperledger Fabric blockchain instance.
• Create a sample application on top of the low-level abstraction.
• Connect other applications to this deployment through RESTful API or Node.js.
147
Chapter 10 ■ the hyperledger projeCt
The functional output of Composer is called a Business Network Archive (BNA), which can then be deployed to a testnet or a live Fabric blockchain. A business network contains participants that are connected via a role or identity, assets that propagate over the network, transactions that describe asset exchange, contracts that serve as rules that underpin transactions, and finally the ledger that records all transactions. Aside from the modeling components of a business network, the BNA also contains transaction processors, access control lists, and query definitions. A transaction processor (written in JavaScript) implements and enforces business logic on these model elements. The access control lists describe rules that allow fine-tuned control over which participants can have access to what assets in the business network after satisfying certain conditions. The language used to describe these access lists is very sophisticated, and can capture complex ownership statements. Keeping access control separate from transaction processor logic allows the developers to maintain and update the two components rapidly, without any fears of compatibility or breaking functionality.
■ Note In this section, our focus is on presenting the fundamentals of hyperledger Composer so that an interested reader can pick up on Composer’s modeling language quicker from the reference material. designing a full business network model would be beyond the scope of this book.
Let’s go through the modeling language and discuss the foundations of Composer in depth here:
• Assets: These represent the resources being exchanged between users on the network. Formally, the description scheme used to define assets is done in the order of keyword–class–identifier–properties–relationships. Other optional fields
could be added here as well, but this general scheme is followed throughout the
modeling language. Assets are defined with the keyword asset and have a domain—
relevant class name associated with them. For instance, a car can be identified by
VIN as: asset Vehicle identified by vin. The assets have a set of properties
that define them. In case of a vehicle, it can be a description stored as a string
description. Additionally, the assets can also have relationships to other resources in the modeling language such a user that owns the car, denoted by --> User owner.
All the assets are stored in an asset registry available to the network.
• Participants: These represent the users (or counterparties) in the network.
Participants are key to all interactions happening on the network, and they
are described the same way as an asset. Participants are represented using the
participant keyword and they also have a class name relevant to their domain
such as buyer or seller. A full description could be given as participant Buyer
identified by email and a property of String firstName. All the participants
are stored in a participant registry, which might not be available to the users of the network.
• Transactions: These represent the movement of assets across the network and the life cycle of assets as they are exchanged. Transactions are described in the same
way as participants or assets, and a sale offer from a participant could be defined as transaction Offer identified by transactionid and with a property of Double
saleprice.
•
Concepts: Concepts are abstract classes that do not belong to assets, participants, or transactions. Concepts are often used to add specifiers to an asset or transaction and typically contained by one of the three. For instance, a concept of address can be described as Concept Address with properties of String street and String city_
default ="Orlando". Now an asset can use this concept to specify an address property.
148
Chapter 10 ■ the hyperledger projeCt
• Transaction processors: These represent the business logic to perform state changes and global updates to the blockchain as a result of transactions being broadcast
to the network. Essentially, these processors provide an implementation for
transactions to act on the model. They are written in a separate js file and use the definitions from the business network model.
Figure 10-6 shows the BNA visually.
Figure 10-6. Components of the BNA. Reproduced with permission from the Hyperledger Project.
Summary
In this chapter, we presented the Hyperledger Project, with a special focus on the currently incubating tools. We began by talking about the five major open source projects currently under Hyperledger, and how the projects are organized under the Linux Foundation umbrella. We then discussed some of the recent developments within Hyperledger, focusing on Fabric and the enterprise features offered in general by Hyperledger. After that, we presented a few decision models to help a project or business decide whether a blockchain would benefit them. Finally, we presented Hyperledger Composer, which is a rapid prototyping tool to help users model their business networks with ease using the modeling language. We concluded our discussion here by talking about components of the modeling language and how they create a business network.
149
Recent Developments in
