MODULE 5

HYPERLEDGER

Module 5 BT, Prof Sapna. B. Patil

 Contents
• Hyperledger
• Hyperledger as a protocol
• Fabric
• Hyperledger Fabric
• Sawtooth lake
• Corda.

Module 5 BT, Prof Sapna. B. Patil

 1. Hyperledger Indtroduction
History
• Hyperledger, a Linux Foundation project, is an open-source community to
help advance technology and thought leadership.
• It is deemed an “umbrella” for developer communities building open-
source blockchain and related technologies.
• Hyperledger was announced and formally named in December 2015 by 17
companies in a collaborative effort created to advance blockchain
technology for cross-industry use in business.
• Hyperledger is curated by the Linux Foundation, which provides tools,
training, and events to scale any open source project.
• IBM initially contributed what was then called Open Blockchain and is
now called Fabric, and arguably that is the biggest/highest profile project.

Module 5 BT, Prof Sapna. B. Patil

 1. Hyperledger Indtroduction
Hyperledger Vision
• To provide robust and efficient standards for blockchain
ledger technology to facilitate mainstream commercial
adoption.
• Another goal is to provide a modular blockchain technology
that contains a rich, easy-to-use application programming
interface (API) and numerous core modules that enable easy
development and interoperability.

Module 5 BT, Prof Sapna. B. Patil

 1. Hyperledger Indtroduction
Projects under Hyperledger
• There are four categories of projects under
Hyperledger. Under each category, there are
multiple projects. The categories are:
1. Distributed ledgers
2. Libraries
3. Tools
4. Domain-specific

Module 5 BT, Prof Sapna. B. Patil

Hyperledger Indtroduction

Figure 17.1: Projects under Hyperledger

Module 5 BT, Prof Sapna. B. Patil
 2. Hyperledger as a protocol
Hyperledger – An Emerging Business Protocol
• Hyperledger aims to develop new blockchain
platforms based on real-world industry use
cases.
• It is evolving into a protocol and specification
for designing business blockchain networks.
• Unlike earlier blockchains focused on specific
industries, Hyperledger provides a reference
model for building cross-industry platforms.

Module 5 BT, Prof Sapna. B. Patil

 2. Hyperledger as a protocol
Hyperledger reference architecture
• Hyperledger published a reference architecture
model to guide developers.
• The architecture supports permissioned distributed
ledgers and is made up of modular components.
• Available publicly via Hyperledger whitepapers and
GitHub (e.g., Grid and hyperledger-labs).
• Reference architecture consists of various
components that form a business blockchain.
• These high-level components are shown in the
reference architecture diagram here, which has been
drawn from the aforementioned white paper: (
Module 5 BT, Prof Sapna. B. Patil
Conti..)
2. Hyperledger as a protocol
Fig: Reference architecture

Module 5 BT, Prof Sapna. B. Patil

 2. Hyperledger as a protocol
Key Components of the Architecture
• Identity Services: Authentication and authorization (Membership).
• Policy Services: Manage blockchain-wide rules and permissions.
• Blockchain & Transactions: Includes consensus manager, ledger, P2P
protocol, and storage. The consensus manager ensures that the ledger is
updateable only through consensus among the participants of the
blockchain network.
• Smart Contracts Layer: provides chaincode services in Hyperledger and
makes use of Secure Container technology to host smart contracts.
– Smart Contract: Code that defines transaction logic and affects
blockchain state.
– Chaincode: A deployable package that can include multiple smart
contracts.
– In Hyperledger Fabric, chaincode and smart contract are often used
interchangeably, but have nuanced differences.
Module 5 BT, Prof Sapna. B. Patil
 2. Hyperledger as a protocol
Core Functional Services provided by Hyperledger
• Consensus Services: Ensure agreement on transaction
order and state.
• Smart Contracts: Execute predefined business logic.
• Communication: Node-to-node message exchange.
• Security & Crypto: Provides confidentiality, integrity, and
privacy.
• Data Stores: Pluggable backend support (e.g., CouchDB,
GoLevelDB).
• Policy Management: Controls endorsement and access
rules.
• APIs & SDKs: Interface for clients and applications to
interact with blockchain.

Module 5 BT, Prof Sapna. B. Patil

 2. Hyperledger as a protocol
Hyperledger design principles: Blockchain services must meet
specific enterprise requirements. he Hyperledger reference
architecture is shaped by:Input from project participants,
Deep analysis of industry use cases. These insights were
distilled into key design principles.
1. Modular Structure
• Hyperledger is designed to be highly modular and pluggable.
• Modules for consensus, identity, smart contracts
(chaincode), data storage, and policy management can be
easily replaced or customized.
• Encourages developers to plug in or swap out components
based on business needs.
• Enables cross-industry flexibility without rebuilding the entire
system.

Module 5 BT, Prof Sapna. B. Patil

 2. Hyperledger as a protocol
2. Privacy and Confidentiality
• Hyperledger supports permissioned networks, where access and visibility are restricted.
• Cryptographic tools and algorithms enforce transaction-level privacy.
• Businesses can customize privacy settings, ranging from minimal to advanced encryption.
• Also supports hardware security modules (HSMs) for sensitive use cases.
• Conforms to regulatory requirements like GDPR and industry-specific compliance needs.
3. Identity Management
• Based on Public Key Infrastructure (PKI).
• Allows fine-grained access control and authentication.
• Supports both pseudonymity and anonymity where needed.
• Ensures participants can verify each other’s identity and authority without revealing
sensitive personal data.
4. Scalability
• Hyperledger is engineered to support high throughput and large user bases.
• Consensus and data handling are optimized for performance without compromising
security.
• It aims to meet real-world transaction volumes, especially for enterprise and supply chain
networks.
Module 5 BT, Prof Sapna. B. Patil
 2. Hyperledger as a protocol
