UNIT 3

What is Hyperledger?
Hyperledger is an open-source project initiated by the Linux Foundation with the goal of
advancing blockchain technologies for enterprise use. It is a collaborative effort to develop and
promote blockchain frameworks and tools that can help businesses create highly secure, scalable,
and efficient distributed ledger systems. Unlike public blockchains like Bitcoin or Ethereum,
which are designed primarily for decentralized digital currency and trustless systems,
Hyperledger focuses on permissioned blockchains designed for private, permission-based
networks, where participants are known and trusted.

Key Features of Hyperledger

1. Modular and Flexible: Hyperledger allows organizations to customize blockchain

solutions according to their needs. The modular architecture means that different
components can be adjusted, swapped, or replaced without affecting the core
functionality.
2. Enterprise-Grade Blockchain: Hyperledger is built specifically for enterprise use,
offering robust tools for building secure, scalable, and configurable blockchain networks
that can be used in real-world business environments.
3. Privacy and Confidentiality: Hyperledger emphasizes privacy, and one of the key
features is the ability to have private transactions and confidential data. It achieves this
by allowing private channels and data isolation, ensuring that only the parties involved
in a transaction can access the data.
4. Permissioned Network: A permissioned blockchain means that only authorized
participants can join and interact with the network. This is a key difference from
permissionless blockchains, which anyone can join. In Hyperledger, the network is
controlled and managed by a set of pre-approved participants, which makes it more
suitable for businesses that require regulatory compliance, confidentiality, and
governance.

2. Key Components of Hyperledger

Hyperledger is not just a single technology but rather a collection of different blockchain
frameworks and tools that serve various needs. Here are the key projects and components that
make up the Hyperledger ecosystem:
Hyperledger Fabric

Fabric is the most well-known framework within Hyperledger and is designed for enterprise
blockchain solutions. It is a permissioned blockchain that focuses on security, scalability, and
modularity. Let’s break down the key features of Hyperledger Fabric:

1. Modular Architecture: Fabric's most powerful feature is its modularity. It allows for
customization at almost every level of the blockchain network. For example, users can
choose the consensus algorithm (e.g., Raft or PBFT), decide how chaincode (smart
contracts) is executed, and control the network configuration, including how data is
stored.
2. Channels: Fabric introduces the concept of channels, which are private, isolated
networks within the overall network. These channels allow participants in different
transactions to share data without exposing it to everyone else on the network. This is a
major advantage in industries where privacy and confidentiality are crucial (e.g., banking,
healthcare).
3. Smart Contracts (Chaincode): In Hyperledger Fabric, the term chaincode is used for
what is commonly referred to as smart contracts in other blockchain platforms.
Chaincode is used to define the business logic for transactions. Fabric supports writing
chaincode in Go, Java, and JavaScript, making it flexible for developers from various
backgrounds.
4. Consensus Mechanisms: Hyperledger Fabric allows different consensus algorithms to
be used based on the needs of the business. Popular consensus mechanisms include Raft
(leader-based) and PBFT (Practical Byzantine Fault Tolerance), which ensures that the
network can maintain agreement even in the case of faulty or malicious nodes.
5. Endorsement Policies: A key feature of Fabric is its endorsement model, which specifies
which peers must validate and approve a transaction. For example, a policy might say
that at least two out of five designated endorsing peers must sign off on a transaction
before it can proceed. This ensures that transactions are approved by trusted participants.

Hyperledger Sawtooth

Sawtooth is another blockchain framework under Hyperledger, and it is designed to focus on

scalability and flexibility. Key features of Sawtooth include:

1. Pluggable Consensus: Sawtooth allows for a variety of consensus mechanisms to be

plugged into the system. One of the key consensus algorithms is PoET (Proof of
Elapsed Time), which is more energy-efficient than traditional proof-of-work systems.
2. Transaction Families: Sawtooth introduces the concept of transaction families. These
are predefined transaction types that can be customized for specific use cases. For
instance, a token transaction family might manage the creation and transfer of digital
assets.
3. Transaction Execution: In Sawtooth, the execution of transactions is separate from the
validation process, allowing for greater flexibility and scalability in large networks.
Hyperledger Iroha

Iroha is a simpler and lightweight framework designed for mobile and web applications. It is
easy to deploy and use and is intended for projects that don’t need the complexity of Fabric or
Sawtooth. Some features include:

1. Simple Design: Iroha is designed with simplicity in mind, making it suitable for use
cases like identity management and asset management.
2. Mobile-Friendly: Iroha is particularly well-suited for use in mobile and IoT applications
because it allows for the creation of lightweight blockchain-based solutions.

Hyperledger Indy

Indy is a framework designed specifically for decentralized identity management. It’s an

important piece of the Hyperledger ecosystem, particularly when you want to build systems that
manage self-sovereign identities (where users control their own identity data, without relying on
a central authority).

Key features of Indy include:

