Blockchain Types are Poorly Explained and Understood:

While conducting research for upcoming blog posts, I noticed that many resources (including conference material and online articles written by experts) use ambiguous and inaccurate language to explain the different types of blockchain. In particular, there is significant confusion regarding public and private blockchains and how they are related to permissioned and permissionless blockchains.

This blog post is intended to amend public understanding. As such, it does not rehash online articles. Rather, it is a product of ULedger’s own analysis and interpretation of the blockchain space.

Public, Private, Permissioned, and Permissionless Blockchains:

Public, private, permissioned, and permissionless are blockchain classifications based on the amount of access a blockchain gives to its underlying data. However, “access” is not sufficiently explained by the vast majority of resources. In reality, access to a blockchain comes in two flavors: access to transaction content and access to transaction processing. Public and private refer to transaction content, whereas permissioned and permissionless refer to transaction processing.

Public vs Private:

A public blockchain is a blockchain whose transactions are publicly available and independently verifiable to some extent. In other words, a public blockchain doesn’t set any restrictions on transaction content; anyone can read transactions and check whether those transactions are mathematically legitimate. By contrast, private blockchains only make transaction content available to read and verify to a list of pre-approved entities.

Consequently, the trade-offs between public and private blockchains revolve around trust and transparency.

By allowing anyone to read and verify transactions, public blockchains demonstrate that they are trustworthy and tamper-proof. This accountability helps provide for pseudonymous, censorship-resistant communication.

Private blockchains are not publicly trustworthy because they only allow pre-approved entities to read and verify transactions. However, enterprises often deal with proprietary information and may want to keep that information private. This makes private blockchains a better fit for internal activities such as database management or auditing.

Permissioned vs Permissionless:

A permissioned blockchain sets restrictions on transactions processing in one or two ways. A permissioned blockchain may need to approve users before they perform transactions, or approve nodes to carry out the underlying consensus mechanism. In a permissionless blockchain, anybody can perform transactions so long as they have a monetary token (a unit of cryptocurrency such as Bitcoin or Ethereum) or fulfill some other criteria that doesn’t include somebody approving them, and / or the nodes performing consensus do not need to be specifically certified to do so.

Permission-related trade offs concern performance as well as trust and security. Permissionless blockchains employ distributed networks to limit censorship and takedowns. While this distribution protects users through pseudonymity and network effects, it also protects malicious actors. To safeguard integrity, every single node in a permissionless blockchain must process every transaction (using expensive consensus methods such as Bitcoin’s Proof of Work) and maintain a copy of the entire blockchain state. This architecture is secure and trustworthy but leads to low transaction throughput and unsustainable storage and energy costs.

By contrast, permissioned blockchains are invitation-only, meaning they don’t have to worry about malicious actors writing or processing bad transactions. Therefore, permissioned blockchains can safely get away with a handful of centralized nodes and less expensive consensus mechanisms, which makes transactions cheaper, faster, and more easily-verified than those on public blockchains. However, members cannot submit transactions pseudonymously. Additionally, this centralized architecture creates a single point of failure. Governments, competing corporations, and hackers could easily shut down a permissioned blockchain. Permissioned blockchains are also vulnerable to internet failure, server failure, and programming bugs.

Design Theory:

With these distinctions in mind, blockchains could belong to one of four theoretical classifications: public-permissionless, public-permissioned, private-permissionless, and private-permissioned. Each classification would come with its own set of advantages and disadvantages.


+ Good Scaling

~ Private→Public Ecosystem

– Centralized

+ Independently Verifiable

– Not Yet Implemented


+ Good Scaling

~ Completely Isolated Ecosystem

– Centralized

– Not Independently Verifiable

+ Implemented by HyperLedger, etc.


– Poor Scaling

~ Completely Public Ecosystem

+ Distributed

+ Independently verifiable

+ Implemented by Bitcoin, Ethereum, etc.


– Poor Scaling

~ Public→Private Ecosystem

+ Distributed

– Not independently verifiable

– Not Yet Implemented

Blockchains Today:

Today, most blockchains are either public-permissionless or private-permissioned. Cryptocurrencies such as Bitcoin and Ethereum support public-permissionless blockchains. Public-permissionless blockchains allow anyone to read, submit, process, and verify any transaction in a trustless, censorship-resistant environment. However, they require massive amounts of storage and energy. By contrast, platforms such as HyperLedger are built on private-permissioned blockchains, which boast a completely insulated and more performant ecosystem at the cost of trust and security guarantees.

Blockchains Tomorrow:

In theory, you can also have public-permissioned blockchains, which would allow anyone to read and verify transactions but only verified parties to submit and process transactions. Because the validators and transaction authors would be trustworthy, public-permissioned blockchains would not have to rely on expensive consensus mechanisms such as Proof of Work, making them highly scalable.

There are many use cases where you could apply public-permissioned blockchains. For example, in Norway, everyone’s salary is public record. Today, that information resides in a public database. However, Norway could power this system with a public-permissioned blockchain, allowing people to update their own entries. Other use cases for public-permissioned blockchains might include real estate registries, a public domain name system, or a global certificate system–any kind of system that allows verified users to maintain a data store for public use.

We also have yet to see a private-permissionless blockchain. Private-permissionless blockchains would allow anybody to submit and process transactions but would limit the reading and independent verification of those transactions to a group of beneficiaries. Since anyone could submit and process transactions (including malicious actors), private-permissionless blockchains would need to employ expensive consensus mechanisms such as Proof of Work to ensure integrity, leading to poor scalability and massive storage and energy requirements. Nonetheless, the records in a private-permissionless blockchain would remain private, internally verifiable, and tamper proof. Thus, private-permissionless blockchains would offer the ability to ingest, secure, and privatize external data.

Private-permissionless blockchains could be used to ingest and centralize government records, compile same-topic research results from different teams, build information retrieval models, conduct poll work, and offer dead drop services to journalists and whistleblowers. Private-permissionless blockchains could also be used as to power oracles and tree data structures for private blockchains.


Private-permissioned blockchains work well for enterprise applications because they are more performant and secluded than public-permissionless blockchains. However, applications built on different private-permissioned blockchains cannot communicate with each other in an independently-verifiable manner. This is an unacceptable limitation in today’s API economy where applications are expected to communicate with each other using open standards.

ULedger completely solves this problem by offering the first true hybrid blockchain for the enterprise. Unlike all other modern blockchains solutions—which impose limitations on data management by design—ULedger doesn’t force users to compromise. Instead of asking users to choose between public / private and permissioned / permissionless, ULedger spans the continuum and can be anything to anybody.

ULedger does not user a traditional consensus mechanism or try to show you a single ledger or database. Instead, ULedger concerns itself with the independent verifiability of data through multiple chains and cross-merkelization. This means that you can carve up the advantages from different types of blockchains however you would like with none of the downsides. ULedger can offer the privacy and scalability of a private-permissioned chain and the trustworthiness of a public-permissionless chain in one solution.

Other solutions such as Orbs, Ripple, and XinFin attempt to reproduce these capabilities by cobbling together pieces of existing public-permissionless and private-permissioned blockchains. ULedger is different because we designed and built these capabilities into our platform from the ground-up.

Contact Us or Request a Trial today!