5. Deterministic Transactions
• Ensures that transactions always produce the same outcome, no matter which
node executes them.
• Determinism is essential for achieving consensus in a distributed network.
• Prevents ambiguity and supports state consistency across the ledger.
6. Auditability
• All activities (transactions, identity changes, policy updates) are immutably
recorded.
• Provides a complete and verifiable audit trail, critical for compliance and
internal controls.
• Ensures accountability and traceability of all ledger activity.
7. Interoperability
• Aims to overcome the siloed nature of blockchain platforms.
• Supports communication and transaction exchange between different blockchain
networks.
• Hyperledger Quilt and external projects like Cosmos and Polkadot are examples
promoting interoperability.
• Seeks to define common standards Module 5for blockchain
BT, Prof Sapna. B. Patil messaging and value transfer.
 2. Hyperledger as a protocol
8. Portability
• Designed to run on a wide variety of environments and
platforms.
• Ensures that Hyperledger-based systems can work across:
– Different OS and hardware setups
– Multiple cloud providers or on-premises
– Standardized APIs and libraries allow consistent development
and deployment.
9. Rich Data Queries
• Enables advanced querying on the current ledger state.
• Supports traditional query languages (e.g., CouchDB's JSON
queries).
• Makes data access user-friendly and efficient, facilitating
analytics and integration.

Module 5 BT, Prof Sapna. B. Patil

 3. Fabric/Hyperledger Fabric
• Hyperledger Fabric is a blockchain project that was proposed
by IBM and Digital Asset Holdings (DAH).
• It is an enterprise-grade permissioned distributed ledger
framework, which provides a framework for the development
of blockchain solutions and applications.
• Fabric is based on a modular and pluggable architecture. This
means that various components, such as the consensus
engine and membership services, can be plugged into the
system as required.
• Currently, its status is active and it is the first project to
graduate from incubation to active state.

Module 5 BT, Prof Sapna. B. Patil

 4. Hyperledger Fabric
 Hyperledger is an open-source, collaborative effort to create blockchain
technology suitable for the enterprise.
 Hyperledger Fabric is an open-source platform for developing blockchain
solutions with a modular architecture and pluggable, interchangeable services using
container technology.
The primary goals of Hyperledger Fabric are to
• Support a wide variety of industry use cases with different requirements
• Comply with statutes and regulations that exist today
• Support verified identities and private and confidential transactions
• Support permissioned shared ledgers
• Support performance, scaling, auditability, identity, security, and privacy
• Reduce costly computations involved in proof of work

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
• Hyperledger Fabric provides a framework for developing blockchain solutions with a
modular architecture, pluggable implementations, and container technology.

• While leveraging open-source best practices, Hyperledger Fabric enables

confidentiality, scalability, and security in business environments.

• Unlike other blockchain implementations like Bitcoin or Ethereum, Hyperledger

Fabric is the only one that fulfills all four key elements of a blockchain for business:
– Permissioned network: Collectively defined membership and access rights within your
business network

– Confidential transactions: Gives businesses the flexibility and security to make

transactions visible to select parties with the correct encryption keys

– Doesn’t rely on cryptocurrencies: Doesn’t require mining and expensive computations to

assure transactions

– Programmable: Leverages the embedded logic in smart contracts to automate business

Module 5 BT, Prof Sapna. B. Patil
processes across your network
 4. HYPERLEDGER FABRIC
4.1 Membership Services
• Membership Service Provider (MSP) handles
identity and access control.
• Uses Certificate Authority (CA) to issue:
– Enrollment certificates (E-Certs)
– Transaction certificates (T-Certs)
• Provides authentication, authorization, and
identity validation.

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.2 Blockchain Services
• Blockchain services are core infrastructure
components of Hyperledger Fabric.
• They include:
I. Consensus
II. Distributed Ledger
III. Peer-to-Peer Protocol
IV. Ledger Storage
• These services are modular and pluggable.

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.2 Blockchain Services( Conti.)
I. Consensus Services
• Consensus provides transaction ordering
via a pluggable interface.
• Implemented through a specialized peer:
the Orderer.
• Orderer:
– Does not hold chaincode or ledgers.
– Creates and orders blocks.
Ordering Mechanisms Other Ordering Mechanisms
• SOLO: •Raft:
– Basic single-node orderer. •Crash fault-tolerant.
– For development/testing only. •Leader-follower consensus.
•PBFT (Practical Byzantine Fault):
• Kafka:
•Tolerance BFT protocol for state
– Uses Apache Kafka (crash fault- machine replication.
tolerant). •Future mechanisms can be plugged
– Not Byzantine fault-tolerant — intoB. Fabric
Module 5 BT, Prof Sapna. Patil due to its modularity.
acceptable in permissioned setups.
 4. HYPERLEDGER FABRIC
4.2 Blockchain Services( Conti.)
II. Distributed Ledger
• Composed of:
– Blockchain (linked blocks of transactions)
– World State (key-value database)
• Transactions update world state via chaincode.
• Databases:
– LevelDB (default)
– CouchDB (supports rich queries)
• Block Header:Number, Data hash, Previous hash
• Block Data:Ordered list of transactions
• Block Metadata: Creator identity, Timestamps, Signatures

Module 5 BT, Prof Sapna. B. Patil

Figure : Blockchain and transaction structure
Module 5 BT, Prof Sapna. B. Patil
 4. HYPERLEDGER FABRIC
