Published On - May 25, 2022
Enterprise Blockchain, Moving Left
Blockchain as a technology is still evolving, and so does our understanding of where this technology fits into the architectural landscape. I like to call this evolution ‘moving to the left’. To understand this, we need a bit of context. It’s not uncommon for developers and architects to initially approach a blockchain network as some sort of distributed database. But it’s not a great database, as it was never designed to function as one.
If you were to pick between running a distributed Cassandra cluster, or maybe HBase, the features and characteristics between those two and say, running a bunch of Geth nodes in your private network, are vastly different. Geth would not be able to match the throughput, nor would the storage requirements scale nicely, as there’s no history pruning.
Blockchain for businesses
But when private consortiums, where you typically find ‘enterprise blockchain,’ go ahead with a private blockchain network, they do so because they want to store private data and share it with a few select partners. Storing private data on a blockchain isn’t ideal, however, as all the nodes store an identical copy of the data. Should a new node be allowed in, it too would receive a copy of this data.
Because of this, various mechanisms have been invented to allow us to store private data in more confined groups, and then anchor the existence of this data against a less private blockchain network. I think this is the only way to keep private data private, i.e. don’t store it on a blockchain.
Because of this, various mechanisms have been invented to allow us to store private data in more confined groups, and then anchor the existence of this data against a less private blockchain network. I think this is the only way to keep private data private, i.e. don’t store it on a blockchain.
How to anchor data and store private data
We have full flexibility in how we anchor data, depending on the use case. It might be that we need to timestamp some data, and could for example choose to publish a type of data fingerprint in a transaction. This would prove the existence of the data at that point in time. The Baseline Protocol comes to mind, but so too do layer 2 solutions more broadly. Or it could be that we want to prove that some data was signed by a particular actor, and hence publish the public key of that entity on the blockchain. For this, decentralised identity and verifiable credentials are applicable standards to explore. Both of these examples anchor data to a blockchain, but in different directions and for different purposes.
With that in mind, we can have a conversation around the steps we need to take to ensure that the anchoring process doesn’t leak any significant detail about our private activities, but I’ll save that for another blog post.
Step 1 in our shift from right to left, is to become comfortable with the idea that we can share private data in more confined groups, and anchor the proof of this activity on a blockchain in such a way that no private data is revealed. The argued benefit of the anchoring process is that it gives solid cryptographic proof that some activity took place, and that this can help simplify complex integration processes between various systems and actors.
Before we continue the journey from right to left, I think it would be good to draw the overall picture. The picture below is originally inspired by an article by Jesus Ruiz in early 2020, titled Public-Permissioned blockchains as Common-Pool Resources. In the article, Ruiz argues in favour of public permissioned chains.
With that in mind, we can have a conversation around the steps we need to take to ensure that the anchoring process doesn’t leak any significant detail about our private activities, but I’ll save that for another blog post.
Step 1 in our shift from right to left, is to become comfortable with the idea that we can share private data in more confined groups, and anchor the proof of this activity on a blockchain in such a way that no private data is revealed. The argued benefit of the anchoring process is that it gives solid cryptographic proof that some activity took place, and that this can help simplify complex integration processes between various systems and actors.
Before we continue the journey from right to left, I think it would be good to draw the overall picture. The picture below is originally inspired by an article by Jesus Ruiz in early 2020, titled Public-Permissioned blockchains as Common-Pool Resources. In the article, Ruiz argues in favour of public permissioned chains.
I agree with much of what’s being suggested, especially around the view of blockchains as some kind of public good. If we go back to the data anchoring use case as described earlier, we can start to ask ourselves, why do I need a private blockchain to store these anchors on? If, for example, the anchoring point is a public key, I’d like this public key of mine to be as widely distributed as possible. Blockchains give me that option, as they prove the integrity of the public key, and can make it widely available. But also, if it’s an anchor point for timestamping reasons, and I’m comfortable with the data in that anchor point being public, why store it on a private blockchain?
Running a private permissioned blockchain network doesn’t come cheap. In addition to the usual production costs of running software, you also need to involve a number of external partners in the governance process. For a network to be useful and secure, you want to have many members part of the network, which adds further strain and cost to that process.
Running a private permissioned blockchain network doesn’t come cheap. In addition to the usual production costs of running software, you also need to involve a number of external partners in the governance process. For a network to be useful and secure, you want to have many members part of the network, which adds further strain and cost to that process.
The case for public permissioned networks
Ruiz argues that by moving to a ‘public permissioned’ network, we can get the best of both worlds. As the network is public, any member of the public could, in principle, connect to the network and execute transactions on it. This might come with a fee, either per transaction or through some other membership cost. And because it’s permissioned, the set of members running nodes can be tightly controlled. That should then make the governance process manageable, as you could for example, limit the number of partners to a sufficiently small but still large enough size to balance the decentralised security against governance overhead. Another argument from Ruiz is that this setup also allows for more scalable consensus algorithms, which would enable the throughput required for more mainstream usage.
While these points still stand to some extent, I also think in the fast-moving world of blockchains, and more broadly Web3, the patina on Ruiz’s article is starting to show.
If we’re moving towards a place where we understand that only data we are comfortable with being public should be stored on a blockchain, and that private data is anchored to this through a process we’re on board with, then why do we need public permissioned chains?
If we’re left with only scalability as an argument for why the permissioned part of ‘public permissioned’ is useful, we’ll quickly run into difficulties defending the overhead costs of running or being members of such a network. This is because scalability is a challenge that’s being solved through the use of sharding and layer 2s. And the energy inefficiency of proof-of-work, the primary consensus mechanism of Bitcoin and, at the time of writing, Ethereum, is soon to also be history. This is because Ethereum, the number 1 smart contract blockchain, moves to proof-of-stake later this year. We are then left with only Bitcoin as a major proof-of-work blockchain but because of the limitations of Bitcoin, we wouldn’t use it for the above anchoring use cases anyway.
Also, this doesn’t take into account the risks of using a public permissioned chain. You, as a member of the network, or a simple user of it, can easily be blocked from participating in any permissioned chain. This reintroduces the third-party risks of Web2 in a Web3 context. After technology upgrades allow us to use public permissionless chains without high costs and with plenty of throughput, public permissioned networks become a last-ditch attempt for operators of these networks to hold on to old outdated business models.
In summary, this is why we’re moving left in the enterprise blockchain world:
While these points still stand to some extent, I also think in the fast-moving world of blockchains, and more broadly Web3, the patina on Ruiz’s article is starting to show.
If we’re moving towards a place where we understand that only data we are comfortable with being public should be stored on a blockchain, and that private data is anchored to this through a process we’re on board with, then why do we need public permissioned chains?
If we’re left with only scalability as an argument for why the permissioned part of ‘public permissioned’ is useful, we’ll quickly run into difficulties defending the overhead costs of running or being members of such a network. This is because scalability is a challenge that’s being solved through the use of sharding and layer 2s. And the energy inefficiency of proof-of-work, the primary consensus mechanism of Bitcoin and, at the time of writing, Ethereum, is soon to also be history. This is because Ethereum, the number 1 smart contract blockchain, moves to proof-of-stake later this year. We are then left with only Bitcoin as a major proof-of-work blockchain but because of the limitations of Bitcoin, we wouldn’t use it for the above anchoring use cases anyway.
Also, this doesn’t take into account the risks of using a public permissioned chain. You, as a member of the network, or a simple user of it, can easily be blocked from participating in any permissioned chain. This reintroduces the third-party risks of Web2 in a Web3 context. After technology upgrades allow us to use public permissionless chains without high costs and with plenty of throughput, public permissioned networks become a last-ditch attempt for operators of these networks to hold on to old outdated business models.
In summary, this is why we’re moving left in the enterprise blockchain world:
-
We get comfortable with the process of anchoring private data to public blockchains
-
Public permissionless chains become energy efficient through proof-of-stake
-
Sharding and layer 2 solutions allow for the necessary throughput at low cost
-
The risk of being excluded from public permissioned chains is too high
-
The governance overhead and complexity of running and participating in your own permissioned network is bad business and provides no added benefit to the use case
Web3 is a shift in thinking, where what’s described above requires time to mature. I hope this article has helped shine some light on the journey we’re still on in our transition from the initial private permissioned approach, to something viewed more as an open and available utility. It of course doesn’t remove some of the requirements that private permissioned blockchains set out to solve for, but through new tools and techniques we can solve these more elegantly.
Have any questions or comments? We’d love to hear from you! If you want to find out more about blockchain, its growth, and newest developments, then check our blog or listen to our enlightening Web3 Innovators podcast.