1. Decentralized Identity: Indy supports the creation and management of verifiable

credentials, which can be used for identity verification across a wide range of
applications (e.g., digital IDs, access control).
2. Privacy: Indy enables privacy-preserving identity systems, allowing users to prove their
identity without revealing unnecessary personal information.

Hyperledger Burrow

Burrow is a permissioned Ethereum smart contract blockchain. It is Ethereum-compatible,

meaning it can run Ethereum-based smart contracts in a permissioned environment. It supports:

1. Smart Contracts: Burrow supports EVM (Ethereum Virtual Machine), so Ethereum

developers can easily use the same smart contract code on Burrow’s permissioned
blockchain.
2. Interoperability: Burrow can interact with other blockchains, which makes it useful in
scenarios where multiple blockchain systems need to be integrated.

Hyperledger Caliper

Caliper is a blockchain benchmarking tool that helps measure the performance of different
blockchain implementations. It helps businesses to:
 1. Test Scalability: Caliper allows you to test how many transactions a blockchain can
handle per second, the latency of transactions, and how well the system scales as more
participants are added.
2. Benchmark Different Networks: It’s useful for comparing performance between
different blockchain frameworks (e.g., Fabric vs Sawtooth) to determine which is best
suited for your needs.

3. How Hyperledger Works

Let’s go through how Hyperledger Fabric (the most commonly used framework) works in
detail.

The Workflow in Hyperledger Fabric

1. Transaction Proposal:
o A user or an application sends a transaction proposal to the network. This
proposal typically requests an action, like transferring assets or executing a smart
contract. The transaction proposal is forwarded to a set of endorsing peers, which
validate whether the transaction makes sense in the current context.
2. Endorsement:
o The endorsing peers simulate the transaction using their own version of the ledger
to check whether it’s valid. If they agree, they send back an endorsement to the
client application, essentially saying, "This transaction looks good."
3. Transaction Submission:
o After gathering enough endorsements from the required endorsing peers, the
client submits the transaction to the ordering service, which is responsible for
arranging transactions in the correct order.
4. Ordering and Consensus:
o The ordering service doesn’t care about the content of the transactions; it only
ensures that they are ordered consistently. Once transactions are ordered, they are
grouped into blocks, which are then broadcast to all peers on the network.
5. Validation and Commitment:
o Once the peers receive the blocks, they validate the transactions by checking
whether the endorsements and signatures are correct and whether the transaction
doesn't violate any business rules. If the transaction is valid, it is committed to the
ledger, and the ledger is updated across all peers.
6. End Result:
o All peers in the network now have an updated and consistent view of the ledger.
This ensures transparency, integrity, and security of data across the network.

4. Key Use Cases for Hyperledger

Since Hyperledger focuses on permissioned blockchains, it is most commonly used for
applications where privacy, security, and governance are important. Here are some key use
cases:

1. Supply Chain Management:

o Hyperledger can be used to track products across the entire supply chain,
providing transparent and immutable records of where products have been, their
origin, and their condition. This can reduce fraud and improve accountability.
2. Financial Services:
o Hyperledger can streamline processes in banking, insurance, and trade finance. It
can be used to settle payments, handle loans, and trade securities more efficiently
and securely.
3. Healthcare:
o In the healthcare industry, Hyperledger can be used to securely store medical
records and ensure that only authorized users can access them. It also enables
interoperability between healthcare systems while preserving privacy.
4. Government and Identity Verification:
o Governments can use Hyperledger for self-sovereign identity management,
allowing individuals to control and manage their identity data. This can be used
for voting, citizenship, or financial services.
5. Voting Systems:
o Hyperledger can be used to create secure and transparent voting systems where
election results can be verified by all stakeholders while protecting voter privacy.

What is Consensus?

At the core, consensus in the context of blockchain is simply a way to make sure that everyone
in the network agrees on what the “truth” is. In a blockchain, the "truth" is the shared ledger that
records all transactions. In other words, it's how everyone in the system agrees on the state of the
data.

In Hyperledger, a permissioned blockchain, this is very important because you don’t have
anonymous users like in public blockchains (e.g., Bitcoin). Instead, the users are known entities
(e.g., businesses, organizations, or participants) that trust each other to some extent but still need
to validate and agree on the transactions.

Consensus in Hyperledger: How Does it Work?

Let’s use Hyperledger Fabric, one of the most common frameworks in the Hyperledger project,
as an example. The process of reaching consensus in Hyperledger Fabric follows several clear
steps:

1. Transaction Proposal: The First Step

Imagine a business wants to make a change to the ledger. They would send a transaction
proposal to a set of endorsing peers. These endorsing peers are just like trusted referees who
help check if the transaction makes sense, according to the rules.

For example:

 The proposal might say, “I want to transfer 100 units of currency from account A to
account B.”
 The endorsing peers will check if this transaction follows the rules, like checking if
Account A has enough units to transfer.

