Hyperledger Fabric news
The following topics will be discussed in our discussion of the Hyperledger Fabric news: what it is, its architecture, development and deployment, and the Hyperledger Fabric 2.0 evaluation.
Hyperledger Fabric definition
Hyperledger Fabric is a popular Permissioned Distributed Ledger Technology (DLT) or Enterprise Blockchain for business and organisational use cases. IBM has made significant contributions to this Linux Foundation-hosted open-source project.
Unlike Bitcoin or Ethereum, Hyperledger Fabric requires authorization to join and transact. One important differentiator is its permissioned character.
Why is Hyperledger Fabric Needed?
The Federal Reserve Bank of Boston investigated Hyperledger because of its permissioned nature, requiring membership services and more encrypted transactions, which caused them to drop their Ethereum approach for interbank settlement. Hyperledger Fabric addresses the drawbacks of public blockchains that render them less appropriate for common enterprise needs. Fabric is engineered to satisfy the following enterprise requirements:
Performance and Scalability
In comparison to public chains, it strives for a substantially higher transaction throughput and reduced latency. Fabric may be very scalable and quick if set up correctly. Its performance is roughly 560 Transactions Per Second (TPS).
Privacy and Confidentiality
Sensitive information that must be kept confidential between parties and not available to all network users is frequently included in enterprise transactions. Fabric encourages secrecy and privacy. Although transactions can be tracked by approved auditors, they can be anonymous, private, and confidential for regular users.
Access Governance and Identity
For security, regulatory, and accountability reasons, businesses must be aware of who is using the network. Membership services are used to find and enlist participants in Fabric.
Finality
Probabilistic finality in many public chains does not ensure the instantaneous and irreversible transaction finality that businesses usually want.
Cost
A lot of public blockchains demand native coin for transaction fees. Some commercial blockchains steer clear of this concept, however it isn’t always stated as a necessity.
Architecture of hyperledger fabric
Several essential ideas are incorporated into the architecture of Hyperledger Fabric to satisfy these business needs:
Permissioned Access
The ability to join and engage requires approval. administered by Membership and Identity Service Providers (MSPs).
Modular Architecture
Consensus algorithms, data stores, and other components are designed to be pluggable for flexibility.
The Ledger
Consists of two components:
The Blockchain, an immutable, cryptographically linked list of blocks that contains the historical transaction log, and the World State, a key-value database that stores the most recent state. LevelDB and CouchDB are two configuration possibilities for the global state database.
Identity
An essential component of a network with permissions. Orderers, peers, and administrators are examples of actors whose identities are linked to particular roles and access privileges. makes use of digital signatures, Public Key Infrastructure (PKI), and certificates (such as X.509).
Membership Service Provider (MSP)
A reputable network authority in charge of issuing, managing, and cancelling certificates (e.g., T-Certs for temporary usage, and E-Certs for enrolment). MSPs can integrate with current identity services and be local to peers or channels.
Policies
A collection of guidelines that specify permissions and access control for various organisations and resources. By comparing signatures linked to identities in transactions, policies guarantee access.
Peers
Peers are nodes that take part in the distributed ledger and keep it up to date. A copy of the ledger is in their possession. Organisations may have one or more peers with the ability to host smart contracts and ledgers. The gossip protocol is used by peers to communicate.
There are two types:
Committing peers, which validate and commit transactions, and endorsing peers, which construct read-write sets and simulate transactions.
Channels
A special feature that enables smaller groups of users (organisations) to establish secure areas inside the broader network. Only channel members can see the information that is shared within the channel. Every channel functions as a subnet and has its own ledger. Every member of the network has access to a base channel.
Orderer
A peer who batches transactions into blocks and determines the overall order of transactions. Neither the ledger state nor smart contracts are owned by orderers. With choices like Solo (for testing), Kafka (deprecated in recent versions), and Raft (a Crash Fault-tolerant (CFT) leader-follower protocol, the most recent option), the ordering service is pluggable. There have also been references to other potential pluggable consensus algorithms, such as PBFT, BFT-SMaRt, Honey Badger, and Simplified BFT.
Chaincode
In Fabric, smart contracts are frequently referred to as Chaincode. The rules and transaction logic for updating the ledger are defined by the chaincode. It operates in secure containers and comes packed as a deployable object. An endorsement policy that outlines which organisations need to authorise a transaction is linked to Chaincode. It can be written in a number of popular languages, including Python, Go, Node.js, and Java.
Private Data Collections
This feature enables small groups of peers to use the gossip protocol to directly communicate sensitive information with one another without the ordering service getting involved. The channel ledger only contains a hash of the confidential information. Although it doesn’t keep historical data like the main ledger, this provides a more straightforward setup for private data sharing than channels.
Interoperability
Using middleware and tools like Oracles, smart contracts may interact with external systems, databases, and APIs, enabling impartial off-chain data access. For Fabric applications, the MVC-B (View, Control, Data model, Blockchain) design pattern is common.
Consensus Mechanism
There are three primary stages to the Hyperledger Fabric consensus mechanism:
Transaction Proposal and Endorsement
When a client suggests a transaction, assigned Endorsing Peers are notified. Based on the endorsement policy of the chaincode, the endorsers create an endorsement signature and a read-write set (the data read and the proposed state changes) by simulating the transaction execution.
Ordering
After receiving the endorsed transactions, the Orderer or Orderers organise them into blocks and assign a sequence to each transaction.
Commitment and Validation
All Committing Peers on the appropriate channels receive the ordered blocks. These peers commit the transactions to their copy of the ledger after validating the transactions within the block (e.g., by comparing the validity of the read-write set and the endorsement policy to the current world state). Through this process, the peers come to an agreement.
Hyperledger fabric development and Deployment
Chaincode can be developed using Hyperledger Fabric in a variety of programming languages. Performance can be measured with tools such as the Calliper benchmark tool. Enterprise deployment is made easier by Fabric’s support on popular cloud platforms including AWS, Microsoft Azure, and Oracle Cloud.
Industry Adoption and Use Cases
Among the main enterprise DLT platforms, Hyperledger Fabric has the most market share and is extensively used in the sector. It is employed in many different industries for a wide range of purposes. Among the examples are:
- Supply Chain Management: Businesses like Walmart use Fabric to track products, like food, from the point of origin to the shelves, granting farmers, distributors, and retailers authorised access.
- Financial Services: Platforms from SAP and Oracle are used to support interbank settlement networks.
- Enterprise Asset Management: IBM teamed with Everledger, a diamond tracking solution, to use Hyperledger.
- IoT Integration: IBM’s Watson AI engine securely stores data on the Fabric-based IBM Blockchain engine and communicates with IoT devices.
Also Read About What Are The Two Types Of Forks In Blockchain: Simple Guide
Hyperledger Fabric 2.0
The Hyperledger Fabric 2.0 protocol is claimed to have changed significantly. It had some improvements and new features over Fabric 1.0.
Among Fabric 2.0’s salient characteristics and attributes are:
- The primary distinction between Fabric 1.0 and Fabric 2.0 is the introduction of New Chaincode Lifecycle Management. Chaincode could be installed by an administrator in Fabric 1.0, and administrators of other companies had to give their unqualified consent before they could instantiate (deploy or upgrade) it. This is fixed in Fabric 2.0 by adding checks, which require organisational administrators’ consent before peers can join a chaincode. In 2.0, each organisation administrator installs the chaincode package on their peers after putting it on the disc. Although they are supported, legacy lifecycle patterns are anticipated to become obsolete.
- New Chaincode Application methods: Fabric 2.0 offers new consensus-building and cooperation methods. These patterns facilitate decentralised agreement, wherein several companies can suggest and agree on terms for a transaction, and they also support the addition of automated checks.
- Enhanced Data Privacy: Features including per-organization collections, collection-level endorsement policies, and flexible sharing and verification of private data all contribute to improved data privacy.
- External Chaincode Launcher: This feature eliminates the need for Docker daemon access in order to generate and execute chaincode by enabling the usage of external builders and launchers. Chaincode is no longer limited to Docker containers and may now run in any suitable environment.
- Raft Consensus: To reach consensus, Raft is incorporated as a Crash Fault-tolerant (CFT) ordering service. It uses a leader-follower paradigm and is based on the etcd library.
- Improved Performance: Fabric 2.0 brought about performance enhancements, particularly through CouchDB state database level caching that lowers read latency from costly lookup operations.
Also Read About Types of Oracles in Blockchain, and How Oracles Work?