Permissioned Blockchain Networks: A Misunderstood Infrastructure Tool
Thoughts on where permissioned blockchains fit into the infrastructure stack of the future of finance
Thanks for following MondayMunday! We now have well over 100 of you who read this. When I started blogging I didn’t think anyone would be interested so it’s great to see all these readers. If you can value from this please feel free to subscribe and share… Now to the post
Welcome back to MondayMunday, this week I thought I’d tackle a topic that I spent a few years of my hopefully still early career wrestling with. This question is the when, why, how and what behind building permissioned blockchain applications? These blockchains are often misunderstood by many folks from either side of the spectrum of Trad-Fi and DeFi.
In the crypto world, they are often mistaken for centralised databases which have no applicability in changing the future of finance.
In Trad-Fi world, they were often seen as a safe choice to get the benefits of blockchains without any trad-offs.
As always is the case in these predicaments, the answer is a mix between both, with the correct implementations and the use-case around using this technology being the key to unlocking the value.
This post aims to provide a toolkit on how to approach designing permissioned blockchain systems guiding you on:
Their role as a new infrastructure service for distributed business applications?
What problems do they solve and the comparison to public blockchains and databases?
What drives a successful permissioned blockchain use-case?
Business Model and Building considerations?
A glimpse into the future of financial networks and permissioned blockchains role?
Introduction
Blockchains as technology are relatively new in the grand scheme of innovation. However, in this short space of time, we have seen remarkable levels of innovation and a diverging set of views of what constitutes a ‘blockchain’ and the types of implementation. Often debates around this miss the key point around why we should use this technology debate and can diverge too far into the realm of a new social order (whilst this is a use-case for the technology, it often negates the first steps of adoption… real-life implementation)
To get to the key point, infrastructure (such as blockchains) is often first used to solve efficiency problems, increase speed and reduce risks in markets. The nature of a universally reconcilable ledger between parties who don’t trust each other is powerful and should not be understated.
Often the distinction between types is needed but not essential to identifying when to use this technology and a much better way to approach the implementation of this technology would be from a ‘use-case first’ perspective.
With regards to permissioned networks, this is often a new form of infrastructure tooling which has some advantages given the correct implementation and its backward / forward compatibility with legacy and future financial systems i.e. traditional settlement rails and DeFi networks.
What is a permissioned blockchain?
Permissioned blockchains are blockchain networks where infrastructure and access to networks are controlled by a network operator. Subsequently, the usage of a decentralised application on the network is controlled by the network operator. This network operator controls the running of the network and aspects of validating the network, with help from admitted network participants.
Hence, securing the network is centralised by the operator with them running the majority of the infrastructure on behalf of network participants.
Often a common misconception is that this means the network operator controls your data, BUT, this is why you have a blockchain ledger as opposed to a central database. The features of a blockchain of user-owned data and trusted sharing and settlement of information are only possible because the fact the network is in part distributed with users running nodes controlling how and when they share data.
Secondly, they have the advantages that blockchains bring. You can now have true ownership of bearer assets on-chain and complex autonomous rule-based workflows that smart contracts bring to systems.
In summary, permissioned blockchains allow you to provide ways to share and store information similarly to a centralised database. The key is in the detail, if in your use case:
You can’t rely on a centralised party to store information or market dynamics dictate your solution can only arise if there way to share information.
You need native bearer asset representation, traditional databases can’t natively store and transact truly digital assets.
Or you need automated workflows to streamline a financial market process
A permissioned blockchain may be the solution that is needed if you require a specific distributed architecture for your application.
What problems do permissioned blockchains solve?
I have previously touched on how blockchains transform finance in my blog on “The Use-Case for DeFi in Fintech: Are You Building Enablers or Solutions?” if you want a zoomed-out view, but to dive into the problems that we are trying to solve with this technology.
Permissioned blockchain provides a new tool for solving key infrastructural issues in financial markets. These are:
Ownership
Using a blockchain-based system you can have direct ownership of digitally native bearer instruments.
Identity / Privacy / The need for infrastructure ownership
Unlike most* open blockchain networks the closed nature of these systems allows you to control the identity and privacy of network participants. Furthermore, they allow you to control the running of infrastructure for all network participants. This has typically proved a problem for enterprises in the initial adoption of new technology, understanding where infrastructure falls in various compliance regimes within heavily regulated financial institutions is a must-solve problem. Whilst we are seeing this occur in the permissionless world slowly, owning infrastructure allows this to happen today.
Information sharing between parties who don’t trust each other
Often the argument against a permissioned blockchain network is that a centralised database can solve all the problems that a permissioned system does. This is untrue, blockchain technology provides the unique benefit of being able to uniquely share and validate information between two parties in a trustless manner. This also has benefits in terms of efficiency and cost of information sharing.
Programmability
Unlike traditional databases, you can create use smart contracting to automate complex business processes and flows based on autonomous rules that are validated by all parties in the network.
Here, we can see the power of these solutions, they allow you to provide the benefit of blockchains and trustless data-sharing with the control of infrastructure that is needed in a select few use-cases.
*There is a new wave of public-permissioned networks solving problem (a topic for another post)
Comparisons vs databases and permissionless ledgers
Often the two camps argue either side solves the problems of a permissioned blockchain.
The database side…
Whilst you can build a permissioned blockchain that functions akin to a database, this is simply a bad solution design. A needed permissioned blockchain application should incorporate the advantages of native bearer assets secure information sharing and trustless management of information, which a database cannot do.
The public blockchain side…
Whilst permissioned networks are gated in access, they are not simply just databases. As we have previously discussed the ability to store native assets, automate complex workflows and solve the problem of needing trusted intermediaries for business processes.
Here, the permission blockchain acts as a hybrid, a database for trustless information sharing of native bearer instruments with in-build workflow automation. A unique combination for unique use-cases.
So when should I use them? - The business-level considerations
A permissioned blockchain is a hybrid approach for bridging the advantages of databases for enterprise with the workflow, native ownership and ability to allow parties to transact in a trustless manner.
But to gain the benefits, you need to find the right use-cases in order to implement them successfully. Permissioned blockchains have numerous benefits as discussed above, however, they do come with some drawbacks, these are namely:
Need for network adoption
Permissioned blockchains are a way of managing networks of users to allow them to transact in a trustless manner. Given this, a successful permissioned blockchain system needs an existing network onboarded from the start in order to gain value from a system. Additionally, given they are closed networks the generation of network effects and flywheel to solve problems is difficult to creat, hence, this works needs to be done when developing the application.
High costs
The benefits of trustless data sharing are achieved through running expensive infrastructure. Many permissioned blockchain designs start from the premise that the introduction of this tool will reduce costs. The infrastructure only reduces costs if you have arcane use-cases when the need to streamline workflows between parties using the advantages of blockchains is there.
As a rule of thumb, you can ask yourself the following questions to see if your use-case may warrant a permissioned system.
Do you need a blockchain?
Understanding the benefits above will help you understand if your solution warrants a blockchain. Blockchains are an infrastructure tool for solving the need to share information and digitally native assets in a peer-to-peer fashion. Oftentimes, solutions simply don’t have the requirements for these to be important.
Secondly, a permissioned system is only needed when you have this level of control over deployment and keen identity issues and a system implementor, if this isn’t the case, it is likely your solution actually brings more complexity than using another technology.
Do you have a finite set of network participants who can sufficiently capture value?
Permissioned blockchain solutions fail when you don’t know who your network is, can’t capture them and maintain incentives for participants. A minimum viable and finite network is often a good framework to assess how to achieve this for your solution.
A minimum viable network is needed for participants who can gain value from the network to transact. You need these participants all to be incentivised to join your network because of the value captured from joining this system
A finite set participant helps you understand the governance in your ecosystem to maintain networks by knowing the set types of participants in a network you can maintain the network by ensuring incentives are aligned and maintained. Additionally, given the closed nature of permissioned systems, a finite set of participants help you solve the problem of having a viable network, trying to onboard a million participants to a closed network is impractical when the alternative of a global permissionless network that solves the same problem exists.
Do you build a process that removes the need for middlemen or can only be created without a middleman?
Permissioned blockchain can be deployed in the name of innovation, yet, without driving cost or process efficiency, which leads to failed implementations of the technology. The use cases where it makes sense are those where introducing this technology reduces the cost or improves speed of the current processes whilst maintaining the existing incentives of the market or where this technology allows you to add new workflows to the market because previously there was no way to trustlessly govern it.
Building considerations
Given we have run through the use-case considerations, there are also some considerations from the building perspective. Permissioned blockchains are expensive and costly infrastructure to maintain and deploy. They often lack the layers of open-source knowledge and tooling that have been built on public blockchains to simplify and abstract deployment and development problems. This comes in form of two key considerations as an application builder:
Running infrastructure
Unlike permissionless and open networks, networks have to be created, users onboarded to and maintained by network participants. This brings challenges and costs in terms of who pays for this infrastructure and maintaining reliability.Building the whole stack
When building in permissioned systems you can’t simply call a node and rely on blockchain to run services like paying other participants. As the builder you are creating this rulebook, you have to design the workflows participants use and how they interact with nodes and the integrations. Given this, often the development journey comes from process mapping your solution to work out where blockchain workflows are best placed.
From a business model perspective, there are also some useful considerations to take into account due to the need to capture a network of participants who is incentivised to transact on the network to gain value, and drive revenue for the application builder.
Governance and network running
With permissioned blockchain systems, how they are governed is key to adoption and growth. In order to ensure the operation is smooth you need to have a network operator who is willing to take on the costs of maintaining the network and has a sufficiently robust business model to ensure this is a profitable venture.
Participant incentivation
How do you maintain the network incentivisation, in order to ensure your solution gets usage? You need to ensure your business model aligns with the value capture in the current market so there is no incentive to switch and move from the network. You also need to ensure a model where you effectively solve the free rider problem, you need to capture the network whilst ensuring there is no disincentive for joining by giving a competitor an easy access to valuable information and/or cost efficiency.
Pricing
Blockchain costs come from transactions, every update to the ledger incurs a cost to store and verify that information. Furthermore, you have associated infrastrcuture costs that come with maintaining and deploying a network. Given this employing typical SaaS models are unlikely to work given usage levels incur variable costs. Given this, an effective business model will meter variable costs which are linked to business outcomes the technology helps drive as it will allow you to monetise from your variable costs whilst ensuring end users see value in paying for the solution.
This is post is a high-level overview of the considerations needed, as you go further into the minutia of your solution there inevitably complexities that arise. The newness of the technology means we are yet to see well-travelled successful playbooks for profitable deployment of a permissioned blockchain application, compared to a model like SaaS. This brings challenges and a need to deeply consider the problem you are solving and why it can only be done using a permissioned system to ensure success.
A glimpse into the future of finance? Permissioned blockchain as an on-ramp for the enterprise to decentralised markets
Hopefully, the above has given you an indication of the problems you can solve with a permissioned blockchain and when they can be useful. As may be gleaned from the post, the nicheness of the value proposition you are solving is a key issue why permissioned blockchains get a bad rap. To date, much of the experimentation has involved solving problems the technology is not suited for.
So where is their place in financial markets? I see it as a way to solve business problems where the market doesn’t need radically changing. You simply need a new infrastructure tool to improve process or speed in a market that maintains incentives but adds governance through technology.
This provides a unique stepping stone for certain financial markets, once they have this blockchain infrastructure to improve processes and add new trustless governance they can use this as an on-ramp to access another digital native ecosystem.
This is game-changing for decentralised services which offer true business model innovation in markets. Permissioned systems act as one form of a gateway for trad-fi users to access, innovate with and transition over to truly decentralised networks.
Overall, both permissioned and permisionless systems have their place in driving innovation in the financial service ecosystem. Even if the end-state may look closer to a global shared open ledger to transact, enterprises need systems as first steps in the world of distributed application building and digital assets, permissioned blockchain provides that first act if used correctly. Hopefully, this post gives some clarity on what makes those use cases.
If you found this interesting don’t hesitate to reach out! feel free to reach me by replying to this email or DM on Twitter or LinkedIn 🙏
Recommended readings / inspiration for this post
Check out my talk from CordaCon where I discuss how to use design thinking to build permissioned blockchain applications on Corda.
Andy Martin’s Token Economy, one of the most pertinent examples of his work in this article on how ‘Alignment is critical’ in the implementation blockchain technology.
Richard Gendal Brown blog on ‘The future of finance’ his article on ‘Enterprise Blockchains for Cryptocurrency Experts’ is a good start