4.2 Blockchain Services( Conti.)
III. Peer-to-Peer (P2P) Protocol
• Fabric uses gRPC with Protocol Buffers for messaging.
• Four main message types:
– Discovery: Node discovery on network join
– Transaction: Deploy, invoke, and query operations
– Consensus: Coordination between orderers
– Synchronization: Keeps all peers updated
IV. Ledger Storage
• Default storage: LevelDB (simple key-value store).
• Alternative: CouchDB (JSON document-based, supports rich
queries).
• Peers store world state locally using one of these backends.

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.3 Smart Contract Services
• Enable secure execution of business logic via chaincode,
components in this category as follows
I. Secure Container:
– Chaincode runs in Docker containers for isolation and safety.
– Primarily supports Golang, with support for other languages
possible.
II. Secure Registry:
– Maintains a record of all smart contract images deployed on
the network.
III. Events:
– Triggered by smart contracts or endorsers.
– External apps can listen and respond using event adapters,
similar to Solidity events.
• These services ensure safe, modular, and reactive
execution of smart contracts in Fabric networks.

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.4 APIs and CLIs in Hyperledger Fabric
• APIs provide an interface into Hyperledger Fabric by
exposing various REST APIs for interaction with the
blockchain.
• CLIs offer a subset of these REST APIs, enabling quick
testing and limited interaction with the blockchain.
• APIs allow developers to integrate and manage
blockchain applications effectively.
• CLIs simplify testing, debugging, and basic interaction
with the blockchain network.
• Both APIs and CLIs play a crucial role in managing and
interacting with the Hyperledger Fabric network.

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.5 Key Components of Hyperledger Fabric
I. Peers: Peers maintain the state of the distributed ledger and hold a local copy of
it. They communicate via the gossip protocol. There are three types of peers:
– Endorsing Peers: Simulate transaction execution and generate a read-write set.
Endorsers execute and endorse transactions.
– Committing Peers: Receive endorsed transactions, verify them, and update the
ledger.
– Orderer Nodes: Receive transactions from endorsers, sequence them, and send
them to committers for validation and commitment.
II. Clients: Software that interacts with Hyperledger Fabric via APIs to propose
transactions.
III. Channels: Allow for confidential transactions between parties on the network
by using separate overlay blockchains, ensuring privacy for transactions
within a channel.
IV. World State Database: A key-value store reflecting all committed transactions.
It uses LevelDB or CouchDB to store data and supports queries.
Module 5 BT, Prof Sapna. B. Patil
 4.5 Key Components of Hyperledger Fabric ( Conti..)
V. Transactions: Can be deployment or invocation transactions.
Deployment transactions deploy new chaincode, while invocation
transactions call functions from smart contracts. Transactions can
be public or confidential, depending on the channel's access.
VI. Membership Service Provider (MSP): Manages identities on the
blockchain network, authenticating clients and using a certificate
authority for identity verification.
VII. Smart Contracts (Chaincode): Chaincode functions like smart
contracts and executes conditions and parameters to update the
ledger. Typically written in Golang or Java.
VIII. Crypto Service Provider: Provides cryptographic algorithms and
standards for the blockchain network, including key management,
signature verification, and encryption/decryption. Works with MSP
to support cryptographic operations for endorsers, clients, and
peers.

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.6 Applications on blockchain:
• Composed of a user interface (usually JavaScript/HTML) interacting
with backend chaincode (smart contract) stored on the ledger via
an API layer.
• Hyperledger Fabric provides various APIs and command-line
interfaces to interact with the ledger, including interfaces for
identity, transactions, chaincode, ledger, network, storage, and
events.

Figure : AModule
typical5 BT,Fabric application
Prof Sapna. B. Patil
 4.6 Applications on blockchain( Conti..)
I. Chaincode Implementation in Hyperledger Fabric

• Chaincode, typically written in Golang or Java, can be public, confidential, or access-

controlled.

• Chaincode serves as a smart contract that users interact with through APIs to initiate state

changes or query the ledger.

• Chaincode implementation is performed by first creating the chaincode shim interface in the
code.
• Shims provide APIs for accessing state variables and the transaction context of chaincode. It
can either be in Java or Golang code.

• Chaincode Functions:

– Init(): Initializes chaincode when deployed and makes an initial state change.

– Invoke(): Executes functions and results in state changes, writing to the ledger.

– Query(): Queries the state of deployed chaincode without altering the ledger.

– Main(): Registers chaincode with peers when deployed.

Module 5 BT, Prof Sapna. B. Patil
4.6 Applications on blockchain( Conti..)

Figure 17.5: A high-level overview of a Hyperledger Fabric network

Module 5 BT, Prof Sapna. B. Patil
 4.6 Applications on blockchain( Conti..)
• Network Overview:
– Peers (Endorsers, Committers, and Orderers)
maintain copies of the blockchain.
– Membership Services (shown at the top-right)
validate and authenticate peers using a Certificate
Authority (CA).
– Blockchain systems can produce and listen for
events, triggering actions.
– User applications interact with the blockchain via
the Invoke() method to query or update the state.

Module 5 BT, Prof Sapna. B. Patil

 4.6 Applications on blockchain( Conti..)
II. Application Model in Hyperledger Fabric
• Any blockchain application for Hyperledger
Fabric follows the MVC-B architecture.
– View Logic: User interface (desktop, web, or
mobile).
– Control Logic: Orchestrates between the user
interface, data model, and APIs.
– Data Model: Manages off-chain data.
– Blockchain Logic: Manages blockchain
transactions via controller and data model.

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.7 Consensus in Hyperledger Fabric
• Consensus in Fabric consists of Three Main Steps:
i. Transaction Endorsement
– Simulates transaction execution using chaincode.
– Endorsing peers sign the result of execution (without updating the ledger).
ii. Ordering
– Handled by a cluster of orderers.
– Collects endorsed transactions and defines the order in which they will be
recorded.
– Pluggable ordering services include:
• Apache Kafka (initial versions)
• BFT-SMaRt
• Honey Badger
• Simplified BFT

iii. Validation and Commitment

– Performed by committing peers.
– Validates endorsed transactions against endorsement policies.
Module 5 BT, Prof Sapna. B. Patil
– Valid transactions are committed to the ledger.
4.7 Consensus in Hyperledger Fabric( Conti..)

Figure : The consensus flow

Module 5 BT, Prof Sapna. B. Patil

 4. HYPERLEDGER FABRIC
4.8 The transaction lifecycle in Hyperledger Fabric
• There are several steps that are involved in a
transaction flow in Hyperledger Fabric. These
steps are visualized in the following diagram:

Figure : The high-level transaction lifecycle

Module 5 BT, Prof Sapna. B. Patil
 4.8 The transaction lifecycle in Hyperledger Fabric
