Perspectives with Paul Sitoh — Part 2
This is a continuation of Chainstack’s interview with Paul Sitoh. Read part 1 here.
Perspectives is a series of interviews, where we sit down with industry experts and thought leaders within and beyond the blockchain space.
Note: This interview has been edited and condensed for clarity.
Are there any blockchain projects that you find particularly interesting, either in terms of technology or in terms of what they are trying to achieve?
I find Quorum and its adoption of zero-knowledge proofs particularly fascinating. Back in the days, I remember that when we were looking at the use of channels to transact privately between two parties in Hyperledger Fabric, there was a great degree of confusion. Channels could be mistaken for isolated pieces of private communication between two parties, but rather they are more like subnets within a larger network.
Zero-knowledge proofs could have avoided all that confusion; especially when there’s no need to exchange data but only to affirm that the data is held by the other party. In fact, most business processes could well do without any exchange of data or movement of documents and, instead, simply rely on recording events and sharing those.
A case in point is property deeds-Why does one have to wait for physical documents to indicate transaction finality? Why not just indicate the transfer of ownership on a digital ledger contingent once certain boxes have been ticked?
Can enterprise blockchains unlock value through decentralizing some processes? Are enterprise blockchains even realistic, considering that enterprises largely operate in a competitive environment, and enterprise blockchains require a great degree of collaboration?
Let’s go back to the case of supply chains. In my past experience with a global auto manufacturer, I remember the difficulty involved in the exchange of data because of the use of different file formats among a large number of players in the ecosystem. But in a supply chain, by nature, parties should be collaborating to some extent. With that as a starting point, a blockchain can be a good fit where parties that need to transact with each other can arrive at a consensus in a more straightforward manner.
A concern that most businesses have with blockchains is the total transparency involved. How can competitors still be part of a consortium but go about their competitive moves of, say, offering a larger discount to their key customer without letting its competitor know? That’s where enterprise blockchains with their permissioned approach and Hyperledger Fabric’s channels or zero-knowledge proofs can come into play.
“ A lot of education is required to assure companies that using a blockchain won’t lead to disruption to the point of extinction. Instead, it is a powerful tool to reduce friction and lower or, perhaps, eliminate the cost of intermediaries. Such focused messaging can be more impactful than talking about grandiose ideas of industry disruption.”
You touched upon communication privacy and channels. In terms of architectural design, is there any other protocol that appears to have addressed privacy in an elegant manner?
Quorum does a good job with its use of constellation. One disadvantage is that all the keys are stored on a node, and so all hell breaks loose if the node is compromised. Z-cash with its use of zk-SNARKS is also extremely interesting except that it is computationally intensive. Simplistically put, in my ideal world, one would have zk-SNARKS without its downtime, because the use of extensive crypto-material in the wake of quantum computing could spell disaster.
On the topic of deployment, once companies have decided to use a blockchain, where are the hurdles?
A key aspect in several companies is a reservation towards the use of the cloud to deploy nodes. Not every business wants to move to the cloud, nor can everything be moved to the cloud. So the ability to deploy a blockchain node on-premise or in a hybrid manner is becoming increasingly important. Consequently, blockchain solution providers that are able to offer an on-premise or hybrid deployment would have a distinct advantage.
On that note, do companies you come across have the expertise to successfully deploy a blockchain? Because all said and done, there is a fair bit of complexity in deploying nodes and getting a group of participants to work on a blockchain.
Blockchain deployment is complex indeed. And there are various levels where this complexity comes to the fore. In general, bringing together a consortium is a tall order. Managing permissions or governance among consortium members is another difficult topic. Key management is tricky.
So, yes, setting up a bare-bones blockchain node is simple enough. But to get the most out of a blockchain, one has to navigate several technical challenges. Regardless of how easy it is to set up a blockchain, there are challenges that cannot be avoided.
Taking the question of deployment complexity further, it is a known fact that the level of maturity in tools for blockchain software development still has a long way to go. What’s your checklist for the blockchain ecosystem so that companies can start adopting blockchains in a faster or cost-effective manner?
Tools for software developers is definitely a big piece of the need-to-improve landscape. My involvement with the Hyperledger Sawtooth team and interacting with the Hyperledger Fabric protocol highlights how important it is to abstract operational complexity so that developers can focus on creating application logic.
Overall, there is still a dearth of robust tools e.g. testing tools for Solidity, and, in particular, tools for rapid deployment on a cloud or in hybrid environments. The latter is where, I believe, Chainstack’s offering can make the entire deployment process so much easier for individual developers and enterprises alike.
Any final words or advice for our readers and the blockchain development community at large?
My advice is to approach blockchain as you would approach any other problem in software engineering. I don’t believe there is an exclusive form of developer such as a ‘blockchain developer’.
As for learning, it is best to get one’s hands dirty and learn through trial and error instead of being fixated on any certification. To be good at blockchain development, it is important to start seeing from the view of an architect, to step back from the code and see the bigger picture, to determine how a blockchain fits into a business’ current scheme of things, and how it can benefit that business.
