Reviewing the Hyperledger Fabric architecture and components

We will review and examine various Hyperledger Fabric components and architectures throughout this recipe. Hyperledger Fabric has three core components, which are peers, ordering service, and Fabric CA:

• Peer: A node on the network that maintains the state of the ledger and manages chaincode. Any number of peers may participate in a network. A peer can be an endorser, which executes transactions, or a committer, which verifies the endorsements and validates transactions results. An endorser is always a committer. Peers form a peer-to-peer gossip network. A peer manages the events hub and delivers events to the subscribers.
• Ordering service: Packages transactions into blocks to be delivered to peers, since it communicates only with peers. The ordering service is the genesis of a network. Clients of the ordering service are peers and applications. A group of orderers run a communication service, called an ordering service, to provide an atomic broadcast. The ordering service accepts transactions and delivers blocks. The ordering service processes all configuration transactions to set up network policies (including readers, writers, and admins). The orderer manages a pluggable trust engine (such as CFT or BFT) that performs the ordering of the transactions.
• Fabric CA: Fabric CA is the certificate authority that issues PKI-based certificates to network member organizations and users. Fabric CA supports LDAP for user authentication and HSM for security. Fabric CA issues one root certificate to member organizations and one enrollment certificate to each authorized user.

Hyperledger Fabric also have several important key features and concepts:

• Fabric ledger: Maintained by each peer and consists of two parts: the blockchain and the world state. Transaction read/write and channel configurations sets are written to the blockchain. A separate ledger is maintained for each channel for each peer that joins. The world state has options of either LevelDB or CouchDB, where LevelDB is a simple key-value store and CouchDB is a document store that allows complex queries. The smart contract decides what is written into the world state.
• Channel: Provides privacy between different ledgers and exists in the scope of a channel. Channels can be shared across an entire network of peers, and peers can participate in multiple channels. Channels can be permissioned for a specific set of participants. Chaincode is installed on peers to access the world state. Chaincode is instantiated on specific channels. Channels also support concurrent execution for performance and scalability.
• Organization: Define boundaries within a Fabric blockchain network. Each organization defines an MSP for the identities of administrators, users, peers, and orderers. A network can include many organizations, representing a consortium. Each organization has an individual ID.
• Endorsement policy: The conditions by which a transaction can be endorsed. A transaction can only be considered valid if it has been endorsed according to its policy. Each chaincode is deployed with an endorsement policy. Endorsement system chaincode (ESCC) signs the proposal response on the endorsing peer and validation system chaincode (VSCC) validates the endorsement.
• Membership services provider (MSP): Manages a set of identities within a distributed Fabric network. It provides identities for peers, orderers, client applications, and administrators. Where the identities can be Fabric CA or external CA, MSP provides authentication, validation, signing and issuance. MSP support different crypto standards with a pluggable interface. A network can include multiple MSPs (typically one per organization), which can include TLS crypto material for encrypted communications.

Getting ready

We will look into a sample transaction flow on Hyperledger Fabric. Fabric uses the execute-order-validate blockchain transaction flow architecture shown in the following diagram:

How to do it...

In this section, we will review how a transaction is created on the Hyperledger Fabric network:

1. The Client Application submits a transaction proposal for smart contact A to the network. The endorsement policy requires three endorsers—E0, E1, and E2—to sign together.
2. The endorsers execute proposed transactions. At this time, three endorsers—E0, E1, E2—will each execute the proposed transaction independently. None of these executions will update the ledger. Each execution will capture the set of read and written (RW) data, which will now flow in the fabric network. All transactions should be signed and encrypted.
3. RW sets are asynchronously returned to the client application with a transaction proposal. The RW sets are signed by each endorser and will be processed later.
4. All transactions that returned from the Fabric network are submitted for ordering. The application can submit responses as a transaction to be ordered, and ordering happens across the Fabric in parallel with transactions submitted by other applications.
5. Ordering Service collects transactions into proposed blocks for distribution to committing peers. This proposed blocks can then be deliver to other peers in a hierarchy. There are two ordering algorithms available: SOLO (single node for development) and Kafka (crash-fault-tolerance for production). In the production system, it is suggested to use Kafka.
6. Committing peers validate the transactions. All committing peers validate against the endorsement policy and check whether RW sets are still valid for the current world state. World state is not update if there is invalid transctions but are retained on the ledger while validated transactions are applied to the world state.
7. Client applications can register to be notified on the status of transactions, to find out whether they succeed or fail, and when blocks are added to the ledger. Client applications will be notified by each peer to which they are independently connected.

How it works...

We reviewed how transaction flow works in Fabric. Fabric uses the execute-order-validate model with the following seven steps:

1. Client application submits a transaction proposal
2. Endorsers execute the proposed transactions
3. Client applications receive transaction proposal response
4. Transactions are submitted for ordering
5. Transactions are delivered to committing peer
6. Validated transaction are applied to world state
7. Client applications get notified with the status of the transaction

In the next recipe, we will walk through how to install Hyperledger Fabric on Amazon Web Services (AWS).