2. Endorsement: Referees Give the OK

The endorsing peers don’t immediately apply the transaction to the ledger. Instead, they simulate
the transaction (like testing it without making any real changes) and then give an endorsement.

This endorsement says, “We checked the transaction, and it looks good to go.” Each endorsing
peer signs this response to confirm it.

Think of it like having three referees in a sports game. Each referee watches the same play, and if
they all agree that it was fair, they sign a report saying the play was valid.

Endorsement Policy: This is a rule that says how many and which peers need to endorse a
transaction. For example, the policy might say that at least two out of three specific peers must
sign off on the transaction for it to proceed.

3. Sending the Transaction to the Ordering Service

Once the client (the one who made the proposal) collects enough endorsements from the referees
(endorsing peers), the transaction is sent to the ordering service.

The ordering service is like the central coordinator that makes sure all transactions are placed
in the right order. It doesn’t care about whether the transaction is valid — it only makes sure that
all transactions happen in a sequence that everyone agrees on.

It’s like a referee crew that orders the sequence of plays in a game, ensuring they happen in a fair
and consistent way.

4. Ordering the Transactions: Consensus Mechanism

Now, the ordering service needs a way to decide which transactions go in which order. This is
where the consensus algorithm comes in. The ordering service uses an algorithm to ensure that
all nodes (computers) in the network agree on the order of transactions.
There are two main consensus algorithms in Hyperledger Fabric:

 Raft: This is a simple, leader-based approach. One node (the leader) is responsible for
ordering transactions, and the others follow the leader's instructions. It’s like having one
referee make all the decisions, while the others just follow the leader.
 PBFT (Practical Byzantine Fault Tolerance): This one is more complex and allows
multiple nodes to make decisions together. It’s like having several referees
communicating with each other to agree on the fairness of each play. It can deal with
some referees acting in a faulty or malicious way.

5. Validation and Commit: The Final Step

Once the transactions are ordered, the peers (the nodes that store the ledger) receive the ordered
transactions in blocks. Now, each peer needs to validate the transactions in the block.

Validation means checking:

 Endorsement: Was the transaction approved by the right number of endorsing peers?
 Conflict check: Is the transaction trying to do something that conflicts with other
transactions? For example, is it trying to spend money that isn’t there?

Once the transactions pass the validation checks, the peers apply them to their ledger (which is
like the record book where all transactions are stored). Now, the ledger is updated with the new
state of things.

How Hyperledger Ensures Trust and Security

In a permissioned blockchain like Hyperledger, the network is more controlled, meaning the
participants (peers) are known and trusted to some extent. However, they still need a process to
verify transactions to avoid mistakes, fraud, or malicious actions.

Here’s how Hyperledger does this:

1. Endorsement policy ensures that only a specific set of trusted peers approve a
transaction.
2. Consensus mechanisms (like Raft or PBFT) ensure that all participants agree on the
order of transactions.
3. Transaction validation checks for errors or conflicts before any changes are made to the
ledger.

This process ensures that even if a small number of peers are faulty or behave maliciously, the
network can still reach agreement on the valid transactions.
Why Is This Important?

The main reason we need consensus is to:

 Ensure fairness: All participants agree on the same transactions, preventing fraud or
mistakes.
 Guarantee reliability: Even if some peers fail or act maliciously, the system can still
work and make decisions.
 Scale effectively: Since endorsement, ordering, and validation happen in different steps,
the system can handle many transactions more efficiently.

Key Points to Remember:

1. Transaction Proposal: A user requests a change to the ledger.

2. Endorsement: Trusted peers check the proposal and say if it’s okay.
3. Ordering Service: The service arranges the transactions in the correct order.
4. Consensus Algorithms: Raft and PBFT are methods to make sure everyone agrees on
the transaction order.
5. Validation: The network checks if the transaction is legitimate before committing it to
the ledger.

Decomposition of the Consensus Process in Hyperledger

Let’s break down the consensus process step by step, focusing on the most commonly used
framework in Hyperledger—Hyperledger Fabric—which includes a modular consensus system
and a flexible approach to consensus.

1. Transaction Proposal and Endorsement

In Hyperledger Fabric, the process begins with the client application initiating a transaction
proposal that requests an operation to be performed on the blockchain. For example, a business
might propose to transfer an asset or record a change in the state of a product in a supply chain.
Key Steps in this Phase:

 Transaction Proposal: The client sends a transaction proposal to a set of endorsing

peers. These are the nodes that are authorized to validate and endorse transactions in the
network.
 Endorsement: Each endorsing peer simulates the transaction and checks it against its
current state of the ledger. The peer executes the chaincode (smart contract) associated
with the transaction proposal, but it does not immediately update the ledger. Instead, the
peer creates an endorsement, which is essentially a signed statement saying that the
transaction is valid according to the business logic and the peer’s version of the ledger.
 Endorsement Policy: Hyperledger Fabric allows for a custom endorsement policy.
