Code Talks: Why Consortium Chains Are Better Than You Think

Published in

ppio

10 min readSep 27, 2019

Public chains get a lot of love but we think there’s a lot of magic in consortium chains. Our latest Code Talks explains why.

PPIO Code Talks is an open platform for high-quality presentations and discussions on blockchain technology with the aim of engaging the community and spreading ideas. Previous Code Talks covered The A-to-Z on zkSnarks and Zero-Knowledge Proof, Libra & PPIO: The Genius of Libra and What We’ve Learned and Tendermint: The Inventiveness of their Consensus Mechanism. The following is an adaption of a slideshow presentation given on September 7, covering the role of consortium blockchains for businesses.

In the world of blockchains, there are two major types of chains: public chains and consortium chains. There is one estimation that public chain developers do not believe consortium chains are decentralized enough, while consortium chain developers do not find the throughput of public chains to be sufficient enough for commercial success.

Our talk can be divided into three parts: The environment and challenges of consortium chains; the current commercial application of these chains; and finally, examples of consortium chains in the real world.

The Current Situation and Challenges of Blockchain Development

At present, the financial industry is still the main industry for the application of blockchain technology with over 50% of blockchain companies operating in finance. Blockchains are also widely used in insurance and payment fields, totaling approximately 22% and 13% respectively of all blockchain-based companies.

In terms of capital investment into blockchain companies in the financial sector, investment has shot to $4 billion in2019 from a mere $0.4 billion five years before. This total continues to increase year after year.

Blockchain research and development is also entering a stage of rapid and continued development, with most opportunity occurring in the finance space.

Does The Blockchain Offer Advantages In The Financial Industry?

We all know that blockchains offer a number of advantages, but when it comes to solving financial industry problems, do blockchains really offer an advantage?

We know that blockchains have the advantage of preventing data from being tampered with. However, digital signatures also solves the problem of data tampering. So why should blockchain technology be the solution?
Financial institutions can record data on blockchains. All processes such as adding, deleting and modifying are recorded and traceable. Yet banks use databases which are also traceable. And in terms of security, financial institutions can already improve security by setting a threshold on the database. Furthermore, these databases can be set so that only authorized personnel may add, delete, or modify data.
Do blockchains really improve efficiency? The implementation of blockchain technology is distributed and decentralized. All data must be validated and agreed on at each node, which may be logically less efficient than other solutions.
By linking data and sharing within the entire network, we can improve efficiency and maximize value. However, for financial enterprises, data is incredibly valuable and the sharing of it violates the privacy of customers.

When considering these facts, while blockchains are an ingenious type of technology, it may have less practical value than what already have. In light of these facts, perhaps its best we take a fresh look at the value of blockchain technology.

As previously stated, enterprises in the financial industry, such as financial institutions, regulatory agencies, auditing institutions, etc. have the most demand for blockchain technology, with also offering the greatest possibility of blockchain being accepted commercially. But for other enterprises in the same industry, there are four important issues to consider before blockchain technology can be implemented:

High privacy and security
High availability
High performance
High scalability

Fortunately, a consortium chain appears to be a welcoming alternative.

The Differences Between Consortium and Public Chains

We know that there are many differences between the two at the technical and the application levels, perhaps the biggest difference is the “access threshold”. All the nodes in the public chain can join the network, but the nodes in the consortium chain nodes must be chosen and approved before joining the network.

Practical Example: Hummingbird vs. CPU

Hummingbirds are the smallest bird in the world averaging between 0.79–1.97 inches in size and are found in the Americas. The hummingbird’s brain only has a few hundred neurons but can transmit millions of times per second. Naturally, they can find food, mate, breed, and avoid risks. One may ask why our universal CPU diodes, that operate on the order of tens of billions, are unable to do what hummingbirds can do? Terry Sejnowski, the father of the current neural network and the author of the neuron depth algorithm, explains that in the million-year evolution of hummingbirds, neurons have evolved through long-term polishing and are highly specialized; their hundreds of neurons only focus on a few things, so they are extremely efficient. In theory, general-purpose chips can do anything with programming training. Therefore, we believe that when a consortium chain has a barrier to entry, it will become more focused, will avoid wastage of redundant resources, and can also establish a more efficient and collaborative industry ecosystem. In other words, a consortium chain can be best applied to various enterprises in the financial industry.

It can also be more focused on the needs of enterprise customers. Consensus mechanisms, such as PoW, PoS, PBFT, are very complex when used by a public chain but can be very simple on a consortium chain. A consortium chain requires access to be a node, therefore the 50%+ voting mechanism suddenly becomes very efficient. Typically a consortium chain consists of hundreds of nodes, whereas the number of nodes that participate in forming a consensus is between 20–30%, or even fewer. For a network, not all nodes attach importance to rights. To have rights, nodes have to pay accordingly, and the corresponding calculations will increase the cost of the network. For node users, the core requirement is to get the most value from the network system rather than to acquire unnecessary rights.

In terms of performance, the current TPS of public chains is only several thousand, whereas the TPS of consortium chains for mainstream services can be more than ten thousand. Due to access being restricted and limitations on that number, businesses that use consortium chains can be more focused while also saving money on operational costs compared to if they adopted a public chain.

