Hyperledger Fabric

Introduction
Hyperledger Fabric is a platform for distributed ledger solutions underpinned by a modular
architecture delivering high degrees of confidentiality, resiliency, flexibility, and scalability.
It is designed to support pluggable implementations of different components and
accommodate the complexity and intricacies that exist across the economic ecosystem.

What is Hyperledger Fabric?

The Linux Foundation founded the Hyperledger project in 2015 to advance cross -industry
blockchain technologies. Rather than declaring a single blockchain standard, it encourages a
collaborative approach to developing blockchain technologies via a community process,
with intellectual property rights that encourage open development and the adopt ion of key
standards over time.

Hyperledger Fabric is one of the blockchain projects within Hyperledger. Like other
blockchain technologies, it has a ledger, uses smart contracts, and is a system by which
participants manage their transactions.

Where Hyperledger Fabric breaks from some other blockchain systems is that it
is private and permissioned. Rather than an open permissionless system that allows
unknown identities to participate in the network (requiring protocols like “proof of work” to
validate transactions and secure the network), the members of a Hyperledger Fabric network
enroll through a trusted Membership Service Provider (MSP).

Hyperledger Fabric also offers several pluggable options. Ledger data can be stored in
multiple formats, consensus mechanisms can be swapped in and out, and different MSPs are
supported.

Hyperledger Fabric also offers the ability to create channels, allowing a group of
participants to create a separate ledger of transactions. This is an especially important option
for networks where some participants might be competitors and not want every transaction
they make — a special price they’re offering to some participants and not others, for
example — known to every participant. If two participants form a channel, then those
participants — and no others — have copies of the ledger for that channel.
Shared Ledger
Hyperledger Fabric has a ledger subsystem comprising two components: the world
state and the transaction log. Each participant has a copy of the ledger to every
Hyperledger Fabric network they belong to.

The world state component describes the state of the ledger at a given point in time. It’s the
database of the ledger. The transaction log component records all transactions which have
resulted in the current value of the world state; it’s the update history for the world state.
The ledger, then, is a combination of the world state database and the transaction log
history.

The ledger has a replaceable data store for the world state. By default, this is a LevelDB
key-value store database. The transaction log does not need to be pluggable. It simply
records the before and after values of the ledger database being used by the blockchain
network.

Smart Contracts
Hyperledger Fabric smart contracts are written in chaincode and are invoked by an
application external to the blockchain when that application needs to interact with the
ledger. In most cases, chaincode interacts only with the database component of the ledger,
the world state (querying it, for example), and not the transaction log.

Chaincode can be implemented in several programming languages. Currently, Go and Node

are supported.

This section outlines the key design features woven into Hyperledger Fabric that fulfill its
promise of a comprehensive, yet customizable, enterprise blockchain solution:

• Assets — Asset definitions enable the exchange of almost anything with monetary value over
the network, from whole foods to antique cars to currency futures.
• Chaincode — Chaincode execution is partitioned from transaction ordering, limiting the
required levels of trust and verification across node types, and optimizing network scalability
and performance.
• Ledger Features — The immutable, shared ledger encodes the entire transaction history for each
channel, and includes SQL-like query capability for efficient auditing and dispute resolution.
• Privacy — Channels and private data collections enable private and confidential multi -lateral
transactions that are usually required by competing businesses and regulated industries that
exchange assets on a common network.
• Security & Membership Services — Permissioned membership provides a trusted blockchain
network, where participants know that all transactions can be detecte d and traced by authorized
regulators and auditors.
• Consensus — A unique approach to consensus enables the flexibility and scalability needed for
the enterprise.

Assets
Assets can range from the tangible (real estate and hardware) to the intangible (contracts
and intellectual property). Hyperledger Fabric provides the ability to modify assets using
chaincode transactions.

Assets are represented in Hyperledger Fabric as a collection of key-value pairs, with state
changes recorded as transactions on a Channel ledger. Assets can be represented in binary
and/or JSON form.

Chaincode
Chaincode is software defining an asset or assets, and the transaction instructions for
modifying the asset(s); in other words, it’s the business logic. Chaincode enforces the rules
for reading or altering key-value pairs or other state database information. Chaincode
functions execute against the ledger’s current state database and are initiated through a
transaction proposal. Chaincode execution results in a set of key-value writes (write set) that
can be submitted to the network and applied to the ledger on all peers.

Ledger Features
The ledger is the sequenced, tamper-resistant record of all state transitions in the fabric.
State transitions are a result of chaincode invocations (‘transactions’) submitted by
participating parties. Each transaction results in a set of asset key-value pairs that are
committed to the ledger as creates, updates, or deletes.