• Clients and peers must be registered with the Membership Service
Provider.
• Steps:
1. Transaction Proposal: Clients propose transactions and send to
endorsing peers.
2. Simulation by Endorsers: Chaincode is executed to generate a Read-
Write (RW) set (no ledger update).
3. Return Endorsement: Endorsed transaction is sent back to the
application.
4. Submission to Ordering Service: Application submits the endorsed
transaction and RW set.
5. Block Assembly: Ordering service creates a block of endorsed
transactions sorted by channel ID.
6. Block Broadcast: Ordering service broadcasts the block to all committing
peers.
7. Transaction Validation: Committing peers validate each transaction.
8. Ledger Update: Valid transactions are committed to the ledger.
9. Client Notification: Success or failure is reported back to the
client/application.

Module 5 BT, Prof Sapna. B. Patil

 4.8 The transaction lifecycle in Hyperledger Fabric
• The following diagram represents the aforementioned steps and the
Fabric architecture from a transaction flow perspective:

Module 5 BT, Prof Sapna. B. Patil

Figure 17.8: The transaction flow
 4.9 Fabric 2.0
• This is a major upgrade to the protocol. The
fundamentals remain the same, but some very
interesting new features and improvements have
been made, which are introduced in the following
sections.
4.9.1 New chaincode lifecycle management
4.9.2 New chaincode application patterns
4.9.3 Enhanced Privacy and Chaincode Deployment
4.9.4 Consensus & Performance Improvements

Module 5 BT, Prof Sapna. B. Patil

 4.9 Fabric 2.0
4.9.1 New Chaincode Lifecycle Management
• In Fabric 1.x, chaincode installation and deployment
had a major issue:
– One organization could install and instantiate chaincode
without consent from others.
– Other organizations had to blindly accept the chaincode.
• Problem with Fabric 1.x
– No proper agreement mechanism between organizations.
– Risk of unapproved or malicious chaincode being forced
onto all organizations.
• Fabric 2.0: The Solution
– Introduced a decentralized and collaborative process for
chaincode lifecycle management.
– Every organization must approve a chaincode before it is
activated on the network.
Module 5 BT, Prof Sapna. B. Patil
 4.9 Fabric 2.0
• Chaincode Lifecycle in Fabric 1.x (Old Way)
1. Each organization admin installs chaincode
on their own peers.
2. One admin instantiates (deploys or upgrades)
the chaincode.
3. Transaction results are sent to the orderers.
4. Orderers order the transactions → send to all
peers → peers commit the transaction.

Module 5 BT, Prof Sapna. B. Patil

 4.9 Fabric 2.0
