At Invector Labs, we are fortunate to be working on highly sophisticated permissioned blockchain implementations for some of the top brands in the world. Differently from other technology trends, there are not well-established best practices and techniques for implementing this type of solutions. As a result, we constantly encounter scenarios in permissioned blockchain apps for which there are no prescribed solutions. While some of those challenges are pretty obvious some others challenge the conventional wisdom of traditional software development. Today, I would like to explore some of those non-obvious challenges of permissioned blockchain systems that you are only likely to encounter if you are building this type of solution in the real world. Most of the permissioned blockchain implementations in enterprise environments are constrained to some variation of record-keeping scenarios. Those use cases are fundamentally focused on leveraging the immutability of a blockchain runtime to enable more sophisticated tracking capabilities in a specific domain. While valuable, those simple scenarios fail to take advantage of the full potential of blockchain-based Web3 stacks. The moment your solution transition from basic record-keeping to more sophisticated smart contract development scenarios, all sorts of unforeseen challenges start surfacing for which there are no trivial solutions. The richness and complexity of enterprise environments contributes to the challenges of permissioned blockchain solutions. While permissioned blockchain architectures are not exposed to the scalability and resource-scarcity constraints of public blockchains, they are challenged on other areas that are not very obvious during at first glance. I’ve listed some of my favorites below: Forget About Agile Development During the last decade software development has evolved from long, waterfall-based cycles to agile methodologies that promote rapid iterations with continuous deployments and troubleshooting. Agile software development practices have become the standard in enterprise environments and have produced an entire generation of tools designed to manage the lifecycle of apps built using those methodologies. The move fast and break things mantra of agile methods doesn’t quite work when comes to blockchain smart contracts. The immutability of blockchain runtimes makes it impossible to regularly version smart contracts, incorporate new features or troubleshoot bugs. As a result, smart contracts typically undergo long development and testing cycles which are constantly at odds with the fast-iterative approach followed by the other components of the solution. Whether in permissioned or public blockchains, smart contract development cycles are more analogous to building hardware than modern software. Hardware development methodologies are typically based on long development and obnoxiously detailed testing cycles as well as carefully crafted distribution mechanisms. Not surprisingly, many of the methodologies and best practices used in hardware development can be extrapolated to smart contracts. In our experience, permissioned blockchain solutions should be structured using waterfall models that are somewhat independent of the development cycle of the rest of the solution. What Identity? Permissioned blockchain solutions operate within trusted environments in which the identity of the participants in well-known. For decades, enterprises have undergone multiple cycles of identity management technologies that enable capabilities such as authentication, access control, federation and several other identity building blocks. Leveraging those identities as part of permissioned blockchain solutions can result on nothing short of a nightmare. Think about the scenario of an accounting app that invokes a series of smart contracts to record some transactions on behalf of specific users. In that model, the users authenticate to their corporate directory and their identity needs to be, somehow, passed to the smart contracts to enforce specific actions. Conceptually, this is a traditional identity federation scenario except that there are no established protocols for federating on-chain and off-chain identities. Some of the most advanced work in which space is coming from the Decentralized Identity Foundation(DIF) but is still in very early stages. Using some of those ideas, we have implemented patterns in which the smart contracts receive the identity of users in the form of decentralized identifiers(DIDs) based on tokens issued by enterprise identity providers. The Monitoring Nightmare Monitoring the execution of smart contracts is another of the omnipresent challenges in permissioned blockchain solutions. What operations have been executed? by whom? what transactions have been processed? which ones failed? Block explorers are the default mechanism for tracking transactions in permissioned blockchain scenarios but they result quite limited when applied to end-to-end, off-chain on-chain transaction flow. Most enterprises already have application performance monitoring(APM) stacks that track workflows for different applications. From that perspective, is way easier to integrate the tracing of smart contract workflows into those tools than the other way around. A pattern that we have successfully implemented multiple times is to use an Oracle that bridges the communication with an APM stacks and logs relevant events about the smart contract execution. This model allows dev-ops to use the same familiar tools and processes to monitor the health of permissioned blockchain applications. How Do I Use this Smart Contract? As smart contracts become more common in enterprise environments, their discoverability and distribution will become more relevant. If you are building a pilot with two smart contracts, then discovery is not a top requirement. However, that picture quickly changes when you are expecting the smart contracts to be reused across multiple applications. Enabling the mechanisms for discovering, testing and interacting with smart contracts is an important aspect to streamline the adoption of permissioned blockchain stacks. A smart contract catalog is a pattern that we have successfully implemented a few times to address this challenge. In that model, the catalog will act as a repository containing the metadata related to different smart contracts as well as JavaScript interfaces to test them and interact with them programmatically. Consensus for What? Permissioned blockchains operated on environment with known identities. However, most permissioned blockchain runtimes rely on consensus mechanisms like proof-of-work or proof-of-stake that replace identity with expensive computations. Computation-based consensus protocols only make sense in scenarios with decent size networks which is not always the case in permissioned blockchain applications. As a result, the consensus protocols of most permissioned blockchain stacks end up introducing unnecessary performance penalties on transactions without adding any benefits. The reality is that most permissioned blockchain solutions failed to effectively leverage consensus models and they will be better off with protocols such as proof-of-authority that are completely based on known identities. These are some of the non-obvious challenges that we regularly encounter in permissioned blockchain solutions. As the industry evolve, permissioned blockchain stacks should adapt to address some of these challenges with native capabilities instead of forcing developer to work they way around them.