At the same time, because the multi-centralization of the consortium chain can be encrypted, it is easier to protect users’ privacy.

Based on the above advantages, the consortium chains can better serve enterprise-level business applications and build a collaborative industry ecosystem. At this stage, direction and application are mainly in asset-related areas e.g. asset securitization, insurance, bank lending, commodity trading, equity trading, and so on.

Basic Architecture of Consortium Chains

Pictured below is the data flow of the official architectural solution of the consortium chain HyperLedger Fabric. We know that the blockchain’s ledger is maintained by the peer node and is not maintained by the ordering service cluster. Therefore, only the blockchain information can be found on the peer node, whereas the order service cluster is only responsible for sorting transactions while retaining part of the blockchain information when processing.

On this blockchain, the endorsing peer verifies the signature of the client and then executes the smart contract code to simulate the transaction. After the transaction processing is completed, the transaction information is signed and returned to the client. The client receives the signed transaction information and sends it to the order node for sorting. The order node then packs the transaction information into blocks, then broadcasts it to committing peers and writes it onto the blockchain.

The Step-By-Step Process:

The client initiates a transaction with information such as <clientID, chaincodeID, txPayLoad, timestamp, clientSig> and other information, indicating the following three elements: who sent the message, at what time, and what was sent. According to the endorsement strategy in the chain code, the message is sent to EP1, EP2, and EP3 peer nodes.
The three peer nodes execute the smart contracts and send the results and their respective CA certificate signatures back to the client. The client collects a sufficient number of results before proceeding to the next step.
The client sends the Tx transaction with the endorsement result to the ordering service.
The ordering service hands the packaged block to the committing peer CP1 and the three endorsers EP1, EP2, and EP3. The endorser will check the result and then write it to the world status and the ledger. At the same time, the client will also be notified because it subscribes to the message.

Two Features of this Architecture

Consensus method. When a node issues an instruction, it can specify which nodes can participate in the consensus. It is equivalent to a smart contract and can be customized when deployed.
To separate consensus from read-write hard drives. The performance bottleneck of blockchains comes largely from the bottleneck of hard disk reading and writing. When they are separated, the consensus process is very fast. With such a native architecture, TPS can reach 3000–4000.

Solutions

If the user is willing to add personal data to the blockchain, then the user’s privacy protection must be guaranteed. In that case, the data of a user, once transmitted to the blockchain, must only be able to be accessed and modified by that user. If someone else needs to view or retrieve that user’s data, it must be authorized by said user. The solution for data safety is to encrypt the data, and on a consortium chain, almost all data is encrypted. However, after encryption, there may be compliance issues. Because in the application scenarios of existing consortium chains, it is necessary to ensure compliance and legality of the data and cross-validation.

Technical Practice of a Consortium Chain

There are two key technologies involved, one is authorized encryption and decryption, the other is zero-knowledge proof.

Authorizable Encryption and Decryption

Authorizable encryption and decryption solves the contradiction between a user’s data privacy and the data being shared. In a business scenario, participant A has a set of information that needs to be shared with the consortium nodes, however, A wants participant B, participant C, and participant D to receive only authorized information. The implementation process is to transmit the data to the block after being encrypted offline or online. Participant A can set information-sharing requirements, by means of authorization and encryption, on participants B, C, and D so that they can only receive certain authorized information. Of course, other technologies need to be applied in the implementation process, such as key management, key security, key transmission and so on.

In addition, on the consortium chain, there are usually regulatory nodes, which can view all the data in the chain to protect users’ rights and interests.

Zero-Knowledge Proof

Mainly used for cross-validation of databases. The verification consists of two parts:

The four operations of data in a ciphertext state.
The data can be verified for legal compliance in the state of full encryption.

An example would be the bank’s financing verification process. If Buyer A purchases something from Seller B, an order book is generated as is all data for the receivable accounts. When B wants to ship to A, logistics data will be generated. Once B receives the account, invoice and billing data is automatically generated. Through the whole process, different actions result in different data, e.g. order data provided by the buyer, invoice documents provided by the seller, logistics information provided by the logistics company. At this time, the relevant calculations of different data can be verified on the chain. We can verify if the amount received by accounts less than or equal to the total order, e.g. with verifying logistics data, we can check if the unit price and quantity equal the total amount of logistics bills, by verifying if the invoice data is equal to the user’s order. At this time, if any party involved applies to the bank for financing, the bank can verify the validation results of the above supply chain — without declassifying the data — and carry out the corresponding legal compliance verification, which is the problem solved by zero-knowledge proof in this scenario. When the data from different channels can be checked against each other in the blockchain network, banks can greatly reduce the risk of lending.

Closing Thoughts

Blockchains have long been touted as necessary for the financial industry. While we agree with this, it is the use of consortium chains that offers an exciting prospect with great potential.

Of course, there are some other technical methods involved in the implementation of a consortium chain and much needs to be considered. In terms of privacy protection, this includes homomorphic encryption, multi-party secure computing, and a trusted execution environment, among others. Even with that in mind, consortium chains are well worth looking into by various organizations. In the end, businesses will use the technology based on their needs and belief in the effectiveness of adopting a new system. We look forward to seeing what that will look like.