The differences between public non-permissioned blockchain networks and private permissioned blockchain networks have been well chronicled. In brief, a public permissionless blockchain has no access restrictions to view its data or participate. Usually, such networks offer economic incentives for those who secure them and utilise some type of lottery-based consensus algorithm. Some of the largest, most known public blockchains are Bitcoin and Ethereum.
A private permissioned blockchain network requires permission to read the information on the blockchain and limits the parties who can transact or participate. Some examples include R3’s Corda, as well as various Hyperledger frameworks, including Hyperledger Fabric and Hyperledger Sawtooth among others. There are few cases, if any, where a private permissionless network would make sense, but there are some examples of public permissioned networks appearing to facilitate better scaling of public networks.
Ethereum creator Vitalik Buterin captured the difference between public and private networks nicely when he said, “Essentially, instead of having a fully public and uncontrolled network and state machine secured by cryptoeconomics (eg. proof of work, proof of stake), it is also possible to create a system where access permissions are more tightly controlled, with rights to modify or even read the blockchain state restricted to a few users, while still maintaining many kinds of partial guarantees of authenticity and decentralisation that blockchains provide.”
When MonetaGo was in the architectural planning stages of a blockchain network deployment in India that aimed to reduce instances of fraud around receivables financing, the team had to assess which type of blockchain framework fit that particular use case. Would a public or private blockchain network be more appropriate? Should the network be tokenised? Which specific blockchain technology is the best choice in this instance?
Private permissioned blockchain network
The particular blockchain network use case in India was not public service. Therefore, it was obvious that access would not be given to the public. The information being stored on this network is private to its participants and needed to be protected.
In the enterprise, and specifically in financial services, when there is a network that will potentially be open to multiple parties, there need to be assurances that all parties follow the same rules, regulations, and disclosures. Additionally, enterprises need assurances that specific information and data is not available to anyone not entitled to access it. If the network is open to every single person on Earth, there could be both abuses and misuses of the information. From a business standpoint, there is rarely a case to make transactional information public, and networks tend to serve a specific purpose, which is restricted to entities that meet specific requirements. For example, regarding participating on the Swift network for interbank payments, access is generally restricted to participants which are of a certain size, are licensed, are regulated, and fall under a certain classification because they have procedures in place and have a vested interest in operating a certain way on the network.
That’s not to say that they aren’t use cases where some aspects of a private network couldn’t be made public. For instance, identity services such as certificate authorities (whose purpose is to validate the link between an identity and cryptographic keys) make more sense as a public service than specific to a single blockchain network. Tying keys to known and verified public identities is a common requirement for private networks.
That being said, the exchange of transactional information itself between parties for enterprise will never be done in a public setting unless it is public information, even if it is encrypted or pseudonymous. There are a few cases where transactional information is mandated to be made public, such as property deeds, which is publicly searchable. However, with the use cases we are pursuing, it is almost always involving sensitive or regulated information and participants for which privacy is a fundamental requirement.
Non-tokenised blockchain network
While there are certainly legitimate use cases for tokens, MonetaGo never thought it appropriate to use the token model for the Fraud Mitigation Network in India. First, there was no requirement for a token to be used. Without tokenisation, the distributed ledger architecture itself added value by providing a secure and immutable service, not controlled by any single entity, where data is being stored and shared while guaranteed to maintain its integrity. Simply put, the use cases that MonetaGo is pursuing for financial institutions just do not have a need for tokens.
Any tokenised blockchain provides value transfer as a core service, and relies on distributed trust to verify that the transactions are valid. That means that the network as a whole, or potentially a subset of the network, needs to see the details of that transaction. That is a breach of privacy. There are a few solutions that have been floated, such as zero knowledge proofs and other proxies for homomorphic encryption, but the problem is that these mechanisms are built on unstable mathematical principles, and have a considerable cost in terms of computing power and latency. There is a reasonable probability that attacks will be found on these types of encryption. As a result, storing private data on an adversary’s computer who is not privy to the information is fundamentally the wrong design choice.
Why Hyperledger Fabric
Picking the right tool for the job is critical. Once decided that the Fraud Mitigation Network was to be built on a private permissioned non-tokenised blockchain network, the question became which blockchain framework best fits the needs in this particular use case? Ultimately, we felt Hyperledger Fabric was the right choice for four primary reasons listed below. It should be noted, however, that there are other use cases where Hyperledger Fabric might not be the best choice, and in fact, we are working on other use cases for which it is not currently appropriate.
First, the requirements were for a global broadcast private permissioned network. Second, the platform needed to be low cost. Third, the platform needed to be flexible in its design principles, and tokenless. Last but not least, it needed to be enterprise grade and industry tested. Hyperledger Fabric is open source, and the scale and openness of the large Hyperledger developer community has resulted in a better platform outcome that can be considered enterprise grade and able to withstand use in enterprise financial service use cases.
Longevity of a platform is critical for enterprise. As a startup, we could not afford the risk of investing resources in a platform which has a low probability of survival. As Hyperledger Fabric has the backing of major industry players and several banks, it has a very high probability of good longevity. We feel that proprietary blockchain technologies have a much lower probability of survival. As the technology evolves, a proprietary team may not be able to keep up with the pace of technological advancement that a huge open source community can manage, or they may fall short of their business objectives and become economically unviable. These risks led us to go open source, and ultimately Hyperledger Fabric.
The decision regarding which type of blockchain network to use for your network can be a complicated choice as many factors weigh into the decision. Public or private? Tokenised or not? Proprietary or open source? Does the use case even require the use of a distributed ledger in the first place? The ultimate choice needs to be primarily driven by the use case at hand. Consult with others who are further along in their use of blockchain technologies. Take the time at the outset to vet options thoroughly before getting too deep into the process.