Hyperledger — Chapter 6 | Hyperledger Fabric Components — Technical Context
Now that we understand the real world context of the tuna fish supplychain scenario, let’s get to know Hyperledger Fabric Components a little deeper in this post so that we can structure the same problem (tuna fish supplychain) technically. As you might recall Fabric is one of the frameworks within the Hyperledger ecosystem that lets us build Modular Blockchain networks with private channels.
By the end of this post, we will know
- Roles within Hyperledger Fabric
- Consensus
- Transaction Flow
- Channels
- State Database
- Chaincode / Smart Contracts
- MSP [Membership Service Provider]
Roles within a Hyperledger Fabric Network
- Clients
- Clients are applications that act on behalf of a person to propose transactions on the network.
- Peers
- 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 endorsing peers 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.
- Ordering Service
- The ordering service accepts endorsed transactions, orders them into a block, and delivers the blocks to the committing peers.
Consensus
In a distributed ledger system, consensus is the process of reaching agreement on the next set of transactions to be added to the ledger. In Hyperledger Fabric, consensus is made up of three distinct steps:
- Transaction endorsement
- Ordering
- Validation and commitment.
Transaction Flow (Step 1)
Within a Hyperledger Fabric network, transactions start out with client applications sending transaction proposals, or, in other words, proposing a transaction to endorsing peers.
Client applications are commonly referred to as applications or clients, and allow people to communicate with the blockchain network. Application developers can leverage the Hyperledger Fabric network through the application SDK.
Transaction Flow (Step 2)
Each endorsing peer simulates the proposed transaction, without updating the ledger. The endorsing peers will capture the set of Read and Written data, called RW Sets. These RW sets capture what was read from the current world state while simulating the transaction, as well as what would have been written to the world state had the transaction been executed. These RW sets are then signed by the endorsing peer, and returned to the client application to be used in future steps of the transaction flow.
Endorsing peers must hold smart contracts in order to simulate the transaction proposals.
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 “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.
Transaction Flow (Step 3)
The application then submits the endorsed transaction and the RW sets to the ordering service. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.
Transaction Flow (Step 4)
The ordering service takes the endorsed transactions and RW sets, orders this information into a block, and delivers the block to all committing peers.
The ordering service, which is made up of a cluster of orderers, does not process transactions, smart contracts, or maintains the shared ledger. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger. The Fabric v1.0 architecture has been designed such that the specific implementation of ‘ordering’ (Solo, Kafka, BFT) becomes a pluggable component. The default ordering service for Hyperledger Fabric is Kafka.
Ordering (Part 1)
Transactions within a timeframe 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 through the solving of a cryptographic puzzle, or mining, Hyperledger Fabric allows the organizations 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.
Ordering (Part 2)
Hyperledger Fabric provides three ordering mechanisms: SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT)
- SOLO is the Hyperledger Fabric ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node.
- Kafka is the Hyperledger Fabric ordering mechanism that is recommended for production use. This ordering mechanism utilizes 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.
- SBFT stands for Simplified Byzantine Fault Tolerance. This ordering mechanism is both crash fault-tolerant and byzantine fault-tolerant, meaning 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 their roadmap.
Transaction Flow (Step 5)
The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state. Specifically, that the Read data that existed when the endorsers simulated the transaction is identical to the current world state. When the committing peer validates the transaction, the transaction is written to the ledger, and the world state is updated with the Write data from the RW Set.
If the transaction fails, that is, if the committing peer finds that the RW set does not match the current world state, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the world state will not be updated.
Committing peers are responsible for adding blocks of transactions to the shared ledger and updating the world state. They may hold smart contracts, but it is not a requirement.
Transaction Flow (Step 6)
Lastly, the committing peers asynchronously notify the client application of the success or failure of the transaction. Applications will be notified by each committing peer.
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.
Transaction Flow Summary:
Channels:
Channels allow organizations to utilize 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.
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.
The diagram above shows three distinct channels — blue, orange, and grey. Each channel has its own application, ledger, and peers.
Peers can belong to multiple networks or channels. Peers 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 to remember:
- 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 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.
The state database 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 get 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. CouchDB 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 function. Both LevelDB and CouchDB 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 modeled 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 modeled as JSON data.
Smart Contracts (Chain Code)
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 (world state).
Hyperledger Fabric smart contracts are called chaincode and are written in Go. The chaincode serves as the business logic for a Hyperledger Fabric network, in that the chaincode directs how you manipulate assets within the network.
Membership Service Provider (MSP) | Identities
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, organizations 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 allows 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 organization brings their favorite.
What Does the MSP Do?
To start, users are authenticated using a certificate authority. The certificate authority 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 utilizes the credentials of the entities associated with their respective identities, and outputs an endorsement. A signature is 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 not. If the output is ‘accept’, the user can see the transactions in the network and perform transactions with other actors in the network. If the output is ‘reject’, 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
In general, Certificate Authorities manage enrollment 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 certificate authority is in charge of issuing and revoking Enrollment Certificates (E-Certs).
The current implementation of Fabric-CA only issues E-Certs, which supply long term identity certificates. E-Certs, which are issued by the Enrollment Certificate Authority (E-CA), assign peers their identity and give them permission to join the network and submit transactions.
Recap:
So in this post, we understood the components of Hyperledger Fabric which will help us define the Tuna Fishing Supplychain problem from a technical stand point. In the next chapter we'll focus on installing Hyperledger Fabric!
-Moses Sam Paul