Implementing permissioned blockchain solutions is both equally fascinating and really challenging. Every day, there are new articles in mainstream media outlets claiming how blockchain technologies are going to transform many industries but the reality is not that glamorous. While blockchains bring tremendous value to established enterprise business processes, most permissioned blockchain implementations are not getting passed the pilot phase. After the initial excitement, most teams realize that implementing permissioned blockchain applications at scale require tremendous levels of technological skills and quite a bit of infrastructure building in order to integrate the new Web3 technologies into existing enterprise stacks.
Over the last year, our teams at Invector Labs have been exposed to highly sophisticated permissioned blockchain scenarios each one with its own set of infrastructure challenges. While sharing our experiences with technologists that have seen several software revolutions, many of them draw parallels to the implementation of web applications in the early days of Netscape or database systems at the beginning of the Oracle or IBM DB2 days. In those instances, the use cases for real world applications of those technologies evolved way faster than the corresponding infrastructure. That dynamic contrasts with recent transformational technology movement such as cloud or mobile computing in which the infrastructure was very solid since the beginning.
What are the real challenges of permissioned blockchain solutions? From core infrastructure areas such as identity, data storage, integration or messaging to the processes for deploying and managing smart contracts; permissioned blockchain apps require developers to setup the right building blocks in place in order to be effective. At Invector Labs, we have been fortunate to experiment to many new blockchain protocols or tools that we regularly used to address the challenges of permissioned blockchain implementations. Unfortunately, that portfolio of tools and techniques looks completely different depending on the underlying blockchain stacks.
The road towards any permissioned blockchain application starts with two fundamental decisions:
The answer to the first question will determine the core development stack for your blockchain applications. At the moment, stacks like Hyperledger Fabric or variations of Ethereum such as Quorum or Parity are the dominant choices for permissioned blockchain solutions with platforms like R3 Corda or Hyperledger Sawtooth also seeing some level of traction. At least on paper, up and coming stacks like Dfinity or Hashgraph seem like a great fit for permissioned blockchain solutions but they haven’t been proven in practice yet.
The answer to the second question will determine the core infrastructure for your permissioned blockchain applications. Provisioning and maintaining on-premise blockchain networks is far from being an easy endeavor and the most permissioned blockchain stacks don’t integrate well with platforms like Docker or Kubernetes. Blockchain as a Service(BaaS) platforms like Azure BaaS, Kaleido or the recent AWS offering can really streamline the provisioning and management of blockchain networks and allow developers to focus on building dApps instead of infrastructure.
The following graph illustrates the decision-making process for the two aforementioned questions.
The Real Challenges of Permissioned Blockchain Applications
Selecting a blockchain platform and the corresponding runtime is just the beginning of the journey. Any permissioned blockchain solution more sophisticated than a glorified database will experience plenty of infrastructure challenges that are not directly addressed by the underlying platform. Let’s explore a few.
Integration
If you are using smart contracts in your permissioned blockchain application, chances are that you will be faced with the challenge of communicating with off-chain systems of APIs. Oracles are the component of blockchain architectures that handles external communications. However, implementing Oracles is a development intensive exercise. There are several technologies we have found helpful in this area:
· Chainlink: Chainlink provides a simple programming model for connecting Bitcoin or Ethereum smart contracts to external inputs. The framework also avoids relying on “centralized oracles” as a single point of failure.
· Rhombus: A recent entrant in the Oracle race, Rhombus provides a very elegant model for connecting Ethereum smart contracts to external data systems. Rhombus supports different Oracle architectures based on activation modes such as scheduled or on-demand as well as push or pull data access modes.
· Oraclize: Oraclize focuses on connecting APIs and data systems to different blockchains such as Ethereum, EOS, Hyperledger Fabric or BlockApps. Oraclize’s programming model is not as rich as some of the other alternatives but it compensates that with a strong support for different blockchains.
Data Access
Permissioned blockchains are great for writing information but not so much for reading it. Most real world permissioned blockchain solutions need to interact with the data that is being recorded in the blockchain but that data is both difficult to access and very unintelligible. Here are some protocols that help with that challenge:
· The Graph: The Graph provides a mechanism for exposing data processed by Ethereum smart contracts as a GraphQL endpoints. This allows external applications to query blockchain data using familiar GraphQL syntaxs.
Data Privacy
Many permissioned blockchain scenarios operate in regulated industries with strong data privacy constraints. As a result, protecting and enforcing access control on on-chain data is a key requirement of permissioned blockchain solutions. Below, I’ve listed some of the technologies we have found helpful in this area:
· Quorum: The Quorum blockchain provides native support for private transactions using a form of zero knowledge proofs.
· Aztec: The recently announced Aztec protocol provides a solid implementation of zero-knowledge privacy in Ethereum smart contracts.
Data Storage
Blockchains are not the best vehicle for storing large volumes of data. It is not uncommon for permissioned blockchain solutions to require external data storage. Unfortunately, many of the decentralized storage solutions that work well for public blockchains are not applicable in permissioned blockchain scenarios. Here are some solutions in this area:
· BigchainDB: BigchainDB provides a decentralized database model optimized for the storage and query of transactions. Data in BigchainDB can be queried using the MongoDB query language which enables rich data access interactions.
· IPFS Private Network: IPFS is the most popular storage system for blockchain applications but is often seen as a public blockchain solution. However, IPFS supports the configuration of private networks that constrained the communication to a group of well-known nodes.
· AWS Quantum Ledger: We are very intrigued by the upcoming launch of the AWS Quantum Ledger Database. The idea of immutability without consensus is certainly practical in many permissioned blockchain scenarios and, if nothing ese, the quantum ledger can become a complementary storage model for private decentralized apps.
Identity
One of the main differences of permissioned blockchain solutions is that the identities of the participants in the network are relatively well-known. As a result, many of the complex consensus computation protocols are overkill of simply not needed in those scenarios. Furthermore, most enterprises already have user directories that they would like to leverage in permissioned blockchain solutions. The technologies listed below are helpful to handle identity in permissioned blockchain solutions:
· uPort: uPort has been steadily building a series of protocols and solutions for managing identities in decentralized applications. The current stack is compatible with Ethereum smart contracts and can be leveraged in permissioned blockchain applications
· Azure BaaS: The Azure team has done a remarkable job extending the core protocols of different blockchain to leverage Azure Active Directory identities. A recent example of this work was the implementation of the proof-of-authority consensus protocol in Ethereum applications.
There are plenty of more challenges in permissioned blockchain applications in areas such as messaging, testing, versioning and many others. The protocols and tools listed in this article are some of the most effective solutions we have found in this real world implementations but there are plenty of up and coming technology stacks that might become relevant in the near future.