With the runaway success of Bitcoin, the interest in distributed ledgers and blockchains has perked up. Hyperledger Fabric is a collaborative open source project that has been created to advance cross-industry blockchain technologies. This article introduces the reader to it.
Hyperledger Fabric was the first proposal to The Linux Foundation’s Hyperledger Project, contributed in part by IBM. This framework is modular, scalable and secure. It has been specifically designed for industries such as manufacturing, agriculture, healthcare and the capital markets. Hyperledger Fabric is revolutionary in its ability to allow entities to conduct confidential transactions without passing through a central authority. It is unique, because it allows for modular consensus and membership service.
There are four different types of roles within a Hyperledger Fabric network:
- Clients are applications that act on behalf of a person to propose transactions on the network.
- Peers maintain the state of the network and a copy of the ledger. There are two different types of peers — endorsing and committing peers. However, there is an overlap between endorsing and committing peers, in that the former are a special kind of committing peers. All peers commit blocks to the distributed ledger.
- Endorsers simulate and endorse transactions.
- Committers verify endorsements and validate transaction results, prior to committing transactions to the blockchain.
The ordering service accepts endorsed transactions, orders them into a block, and delivers the blocks to the committing peers.
Key components of Hyperledger Fabric
Transaction endorsement
A transaction endorsement is a signed response to the results of the simulated transaction. The method of transaction endorsements depends on the endorsement policy, which is specified when the chaincode is deployed. An example of an endorsement policy would be something like, “The majority of the endorsing peers must endorse the transaction.” Since an endorsement policy is specified for a specific chaincode, different channels can have different endorsement policies.
Ordering
Transactions within a time frame are sorted into a block and are committed in sequential order. In a blockchain network, transactions have to be written to the shared ledger in a consistent order. The order of transactions has to be established to ensure that the updates to the world state are valid when they are committed to the network. Unlike the Bitcoin blockchain, where ordering occurs by the solving of a cryptographic puzzle or by mining, Hyperledger Fabric allows the organisations running the network to choose the ordering mechanism that best suits that network. This modularity and flexibility makes Hyperledger Fabric incredibly advantageous for enterprise applications.
Hyperledger Fabric provides three ordering mechanisms — SOLO, Kafka and Simplified Byzantine Fault Tolerance (SBFT), though the last mechanism has not yet been implemented in Fabric v1.0.
SOLO is the ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. It involves a single ordering node.
Kafka is the Hyperledger Fabric ordering mechanism that is recommended for production use. It uses Apache Kafka, an open source stream-processing platform that provides a unified, high-throughput, low-latency platform for handling real-time data feeds. In this case, the data consists of endorsed transactions and RW sets. The Kafka mechanism provides a crash fault-tolerant solution to ordering.
Simplified Byzantine Fault Tolerance or SBFT is an ordering mechanism that is both crash fault-tolerant and Byzantine fault-tolerant. This means that it can reach agreement even in the presence of malicious or faulty nodes. The Hyperledger Fabric community has not yet implemented this mechanism, but it is on its roadmap.
These three ordering mechanisms provide alternate methodologies for agreeing on the order of transactions.
Identity verification
In addition to the multitude of endorsement, validity and versioning checks that take place, there are also ongoing identity verifications happening during each step of the transaction flow. Access control lists are implemented on the hierarchical layers of the network (from the ordering service down to channels) and payloads are repeatedly signed, verified and authenticated as a transaction proposal passes through the different architectural components.
Channels
Channels allow organisations to use the same network, while maintaining separation between multiple blockchains. Only the members of the channel on which the transaction was performed can see the specifics of the transaction. In other words, channels partition the network in order to allow transaction visibility for stakeholders only. This mechanism works by delegating transactions to different ledgers. Only the members of the channel are involved in consensus, while other members of the network do not see the transactions on the channel.
Figure 1 shows three distinct channels — blue, orange, and grey. Each channel has its own application, ledger and peers. The peers could belong to multiple networks or channels. Those that do participate in multiple channels simulate and commit transactions to different ledgers. The ordering service is the same across any network or channel.
A few things that must be kept in mind are:
- The network setup allows for the creation of channels.
- The same chaincode logic can be applied to multiple channels.
- A given user can participate in multiple channels.
State database
The current state data represents the latest values for all assets in the ledger. Since the current state represents all the committed transactions on the channel, it is sometimes referred to as the world state. Chaincode invocations execute transactions against the current state data. To make these chaincode interactions extremely efficient, the latest key/value pairs for each asset are stored in a state database, which is simply an indexed view into the chain’s committed transactions. It can therefore be regenerated from the chain at any time. The state database will automatically be recovered (or generated, if needed) upon peer startup, before new transactions are accepted. The default state database, LevelDB, can be replaced with CouchDB.
LevelDB is the default key/value state database for Hyperledger Fabric and simply stores key/value pairs. CouchDB is an alternative to LevelDB. Unlike LevelDB, CouchDB stores JSON objects. The latter is unique in that it supports keyed, composite, key range, and full data-rich queries.
Hyperledger Fabric’s LevelDB and CouchDB are very similar in their structure and functions. Both support core chaincode operations, such as getting and setting key assets, and querying based on these keys. With both, keys can be queried by range and composite keys can be modelled to enable equivalence queries against multiple parameters. But, as a JSON document store, CouchDB additionally enables rich query against the chaincode data, when chaincode values (e.g., assets) are modelled as JSON data.
Smart contracts
As a reminder, smart contracts are computer programs that contain logic to execute transactions and modify the state of the assets stored within the ledger. Hyperledger Fabric’s smart contracts are called chaincode and are written in Go. The chaincode serves as the business logic for a Hyperledger Fabric network, in that it directs how you manipulate assets within the network.
Membership service provider (MSP)
The membership service provider, or MSP, is a component that defines the rules in which identities are validated, authenticated and allowed access to a network. The MSP manages user IDs and authenticates clients who want to join the network. This includes providing credentials for these clients to propose transactions. The MSP makes use of a certificate authority, which is a pluggable interface that verifies and revokes user certificates upon confirmed identity. The default interface used for the MSP is the Fabric-CA API; however, organisations can implement an external certificate authority of their choice. This is another feature of Hyperledger Fabric that is modular.
Hyperledger Fabric supports many credential architectures, which allow for many types of external certificate authority interfaces to be used. As a result, a single Hyperledger Fabric network can be controlled by multiple MSPs, where each organisation brings its favourite.
What the MSP does: To start, users are authenticated using a certificate authority, which identifies the application, peer, endorser and orderer identities, and verifies these credentials. A signature is generated through the use of a signing algorithm and a signature verification algorithm.
Specifically, generating a signature starts with a signing algorithm, which uses the credentials of the entities associated with their respective identities, and outputs an endorsement. A signature is then generated, which is a byte array that is bound to a specific identity.
Next, the signature verification algorithm takes the identity, endorsement and signature as inputs and outputs ‘Accept’ if the signature byte array corresponds with a valid signature for the inputted endorsement, or outputs ‘Reject’ if it does not. If the output is ‘Accept’, the user can view the transactions in the network and perform transactions with other actors in the network. If the output is ‘Reject’, it implies that the user has not been properly authenticated and is not able to submit transactions to the network, or view any previous transactions.
Fabric-Certificate Authority (Fabric-CA)
In general, certificate authorities manage enrolment certificates for a permissioned blockchain. Fabric-CA is the default certificate authority for Hyperledger Fabric and handles the registration of user identities. The Fabric-CA is in charge of issuing and revoking enrolment certificates (E-Certs). The current implementation of Fabric-CA only issues E-Certs, which supply long term identity certificates. E-Certs issued by the enrolment certificate authority (E-CA) assign peers their identity, and give them permission to join the network and submit transactions.
Getting involved with the Hyperledger Fabric project
Hyperledger Fabric is an open source project, where ideas and code can be publicly discussed, created and reviewed. There are many ways to join the Hyperledger Fabric community. You can join the weekly meeting on Fabric Documentation or other Hyperledger Fabric-related get-togethers. The Hyperledger Community Meetings Calendar is a great resource to learn about the timings for these meetings. You can also join the Hyperledger Fabric mailing lists for technical discussions and announcements. Gerrit is used for submitting PRs and managing code reviews and check-ins. You can join the live conversations on Rocket.Chat (which is an alternative to Slack), using your Linux Foundation ID.
What’s next?
In subsequent articles, we will look at Hyperledger Fabric with respect to transaction flow, installation and chaincode development.
