Council Post: Public Vs. Private Permissioned Ledgers And Blockchain Standards

Public and private ledgers provide different types of solutions since they solve different types of problems. A network implementation can make use of both private and public ledgers with interoperability implemented between them. An example of this is Project Ubin. Many real-world use cases will likely make use of more than one ledger integrated seamlessly. As one starts the evaluation of their own use cases for distributed ledger technology (DLT) adoption, a common issue that will arise early on in the project will be the need to distinguish between public and private permissioned ledgers. This article attempts to cover the key differences between the two. Basic Difference A public blockchain network is a permission-less network, which means anyone can join the network (e.g., Ethereum, Bitcoin). It's important to note that permissioned does not mean private -- some of the public networks like Stellar and Sovrin are public permissioned networks. A private permissioned ledger is permissioned, so only selected participants can join the network. (e.g., Hyperledger Fabric, R3’s Corda). Network Participants For a public blockchain, all participants participate in all the transactions (i.e., data is replicated to all the nodes in the network). There is no preferential treatment and all users (nodes) are treated equally, and data is shared with everyone. Variants of the applications in such a network use ZKPs (zero-knowledge proofs) to cloak the confidential data (e.g., Mediledger). Depending upon the permissioned network (e.g., in Corda), only selected participants get to participate in a given transaction for a private permissioned ledger. Data is shared with selective nodes based on the smart-contract logic on the ledger. Since this is a private permissioned ledger, adherence to compliance audit rules is much easier to implement. Ideal Settings Public blockchains are best-suited for crypto-related use cases and also for some business to consumer (B2C) use cases. Meanwhile, private permissioned ledgers are best-suited for business to business (B2B) use cases, chain of custody-type of use cases, value chain relationships, a shared infrastructure between different enterprises as well as some B2C use cases like cash on ledger type of transactions. Identity Management Public blockchains do not have identity management capability by design. Private permissioned ledgers have identity management tools (or modular architecture) that allow users to plug in their own identity management solutions (e.g., OAuth solution using Google, LinkedIn, etc.). Consensus Mechanism Private permissioned ledgers can use more efficient consensus algorithms. Some of the ledgers also allow the use of more than one consensus algorithm within the same network. As compared to this, public blockchains are secure due to mining (the 51% rule). Performance for Enterprise Applications Performance is much better in a private permissioned ledger due to a closed network with a fewer number of nodes where participants are already known. They are also more suited for enterprise applications because of the capability to add nodes and services on demand, which is a much more practical approach to any business solution. Better Analytics Opportunity Applications designed in a way where some of the transactions use a private permissioned ledger can benefit from combining the ON and OFF ledger data stores for better analytics. They can also take the machine learning/artificial intelligence (ML/AI)-based outputs from their enterprise systems and share that on the ledger to have a collective de-centralized intelligence network, which benefits all the network participants. Regulations Regulations are still evolving, but the likelihood of a public blockchain getting a nod of approval from enterprises is relatively unlikely unless the use case is very limited in terms of scope and practical application. Enterprise use cases are more robust and practical, and as such, the private permissioned ledgers have a better chance of compliance with existing and/or new standards. Tokenization Tokens are a part of every public blockchain. Private permissioned ledgers allow for tokenization via enterprise tokens (but these are not available by default). Blockchain Standards Another common question that comes up frequently is about the different initiatives that are going on around the world for establishing standards for blockchain-based implementations. Here are some of the standard committees that are in place: • ISO/TC 307 is driven via the Australian Standards Body. The primary areas of focus are architecture and taxonomy, security and privacy, smart contracts, governance and interoperability between blockchains. • W3C has a blockchain community group that has been working on a web ledger protocol. A draft has been published to cover the data model and protocol for read/write operations to the ledger. • IEEE has been working on standards for internet of things (IoT) and blockchain, standards for blockchain in clinical trials and has also partnered with NIST and had a Global Summit in September 2018. • IMI (Innovative Medicines Initiative) deals with pharma supply chain and clinical trials. It is a public/private partnership between the EU and the European pharma industry represented by EFPIA. • There are other non-health care standards being created as well from ITU (International Telecommunication Union) and BITA (Blockchain in Transport Alliance). Summary Hopefully, this high-level list of differences above will aid in your initial research if you're company is thinking about implementing a DLT-based solution. The key is to first understand if the use case is really suited for a DLT-based solution. Certain transactions of a given solution can also lend themselves to be candidates for a DLT-based solution. If the use case is suited for DLT, then one needs to decide whether one needs a public or a private permissioned ledger to solve that problem. Then comes the key part of solution design where one has to keep the existing enterprise systems in mind, the technical debt in the current systems, who the participants in the network are, the data privacy/flow/distribution logic and the infrastructure. An understanding of the different options available (Hyperledger vs. Corda) is critical at that time in order to do the right solution design. Another discussion point that will come up with your head of compliance is the standards (or lack thereof) for such an implementation. The above section on blockchain standards hopefully provided some new information on a few standard committees where work is being done in this regard.