This policy dictates how many and which endorsing peers must sign off on a transaction
before it can proceed. For example, the policy may require that at least 3 of 5 endorsing
peers approve a transaction.

The endorsement process ensures that transactions are only considered valid if they meet
the business rules encoded in the chaincode and are agreed upon by trusted parties.

2. Transaction Ordering

After the transaction proposal is endorsed by the required number of endorsing peers, the next
step is to order the transactions. This is where ordering service comes into play. The ordering
service is responsible for establishing the order in which transactions are added to the
blockchain.

Key Steps in this Phase:

 Batching Transactions: Endorsed transactions are gathered into a block (a batch of

transactions).
 Ordering Service: The ordering service does not validate transactions. It only organizes
the transaction proposals in the correct order and places them in a block. This is a key
part of the consensus process in Hyperledger Fabric. The ordering service operates by
using a consensus protocol such as Raft, Kafka, or PBFT.
o Raft: A leader-based consensus protocol, widely used for small-to-medium scale
networks, provides high availability and fault tolerance.
o Kafka: A distributed message queue that also acts as an ordering service. It is
more suitable for high-throughput use cases.
o PBFT (Practical Byzantine Fault Tolerance): A consensus algorithm that
guarantees safety and consistency, even if some participants are faulty or
malicious.

In this step, the ordering service does not look at the transaction’s content; it just
ensures that they are ordered consistently across the entire network.
  Transaction Block Creation: Once the transactions are ordered, they are grouped into a
block and prepared for final validation.

3. Transaction Validation and Commitment

Once the ordered block containing the transactions is created, it is sent to all peers for
validation and commitment. Each peer validates the block before adding it to their version of
the ledger.

Key Steps in this Phase:

 Validation: Each peer checks the transactions in the block to ensure that:
1. The endorsements are valid (i.e., the transactions have been endorsed by the
required number of peers).
2. The transaction hasn’t already been included in the ledger.
3. The state of the ledger is still consistent with the transaction’s proposed changes
(i.e., no double-spending or conflicting operations).
 Commitment: After validation, each peer commits the block to their local copy of the
ledger. At this point, the ledger is updated, and the transaction is officially recorded in
the blockchain.
 Event Notification: Once the transaction is committed, an event is triggered to notify
interested parties, such as applications or other systems, that the transaction has been
successfully committed to the ledger.

HYPER LEDGER FABRIC COMPONENTS

1. Peers

Peers are like the workers or participants in the network. They keep track of the blockchain and
play different roles:

 Endorsing Peers: These are the peers that check if the transactions are correct. They
don’t immediately record them, but they verify that the transaction follows the rules and
then sign off on it (this is called endorsing).
 Committer Peers: These peers record the transactions into the blockchain once they
have been validated and endorsed.
 Anchor Peers: These peers help with communication between different organizations in
the network. They make sure peers from different organizations can talk to each other.

2. Ordering Service

Think of the ordering service as a traffic controller. Its job is to take all the validated
transactions from the endorsing peers and order them in the right sequence before adding them
to the blockchain.
  It doesn’t check the transactions for correctness, it just arranges them in the correct
order.
 The ordering service uses a consensus mechanism (a way to agree on the transaction
order), such as Raft (which is like a voting system for the network participants).

3. Ledger

The ledger is where all the data about transactions is stored. It has two important parts:

 Blockchain: This is like the history book. It stores every transaction that happens in the
network. Once a transaction is confirmed, it is added to the blockchain and can’t be
changed or erased.
 State Database: This is like the current state of the network. It keeps track of the latest
values of things, such as how many assets are owned by a person. This helps the system
to quickly check the current status without needing to read through the whole history.

4. Chaincode (Smart Contracts)

Chaincode is simply smart contracts—the rules that govern how transactions can happen on
the blockchain. It’s like the programming code that defines the business logic.

For example, if a person wants to transfer an asset, the chaincode will define whether that action
is valid (e.g., does the sender have enough of the asset to transfer?). It ensures all the rules are
followed when transactions happen.

 Chaincode can be written in languages like Go, Java, or JavaScript.

 It runs on endorsing peers when transactions are proposed, ensuring everything is valid.

5. Channels

A channel is like a private conversation in a big group. In a network with multiple

organizations, each channel is used to ensure that only the participants in a particular channel
can see and discuss specific transactions.

 Channels allow for privacy. Even though the same network is shared by many
participants, each group can keep its transactions private from others.

For example, if Organization A and Organization B want to work together on a project, they
can set up a channel where only they can see the transactions, even though other organizations
are on the same network.

6. Certificate Authority (CA)

The Certificate Authority (CA) is like a trusted identity provider. It verifies who each
participant is and gives them an identity certificate. These certificates are used to authenticate
people, organizations, and peers in the network.
  When a new participant wants to join the network (e.g., a new organization), the CA