Chaincode Lifecycle in Fabric 2.0 (New Way)
1. Install chaincode package on filesystem (each organization installs it on their
own peers).
2. Approve for your organization using approveformyorg function (meaning: "I
agree to this chaincode").
3. Send approved definition to orderers.
4. Commit to private collections if needed (collections = share private data only
between certain organizations, even if others are on the same channel).
5. Other organizations repeat the above steps (install + approve + send).
6. After everyone agrees, record is created that shows chaincode agreement.
7. Define the chaincode based on this mutual agreement.
8. Submit chaincode definition to orderers.
9. Commit the definition to all peers.
10. The admin who did the commit invokes init function to initialize the
chaincode.
11. Submit init to ordering service.
12. Commit the initialization to all peers.
Module 5 BT, Prof Sapna. B. Patil
 4.9 Fabric 2.0
4.9.2 New Chaincode Application Patterns
• Automated Checks:
Organizations can implement automated checks to add
additional validation steps before a transaction is endorsed.
This allows them to ensure specific internal or collaborative
conditions are satisfied before proceeding.
• Decentralized Agreement Support:
Hyperledger Fabric 2.0 supports decentralized agreement,
where multiple organizations can propose conditions that
must be fulfilled. A collective agreement on a transaction is
reached only when all proposed conditions are met.

Module 5 BT, Prof Sapna. B. Patil

 4.9 Fabric 2.0
4.9.3 Enhanced Privacy and Chaincode Deployment
• Data Privacy Enhancements:
– Collection-level endorsement policies
– Per-organization collections
– Share and verify private data within selected
organizations
• Chaincode Deployment Flexibility:
– No dependency on Docker daemon
– Use of external builders and launchers
– Chaincode can run in any environment approved by
the network operator

Module 5 BT, Prof Sapna. B. Patil

 4.9 Fabric 2.0
4.9.4. Consensus & Performance Improvements
• Consensus – Raft Protocol:
Hyperledger Fabric 2.0 uses the Raft protocol as a
Crash Fault-Tolerant (CFT) ordering service. It
operates on a leader-follower model and is built
using the etcd library to ensure reliable consensus.
• Performance Boosts:
Performance in Fabric 2.0 is enhanced by introducing
caching at the CouchDB state database level. This
improvement significantly reduces read latency
caused by previously expensive lookup operations.

Module 5 BT, Prof Sapna. B. Patil

 5. Hyperledger Sawtooth
• Sawtooth is an enterprise-grade distributed ledger that
can run in both permissioned and nonpermissioned
modes.
• Sawtooth has several 5.1 core features, which are
introduced in the following sections
i. Modular design
ii. Parallel transaction execution
iii. Global state agreement
iv. Dynamic and pluggable consensus algorithms
v. Multi-language support
vi. Enhanced event mechanism
vii. On-chain governance
viii. Interoperability

Module 5 BT, Prof Sapna. B. Patil

i. Modular Design
5. Hyperledger Sawtooth
• The modular architecture of Sawtooth separates the business logic from
core blockchain operations, making development more focused and
efficient.
• By using distinct layers for transaction processing and consensus
validation, it enhances scalability and maintainability of blockchain
applications.
ii. Parallel Transaction Execution
• Sawtooth’s parallel scheduler enables multiple transactions to be
executed simultaneously, breaking away from the traditional serial
execution model.
• This innovation significantly improves transaction throughput, making
Sawtooth suitable for high-performance enterprise use cases.
iii. Global State Agreement
• Each node in the Sawtooth network maintains a consistent and
cryptographically verifiable copy of the blockchain ledger.
• This ensures data integrity and trust across the entire distributed
Module 5 BT, Prof Sapna. B. Patil
network.
 5. Hyperledger Sawtooth
iv. Dynamic and Pluggable Consensus
• Sawtooth allows the consensus algorithm to be changed even after
the blockchain network has started running, providing unmatched
flexibility.
• The separation of consensus logic from transaction semantics
ensures adaptability without disrupting ongoing operations.
v. Multi-language Support
• Developers can create applications using languages they are
comfortable with, thanks to Sawtooth’s SDKs for Python, JavaScript,
Go, and more.
• This multi-language support broadens accessibility and speeds up
development for a diverse developer base.
vi. Enhanced Event Mechanism
• Applications built on Sawtooth can subscribe to specific blockchain
or custom events, enabling responsive and real-time functionality.
• The system can broadcast transaction outcomes without saving
them to the state, reducing overhead and improving efficiency.

Module 5 BT, Prof Sapna. B. Patil

 5. Hyperledger Sawtooth
vii. On-chain Governance
• Configuration settings and access permissions can be
stored and modified directly on the blockchain,
enabling transparent governance.
• This centralized reference for all nodes promotes
consistency and simplifies network administration.
viii. Interoperability
• Sawtooth integrates with other blockchain ecosystems,
such as Ethereum, through projects like SETH, which
supports EVM-based smart contracts.
• This cross-platform compatibility expands the usability
of Sawtooth in diverse, multi-chain environments.

Module 5 BT, Prof Sapna. B. Patil

 5. Hyperledger Sawtooth
5.2 Consensus in Sawtooth
Hyperledger Sawtooth supports multiple
consensus algorithms to suit different use
cases, ranging from testing environments to
secure production networks.
5.2.1 PoET
5.2.2 Devmode
5.2.3 PBFT
5.2.4 Raft

Module 5 BT, Prof Sapna. B. Patil

 5.2 Consensus in Sawtooth
5.2.1 PoET (Proof of Elapsed Time)
• PoET randomly elects block proposers based on the amount of time a
node has waited before proposing a block, rather than through
intensive computation like traditional Proof of Work.
• It uses Intel's SGX (Software Guard Extensions) to ensure trust and
security, creating a Trusted Execution Environment (TEE) for fairness
and cryptographic integrity.
• Unlike PoW used in Bitcoin, PoET minimizes electricity and resource
usage by replacing computational work with secure, verifiable wait
times.
Limitations of PoET
• Stale Chip Problem: Malicious actors can collect old, inexpensive SGX-
enabled CPUs to increase their chances of winning the leader lottery,
leading to inefficient hardware use and skewed fairness.
• Broken Chip Problem: If an SGX chip is compromised, it can be
exploited repeatedly to win consensus rounds, undermining the
system's trust and decentralization.
Module 5 BT, Prof Sapna. B. Patil
 5.2 Consensus in Sawtooth
Types of PoET
1. PoET CFT
– Uses a simulated SGX environment and can run on any
processor.
– Provides Crash Fault Tolerance (CFT) but is not Byzantine Fault
Tolerant (BFT).
2. PoET SGX
– Depends on real SGX hardware to ensure secure, verifiable
execution.
– Offers Byzantine Fault Tolerance (BFT) and consumes minimal
processing power.
3. DevMode Consensus
– A simple, development-mode consensus for testing purposes.
– Uses a basic random leader election method, not intended for
production environments.

Module 5 BT, Prof Sapna. B. Patil

 5.2 Consensus in Sawtooth
5.2.2 Devmode
• Development-Focused: Devmode is intended for
testing and development environments,
especially suitable for single-validator setups.
• Simple Leader Election: It uses a basic, random
leader election algorithm to simulate block
creation without complex consensus logic.
• Not for Production: Due to its lack of security and
fault tolerance, Devmode should not be used in
live or production blockchain networks.

Module 5 BT, Prof Sapna. B. Patil

 5.2 Consensus in Sawtooth
5.2.3 PBFT (Practical Byzantine Fault Tolerance):
A widely used BFT algorithm ideal for consortium networks,
offering robustness in environments with potentially
malicious nodes.
5.2.4 Raft:
A lightweight, leader-based consensus providing crash fault
tolerance and immediate transaction finality due to its fork-
free structure.
5.2.5 Quorum Voting:
Inspired by Ripple and Stellar, this mechanism offers near-
instant transaction finality, making it ideal for permissioned
networks where speed is critical.

Module 5 BT, Prof Sapna. B. Patil

 5.3 Transaction lifecycle
• Transaction is a function that, when executed, results in changing the
state of the blockchain.
• let's explore how a transaction flows in a Sawtooth network:
1. A client submits a transaction to a validator. This is usually achieved by
utilizing the REST API available with the validator. By default, port TCP
8008 is exposed where REST API is available.
2. After the transaction is submitted, it is propagated across the validator
network.
3. One of the validators is elected as a leader, which then creates a
candidate block and publishes it on the network.
4. This candidate block is propagated across the entire validator network.
5. When validators receive this block, it is validated. In addition,
transaction processors validate and execute all transactions present in
the candidate block.
6. Once the block is validated and verified, it is written in its respective
local storage and the stateModule 5 BT, Prof Sapna. B. Patil
is updated accordingly.
Figure : Sawtooth transaction lifecycle
Module 5 BT, Prof Sapna. B. Patil
 5.4 Components
• A Sawtooth network is a collection of such nodes, each maintaining
the same blockchain state through consensus.
• A Sawtooth node consists of several components like Validator,
REST API, Consensus Engine, and Transaction Processors.
5.4.1 We will introduce each one of these in the following section

Figure : Sawtooth node and network

Module 5 BT, Prof Sapna. B. Patil
 5.4 Components
1. Validator
• Core component that validates transaction batches and combines
them into blocks.
• Maintains network consensus and coordinates with clients,
processors, and other validators.
• Uses the Gossip Protocol for communication between nodes.
2. REST API & Client
• REST API acts as a bridge between clients and validators (default on
TCP port 8008).
• Client handles:
– Transaction creation and signing.
– Submitting batches to the validator.
– Event handling and user interface updates.

Module 5 BT, Prof Sapna. B. Patil

 5.4 Components
3. State Management
• Blockchain state is a record of all transactions since the
genesis block.
• Every node stores a local copy of the state and updates it
as new blocks are added.
• Global state ensures all nodes are synchronized.
4. Transaction Processors
• Validate transactions and update the state based on
transaction family rules.
• There is always a transaction family associated with a
transaction processor. Ex: smallbank_tp
• Responsible for:
– Business logic execution.
– State transition and validation.
– Registering with the validator and handling payloads.

Module 5 BT, Prof Sapna. B. Patil

 5.4 Components
5.4.1 Transaction families
• Platforms like Ethereum use a generic virtual machine (EVM) with a general-
purpose instruction set (opcodes).
• This flexibility allows smart contracts for any industry/domain.
• Problem: This approach creates a large attack surface, making it less secure.
– Example: The DAO hack and DoS attacks that exploited EVM opcodes.
• A model shown in the following figure describes the traditional smart contract
model, where a Generic virtual machine has been used to provide the interface
into the Blockchain for all domains:

Figure : The traditional smart

Module 5 BT, Prof contract
Sapna. B. Patil paradigm
 5.4 Components
5.4.1 Transaction families( Conti..)
• To address this, Sawtooth introduces transaction families, which
decompose the logic layer into domain-specific sets of rules and
operations. This reduces attack vectors and isolates business logic.
Key Concepts
• A Transaction Family = Data Model + Transaction Language
• It represents the logic layer for a specific domain (e.g., supply chain,
finance).
• Unlike a one-size-fits-all VM, each domain has its own transaction family
with:
– Its own rules
– A custom logic layer
– Restricted and domain-specific operations
Benefits
• Increased security – only relevant operations are exposed.
• Separation of concerns – keeps blockchain core separate from business
logic.
• Customization – businesses can create their own transaction families.

Module 5 BT, Prof Sapna. B. Patil

 5.4 Components
5.4.1 Transaction families( Conti..)

Figure 17.12: The Sawtooth (transaction families) smart contract paradigm

Module 5 BT, Prof Sapna. B. Patil
5.4.1 Transaction families( Conti..)
5.4 Components
Components of a Transaction Family
• Transaction Processor:
– Registers with validator.
– Handles transaction payloads.
– Updates/retrieves state.
• Data Model:
– Records & stores data.
– Defines valid operations.
• Client:
– Creates, signs, and batches transactions.
– Submits to validator.
REST API: an optional component in Hyperledger Sawtooth, facilitates
interaction between the client and the transaction processor. It can
run either on a validator node or as a separate service, thereby
making the system moreModule
modular [Link].
5 BT, Prof Sapna. Patil
 5.4 Components
5.4.1 Transaction families( Conti..)
Sample Transaction Families:

Module 5 BT, Prof Sapna. B. Patil

 6. CORDA
• Corda is a distributed ledger platform, but not a blockchain in
the traditional sense.
• Corda is a distributed ledger platform that offers blockchain-
like benefits without using blocks to batch transactions.
• It was built from scratch to solve problems in the financial
industry, such as inconsistent data, duplicated infrastructure,
and high operational risks.
• Unlike traditional blockchains, Corda doesn’t link transactions
in blocks but still ensures immutability and decentralization.
• Initially designed for financial applications, Corda now
supports government, healthcare, insurance, and supply
chains.

Module 5 BT, Prof Sapna. B. Patil

 6. CORDA
• Corda comes in two forms: Open Source (freely available) and
Enterprise Edition, which includes advanced features like
firewalls, high-availability nodes, and HSM support for
business use.
• The platform supports direct business transactions, enabling
privacy, reduced complexity, and lower operational costs.
• Corda is written in Kotlin for the Java Virtual Machine (JVM)

Module 5 BT, Prof Sapna. B. Patil

 6.1 Corda Architecture
• The main components of the Corda platform
include the
1. Corda network
2. state objects (contract code and legal prose)
3. Transactions
4. Consensus
5. flows.
We will explore these in more detail now.

Module 5 BT, Prof Sapna. B. Patil

 6.1.1 Corda Network
• Corda Network – A Secure, Permissioned Peer-to-Peer
Architecture
• The Corda network operates as a fully connected,
permissioned graph, enabling direct point-to-point (P2P)
communication between nodes.
• Unlike traditional blockchains, Corda does not use global
broadcasts or gossip protocols; instead, communication
happens only on a "need to know" basis.
• Nodes use the AMQP protocol for secure message
serialization and transmission.
• A central component, the Network Map Service, maintains
and publishes the list of participating peers, enabling trusted
discovery in the network.

Module 5 BT, Prof Sapna. B. Patil

Figure : Corda high-level network architecture
Module 5 BT, Prof Sapna. B. Patil
 6.1.2 State Objects
• State objects are the smallest data units that represent a shared
financial agreement between parties in Corda.
• They function as digital documents, capturing all essential details of the
agreement.
• Created or consumed during transaction execution, they refer to both
contract code (mandatory) and optional legal prose.
• Contract code defines the state transition rules and ensures business
logic is followed.
• Each state object has a data structure representing its current status,
and can be either live (current) or historic (consumed).
• Example: A state object might represent a payment of 1,000 GBP from
Party A to Party B, which can later be updated by a new transaction.
• Think of state objects as state machines—updated and replaced by
transactions in a secure, traceable manner.
Module 5 BT, Prof Sapna. B. Patil
6.1.2 State Objects

Figure : An example state object

Module 5 BT, Prof Sapna. B. Patil
 6.1.3 Transaction
• Transactions in Corda are responsible for changing state
objects, enabling transitions from one state to another.
• Corda uses a UTXO-based (Unspent Transaction Output) model,
similar to Bitcoin, allowing multiple inputs and outputs in a
transaction.
• All transactions are digitally signed, ensuring authenticity and
integrity.
• Unlike traditional blockchains, Corda has no mining and does not
use blocks for transaction ordering.
• Instead, notary services ensure temporal ordering and
uniqueness of transactions across the network.
• Corda allows custom transaction types to be defined in JVM
bytecode, offering flexibility and extensibility in business logic.
Module 5 BT, Prof Sapna. B. Patil
 6.1.4 Consensus
• Consensus in Corda – Ensuring Valid and Unique
Transactions
• Corda uses notary services to achieve consensus,
focusing on transaction uniqueness rather than block
confirmation.
• Transactions are signed by notaries if their inputs are
confirmed as unique.
• Multiple notary services (single or clustered) may
operate using consensus algorithms like PBFT or Raft.
• The core purpose is to verify whether a transaction is a
valid and unique ledger update, avoiding double-
spends.

Module 5 BT, Prof Sapna. B. Patil

 6.1.4 Consensus (Conti..)
• Types of Consensus in Corda – Validity and Uniqueness
i. Validity Consensus:
– Ensures contract rules are met for all input/output states.
– The transaction possesses all necessary signatures.
– Involves "walking the chain" – verifying the entire transaction
history leading up to the current inputs.
ii. Uniqueness Consensus:
– Ensures no double-spending – that a state hasn’t been
consumed in another transaction.
– Performed only by notary services.
– Works alongside validity checks to confirm that a transaction is
both valid and unique.

Module 5 BT, Prof Sapna. B. Patil

 6.1.5 Flows
• Flows in Corda are a novel idea that allows the
development of decentralized workflows.
• All communication on the Corda network is handled
by these flows.
• These are transaction building protocols that can be
used to define any financial flow of any complexity
using code.
• Flows run as an asynchronous state machine, and
they interact with other nodes and users. During
their execution, they can be suspended or resumed
as required.

Module 5 BT, Prof Sapna. B. Patil

 6.2 CorDapps
• CorDapps – Distributed Applications on the Corda Network
• A CorDapp (Corda Distributed Application) is a decentralized app that
runs on the Corda network, enabling nodes to agree on ledger
updates.
• Built using state objects, transactions, protocols, contract code, APIs,
and user interfaces.
• Uses flows to define routines that nodes follow during execution.
• Smart contracts in CorDapps are written in Kotlin or Java, executed on
a deterministically modified JVM.
• Core components of a CorDapp smart contract:
– Executable Code: Defines validation rules for state changes.
– State Objects: Represent contract state; consumed or created by
transactions.
– Commands: Carry metadata for transaction verification.
• CorDapps provide a secure, flexible framework for distributed
agreement and ledger interaction.
Module 5 BT, Prof Sapna. B. Patil
 6.3 Components
• The Corda network has multiple components. These
components are described as follows.
1. Nodes
2. The permissioning service
3. Network map service
4. Notary service
5. Oracle service
6. Transactions
7. Vaults
8. Other tools: Application firewall,Network simulator,
Node explorer, Load tester
9. Transaction flow

Module 5 BT, Prof Sapna. B. Patil

 6.3.1 Nodes
• Corda Nodes – Identity and Communication
• A Corda node is a JVM runtime with a unique network
identity.
• Nodes are run by different organizations and verified
through a KYC process.
• Each node hosts CorDapps and provides Corda services.
• Nodes operate in a trustless, authenticated P2P network.
• Communication between nodes uses AMQP, an ISO/IEC
standard.
• Transport Layer Security (TLS) ensures data privacy and
integrity.
• Messages are encoded in compact binary format for
efficiency.
• Apache Artemis (Active MQ) handles reliable message
delivery.
Module 5 BT, Prof Sapna. B. Patil
Figure 20.7: Simplified Corda node architecture
Module 5 BT, Prof Sapna. B. Patil
 6.3.1 Nodes (Conti..)
Key Elements of Corda Nodes – Architecture and
Components
• The Persistence layer stores states and transactions in
a local SQL database.
• The Network Interface allows secure P2P
communication during flows.
• The RPC Interface enables interaction with the node
owner for managing flows and data.
• The Service Hub Provides services (like vault storage)
to flows running in the node.
• The CorDapp interface allows deployment and
execution of distributed apps.
• Nodes can function as a regular node, notary, oracle,
or network map service.

Module 5 BT, Prof Sapna. B. Patil

 6.3.2 The Permissioning service
• Doorman is the permissioning service in Corda
that manages network access and security.
• It provisions TLS certificates to ensure secure
communication between nodes.
• Every participant must have a signed identity
issued by a root certificate authority (CA).
• Identities must be unique and follow the X.500
naming convention (e.g., CN, O, L, C).
• Doorman verifies identities through a KYC
process before allowing node participation.
• It ensures only trusted and verified nodes can
join and operate on the network.

Module 5 BT, Prof Sapna. B. Patil

 6.3.3 Network Map Service
• The Network Map Service maintains a registry of all active
nodes in the Corda network.
• It provides a document listing node IP addresses, identity
certificates, and offered services.
• When a node starts up, it registers itself with the network
map service to announce its presence.
• The service enables identity resolution, mapping
participant identities to physical node locations.
• Before establishing a connection, nodes verify the
presence of peers using the network map.
• This ensures secure and validated communication among
verified participants.

Module 5 BT, Prof Sapna. B. Patil

•
6.3.4 Notary Service
Corda uses notary services instead of mining to ensure transaction ordering and
finality.
• Multiple notaries can exist in a network, each identified by composite public
keys.
• Notaries sign transactions to confirm validity and prevent double-spending.
• They can use consensus algorithms like BFT (Byzantine Fault Tolerance) or Raft,
based on application needs.
• To handle high load, notaries can be load-balanced across nodes.
• Proximity of notary nodes to participants is encouraged to minimize latency.
• Corda allows transactions to include a time window – a range during which the
transaction must be notarized.
• Time windows help validate if a transaction occurred after or before a specific
event or time.
• Notaries serve as timestamping authorities, ensuring accurate event timing.
• Useful for scenarios like:
– Verifying a transaction occurred after contract expiry.
– Ensuring a transaction was committed within a deadline.
• For this to function properly, notaries require an accurate and synchronized time
Module 5 BT, Prof Sapna. B. Patil
source.
 6.3.5 Oracle service
• Oracles are trusted parties that provide external data (e.g.,
interest rates, stock prices) to smart contracts.
• They digitally sign data, ensuring authenticity and integrity
before it's used in a transaction.
• Oracles do not execute or validate the entire transaction —
they only attest to the correctness of specific data points.
• This helps maintain confidentiality; oracles see only the
data they’re supposed to validate.
• Used in scenarios such as:
– Derivatives trading (e.g., “pay if stock hits ₹X”)
– Insurance claims (e.g., based on weather or time events)
• They enhance automation and trust in contracts that rely
on real-world data.

Module 5 BT, Prof Sapna. B. Patil

 6.3.6 Transactions
• Corda uses a semi-private model where transactions are shared only
among involved parties, unlike global broadcast in traditional
blockchains.
• Transactions are digitally signed by all required participants to ensure
authenticity and consent.
• Each transaction consumes existing states (inputs) and creates new
states (outputs), maintaining a clear history.
Key Components of a Transaction:
i. Input References: Pointers to existing states that the transaction will
consume.
ii. Output States: New states generated by the transaction after
validation.
iii. Attachments: References to ZIP files that may contain contract code
or documents. Only hashes are included in the transaction.
iv. Commands: Define the intended action of the transaction and list
public keys of signers required
Module 5 BT,to
Profauthorize
Sapna. B. Patil it.
 6.3.6 Transactions (Conti..)
v. Signatures: Digital signatures from all required
signers, matching the keys listed in commands.
vi. Transaction Type:
– Normal: A standard transaction that modifies states.
– Notary Changing: A special transaction to reassign the
notary of a state.
vii. Timestamp: A time window that defines when the
transaction is valid. Verified by the notary.
viii. Summary: A short, descriptive text explaining what
the transaction does.

Module 5 BT, Prof Sapna. B. Patil

 6.3.7 Vaults
• Vaults are components that run on individual nodes,
functioning similarly to wallets in Bitcoin.
• Since transactions are not broadcast globally, each
vault only stores data relevant to its own node.
• Data in vaults is stored in a standard relational
database, allowing for SQL-based queries.
• Vaults can store both:
– On-ledger data: States recorded and verified on the Corda
ledger.
– Off-ledger data: Additional information that isn't part of
the shared ledger but relevant locally.
• Vaults also track the lifecycle of states, maintaining a
record of spent and unspent states.
Module 5 BT, Prof Sapna. B. Patil
 6.3.8 Other Tools
i. Application Firewall
• Acts like a reverse proxy, enabling Corda to operate securely behind corporate
firewalls.
• It is typically deployed in the DMZ (Demilitarized Zone) of enterprise networks.
• Its purpose is to minimize the code running in the DMZ, reducing the attack surface.
• Supports secure communication over AMQP with TLS 1.2 for interaction with
external peer nodes.
• Comprises two main components:
– Bridge – manages outbound connections.
– Float – handles inbound connections.
• A single firewall instance can be used for multiple Corda nodes.
ii. Network Simulator
• A visualization tool that displays network traffic between nodes.
• Uses the network map service to help simulate and observe interactions.
iii. Node Explorer
• Another visualization tool for inspecting transaction information on a node.
iv. Load Tester
• Used to stress test nodes under extreme or simulated heavy-load scenarios.
Module 5 BT, Prof Sapna. B. Patil
 6.3.9 Transaction flow
• In this section, we'll explore how, when a request is sent to a node,
Corda accepts the request and responds. The flow process can be
summarized as follows:
i. An HTTP request via API or RPC call is made directly to flows in
Corda. This is a request to start a transaction.
ii. Start a flow. Flows contain the business logic.
iii. Perform initial steps such as transaction building and verification.
iv. Obtain counterparty signatures.
v. Sign the transaction and check signatures.
vi. Obtain notarization/finality.
vii. Record the transaction and store it in persistent storage and
Vaults.
viii. Respond via an HTTP response through API

Module 5 BT, Prof Sapna. B. Patil

 6.3.9 Transaction flow
This process can be visualized using the following diagram:

Figure : Node high-level flow

Module 5 BT, Prof Sapna. B. Patil
Additional Key Concepts
• A CorDapp is the application logic that defines the transaction
rules and behavior.
• The Vault uses JDBC to store transaction states.
• Nodes communicate using AMQP over TLS 1.2, ensuring
secure messaging.
• SSH is used by administrators to interact with nodes.
• Doorman service provides identity certificates over HTTPS.
• Nodes discover others using the Network Map Service via
HTTPS.
• CRLs (Certificate Revocation Lists) are checked using
HTTP/HTTPS to ensure certificate validity.

Module 5 BT, Prof Sapna. B. Patil

 7. Corda development environment
• To begin developing on the Corda platform, install the following tools:
Required Software
1. JDK 8 (8u131)
– Download: Oracle JDK 8
2. IntelliJ IDEA (Community Edition)
– Free to use.
– Download: IntelliJ IDEA
3. H2 Database (Platform-independent ZIP)
– Used for lightweight data storage.
– Download: H2 Database
4. Git
– Required for version control and cloning repositories.
– Download: Git
5. Kotlin Language Plugin
– Kotlin is the primary programming language for Corda.
– Available through IntelliJ or at: Kotlin
6. Gradle
– Used for building and managing dependencies.
– Download: Gradle
Starting Smart Contract Development
• Use the Hello World CorDapp template to start:
– Hello World Template
• Refer to Corda’s official documentation for contract development:
– Corda Documentation

Module 5 BT, Prof Sapna. B. Patil

 7. Corda development environment
Cloning the Corda Codebase
• Open your terminal and run:
• bash
• CopyEdit
• git clone [Link]
• This command clones the Corda repository to your local machine in a folder
named corda.
Developing with IntelliJ IDEA
• After cloning, open the project in IntelliJ IDEA.
• Explore multiple sample projects found in:
• bash
• CopyEdit
• /corda/samples
– Examples include:
• Bank of Corda
• Interest Rate Swaps Demo
• Traders' Demo
• These demos are helpful to understand the development flow of CorDapps.

Module 5 BT, Prof Sapna. B. Patil