The Linux Foundation hosts Hyperledger and provides a governance structure and oversight to the Hyperledger community. It is a global open source project and the result of collaboration from technology leaders.
The Linux Foundation also embraces a modular umbrella approach to enterprise blockchains. Hyperledger is an open source software licensing model, which allows the user to model code and distribute it in an appropriate manner.
As shown in Figure1 Hyperledger uses an umbrella approach to manage its open source projects. As an organization, Hyperledger manages more than 100 open source collaborations (projects).
The Hyperledger structure has three modules
Figure 1 Hyperledger Greenhouse approach (Linux Foundation)
Graphic courtesy of Linux Foundation
You can see that Hyperledger has six frameworks and six tools and utilities. I will focus mainly on Hyperledger Fabric for this book because of its wide development base and the significant enterprise use cases in play now.
The umbrella strategy, also referred to as the greenhouse strategy, is a proven model that the Linux Foundation has used repeatedly in the other projects it maintains. Historically, the Linux Foundation provides excellent management and insight into how to manage an open source project for consortium members.
As mentioned, Hyperledger has six frameworks at the time of writing. Each framework is a blockchain. The Hyperledger consortium of members realized that one blockchain framework would not meet the requirements of all its members.
The Six frameworks** ensure its consortium members have the features, functions, and other requirements to deploy an appropriate blockchain for its members’ use cases.
Figure 2.4 presents the five blockchains that make up the Hyperledger frameworks. I will focus on the Fabric framework, which is a permissioned blockchain that supports channels. Channels allow for controlled transactions that are private.
Table 1 Hyperledger framework blockchains
The figure lists the frameworks and application use cases for each of the blockchain frameworks. As mentioned, Fabric will be the focus of the book, but the other frameworks in the Hyperledger blockchain family such as Burrow or Sawtooth will be referenced throughout the book mainly as a comparison for use cases.
Hyperledger as an organization empowers its members through the project’s blockchain frameworks, tools, and organizational infrastructure. Hyperledger Fabric is by far the most widely used of the frameworks.
For example, if you go to the Hyperledger GitHub project, you will see that Fabric has the most forks. GitHub is a collaborative web-based platform for software development projects that use the Git revision control system. Git is the standard for software development and is the most widely used platform.
Figure 2 shows that Fabric has more than 4,700 forks. A fork is when developers make a copy of the repository, which is good sign since it shows that developers are making changes to code, testing the code, or using the code.
Figure 2 Hyperledger Fabric GitHub forks
The figure above shows the Github page for Hyperledger. It’s clear that Fabric has the most activity as compared to the other frameworks. This is mainly because it’s the framework that meets the most use cases. Fabric provides some significant features, such as modularity of consensus and encryption key management, but it also supports private channels. This book focuses on the power and flexibility of Hyperledger Fabric specifically.
Hyperledger Indy was created and contributed by the Sovrin Foundation. The Sovrin Foundation is a private-sector, international nonprofit that was established intentionally to govern the world’s first self-sovereign identity (SSI) network.
Indy is a Hyperledger project made to support independent identities on distributed ledger platforms. Indy provides a wide breadth of tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers. The benefits are that the digital identities[AU: ok?] provide an interoperable capacity to enterprises across administrative domains, applications, and any other silos.
Hyperledger Iroha was created by numerous participating companies, such as Soramitsu, Hitachi, NTT Data, and Colu. Iroha is a business blockchain framework designed to be easily incorporated into mobile projects requiring distributed ledger technology.
Iroha features a modern, domain-driven C++ design as well as a chain-based Byzantine fault-tolerant consensus algorithm called Sumeragi. Sumeragi uses a permissioned server reputation system, known as Hijiri, that calculates the reliability of servers based on three factors, listed here:
- The time each server registered with the membership service
- The number of successful transactions processed by each server
- The number of failures detected
Consensus in Sumeragi is performed on individual transactions and on the global state resulting from the application of the transaction.
Hyperledger Fabric was mainly developed by IBM. Fabric is clearly intended as a foundation for developing applications or solutions with the modular architecture that enterprises require. Hyperledger Fabric allows for essentially a modular approach to components, such as consensus and membership services, and leverages containers to host smart contracts called chaincode that comprise the application logic of the system.
The permissioned nature of Hyperledger Fabric provides for privacy of operations for the participants. The need for privacy does not exclude the need for identification and audit ability from regulators.
Basically, the encryption of identity (membership) is done in a manner that remains “private” from other blockchain participants. Auditing is built in and provides for compliance requirements, which is a major concern for enterprises.
Hyperledger Fabric does not perform mining, although cryptocurrency support is possible via chaincode.
Hyperledger Sawtooth was built by Intel and is closer to a proprietary blockchain than an open source blockchain. Sawtooth is a modular platform for building, deploying, and running distributed ledgers, and it is considered Hyperledger’s second most widely accepted blockchain framework.
Hyperledger Sawtooth includes a varied consensus algorithm called proof of elapsed time (PoET), which targets large distributed validator populations with minimal resource consumption. This essentially means that it can target distributed consensus efficiently.
Hyperledger Burrow is a permissionable smart contract machine that was the first of its kind when it was released in 2014. Burrow provides a modular blockchain client with a permissioned smart contract interpreter built in part to the specification of the Ethereum Virtual Machine (EVM).
Burrow was specifically built to be a lightweight, efficient, and fast permissioned smart contract machine. Burrow accomplishes this goal by leveraging the hardened and speedy Tendermint protocol for consensus working with the Burrow’s Apache-licensed EVM. Because of these features, users have access to one of the fastest codebases available.
Smart contracts should perform the same across different blockchains that support smart contracts. This is really useful for portability since users can easily start with Hyperledger Burrow and over time migrate their smart contracts to other
From this chart, it’s clear that Hyperledger as a portfolio of blockchain frameworks has some similar capabilities, but the frameworks have some substantial use cases differences between them as well.
Hyperledger Fabric has wide acceptance as an enterprise blockchain and is Hyperledger’s most active project. The number of developers using the GitHub repository is clearly well above other blockchain frameworks in Hyperledger
However, I will compare Hyperledger Fabric to Burrow, Sawtooth, Iroha, and Indy since those frameworks all have very specific use cases but also have some functionality that overlaps in the framework portfolio as well.
Hyperledger Fabric supports distributed ledger solutions on permissioned networks for a wide range of industries. It was purposely built to have a modular architecture that maximizes the confidentiality, resilience, and flexibility of enterprise blockchain solutions.
Hyperledger Fabric was started by Digital Asset and IBM and has now emerged as a collaborative cross-industry venture that is currently hosted by the Linux Foundation. Fabric was the first blockchain to exit the “Incubation” stage and achieve the “Active” stage in March 2017 with the Hyperledger Project.
Hyperledger Fabric is a blockchain implementation that is designed for deploying a modular and extensible architecture. It has a modular subsystem design so that different implementations can be added and implemented over time.
The modular architecture of Hyperledger Fabric separates the transaction processing workflow into three different stages, as listed here:
1. Chaincode invocation and initiation, where the client application requests access to the blockchain network.
2. Transaction processing and ordering, where the transactions are processed in order first and then validated.
3. Transaction validation and commitment, where the transactions are validated and then committed to the blockchain ledger. The world state is updated as part of this step.
These distinct steps provide multiple benefits to the enterprise such as a reduced number of trust levels and verification, which improve network scalability and performance. In other blockchains such as Ethereum, transactions are processed differently in the sense they are deterministic, meaning they always yield the same result given the same input and the same logic.
Figure 3 shows a typical Fabric network structure. As part of the structure you would have a client application, organizations, various types of peers, ordering peers, and membership services provider.
Figure 3 Hyperledger Fabric overview
In the figure, Workflow should be one word. and the label should be Company A and Company B.
This figure shows a simple Fabric network setup with different peers, two organizations, and a client application. Hyperledger Fabric can scale to hundreds of peers, for example.
Hyperledger Fabric’s support for pluggable components allows for reuse of existing features and ready-made integration of various modules. For instance, if a function already exists that verifies the participant’s identity, an enterprise-level network simply needs to reuse this existing module instead of building the same function anew.
Hyperledger Fabric Definitions
The following definitions will be useful to know as you read this book:
Block—This is an ordered set of transactions that is cryptographically linked to the preceding block(s) on a channel.
Chain—The ledger’s chain is a transaction log structured as a hash-linked blocks of transactions.
Chaincode—Also known as a smart contract, this is code that is invoked by a client application external to the blockchain network.
Channel—This is a private blockchain overlay that allows for data isolation and confidentiality.
Consensus—This is a broader term, overarching the entire transactional flow, that serves to generate an agreement on the order and to confirm the correctness of the set of transactions constituting a block.
Endorsement—This is the process where specific peer nodes execute a chaincode transaction and return a proposal response to the client application.
Genesis block—This is the configuration block that initializes the ordering service or serves as the first block on a chain.
Gossip protocol—A gossip data-dissemination protocol performs three functions: manages peer discovery and channel membership, disseminates ledger data across all peers on the channel, and syncs ledger state across all peers on the channel.
State database—Data is stored in a state database for efficient reads and queries from chaincode. Hyperledger-supported databases include LevelDB and CouchDB, depending on your use case.
World state—Also known as the current state, the world state is a component of the Hyperledger Fabric ledger. The world state represents the latest values for all keys included in the chain transaction log.
The Hyperledger Fabric ledger is the sequenced, tamper-resistant record of all state transitions. State transitions are a result of chaincode invocations (transactions) submitted by participating members. A transaction can also be considered a request to update the ledger as another way to look at it.
Each transaction results in a set of asset key-value pairs that are committed to the ledger as either a create, update, or delete operation.
A key-value pair is a way to represent and identify an asset in the Fabric ledger. For example, a key-value pair would be an asset such as a car whose data is stored in the Fabric ledger. The data is stored in a key-value (description of the value and the value) pair.
Here’s an example:
‘color’ : ‘red’
In this example, “color” is the key, and “red” is the value. This key-value pair is then stored on the ledger. Assets are tracked, identified, or updated via a ledger request (transaction) such as a query or update. Simply put, the ledger is the actual blockchain. The ledger is a file-based ledger that stores serialized blocks. Each block has one or more transactions. Each transaction contains a read-write set that modifies one or more key-value pairs.
The ledger is the definitive source of data and is immutable, meaning once it is written, it cannot be deleted or modified. The state database holds the last known committed value for any given key. It is populated when each peer validates and commits a transaction.
Hyperledger Fabric has some interesting capabilities that are outside the standard behavior for a blockchain. For example, the state database can always be rebuilt from reprocessing the ledger, and a transaction can be rolled back, for example, if a transaction is deemed not valid.
There are currently two options for the state database in Fabric as well. First is an embedded database called LevelDB.
You can also choose an external CouchDB as another option.
- State data is a representation of current state of the assets. Asset state data can be changed upon changes to the state of the data.
- Transaction logs record all the transactions in the order they are received that modified the state data. Once the data is written to the transaction logs, they are immutable and cannot be modified or deleted.
Hyperledger Fabric Ledger has two distinct parts.
Want to learn more about Hyperledger? Check out our bootcamp!
**Hyperledger has several more Frameworks in the planning stages.