checks their identity and gives them the proper credentials.
 If someone’s credentials are revoked (e.g., if they leave the network), the CA can remove
their access.

7. Network Policies and Endorsement Policies

 Network Policies: These define the rules for how the network works. For example,
which peers can join, how transactions are validated, and who gets to see which data.
 Endorsement Policies: These define who needs to approve a transaction before it’s
considered valid. For instance, the policy might say, "For a transaction to be valid, two
out of three peers need to endorse it." These policies make sure that the right people
approve a transaction before it goes through.

8. Clients

Clients are like users or applications that interact with the network. They ask the network to
perform actions like submitting transactions, checking the status of the ledger, or interacting with
smart contracts.

 Clients don’t hold the blockchain themselves; they send requests to peers.
 They use special Software Development Kits (SDKs) to make it easier for developers to
create applications that interact with Hyperledger Fabric.

9. Fabric SDKs and APIs

The SDKs (Software Development Kits) are tools that developers use to build applications that
communicate with the blockchain. They act as a bridge between the client application and the
blockchain network.

 SDKs help developers send transaction requests, query the ledger, and call the chaincode
(smart contracts).

10. Configuration Files

Configuration files are the settings for the blockchain network. These files tell Hyperledger
Fabric how the network should operate. For example, they define:

 How the channels should be set up.

 What policies should be in place for validating transactions.
 Which peers and ordering services should be used.

How All These Components Work Together:

 1. Transaction Flow:
o A client asks for a transaction (like transferring money or updating data).
o Endorsing peers check the transaction, ensuring it follows the rules set in the
chaincode (smart contract).
o If the transaction is valid, the endorsing peers sign off on it, creating an
endorsement.
o The ordering service takes these endorsed transactions, orders them, and places
them into blocks.
o The peers validate these blocks and then commit the transactions to the ledger
(the blockchain).
o The state database is updated, reflecting the latest values of assets, balances, etc.
2. Privacy through Channels:
o If a transaction is private, it’s sent to a specific channel, where only the peers in
that channel can see the transaction. Other organizations can’t see it.
3. Security:
o Each participant in the network (whether a peer or client) must have a digital
certificate issued by the Certificate Authority. This ensures that everyone’s
identity is verified before they can join the network or submit a transaction.

Chaincode Design and Implementation in Hyperledger Fabric

Chaincode in Hyperledger Fabric is essentially the smart contract that governs the logic for
how transactions are executed on the blockchain. It is where you define the rules and operations
of the business application running on Hyperledger Fabric. Let’s break down its design and
implementation without going into specific coding details.

1. What is Chaincode?

Chaincode is the term used for smart contracts in Hyperledger Fabric. It defines the business
logic or the rules for how transactions should be validated and how data should be managed on
the blockchain. Chaincode ensures that the data on the blockchain is accurate, up-to-date, and
adheres to the established rules.

In simpler terms, it's the "code" that runs on the blockchain network and defines what operations
are allowed and how the data should be manipulated when those operations happen.

2. Core Functions of Chaincode

 Initialization: When chaincode is first deployed to the blockchain network, it may need
to perform some setup, such as creating initial records or setting default values. This is
usually done through the init function.
  Transaction Execution: When a client sends a transaction request to the blockchain,
chaincode checks whether the transaction is valid according to its logic. The invoke
function is responsible for executing transactions such as adding new records, updating
existing ones, or transferring assets.
 State Management: Chaincode interacts with the ledger (a database-like structure)
where data is stored. It can read data from the ledger (e.g., to check an asset’s current
value) and write new data (e.g., when adding new records).

3. Key Lifecycle Stages of Chaincode

The lifecycle of chaincode involves several important stages:

a. Installation

 Chaincode must be installed on all peer nodes (computers that participate in the
network). These peers are the ones that execute the chaincode.

b. Instantiation

 Once installed, the chaincode needs to be instantiated (deployed) on the network. During
this stage, the init function is called, which is where any initial setup or data population
takes place. This is the moment when the chaincode starts running on the blockchain.

c. Invocation

 After instantiation, clients (users or applications) can invoke the chaincode to propose
transactions. For instance, a client might request to add a new car record or transfer
ownership of an asset. The invoke function processes these requests, validates them, and
then updates the blockchain if the request is valid.

d. Upgrade

 As business needs change, the chaincode might need to be updated. This can be done by
deploying a new version of the chaincode. When chaincode is upgraded, the system
checks and applies the necessary changes while ensuring the previous transactions remain
intact.

4. Designing Chaincode

When designing chaincode, follow these steps:

a. Understand Business Logic

The first step is to understand the problem you're solving. The business logic could involve
operations like:

 Creating or registering new assets.

 Updating or modifying asset details.
 Querying the current status of an asset.
 Transferring assets between parties.

Based on these operations, you can start defining what the chaincode will do.

b. Identify the Data to Be Managed

