Throughout the previous year, the idea of “private blockchains” has gained significant traction in the broader dialogue surrounding blockchain technology. Essentially, rather than having a completely open and unregulated network and state mechanism safeguarded by cryptoeconomics (e.g., proof of work, proof of stake), it’s feasible to develop a system where access rights are more stringently managed, allowing only a select group of users to modify or even access the blockchain state, all while retaining various forms of limited assurances of authenticity and decentralization that blockchains offer. These systems have largely attracted the attention of financial institutions and have, in part, sparked backlash from those who perceive such trends as compromising the essence of decentralization or being desperate measures by outdated intermediaries striving to maintain relevance (or simply the wrongdoing of utilizing a blockchain other than Bitcoin). Nevertheless, for those engaged in this endeavor purely to discover how best to benefit humanity, or even to pursue the more modest aim of catering to their clientele, what are the fundamental distinctions between these two approaches?
Firstly, what are the possibilities available? In summary, there are typically three classifications of blockchain-like database applications:
- Public blockchains: a public blockchain is one that everyone globally can access, anyone can transmit transactions to and anticipate seeing them included if they are valid, and anyone can join the consensus procedure – the method for deciding which blocks are added to the chain and what the current state is. As an alternative to centralized or semi-centralized trust, public blockchains are secured through cryptoeconomics – the blend of economic incentives and cryptographic verification using elements such as proof of work or proof of stake, adhering to a general principle that the extent of influence one can exert in the consensus process is proportional to the quantity of economic resources they are capable of presenting. These blockchains are typically regarded as “entirely decentralized”.
- Consortium blockchains: a consortium blockchain is one where the consensus process is administered by a pre-established group of nodes; for instance, one might envision a consortium consisting of 15 financial institutions, each managing a node, out of which 10 must validate every block for it to be recognized as valid. The privilege to access the blockchain may be public or limited to participants, and there are also blended options such as the primary hashes of the blocks being public alongside an API that enables members of the public to submit a restricted number of queries and receive cryptographic proofs for certain aspects of the blockchain state. Such blockchains may be classified as “partially decentralized”.
- Fully private blockchains: a fully private blockchain is one in which write permissions are centralized within a single organization. Read permissions can be either public or limited to a certain degree. Likely applications involve database management, auditing, etc., within a single enterprise, and thus public visibility may often be unnecessary, although there are situations in which public auditability is sought.
In general, so far there has been little focus on the differentiation between consortium blockchains and fully private blockchains, even though it is significant: the former acts as a blend between the “low-trust” provided by public blockchains and the “single highly-trusted entity” framework of private blockchains, while the latter can be more accurately described as a conventional centralized system with a level of cryptographic auditability attached. Nevertheless, to some extent, there is a valid reason for the emphasis on consortium over private: the inherent value of blockchains within a completely private context, aside from the replicated state machine functionality, is cryptographic authentication, and there is no justification to assume that the optimal structure for such authentication provision must consist of a series of hash-linked data packets containing Merkle tree roots; generalized zero-knowledge proof technology offers a much broader spectrum of intriguing possibilities regarding the kinds of cryptographic assurances that applications can deliver to their users. Overall, I would even contend that generalized zero-knowledge proofs are, in the corporate financial arena, significantly underappreciated compared to private blockchains.
For the time being, I will thus concentrate on the more straightforward “private versus public” blockchain discourse. Generally speaking, the notion that there is “one definitive way” to implement blockchain is fundamentally misguided, and both categories possess their respective advantages and drawbacks.
First, regarding private blockchains. When contrasted with public blockchains, they offer several benefits:
- The consortium or organization overseeing a private blockchain can readily, if desired, modify the regulations of a blockchain, reverse transactions, adjust balances, etc. In certain scenarios, e.g., national land registries, this capability is essential; it would be unacceptable for a system to exist where Dread Pirate Roberts holds legal ownership rights over a clearly visible piece of land, thus an attempt to establish a government-immune land registry would practically regress into one that is not acknowledged by the government itself. Of course, one could contend that this could be managed on a public blockchain by providing the government with a backdoor key to a contract; the counter-argument to this is that such a method is essentially a Rube Goldbergian alternative to the more efficient approach of having a private blockchain, although there is, in turn, a partial counter-argument to that which I will elaborate on later.
- The validators are identifiable, so the potential risk of a 51% attack arising from miner collusion in China does not apply.
- Transactions incur lower costs, as they only require verification from a limited number of nodes that can be trusted to possess very high processing capabilities, and do not need validation from thousands of laptops. This is an immensely crucial consideration at present, as public blockchains frequently have transaction fees exceeding $0.01 per transaction, but it is essential to highlight that this may evolve in the long run with scalable blockchain technology that promises to reduce public-blockchain costs to within one or two orders of magnitude of an optimally efficient private blockchain system.
- Nodes can be relied upon to be very well-connected, and errors can be quickly rectified through manual intervention, enabling the use of consensus algorithms that provide finality after significantly shorter block intervals. Enhancements in public blockchain technology, such as Ethereum 1.0’s uncle concept and later proof of stake, can render public blockchains…much nearer to the “immediate affirmation” benchmark (for instance, guaranteeing total conclusiveness after 15 seconds, rather than 99.9999% conclusiveness after two hours like Bitcoin), yet even so, private blockchains will perpetually exhibit greater speed and the latency variation will never vanish since, regrettably, the speed of light does not double every two years as per Moore’s law.
- When read authorizations are limited, private blockchains can offer a superior level of, well, confidentiality.
Considering all of this, it might appear that private blockchains are undoubtedly a more favorable option for organizations. Nevertheless, even within an organizational framework, public blockchains still hold significant value, which largely resides in the philosophical principles that proponents of public blockchains have championed consistently, the foremost of which include freedom, impartiality, and transparency. The benefits of public blockchains typically fall into two primary categories:
- Public blockchains offer a mechanism to safeguard application users from developers, asserting that there are specific actions that developers of an application lack the authority to undertake. From a simplistic perspective, it may be challenging to grasp why an application developer would want to willingly relinquish power and restrict their own capabilities. However, a more sophisticated economic examination provides two reasons why, in Thomas Schelling’s terms, vulnerability can be a strength. Firstly, if you intentionally make it more difficult or impossible for yourself to engage in certain actions, others are more likely to trust you and interact with you, believing that those actions are less probable to affect them. Secondly, if you are being coerced or pressured by another entity, then asserting “I possess no power to execute this even if I desired to” serves as an important negotiating tool, as it deters that entity from attempting to force you to comply. A significant type of pressure or coercion that application developers may face is from governmental bodies, making “censorship resistance” closely linked to this argument.
- Public blockchains are transparent, thus are likely to be utilized by numerous entities and accrue certain network effects. To illustrate, take the scenario of domain name escrow. Presently, if A wishes to sell a domain to B, there exists the conventional counterparty risk issue that must be addressed: if A initiates the transfer first, B might not send the payment, and if B initiates the transfer first, A might not deliver the domain. To resolve this dilemma, we have centralized escrow intermediaries, which typically charge fees ranging from three to six percent. However, if we establish a domain name system on a blockchain and a currency on the same blockchain, we can reduce expenses to nearly zero by means of a smart contract: A can transfer the domain to a program that instantly sends it to the first individual who transfers money to the program, and the program is deemed trustworthy because it operates on a public blockchain. It’s crucial to note that for this to function effectively, two entirely distinct asset classes from separate industries must coexist on the same database – a scenario that is not easily achievable with private ledgers. Another comparable example in this realm includes land registries and title insurance; however, it’s essential to mention that an alternative route to interoperability involves having a private chain that the public chain can validate, btcrelay-style, and facilitate transactions across chains.
In certain instances, these benefits may not be necessary, but in others, they are exceedingly influential – influential enough to justify threefold longer confirmation periods and incurring 0.0003 for a transaction). It’s noteworthy that by developing privately governed smart contracts on public blockchains or cross-chain exchange layers between public and private blockchains, one can attain numerous hybrid combinations of these features. The ideal solution for a specific industry is significantly contingent on the precise nature of that industry. In certain situations, public is evidently more advantageous; in others, a level of private oversight is simply indispensable. As commonly observed in the real world, it is context-dependent.