[Part-6]Blockchain Simplified Notes NPTEL
Contents.
- Hyperledger.
- Hyperledger vs Ethereum vs Bitcoin.
- Hyperledger Fabric.
- Transaction Flow in Hyperledger Fabric.
- Hyperledger Fabric Details.
Hyperledger.
- Hyperledger is the umbrella open source project that The Linux Foundation has created and hosted since 2015.
- It aims at advancing and promoting cross-industry blockchain technologies to ensure accountability, transparency, and trust among business partners.
- Hyperledger makes business network and transactions more efficient.
- Hyperledger blockchains are generally permissioned blockchains, which means that the parties that join the network are authenticated and authorized to participate on the network.
- Hyperledger’s main goal is to create enterprise-grade, open source, distributed ledger frameworks and code bases to support business use cases.
To learn more about the Hyperledger, click here.
Hyperledger vs Ethereum vs Bitcoin.
Hyperledger Fabric.
Hyperledger Fabric was the first proposal for a codebase, combining previous work done by Digital Asset Holdings, Blockstream’s libconsensus, and IBM’s OpenBlockchain.
Hyperledger Fabric provides a modular architecture, which allows components such as consensus and membership services to be plug-and-play.
Hyperledger Fabric is revolutionary in allowing entities to conduct confidential transactions without passing information through a central authority. This is accomplished through different channels that run within the network, as well as the division of labor that characterizes the different nodes within the network.
Hyperledger Fabric supports permissioned deployments.
Roles within Hyperledger Fabric Network:
- Clients
Clients are applications that act on behalf of a person to propose transactions on the network. - Peers
Peers maintain the state of the network and a copy of the ledger. There are two different types of peers: endorsing and committing peers. However, there is an overlap between endorsing and committing peers, in that endorsing peers are a special kind of committing peers. All peers commit blocks to the distributed ledger.
- Endorsers simulate and endorse transactions
- Committers verify endorsements and validate transaction results, prior to committing transactions to the blockchain. - Ordering Service
The ordering service accepts endorsed transactions, orders them into a block, and delivers the blocks to the committing peers.
(Source: Blockchain for Business — An Introduction to Hyperledger Technologies)
Transaction Flow in Hyperledger Fabric.
In Hyperledger Fabric, consensus is made up of three distinct steps:
- Transaction endorsement
- Ordering
- Validation and commitment
Step I: Propose Transation
Within a Hyperledger Fabric network, transactions start out with client applications sending transaction proposals, or, in other words, proposing a transaction to endorsing peers.
Client applications are commonly referred to as applications or clients, and allow people to communicate with the blockchain network. Application developers can leverage the Hyperledger Fabric network through the application SDK.
Step II: Execute Proposed Transaction
Each endorsing peer simulates the proposed transaction, without updating the ledger. The endorsing peers will capture the set of Read and Written data, called RW Sets. These RW sets capture what was read from the current world state while simulating the transaction, as well as what would have been written to the world state had the transaction been executed. These RW sets are then signed by the endorsing peer, and returned to the client application to be used in future steps of the transaction flow.
Endorsing peers must hold smart contracts in order to simulate the transaction proposals.
Steps III: Proposal Response
The application then submits the endorsed transaction and the RW sets to the ordering service. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.
Step IV: Order & Deliver Transaction
The ordering service takes the endorsed transactions and RW sets, orders this information into a block, and delivers the block to all committing peers.
The ordering service, which is made up of a cluster of orderers, does not process transactions, smart contracts, or maintains the shared ledger. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger.
The Fabric v1.0 architecture has been designed such that the specific implementation of ‘ordering’ (Solo, Kafka, BFT) becomes a pluggable component. The default ordering service for Hyperledger Fabric is Kafka. Therefore, the ordering service is a modular component of Hyperledger Fabric.
Step V: Validate Transaction
The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state. Specifically, that the Read data that existed when the endorsers simulated the transaction is identical to the current world state. When the committing peer validates the transaction, the transaction is written to the ledger, and the world state is updated with the Write data from the RW Set.
If the transaction fails, that is, if the committing peer finds that the RW set does not match the current world state, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the world state will not be updated.
Committing peers are responsible for adding blocks of transactions to the shared ledger and updating the world state. They may hold smart contracts, but it is not a requirement.
Step VI: Notify Transaction
Lastly, the committing peers asynchronously notify the client application of the success or failure of the transaction. Applications will be notified by each committing peer.
Important Points To Remember:
- The state of the network is maintained by peers, and not by the ordering service or the client.
- Machines that are part of the ordering service should not be set up to also endorse or commit transactions, and vice versa.
- Endorsing peers do commit blocks, but committing peers do not endorse transactions.
Hyperledger Fabric Details.
Channels:
- Channels allow organizations to utilize the same network, while maintaining separation between multiple blockchains.
- Channels can either be shared across an entire network of peers or can be permissioned for a specific set of participants.
- Peers can participate in multiple channels.
- Channels partition the network in order to allow transaction visibility for stakeholders only.
In the above diagram, blue, grey and orange are the channels with each channel having its own application, ledger, and peers.
Ordering Service:
Transactions within a timeframe are sorted into a block and are committed in sequential order by the ordering service.
Unlike the Bitcoin blockchain, where ordering occurs through the solving of a cryptographic puzzle, or mining, Hyperledger Fabric allows the organizations running the network to choose the ordering mechanism that best suits that network.
Hyperledger Fabric provides three ordering mechanisms: SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT), the latter of which has not yet been implemented in Fabric v1.0.
- SOLO is the Hyperledger Fabric ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node.
- Kafka is the Hyperledger Fabric ordering mechanism that is recommended for production use. This ordering mechanism utilizes Apache Kafka, an open source stream processing platform that provides a unified, high-throughput, low-latency platform for handling real-time data feeds. In this case, the data consists of endorsed transactions and RW sets. The Kafka mechanism provides a crash fault-tolerant solution to ordering.
- SBFT stands for Simplified Byzantine Fault Tolerance. This ordering mechanism is both crash fault-tolerant and byzantine fault-tolerant, meaning that it can reach agreement even in the presence of malicious or faulty nodes. The Hyperledger Fabric community has not yet implemented this mechanism, but it is on their road map.
Chain code:
- Hyperledger Fabric smart contracts are called chaincode and are written in Go.
- The chaincode serves as the business logic for a Hyperledger Fabric network, in that the chaincode directs how you manipulate assets within the network.
- Applications interact with the blockchain ledger through the chaincode. Therefore, the chaincode needs to be installed on every peer that will endorse a transaction and instantiated on the channel.
State Database:
- The current state data represents the latest values for all assets in the ledger. Since the current state represents all the committed transactions on the channel, it is sometimes referred to as world state.
- Chaincode invocations execute transactions against the current state data. To make these chaincode interactions extremely efficient, the latest key/value pairs for each asset are stored in a state database.
- The state database is simply an indexed view into the chain’s committed transactions. It can therefore be regenerated from the chain at any time.
- The state database will automatically get recovered (or generated, if needed) upon peer startup, before new transactions are accepted.
- The default state database, LevelDB, can be replaced with CouchDB.
- LevelDB is the default key/value state database for Hyperledger Fabric, and simply stores key/value pairs.
- CouchDB is an alternative to LevelDB. Unlike LevelDB, CouchDB stores JSON objects. CouchDB is unique in that it supports keyed, composite, key range, and full data-rich queries.
- Hyperledger Fabric’s LevelDB and CouchDB are very similar in their structure and function.
- Both LevelDB and CouchDB support core chaincode operations, such as getting and setting key assets, and querying based on these keys.
- With both, keys can be queried by range, and composite keys can be modeled to enable equivalence queries against multiple parameters.
- But, as a JSON document store, CouchDB additionally enables rich query against the chaincode data, when chaincode values (e.g. assets) are modeled as JSON data.
Fabric Certificate Authority:
- Certificate Authorities manage enrollment certificates for a permissioned blockchain.
- Fabric-CA is the default certificate authority for Hyperledger Fabric, and handles the registration of user identities.
- The Fabric-CA certificate authority is in charge of issuing and revoking Enrollment Certificates (E-Certs).
- The current implementation of Fabric-CA only issues E-Certs, which supply long term identity certificates.
- E-Certs, which are issued by the Enrollment Certificate Authority (E-CA), assign peers their identity and give them permission to join the network and submit transactions.
About this Series.
This is a series of notes based on the Blockchain Course by NPTEL, which serves as a primer for understanding the blockchain fundamentals. You can find previous articles here:
I am always open to discussions so shoot your thoughts about this topic in the comment section below.
About MoatFund.
We are continuously assisting people get educated about how rapidly this technology is advancing and revolutionising our world. Our mission is to create a decentralised fund managing protocol operated on smart contracts, which is publicly accessible and can control the entire network of fund managing capabilities on blockchain. Here’s Everything You Need to Know About MoatFund, All In One Place.