You need to decide what kind of data will be stored on the blockchain. For example, if you're
building a supply chain application, the data might include products, shipping statuses, and
transaction history.

 This data must be represented in a format (like a Car object or Product object) that can be
easily accessed, modified, and queried.

c. Define Key Operations

Define what operations the chaincode should perform. Typical operations include:

 Create: Add new records to the blockchain.

 Read: Query the current state of the records (e.g., get the current owner of an asset).
 Update: Modify existing records (e.g., transfer ownership of an asset).
 Delete: Remove records (though this is rare in blockchain, some systems may allow
logical deletion).

Each of these operations will be mapped to specific functions in the chaincode.

5. How Chaincode Works

Let’s walk through how chaincode operates in a blockchain network:

1. Client Request: A client application sends a transaction request to the network. For
example, this could be a request to transfer ownership of an asset, such as a car, from one
person to another.
 2. Chaincode Validation: The chaincode validates the transaction based on its business
rules. For instance, it checks if the current owner of the asset has permission to transfer
ownership, whether the asset exists, and if the transfer conditions are met.
3. Endorsement: The request is sent to endorse peers for validation. These peers check the
chaincode’s logic to ensure the transaction is valid. If the peers agree, they "endorse" the
transaction and send it back to the client.
4. Ordering: The ordering service groups endorsed transactions into blocks and orders
them. These blocks are then added to the blockchain in a sequential order.
5. Commitment: After ordering, the committing peers update the blockchain with the new
block of transactions. The state of the blockchain (data ledger) is now updated to reflect
the new transaction, such as the updated ownership of the car.

6. Benefits of Chaincode in Hyperledger Fabric

 Security: Chaincode ensures that only valid transactions can be executed based on the
business logic. Transactions are checked before being written to the ledger.
 Immutability: Once a transaction is committed to the blockchain, it cannot be changed
or erased. This ensures the integrity and trustworthiness of data.
 Flexibility: Since Hyperledger Fabric supports multiple programming languages (Go,
Java, JavaScript), developers can write chaincode in the language they are most
comfortable with.
 Privacy: Using channels in Hyperledger Fabric, chaincode can ensure that transactions
are private and only visible to authorized parties.

7. Testing and Deployment

Before deploying chaincode on a live network, it’s important to test it:

 Unit Testing: Testing individual chaincode functions to make sure each operation works
as expected.
 End-to-End Testing: Simulating real-world use cases to test how the entire system
works, from client interaction to blockchain updates.
 Performance Testing: Checking the scalability of chaincode to handle a large number of
transactions or requests.

Once tested, the chaincode is installed, instantiated, and invoked as needed by the clients.
When business logic changes, the chaincode can be upgraded without affecting previous data or
transactions.

Beyond Chaincode: Fabric SDK and Front-End

Hyperledger Fabric SDK (Software Development Kit)

The Hyperledger Fabric SDK is a crucial tool that connects your application (whether backend
or front-end) to the Fabric blockchain network. Think of it as the communication bridge between
the blockchain's underlying ledger and the business logic you've defined in chaincode.

The SDK handles many operations, such as managing network connections, submitting
transactions, querying data, and handling user identities. It abstracts the complex interactions
with the blockchain so that developers can focus on creating the business logic and user
interface.

Core Functions of the Fabric SDK

1. Network Connection Management:

o The SDK establishes and maintains the connection between your application and
the Hyperledger Fabric network.
o To connect, the SDK uses network configuration files, which describe details like
the peers (nodes that hold the blockchain ledger), orderers (nodes responsible for
maintaining the consensus of the blockchain), and channels (virtual networks for
private communications between network participants).
o The SDK typically requires configuration files like connection-profile or network-
config which define how the application communicates with the network.
2. Transaction Submission:
o Once a connection is established, the SDK provides methods to submit
transactions to the network. These transactions can involve chaincode functions
that add or modify the state in the blockchain ledger.
o Transactions follow a typical process:
1. Submit Transaction Request: The application calls a chaincode function
(using the SDK), which sends the transaction proposal to the peer nodes.
2. Endorsement: Multiple peers verify the transaction, ensuring it's valid.
This is called endorsing.
3. Ordering: After endorsement, the transaction is submitted to the ordering
service, which organizes the transactions into blocks and commits them to
the blockchain ledger.
3. Chaincode Interaction:
o The SDK abstracts how your application interacts with chaincode. For example,
the SDK allows you to invoke chaincode functions, query the state of the ledger,
and handle the results.
o Chaincode functions can perform tasks like querying the current state (e.g., asset
ownership) or updating it (e.g., transferring ownership of an asset).
4. Identity and Authentication:
 o Identity management in Hyperledger Fabric is built on X.509 certificates, and