The ledger is comprised of a blockchain (‘chain’) to store the immutable, sequenced record
in blocks, as well as a state database to maintain current fabric state. There is one ledger per
channel. Each peer maintains a copy of the ledger for each channel of which they are a
member.

Some features of a Fabric ledger:

• Query and update ledger using key-based lookups, range queries, and composite key queries
• Read-only queries using a rich query language (if using CouchDB as state database)
• Read-only history queries — Query ledger history for a key, enabling data provenance scenarios
• Transactions consist of the versions of keys/values that were read in chaincode (read set) and
keys/values that were written in chaincode (write set)
• Transactions contain signatures of every endorsing peer and are submitted to ordering service
• Transactions are ordered into blocks and are “delivered” from an ordering service to peers on a
channel
• Peers validate transactions against endorsement policies and enforce the policies
• Prior to appending a block, a versioning check is performed to ensure that states for assets that
were read have not changed since chaincode execution time
• There is immutability once a transaction is validated and committed
• A channel’s ledger contains a configuration block defining policies, access control lists, and
other pertinent information
• Channels contain Membership Service Provider instances allowing for crypto materials to be
derived from different certificate authorities

See the Ledger topic for a deeper dive on the databases, storage structure, and “query-
ability.”

Privacy
Hyperledger Fabric employs an immutable ledger on a per-channel basis, as well as
chaincode that can manipulate and modify the current state of assets (i.e. update key-value
pairs). A ledger exists in the scope of a channel — it can be shared across the entire network
(assuming every participant is operating on one common channel) — or it can be privatized
to include only a specific set of participants.

In the latter scenario, these participants would create a separate channel and thereby
isolate/segregate their transactions and ledger. In order to solve scenarios that want to
bridge the gap between total transparency and privacy, chaincode can be installed only on
peers that need to access the asset states to perform reads and writes (in other words, if a
chaincode is not installed on a peer, it will not be able to properly interface with the ledger).

When a subset of organizations on that channel need to keep their transaction data
confidential, a private data collection (collection) is used to segregate this data in a private
database, logically separate from the channel ledger, accessible only to the authorized subset
of organizations.
Thus, channels keep transactions private from the broader network whereas collections keep
data private between subsets of organizations on the channel.

To further obfuscate the data, values within chaincode can be encrypted (in part or in tota l)
using common cryptographic algorithms such as AES before sending transactions to the
ordering service and appending blocks to the ledger. Once encrypted data has been written
to the ledger, it can be decrypted only by a user in possession of the corresp onding key that
was used to generate the cipher text.

See the Private Data topic for more details on how to achieve privacy on your blockchain
network.

Depending on the needs of a network, participants in a Business-to-Business (B2B)

network might be extremely sensitive about how much information they share. For other
networks, privacy will not be a top concern.

Hyperledger Fabric supports networks where privacy (using channels) is a key operational
requirement as well as networks that are comparatively open.

Security & Membership Services

Hyperledger Fabric underpins a transactional network where all participants have known
identities. Public Key Infrastructure is used to generate cryptographic certificates which are
tied to organizations, network components, and end users or client applications. As a result,
data access control can be manipulated and governed on the broader network and on channel
levels. This “permissioned” notion of Hyperledger Fabric, coupled with the existence and
capabilities of channels, helps address scenarios where privacy and confidentiality are
paramount concerns.

See the Membership Service Providers (MSP) topic to better understand cryptographic
implementations, and the sign, verify, authenticate approach used in Hyperledger Fabric.

Consensus
In distributed ledger technology, consensus has recently become synonymous with a
specific algorithm, within a single function. However, consensus encompasses more than
simply agreeing upon the order of transactions, and this differentiation is highlighted in
Hyperledger Fabric through its fundamental role in the entire transaction flow, from
proposal and endorsement, to ordering, validation and commitment. In a nutshell, consensus
is defined as the full-circle verification of the correctness of a set of transactions comprising
a block.

Consensus is achieved ultimately when the order and results of a block’s transactions have
met the explicit policy criteria checks. These checks and balances take place during the
lifecycle of a transaction, and include the usage of endorsement policies to dictate which
specific members must endorse a certain transaction class, as well as system chaincodes to
ensure that these policies are enforced and upheld. Prior to commitment, the peers will
employ these system chaincodes to make sure that enough endorsements are present, and
that they were derived from the appropriate entities. Moreover, a versioning check will take
place during which the current state of the ledger is agreed or consented upon, before any
blocks containing transactions are appended to the ledger. This final check provides
protection against double spend operations and other threats that might compromise data
integrity, and allows for functions to be executed against non-static variables.

