Thoughts on Public and Private Blockchain Technology for Enterprise

In advance of moderating tonight’s Counterpoints discussion hosted by the WSBA, I’m sharing some foundational thoughts on Public and Private Blockchain Technology for Enterprise.

Introduction

Enterprise is increasingly looking to blockchain technology to solve problems and drive efficiency.  Success or failure can be driven by manifold business, technological and relationship issues. One of the most fundamental decisions these organizations face is whether to base their solution on a private blockchain or a public one, and the choice has implications for all of those types of considerations.  Given that Gartner estimates blockchain technology will contribute over $3 trillion in business value in ten years, a broad understanding in the community of key issues will enable faster, more successful adoption and the benefits that can be achieved from it.

Private and public blockchains used by enterprise all restrict access to their networks, but are distinguished by the source of the software that enables participation in the related network.   Private blockchain projects are those like Corda and Symbiont (a client of my firm), and public projects include those like Monax and Besu.  Because enterprise deployments require a level of security and counterparty identification that isn’t relevant to non-permissioned blockchain uses like the Bitcoin network, even public blockchains will involve permissioning of users.  So for purposes of this piece, we will assume that public blockchain technology being deployed uses an application layer that requires permissioned users who are identifiable to other users for purposes of reading, writing and access roles.

What’s on and off the chain?

One of the main distinguishing characteristics of private and public blockchains for enterprise is what can be deployed on the blockchain itself (also known as “Layer 1”).  For privacy and efficiency reasons, public enterprise solutions often keep a portion, and in some cases, almost all [transaction] data out of the blockchain. Sensitive data like party identities and transaction amounts on a public ledger is or can become (as the name implies) viewable by anyone having access to the ledger, which is unrestricted.  Some companies are working to overcome this limitation by aiming to create solutions that work with the Layer 1 protocol that would obscure activity on-chain (MedRec, Kaleido and Zagg Protocol, which are in various stages of development). A further evolution of this is a system like ZeroCash, which uses “zero-knowledge” proof that allow users to prove to each other that a statement is true without revealing any interaction between the two, and mixing services, like ShuffleCoin, that blend user input to obscure its source.  

For this and other reasons, public-network enterprise solutions will generally include only a portion of the data set relating to a particular transaction on Layer 1, relegating the remainder of the data to an off-chain application/database layer that is either centralized (similar to a SaaS solution) or on a secondary chain, like a “child chain” (both are also known as a “Layer 2”).  While this application layer, being permissioned, will restrict the information there to select participants, the underlying platform that provides timestamping and immutability features, as noted above, is not. For a significant number of critical enterprise activities (like trading), the mere presence of that activity needs to be strictly private, for both regulatory and business reasons.  The efforts of the companies trying to solve for these concerns (like those listed above) amount to features added on to a system of protocols and are still in various stages of development. For the most sensitive use cases, a solution that doesn’t include integrated privacy for all transaction data may not suffice.  

Another reason for this bifurcation of data is that public blockchains currently and for the foreseeable future require a tremendous amount of computing power.  Moving part of the process can provide efficiencies for a public-network solution. This efficiency issue is likely to diminish as transaction processing speeds increase.  Companies like HyperLedger and Falcon have reported faster transaction speeds, which if realized, would greatly influence the utility of public blockchains for enterprise.  

Governance/Consensus Protocol

Because both public and private enterprise blockchain solutions rely on permissioning of the users, at the Layer 2 level, they share the same attributes relating to the decision-making amongst participants, like the timing for protocol updates and whether to add new participants into their permissioned ecosystem.  These considerations are important, but not particularly distinguishing between the two types of networks.

However, the underlying network technology does present an added consideration for enterprise solutions running on a public network.  Because the underlying network is not under the control of the participants, the benefits of using a public blockchain to underpin an enterprise, like decentralization, should be balanced against the impact of network events such as reorgs and forks.  While some reorg activity is part of the Satoshi protocol and doesn’t necessarily affect the overall finality of network transactions, in other cases, they can result in more uncertainty and disruption to the network’s history, as in the case of a 51% attack.  While Layer 2 solutions like side or child chains remove almost all activity from the Layer 1 “mainnet,” the second layer must maintain a nexus with the first that relies on periodic interaction to prove the validity of the second layer.

Consensus on a private network is determined by a known, accountable set of validators that propose and validate the order of transactions.  When a quorum (the number agreed by the group to be the minimum number required) signs a block to declare it valid, that block is added to the chain without the option for a reorg or fork.  Consensus is maintained even where a node is disabled by means of Byzantine Fault Tolerance, which provides stability.  

Cost

Although comparison data isn’t available, it seems logical that a private system would be more costly to develop: it’s more difficult and time-consuming to develop an entire ecosystem.  Smart contracts built in a more widely-known language may be easier to develop because the engineer pool is broadened by wider access to the language, especially  where such languages have been open-sourced (like Solidity and DAML), which spreads the cost of development.  

But we also need to consider the transaction costs associated with public blockchains - they change.  So the ability of an enterprise organization to budget for a particular use case will come with some level of variability that may be difficult to build in to the budgeting process.

Without a cryptocurrency element, enterprise’s incentive to participate in a private blockchain solution shifts to the efficiencies and other business reasons to justify the cost of implementing and maintaining a private system.  For many larger institutional players, this will be a cost worth taking on, but until private systems mature and become more widely available, proprietary technology used in closed consortia may not be a cost-effective solution for a broader range of small to medium-sized enterprise customers.

Regulatory oversight

A private blockchain is a closed ecosystem that, if designed to allow regulatory oversight, will allow relevant agencies to access records necessary to the audit function of their roles.  A public blockchain is able allow this in the second layer, but the dictates of a public chain’s protocol will override regulatory review if incompatible.

For example, a public blockchain will necessarily contain other parties’ activity that cannot be known by a regulator.  In certain cases, like entities subject to the ’40 Act, this is a relevant consideration, and makes the use of a public blockchain for these regulated entities a challenge, if not impossible.  In addition, the compensation paid to miners on a public blockchain in exchange for the services they provide in settling transactions as of now must still be viewed as compensatory to a transaction. Others have written extensively on the question of whether this constitutes a broker fee or other regulated compensation; for our purposes, it remains a possible complication for some deployments of public blockchain technology.