the SDK provides tools for managing identities. These identities represent users
or organizations that interact with the blockchain.
o When a user attempts to invoke a chaincode function, the SDK verifies the user's
digital certificate and checks if they have the necessary permissions to perform
the action.
o The SDK manages the Certificate Authority (CA) system, which is responsible
for issuing certificates and managing identities.
5. Event Handling:
o Blockchain events such as the commitment of a block or the endorsement of a
transaction can be captured using the SDK.
o The SDK allows the application to subscribe to specific events (like a change in
the state or the completion of a transaction) and react to them. This could be
useful for triggering actions or providing real-time updates to the user interface.

Language-Specific Fabric SDKs

Hyperledger Fabric offers SDKs for several popular programming languages, allowing
developers to build applications in their preferred environment.

1. [Link] SDK:
o This is the most commonly used SDK for web and server-side JavaScript
applications.
o It provides a rich API to interact with the blockchain network, submit
transactions, query the ledger, and handle identity management.
2. Java SDK:
o The Java SDK is for developers working in Java environments, commonly used in
enterprise applications.
o It provides similar functionality to the [Link] SDK, but tailored for Java-based
applications.
3. Go SDK:
o The Go SDK is designed for Go (Golang) developers and provides functions to
interact with the Hyperledger Fabric network, just like the [Link] and Java
SDKs.
4. Python SDK (Community-Supported):
o There isn't an official Python SDK from Hyperledger Fabric, but community-
driven efforts provide the ability to use Fabric with Python applications.

Each SDK is designed to simplify interaction with the Fabric network and abstracts complex
blockchain operations like peer communication, transaction endorsement, and event
listening.
How SDK Works in Detail

1. Establishing Connection:
o Configuration Files: The SDK loads connection profiles that describe the Fabric
network, including the details of peers, channels, and ordering services. This
configuration helps the SDK understand how to connect to different nodes in the
network.
o Gateway: The Gateway in the SDK is responsible for connecting to the Fabric
network. It authenticates the client and manages the interaction between the client
application and the network. The Gateway abstracts away much of the low-level
complexity of interacting with the Fabric network.
2. Endorsement and Validation:
o When a transaction request is sent, endorsement is the process where peer nodes
validate the transaction proposal. This ensures that the transaction meets the
business rules as defined in the chaincode.
o The SDK manages this endorsement process, collects the endorsed responses
from peer nodes, and then submits the endorsed transaction to the ordering
service.
3. Transaction Submission:
o Once endorsed, the transaction is ordered and placed into blocks, which are then
committed to the blockchain ledger.
o The SDK can query the status of the transaction (e.g., success or failure) and
provide real-time feedback to the user.
4. Listening for Blockchain Events:
o The SDK allows applications to listen for events such as the completion of a
transaction, block commits, or changes to the ledger state. This is useful for
applications that require real-time updates or notifications based on blockchain
activities.

2. Front-End Development

Once the backend interactions are taken care of by the Fabric SDK, the next piece is providing a
user-friendly interface through which users can interact with the blockchain. This is typically
achieved via front-end web applications, mobile apps, or desktop software. The front-end is
what the end-users see and interact with, and it communicates with the blockchain through the
Fabric SDK.

Components of the Front-End

1. User Interface (UI):

 o The front-end provides a UI that displays information from the blockchain, such
as the status of assets, transaction histories, or user balances.
o The UI can be built using popular front-end frameworks such as React, Angular,
or [Link] for web applications or React Native for mobile apps. These
frameworks allow for dynamic, interactive interfaces that respond to changes in
data from the blockchain.
2. Interacting with Blockchain:
o The front-end uses the Fabric SDK to communicate with the blockchain network.
For example, it can submit transactions (such as transferring ownership of an
asset) or query the ledger (e.g., to get the current owner of an asset).
o The front-end sends requests to a backend API (RESTful or GraphQL) that, in
turn, interacts with the Fabric SDK to process the requests.
3. User Actions:
o The user interacts with the front-end through buttons, forms, or other elements.
For example:
 A user may fill out a form to submit a transaction (e.g., transferring an
asset).
 The front-end sends this transaction request to the back-end via the SDK.
 The back-end processes the request by invoking chaincode, and the user is
notified about the transaction's success or failure.
4. Authentication:
o Users need to authenticate themselves before performing blockchain-related
actions. The front-end works with the Fabric CA (Certificate Authority)
system, which manages user identities.
o Authentication can be done using digital certificates (X.509 certificates) issued by
the CA. The front-end ensures that only authorized users can invoke transactions
or access sensitive data.
5. Event Handling and Real-Time Updates:
o The front-end application can subscribe to blockchain events via the SDK. For
example, if a transaction has been confirmed on the blockchain, the front-end can
listen to this event and update the UI to reflect the new state.
o This enables real-time functionality, such as updating transaction status,
confirming block commits, or notifying users when specific actions have been
completed on the blockchain.

Example: Car Ownership System

Imagine you are building a car ownership system using Hyperledger Fabric.