In addition to the multitude of endorsement, validity and versioning checks that take place,
there are also ongoing identity verifications happening in all directions of the transaction
flow. Access control lists are implemented on hierarchical layers of the network (ordering
service down to channels), and payloads are repeatedly signed, verified and authenticated as
a transaction proposal passes through the different architectural components. To conclude,
consensus is not merely limited to the agreed upon order of a batch of transactions; rather, it
is an overarching characterization that is achieved as a byproduct of the ongoing
verifications that take place during a transaction’s journey from proposal to commitment.

Check out the Transaction Flow diagram for a visual representation of consensus.

Transactions must be written to the ledger in the order in which they occur, even though
they might be between different sets of participants within the network. For this to happen,
the order of transactions must be established and a method for rejecting bad transactions
that have been inserted into the ledger in error (or maliciously) must be put into place.

This is a thoroughly researched area of computer science, and there are many ways to
achieve it, each with different trade-offs. For example, PBFT (Practical Byzantine Fault
Tolerance) can provide a mechanism for file replicas to communicate with each other to
keep each copy consistent, even in the event of corruption. Alternatively, in Bitcoin,
ordering happens through a process called mining where competing computers race to solve
a cryptographic puzzle which defines the order that all processes subsequently build upon.
Hyperledger Fabric has been designed to allow network starters to choose a consensu s
mechanism that best represents the relationships that exist between participants. As with
privacy, there is a spectrum of needs; from networks that are highly structured in their
relationships to those that are more peer-to-peer.

Applications and Smart Contract chaincode

Now that the channel C1 has a ledger on it, we can start connecting client applications to
consume some of the services provided by workhorse of the ledger, the peer!

Notice how the network has grown:

A smart contract S5 has been installed onto P1. Client application A1 in organization R1
can use S5 to access the ledger via peer node P1. A1, P1 and O4 are all joined to channel
C1, i.e. they can all make use of the communication facilities provided by that channel.

In the next stage of network development, we can see that client application A1 can use
channel C1 to connect to specific network resources – in this case A1 can connect to both
peer node P1 and orderer node O4. Again, see how channels are central to the
communication between network and organization components. Just like peers and orderers,
a client application will have an identity that associates it with an organization. In our
example, client application A1 is associated with organization R1; and although it is outside
the Fabric blockchain network, it is connected to it via the channel C1.
It might now appear that A1 can access the ledger L1 directly via P1, but in fact, all access
is managed via a special program called a smart contract chaincode, S5. Think of S5 as
defining all the common access patterns to the ledger; S5 provides a well-defined set of
ways by which the ledger L1 can be queried or updated. In short, client application A1 has
to go through smart contract S5 to get to ledger L1!

Smart contracts can be created by application developers in each organization to implement

a business process shared by the consortium members. Smart contracts are used to help
generate transactions which can be subsequently distributed to every node in th e network.
We’ll discuss this idea a little later; it’ll be easier to understand when the network is bigger.
For now, the important thing to understand is that to get to this point two operations must
have been performed on the smart contract; it must have been installed on peers, and
then defined on a channel.

Hyperledger Fabric users often use the terms smart

contract and chaincode interchangeably. In general, a smart contract defines
the transaction logic that controls the lifecycle of a business object contained in the world
state. It is then packaged into a chaincode which is then deployed to a blockchain network.
Think of smart contracts as governing transactions, whereas chaincode governs how smart
contracts are packaged for deployment.

Installing a chaincode package

After a smart contract S5 has been developed, an administrator in organization R1 must
create a chaincode package and install it onto peer node P1. This is a straightforward
operation; once completed, P1 has full knowledge of S5. Specifically, P1 can see
the implementation logic of S5 – the program code that it uses to access the ledger L1. We
contrast this to the S5 interface which merely describes the inputs and outputs of S5,
without regard to its implementation.
When an organization has multiple peers in a channel, it can choose the peers upon which it
installs smart contracts; it does not need to install a smart contract on every peer.

Defining a chaincode
Although a chaincode is installed on the peers of individual organizations, it is governed
and operated in the scope of a channel. Each organization needs to approve a chaincode
definition, a set of parameters that establish how a chaincode will be used on a channel. An
organization must approve a chaincode definition in order to use the installed smart contract
to query the ledger and endorse transactions. In our example, which only has a single peer
node P1, an administrator in organization R1 must approve a chaincode definition for S5.

A sufficient number of organizations need to approve a chaincode definition (A majority, by

default) before the chaincode definition can be committed to the channel and used to
interact with the channel ledger. Because the channel only has one member, the
administrator of R1 can commit the chaincode definition of S5 to the channel C1. Once the
definition has been committed, S5 can now be invoked by client application A1!

