Hyperledger

Hyperledger is basically an umbrella project that features open-source blockchains, as well as blockchain-related tools. The project was initiated in 2015 by the Linux Foundation to support the development of blockchain-based distributed ledger applications. It does not declare a specific blockchain standard and focuses on the adoption of a collaborative approach for blockchain technology development through the participation of the community.

Hyperledger Fabric is the most notable blockchain project in the Hyperledger ecosystem. It features a ledger just like other blockchain technologies and also utilizes smart contracts. Hyperledger Fabric also allows all participants to manage their transactions like other blockchain applications. It differs from other blockchain systems because it is permissioned and private. Members of the Hyperledger Fabric network have to use Membership Service Provider, or MSP, to enrol in the network.

Hyperledger Fabric features a ledger subsystem that has two distinct elements, such as the transaction log and the world state. The world state element in Hyperledger Fabric provides a description of the state of a ledger at a specific time and serves as the ledger’s database. The transaction log documents all the transactions responsible for the existing value of the world state. The transaction log actually represents the updated history of the world state.

The chain of a ledger basically refers to the transaction log organized in the form of different transaction blocks linked to each other with a hash. The ordering service sends different transaction blocks to peers. The peers verify the validity or invalidity of transaction blocks. Peers use concurrency violations alongside endorsement policies to check the validity of the transaction blocks. Subsequently, peers add the block in the hash chain over the peer file system.

Smart contracts in Hyperledger Fabric are scripted in chaincode and could be invoked only by applications outside of the blockchain. Chaincode generally interacts with the database aspect of the ledger, i.e., the world state in most of the cases where an application has to engage in an interaction with the ledger. Chaincode does not interact with the transaction log. Chaincode implementation supports different programming languages like Java, Go, and Node.js.

Channel is defined as a private blockchain overlay that is quite helpful for fostering data isolation. It is important to ensure confidential transactions. A channel-specific ledger has to be shared throughout among different channel peers. In addition, all the parties involved in the transaction should have the necessary authentication to the concerned channel for interacting with it. The definition of channels is generally presented in the form of the configuration block.

The configuration block is the one that includes the configuration data that defines all members and policies concerning a system chain or ordering service or a channel. Any kind of modifications to configuration for a channel or overall network could result in the addition of a new configuration block to the relevant chain. The configuration block would generally include the contents of the genesis block as well as the delta.

Concurrency Control Version Check refers to the method of maintaining the ledger state in synchronization through peers in the concerned channel. Peers carry out the execution of parallel transactions and check for any modifications in the ledger state, viewed at the time of execution of the transaction. Concurrency Control Version Check violation is evident when the data read for a specific transaction has been altered in between the execution and commit time.

Assets in the case of Hyperledger could include tangible as well as intangible variants. Tangible assets refer to real estate and hardware, while intangible assets refer to contracts and intellectual property. Hyperledger Fabric enables the ability for modification of assets through chaincode transactions. Assets in Hyperledger Fabric are found as an assortment of key-value pairs. In addition, it also involves the recording of state changes as transactions on the channel ledger.

The list of actors in a blockchain network would include client applications, peers, administrators, and others. Every actor or active element working in or out of the network with the ability to consume services features the encapsulation of their digital identity in an X.509 digital certificate. The digital identities are quite significant as they are important for determining the actual permissions for resources and information access allotted to network actors.

Anchor peer is an important requirement for communications among organizations. The primary function of an anchor peer involves helping peers in different organizations know about each other. Communication among organizations depends profoundly on gossip, and one anchor peer definition is a requirement in the channel configuration. Every organization should offer its unique set of anchor peers. This can help organizations in achieving better availability and redundancy for all their communications.

Access Control List, or ACL, helps in relating the access to particular peer resources like event services or system chaincode APIs to a specific policy. The policy, in this case, would define the number and types of roles or organizations required. The ACL is an integral aspect of a channel’s configuration and could be found persistent in the configuration blocks in a channel. It is generally formatted as key-value pairs.

Consortium in Hyperledger Fabric refers to the assortment of non-orderer organizations present in a blockchain network. Such organizations are responsible for creating and joining channels, as well as have ownership over peers. A particular blockchain network could have different consortia. However, the majority of blockchain networks feature only one consortium. All the organizations added to a channel should be involved in a consortium at the time of creating the concerned channel.

Endorsement is an important process in Hyperledger Fabric and involves particular peer nodes carrying out the execution of a chaincode transaction. The peer nodes also offer a proposal response for concerned client applications in the endorsement process. The related proposal response features the write set and reads set results, events, and chaincode execution response message. It also includes a signature that can work as a proof for executing chaincode of peers.

Chaincode applications include specifically relevant endorsement policies. Endorsement policies provide the definition of peer nodes in a channel that is responsible for executing the transactions. It’s related to a particular chaincode application. The endorsement policies also feature the desired combination of endorsements of responses. The type of application and desired resilience levels determine the design of endorsement policies. The endorsement policy is important for verifying the validity of transactions.

