This series will be focused upon Permission-ed Blockchain aiming towards Development and Deployment of Hyperledger Projects like Fabric ,Sawtooth,Explorer and Caliper.

You might have heard about Hyperledger Fabric is used for Permission based Blockchain deployment, but what makes it robust for Enterprise based Projects Development ?, or whats the Architecture behind this, lets go into the depth of it .

Blockchain is a Technology based upon Consensus, which comes from the subject of Distributed Systems. We will have various nodes in the network participating for making a transaction successful .But what did the IBM or Linux Foundation folks come up with to deal with a Technology which involves Distributed Systems, Messaging(Kafka), Containerization(Docker) ,Cloud(Latency Issues) , Operating Systems(Linux),Network Security(TLS,CA) and many more concepts from the Beautiful world of Computer Science.Lets explore this!

Fabric introduces a new Blockchain architecture aiming at resiliency, flexibility, scalability, and confidentiality.To achieve this we will need to have a way that allows programmers to execute their code written in different Programming Languages consistently across many nodes.Hence Fabric is a Pioneer when it comes to Distributed OS for permissioned Blockchain.

Fabric was able to achieve end to end throughout of more than 3500 transactions per second (much more then Ethereum or Bitcoin Blockchain) in certain popular deployment configurations, with sub-second latency, scaling well to over 100 peers(one of the component in Fabric a node that participates in consensus).Lets reverse Engineer the 2 approaches taken by IBM folks to reach to this point.

The two approaches are :

1. Order, Execute and Validate

2. Execute,Order and Validate

Order ,Execute and Validate Approach

All previous blockchain systems, permissioned or not, follow the order-execute architecture. This means that the blockchain network orders transactions first, using a consensus protocol, and then executes them in the same order on all peers sequentially.In a system like Ethereum (Public Permission-less Blockchain) the flow is :

1. Every peer(node) assembles a block containing valid transactions (to establish validity, this peer already pre-executes those transactions)

2. This Peer will try to solve the Proof of Work based Puzzle associated with the block.

3. If the Peer is lucky and is able to solve the Puzzle it propagates the block to the network via a gossip protocol.

4. Every node receiving the block validates the solution to the puzzle and all transactions in the block(they exchange each others Ledgers for confirmation). Effectively, every peer thereby repeats the execution of the lucky peer from its first step.Moreover, all peers execute the transactions sequentially (within one block and across blocks). The order-execute architecture is illustrated by:

Order,Execute and Validate

It looks cool, but there was an Observation made over here at the diverging states at the peers:

They reported a bug in the consensus protocol in non-deterministic transaction code ,which addressed limited performance, e.g., “only five transactions per second,” until users confessed that their average transaction took 200ms to execute. We learned that the key properties of a blockchain system, namely consistency, security, and performance, must not depend on the knowledge and goodwill of its users, in particular since the blockchain should run in an untrusted environment.

Fabric Had to discard this approach and moved on with the other one.

Execute,Order and Validate Approach

Fabric has no cryptocurrency associated with itself .It securely tracks its execution history in an append-only replicated ledger data structure .

In a nutshell, a distributed application for Fabric consists of two parts:

A smart contract, called chaincode, which is program code that implements the application logic and runs during the execution phase. The chaincode is the central part of a distributed application in Fabric and may be written by an untrusted developer. Special chaincodes exist for managing the blockchain system and maintaining parameters, collectively called system chaincodes .

Execute ,Order and Validate

1.We will have to create a Read ,Write Set ,collect the endorsements. and Order them,validate them and execute.

Read set and write sets are related to a transaction.

Suppose you have a transaction, read key a1 (suppose a1’s value = value_a1, version = version_a1), and key a2(suppose a2’s value = value_a2, version = version_a2), suppose we want a1’s value to be decremented, and a2’s value incremented;

So this transaction’s read set is :

{a1, value_a1, version_a1; a2, value_a2, version_a2};

i.e., the related key, its value, its version list;

This transaction’s write set is:

{a1, (value_a1 -1); a2, (value_a2 +1)};

i.e., the updated key and its new value list.

Read set and Write set are used for transaction endorsement and commit (update world state) at committer.

Endorsement policies define which peers need to agree on the results of a transaction before it can be added to the ledger(Account Book). Endorsement policies cannot be chosen or modified by untrusted application developers. An endorsement policy acts as a static library for transaction validation in Fabric, which can merely be parameterized by the chaincode. Only designated administrators may have a permission to modify endorsement policies through system management functions. A typical endorsement policy lets the chaincode specify the endorsers for a transaction in the form of a set of peers that are necessary for endorsement; it uses a monotone logical expression on sets, such as “three out of five” or “(A ∧ B) ∨ C.” Custom endorsement policies may implement arbitrary logic.

The Transaction flow looks like:

1. A Client sends transactions to the peers specified by the endorsement policy. Each transaction is then executed by specific peers and its output is recorded; this step is also called endorsement.

2. After execution, transactions enter the ordering phase, which uses a pluggable consensus protocol to produce a totally ordered sequence of endorsed transactions grouped in blocks.

3. These are broadcast to all peers, with the (optional) help of gossip. Unlike standard active replication , which totally orders transaction inputs, Fabric orders transaction outputs combined with state dependencies, as computed during the execution phase.

4. Each peer then validates the state changes from endorsed transactions with respect to the endorsement policy and the consistency of the execution in the validation phase.

5. All peers validate the transactions in the same order and validation is deterministic. In this sense, Fabric introduces hybrid replication paradigm in the Byzantine model, which combines passive replication (the pre-consensus computation of state updates) and active replication (the post-consensus validation of execution results and state changes).

As Fabric is permission-ed, all nodes that participate in the network have an identity, as provided by a modular membership service provider (MSP).Nodes in a Fabric network take up one of three roles:

1. Clients submit transaction proposals for execution, help orchestrate the execution phase, and, finally, broadcast transactions for ordering.

2. Peers execute transaction proposals and validate transactions. All peers maintain the blockchain ledger, an append-only data structure recording all transactions in the form of a hash chain, as well as the state, a succinct representation of the latest ledger state.Not all peers execute all transaction proposals, only a subset of them called endorsing peers (or, simply, endorsers) does, as specified by the policy of the chaincode to which the transaction pertains.

3. Ordering Service Nodes (OSN) (or, simply, Orderers) are the nodes that collectively form the ordering service. In short, the ordering service establishes the total order of all transactions in Fabric, where each transaction contains state updates and dependencies computed during the execution phase, along with cryptographic signatures of the endorsing peers. Orderers(heart of the Fabric )are entirely unaware of the application state, and do not participate in the execution nor in the validation of transactions. This design choice renders consensus in Fabric as modular as possible and simplifies replacement of consensus protocols in Fabric.

MSP giving identity, P2P gossip with Peers and Orderers.

A Fabric network actually supports multiple blockchains connected to the same ordering service. Each such blockchain is called a channel and may have different peers as its members. Channels can be used to partition the state of the blockchain network, but consensus across channels is not coordinated and the total order of transactions in each channel is separate from the others. Certain deployments that consider all orderers as trusted may also implement by-channel access control for peers.

We will go into depth of the Network Security implementation and flow of Fabric across all the components in my next Post.

For any further Queries or anything related to Blockchain or Devops you can DM me on Linkedin.

https://in.linkedin.com/in/anubhav-chaturvedi-a7465a72