Note that although every component on the channel can now access S5, they are not able to
see its program logic. This remains private to those nodes who have installed it; in our
example that means P1. Conceptually this means that it’s the smart contract interface that is
defined and committed to a channel, in contrast to the smart contract implementation that is
installed. To reinforce this idea; installing a smart contract shows how we think of it
being physically hosted on a peer, whereas a smart contract that has been defined on a
channel shows how we consider it logically hosted by the channel.
NOTE:

Types of peers
In Hyperledger Fabric, while all peers are the same, they can assume multiple roles
depending on how the network is configured. We now have enough understanding of a
typical network topology to describe these roles.

• Committing peer. Every peer node in a channel is a committing peer. It receives blocks
of generated transactions, which are subsequently validated before they are committed to
the peer node’s copy of the ledger as an append operation.
• Endorsing peer. Every peer with a smart contract can be an endorsing peer if it has a
smart contract installed. However, to actually be an endorsing peer, the smart contract
on the peer must be used by a client application to generate a digitally signed transaction
response. The term endorsing peer is an explicit reference to this fact.

An endorsement policy for a smart contract identifies the organizations whose peer
should digitally sign a generated transaction before it can be accepted onto a committing
peer’s copy of the ledger.
These are the two major types of peer; there are two other roles a peer can adopt:

• Leader peer. When an organization has multiple peers in a channel, a leader peer is a
node which takes responsibility for distributing transactions from the orderer to the other
committing peers in the organization. A peer can choose to participate in static or
dynamic leadership selection.

It is helpful, therefore to think of two sets of peers from leadership perspective – those
that have static leader selection, and those with dynamic leader selection. For the static
set, zero or more peers can be configured as leaders. For the dynamic set, one peer will
be elected leader by the set. Moreover, in the dynamic set, if a leader peer fails, then the
remaining peers will re-elect a leader.

It means that an organization’s peers can have one or more leaders connected to the
ordering service. This can help to improve resilience and scalability in large ne tworks
which process high volumes of transactions.
• Anchor peer. If a peer needs to communicate with a peer in another organization, then it
can use one of the anchor peers defined in the channel configuration for that
organization. An organization can have zero or more anchor peers defined for it, and an
anchor peer can help with many different cross-organization communication scenarios.
Note that a peer can be a committing peer, endorsing peer, leader peer and anchor peer all at
the same time! Only the anchor peer is optional – for all practical purposes there will always
be a leader peer and at least one endorsing peer and at least one committing pe er.

What is Hyperledger fabric in Blockchain?

Hyperledger Fabric is a modular blockchain framework that acts as a foundation for
developing blockchain-based products, solutions, and applications using plug-and-play
components that are aimed for use within private enterprises.

Who is using Hyperledger fabric?

Companies Currently Using Hyperledger Fabric

Company Name Website Employees

Northern Trust northerntrust.com Above 10,000

SAP sap.com Above 10,000

Horizons horizonsfamily.org From 50 to 199

Amazon Web Services aws.amazon.com Above 10,000

How does Hyperledger fabric work?
Hyperledger Fabric is a permissioned blockchain network that gets set by the organizations that
intend to set up a consortium. ... The client application uses Hyperledger Fabric SDK or REST
web service to interact with the Hyperledger Fabric network.

Does Hyperledger have a coin?

No, Hyperledger is a developmental framework and set of tools designed to enable users to
build their own blockchain solutions. ... Hyperledger Project itself will never build its own
cryptocurrency. You'll never see a Hyperledger coin.

What is difference between Hyperledger and ethereum?

The most essential distinction between Hyperledger and Ethereum is the intent they are
designed for. Ethereum runs the Smart Contracts on the EVM for applications that are attributed
to being decentralized and are for mass consumption. On the other hand, Hyperledger leverages
blockchain technology for business.

Is Hyperledger fabric a private Blockchain?

Hyperledger Fabric is one of the blockchain projects within Hyperledger. Like
other blockchain technologies, it has a ledger, uses smart contracts, and is a system by which
participants manage their transactions. Where Hyperledger Fabric breaks from some
other blockchain systems is that it is private and permissioned.
Who is the founder of Hyperledger fabric in Blockchain?
The founders of hyper ledger fabric are Tama Blummer and Christopher Ferris. Hyperledger
Fabric is a blockchain structure usage and one of the five "hyper ledger ventures" facilitated
by The Linux Foundation. Consensus and membership services.

Is Hyperledger free to use?

How much does Hyperledger cost? Hyperledger is an open source collaborative effort that is
hosted by The Linux Foundation. ... All projects are open source, which means that you can
download and use the software free of charge.