An end-user in the case of Hyperledger could be any individual interacting with the blockchain by leveraging a specific set of published APIs. Generally, an admin user allows permissions to the components of the Member. The client user needs appropriate authentication from the admin user for driving chaincode applications throughout different channels. The application itself could also serve as the end-user in cases where you find self-executing transactions.

An ordering service basically refers to a centralized or decentralized service that helps you order the transactions in a block. Users could select various implementations related to the ‘ordering’ function. For example, the ‘solo’ implementation could help in simplicity and testing. On the other hand, Kafka’s implementation of the ordering function offers better crash fault tolerance. sBFT or PBFT implementations could enable better byzantine fault tolerance with flexible protocol design.

Hyperledger Fabric implements the gossip protocol for optimization of blockchain network scalability, performance, and security through division of workload among transaction ordering nodes and transaction execution peers. Peers can depend on gossip for broadcasting ledger and channel data with sufficient scope for scalability. Gossip protocol also helps in managing peer discovery alongside channel membership and synchronization of ledger state throughout every peer on the channel other than distributing ledger data.

The endorser in Hyperledger Fabric points out to one of the network entities responsible for the formation of the ordering service. An assortment of ordering service nodes or OSNs can help in ordering transactions into blocks on the grounds of selected ordering implementation of the network. Users should note that they would need only one OSN in the case of ‘solo’ implementations. Transactions are broadcasted first to orderers before channels.

Follower nodes are one of the crucial aspects that you would encounter in a leader-based consensus protocol. Leader-based consensus protocols such as the example of Raft can clearly show the functionality of follower nodes. The follower node could support the replication of log entries created by the leader. Interestingly, followers could start a leader election in cases where the leader doesn’t send ‘heartbeat’ messages for a set period of time.

Multi-channel protocol enables the existence of multiple channels featuring designated ledger for each channel. The multi-channel capability could offer support for multilateral contracts. The multi-channel feature can enable restricted participants on the channel for submission, endorsement, ordering, and commitment of transactions on the concerned channel. According to the multi-channel capability, one particular peer has the capability for maintaining multiple ledgers without any compromises in confidentiality and privacy.

Invoke is a common command used in Hyperledger Fabric for calling chaincode functions. Client applications could invoke chaincode through the transmission of a transaction proposal for a peer. The peer is responsible for the execution of the chaincode alongside returning an endorsed proposal response to the concerned client application. The client application would have to collect sufficient proposal responses for compliance with an endorsement policy before submission of the transaction results.

Membership Service Provider, or the MSP, points out a conceptual component in the system that offers credentials for clients, as well as peers, to enable them to participate in a Hyperledger Fabric network. The clients can use the credentials to authenticate their transactions. Peers can use the credentials for authentication of endorsements or outcomes of transaction processing. MSP also enables smooth deployments of alternative implementations without core modifications.

Policies are critical elements for defining the tasks and rules in a Hyperledger Fabric network. They are expressions that are made up of characteristics that are found in digital identities. Policies can help in restricting the access to resources available throughout a blockchain network. It is easy to define policies before creating a channel and bootstrapping a specific ordering service. Users can specify policies during the instantiation of chaincode on the channel.

Private data refers to confidential data which is stored in the private database relevant for every authorized peer. The confidential data remains logically different from the data on the channel ledger. Either one or multiple organizations in a channel could access the data through a private data collection definition. Ineligible organizations will feature a hash for the private data in the channel ledger with the evidence for transaction data with better privacy.

A query in Hyperledger Fabric refers to the chaincode invocation that helps in reading the current state of the ledger without writing on the ledger. A chaincode function could query-specific keys in the ledger and query for key sets in the ledger. Queries cannot modify the ledger state, and related client applications cannot submit the read-only transactions generally for commit, ordering, and validation. Specific client applications could present the read-only transaction.

Raft is actually a unique crash fault-tolerant ordering service implementation in Hyperledger Fabric. It follows the specific etcd library related to Raft protocol. Raft employs a ‘leader and follower’ model with the election of a leader node on every channel. The decisions of the leader node are replicated throughout the follower network. Raft’s ordering services present better ease of setup and management in comparison to the ordering services based on Kafka.

System chain is an integral aspect of the Hyperledger ecosystem, and it features the configuration block providing network definition at the system layer. A system chain exists in the ordering services. Just like a channel, a system chain features a starting configuration with information like the configuration details, MSP information, and policies. Any modifications in the overall network would result in the addition of a completely novel configuration block on the system chain.

The responsibility of cryptographic operations carried out by the nodes in Hyperledger Fabric could be allocated to a Hardware Security Module or HSM. The HSM is responsible for safeguarding the private keys of users alongside ensuring the efficient management of cryptographic operations. It helps peers in the endorsement of transactions as well as orderer nodes for signing blocks without compromising private keys. The PKCS11 standard is ideal for HSM communication.

Bootstrap basically points out the initial setup for a network. The bootstrap of the peer network involves the distribution of cryptographic resources, policies, and chaincodes among participants. The bootstrapping for ordering network should be executed before the peer network’s bootstrapping. The peer network depends on the existence and functionality of ordering services. Interestingly, bootstrapping is a mandatory activity, and every network needs bootstrapping only once in its complete lifetime.