1. Home Page:
o The front-end displays a list of cars owned by the logged-in user, showing
information like the make, model, and VIN (vehicle identification number).
o This data is pulled from the blockchain via queries made through the Fabric
SDK.
 2. Transfer Ownership:
o The user clicks on a car and selects the option to transfer ownership to another
user.
o They fill out a form with the new owner’s details, and the front-end sends a
request to the back-end (via SDK) to invoke the chaincode and transfer
ownership.
o The SDK submits the transaction to the Fabric network. Once the transaction is
validated and committed to the blockchain, the front-end updates to show the new
owner.
3. Real-Time Updates:
o The front-end listens for events (e.g., "transaction committed" or "block
updated"). Once the transaction is completed and the new ownership is recorded,
the UI updates in real-time to reflect the change.
4. User Authentication:
o Before the user can perform any transaction, they must authenticate. The front-
end integrates with the Fabric CA to handle certificate-based login.

What is Hyperledger Composer?

Imagine you're building a business app — like for managing car ownership, land records, or
supply chains — but instead of using a regular database, you want to use blockchain.

Hyperledger Composer was a set of tools that made it easy for people (even beginners) to
design, build, and test these kinds of blockchain apps on Hyperledger Fabric.

It was like a toolkit and playground rolled into one, to help you model real-world things (like
people, products, and contracts) and create logic (rules, permissions) without diving deep into
complex blockchain code.

Think of it like “LEGO blocks” for building blockchain business apps.

🔧 The Main Tools in Hyperledger Composer

1. Business Network Definition (BND)

This is like your whole app in one box. It contains:

 Who is involved (people, companies),

 What they’re working with (assets like cars, documents, products),
 What actions they can take (like transferring ownership),
 Who’s allowed to do what.

You can package all of this into a neat file that can be deployed onto the blockchain.
2. Modeling Tools (for describing data)

This lets you define what kind of data you're working with, like:

 What a product looks like (e.g., it has a name, serial number, and price),
 Who owns it (e.g., a person or a company),
 What kind of transactions can happen (like buying, selling, or transferring).

This is like creating blueprints or a catalog of everything in your blockchain app.

3. Logic Builder (for business rules)

Once you have your data, you need to decide how things work.

For example:

 What happens when someone transfers ownership?

 Can anyone sell an asset, or only the owner?
 Should the system notify someone when an asset is updated?

This tool allows you to define the rules and actions your app should take when users interact
with it.

4. Access Control Rules (for permissions)

Every blockchain user doesn’t need to see or do everything.

Access control helps you define:

 Who is allowed to see or update certain data,

 Who can create or approve transactions,
 What actions are blocked for certain roles.

It’s like setting security roles: admin, user, viewer, etc.

5. Composer Playground (Web Tool)

This was a visual website interface where you could:

 Create and modify your app without coding,

 Simulate transactions (like testing how selling a product would work),
 See how the ledger (blockchain database) changes over time.

Playground was great for learning and trying out ideas without writing much code.

It’s like a "demo room" where you build and test your app before going live.

6. Composer REST Server

Once your app is ready, you’ll probably want others to use it — like through a website or mobile
app.

The REST server:

 Instantly creates a way for outside applications to talk to your blockchain app.
 Lets developers build interfaces (front-end apps) more easily.
 Acts like a “translator” between regular apps and your blockchain backend.

So, you didn’t need to write complicated code to connect your app to the blockchain —
Composer did it for you.

7. Composer CLI (Command Line Tool)

For those who preferred working in the terminal, the CLI allowed you to:

 Deploy your app onto a live blockchain network,

 Install updates,
 Add new users,
 Manage the app's lifecycle.

This was used more by developers for setup and maintenance.

🔧 How Everything Worked Together — A Simple Analogy

Let’s say you're building a blockchain app for car registrations:

Real-World Equivalent Composer Tool

List of car owners and cars Modeling tools (Participants & Assets)

Rules like “Only the owner can sell a car” Logic builder & Access control rules

Simulation: Try transferring a car Composer Playground

Putting your app on the real blockchain Composer CLI

Allowing others to use your app Composer REST Server

🔧 Why Composer Was Retired

Hyperledger Composer was great for beginners, but:

 It simplified things too much for complex, real-world applications.

 Hyperledger Fabric kept evolving, but Composer couldn't keep up.
 Developers now prefer to use Fabric directly through SDKs, which is more powerful
and flexible, even though it takes more work.

So while Composer is no longer updated, it still serves as an awesome learning tool to

understand blockchain app development concepts quickly.

🔧 Key Takeaways (In Very Simple Terms)

 Hyperledger Composer helped people design, build, and test blockchain apps quickly.
 It included tools for defining who is involved, what data is tracked, and how
everything works.
 It gave you a visual way to try out ideas and test transactions.
 It created automatic APIs so other apps could talk to the blockchain easily.
 Although it's not used anymore in production, it's a great stepping stone to learning
Hyperledger Fabric.