How to Develop Blockchain Applications Using Hyperledger Fabric?

Hyperledger Fabric is an opensource collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration including leaders in banking, finance, Internet of Things, manufacturing, supply chains, and technology.

The Linux Foundation hosts Hyperledger under the foundation.

Hyperledger does not promote a single blockchain codebase or a single blockchain project. Rather, it enables a worldwide developer community to work together and share ideas, infrastructure and code.

Hyperledger Fabric is one of the project framework under Hyperledger, it can be deployed as fully disjoint networks with separate endorser sets and ordering nodes to provide privacy and confidentiality.

(Image Source: https://www.hyperledger.org/blog/2018/10/26/hyperledger-fabric-now-supports-ethereum)

It is a platform for building distributed ledger solutions with a modular architecture that delivers a high degree of confidentiality, flexibility, resiliency and scalability. This enables solutions developed with Fabric to be adapted for any industry.

The Hyperledger Fabric can be classified into 3 steps:

Step 1: Execution Phase

In the execution phase, clients sign and send the transaction proposal (or simply, proposal) to one or more endorsers for execution.

Recall that every chaincode implicitly specifies a set of endorsers via the endorsement policy. A proposal contains the identity of the submitting client, the transaction payload in the form of an operation to execute, parameters, and the identifier of the chaincode, a nonce to be used only once by each client (such as a counter or a random value) and a transaction identifier derived from the client identifier and the nonce.

The endorsers simulate the proposal, by executing the operation on the specified chaincode, which has been installed on the blockchain. The chaincode runs in a Docker container, isolated from the main endorser process.

Executing a transaction before the ordering phase is critical to tolerating non-deterministic chaincodes. A chaincode in Fabric with non-deterministic transactions can only endanger the liveness of its own operations, because a client might not gather a sufficient number of endorsements, for instance. This is a fundamental advantage over order-execute architecture, where non-deterministic operations lead to inconsistencies in the state of the peers.

Finally, tolerating non-deterministic execution also addresses DoS attacks from untrusted chaincode as an endorser can simply abort an execution according to a local policy if it suspects a DoS attack. This will not endanger the consistency of the system, and again, such unilateral abortion of execution is not possible in order execute architectures.

Step 2: Ordering Phase

When a client has collected enough endorsements on a proposal, it assembles a transaction and submits this to the ordering service. The transaction contains the transaction payload (i.e., the chaincode operation including parameters), transaction metadata, and a set of endorsements. The ordering phase establishes a total order on all submitted transactions per channel.

In other words, ordering atomically broadcasts endorsements and thereby establishes consensus on transactions, despite faulty orderers. Moreover, the ordering service batches multiple transactions into blocks and outputs a hash-chained sequence of blocks containing transactions. Grouping or batching transactions into blocks improves the throughput of the broadcast protocol, which is a well-known technique used in fault-tolerant broadcasts.

The ordering service ensures that the delivered blocks on one channel are totally ordered.

However, every individual ordering implementation is allowed to come with its own liveness and fairness guarantees with respect to client requests.

Step 3: Validation Phase

Blocks are delivered to peers either directly by the ordering service or through gossip. A new block then enters the validation phase which consists of three sequential steps:

• The endorsement policy evaluation occurs in parallel for all transactions within the block. The evaluation is the task of the so-called validation system chaincode (VSCC), a static library that is part of the blockchain’s configuration and is responsible for validating the endorsement with respect to the endorsement policy configured for the chaincode.

• A read-write conflict check is done for all transactions in the block sequentially. For each transaction it compares the versions of the keys in the read set field to those in the current state of the ledger, as stored locally by the peer, and ensures they are still the same. If the versions do not match, the transaction is marked as invalid and its effects are disregarded.

• The ledger update phase runs last, in which the block is appended to the locally stored ledger and the blockchain state is updated. In particular, when adding the block to the ledger, the results of the validity checks in the first two steps are persisted as well, in the form of a bit mask denoting the transactions that are valid within the block. This facilitates the reconstruction of the state at a later time.

Fabric allows components, such as consensus and membership services, to be plug-and-play. It leverages container technology to host smart contracts called “chaincode” that contain the business rules of the system. And it’s designed to support various pluggable components and to accommodate the complexity that exists across the entire economy.

Starting from the premise that there are no “one-size-fits-all’’ solutions, Fabric is an extensible blockchain platform for running distributed applications. It supports various consensus protocols so it can be tailored to different Blockchain use cases and trust models.

Request for a free quote to reach out to us on [email protected] and our experts will get back to you with the best solution for your business.