Blockchain for business has been buzzed about and touted as a combination that will unlock efficiencies for enterprises spanning all industries. Whenever there is a situation where two or more parties transact in goods or information, there are purported benefits to placing some of it on a shared ledger. 

At Hyperledger Jump Start, a corporate training session on enterprise blockchain, eight hours of condensed education exposed not only how companies are using blockchain technology, but what actually goes on under the hood.

Held by ChainDigit, an enterprise blockchain consulting firm, the one day crash course focused specifically on Hyperledger Fabric, one of the most popular frameworks businesses are using to build permissioned blockchains. The course began with theory, but ended in practice with ‘students’ firing up their laptops and becoming nodes on a private blockchain.

Adding blockchain to the enterprise focuses on data privacy and gaining efficiency

Even though the class consisted exclusively of technology experts, it seems there is always something to be learned by hearing others explain blockchains in their own words.

“At the heart of a blockchain network is a distributed ledger that records all the transactions that take place on the network,” said Jimjees Abraham, one of the professors. “In addition to being decentralized and collaborative, the information recorded to a blockchain is append-only, using cryptographic techniques that guarantee that once a transaction has been added to the ledger it cannot be modified.”

With this in mind, the classmates, an impressive group of CTOs and engineers from industries spanning telecom, supply chain, and consumer platforms, expressed how they’re planning to use blockchains within their organizations. The use cases centered around data privacy, preventing a single point of failure, improving efficiencies, and removing the requirement to trust third parties.

Ensuring no unknown actors get on your Hyperledger Fabric blockchain

Each participant has a copy of the ledger to any Hyperledger Fabric network they belong to. Since Hyperledger Fabric is dealing with enterprise ledgers that require some privacy, the participants, or members to a network, enroll through a Membership Service Provider (MSP). MSPs are simply the entities who are given ‘passes’ to join or create a Fabric blockchain; there are no unknown participants allowed.

Hyperledger Fabric has a ledger subsystem consisting of two components: the world state and the transaction log. The world state component describes the state of the ledger at a given point in time; it’s the database of the ledger. The transaction log component records all transactions which have resulted in the current value of the world state; it’s the update history for the world state.

The ledger is thus a combination of the world state database and the transaction log history. The world state is simply a key-value store database. The transaction log does not need to be interfaced with as it simply records the before and after values of the ledger database being used by the network participants.

Chaincode: where transactions execute

Chaincode is responsible for processing transaction requests and determining if transactions are valid by executing some pre-written business logic. Chaincode is to Hyperledger Fabric what smart contracts are to a public blockchain like Ethereum. As of now, chaincode can be written in Go with support for other languages such as Java planned for future releases.

Transaction validation rules typically begin with authorization checks to ensure that the requesting node has permission to make such a request (i.e. is the owner of an asset/account). Then, it will read the starting state (history), and execute the business logic to process the transaction and verify that the results are valid (i.e. payment is valid if asset/account balance is sufficient). Finally, the chaincode will compute the associated state changes in a simulation.

If any of the above are found to be invalid, the chaincode will reject the transaction. If accepted, it will trigger events that can lead to output actions, triggers, or notifications to system peers or external applications.

Chaincode is invoked by an application/client that is external to the blockchain when that application needs to interact with the ledger. Typically, chaincode only interacts with the world state, not the transaction log.

Reaching consensus: deciding how to decide

Consensus is the process of generating an agreement on the order and correctness of a set of transactions within a block. Thus, a consideration participants must decide on is how to decide on things in the future, or how to reach consensus.

The set of rules that decides this, referred to as policy decisions, can be as flexible as needed, and part of Hyperledger Fabric’s allure is the ability to plug and play different consensus rules for different use cases and as a network scales.

Consensus in Hyperledger Fabric is split into 3 phases: Endorsement, Ordering, and Validation.

Endorsing

Endorsers are specific peers who have the chaincode attached to them. They receive the transaction request from an external client, run the chaincode, and provide an appropriate output of TRUE or FALSE with their signature. This is where a policy rule comes in to reach consensus. For example, a network of seven organizations may require any four organizations endorsers to agree that a transaction is valid. Or they may require that four organizations endorse it, with one of them being organization ‘6’, etc.

Ordering

Ordering is the next step, which is again done by specific nodes. Ordering nodes check that endorsers’ signatures are correct, and don’t care about the data being endorsed. They ensure the sequence of transactions is correct, and act as orchestrators. This ordering service then broadcasts the information to peers in the network. They can communicate to all peers or just tell specific ‘anchors’.

Validating

After endorsers and orderers, validation is the final step, which is the appending of the proposed block to the end of the chain. There are no peers explicitly tasked as validators, as all peers are responsible for updating their ledger and disseminating this in a P2P manner through gossip communication protocol. Like this, peers communicate with each other in a similar way as social networks disseminate information.

This consensus mechanism is driven by Apache Kafka, a software platform for handling real-time data feeds. This results in the network being crash fault tolerant, meaning it can reach consensus with nodes failing. It’s not, however,i Byzantine fault tolerant, which prevents the system from reaching agreement in the case of malicious or faulty nodes. This level of security is acceptable for permissioned blockchains, since you know the members and need to worry less about random malicious actors.

How to create privacy on an open blockchain through Hyperledger channels

In any given permissioned blockchain, there will likely be cases where only some peers should be privy to the transactions, but not others. Imagine a large manufacturer setting up a blockchain for all their buyers, for instance, who wants to have the privacy that allows them to price-discriminate or generally keep some info between them and a single peer.

For this, Hyperledger Fabric has one of its greatest benefits: channels. A channel is like a private blockchain within an existing blockchain which allows for data isolation and confidentiality. A channel-specific ledger is shared across the peers in the channel, and transacting parties must be properly authenticated to a channel in order to interact with it. One channel has one ledger, so parties to this channel can keep track of transactions with specific counterparties.

Channels are powerful for data segregation and should be considered on a case by case basis. Scaling could be hard for thousands of channels from a human/overhead point of view, as it requires admins configuring them. However, there is no official technical challenge to this process. Thus, while it is a powerful feature for stable networks, it’s less feasible for networks that require adding and removing multiple channels on a regular basis.

Tying it all together

Permissioned blockchains come in all different flavours;hat works well for one industry use case may not be ideal for another. The training exposed that before simply transferring your company’s business process onto a blockchain, there must first be thoughtful analysis of the design phase. The appropriate questions may include, who needs to speak with whom? What level of privacy do they need? How will we reach consensus? How flexible should this network be? Will it grow?

After answering these questions and many more, building out the network architecture on Hyperledger Fabric may seem like the easy part.

 

Image credit: Hyperledger Fabric logo

 

Buy Bitcoin, Ethereum, XRP, and other cryptocurrencies on Coinsquare.

Buy Digital Currencies on Coinsquare

Share your comments below