Operating a permissioned blockchain network is not easy. What appears to be a few nodes and some networking configurations is actually a Pandora’s box of technical intricacies and obstacles. Many first-class issues might quickly turn into significant impediments, especially when these networks are constructed on constantly growing open source protocols. Because enterprises share IT duties to regulate and maintain these business networks, collaborating with IT Ops specialists from diverse companies is tough. This article will discuss how successful business networks can employ Blockchain Software as a Service (BaaS) to deliver commercial value across new business models and cross-industry ecosystems.
How Local Blockchain Deployments Have Evolved
Creating a local blockchain instance used to be a huge undertaking. The fundamental code bases of the three primary blockchain protocols (Ethereum, Fabric, and Corda) were still being developed and hardened. Enough knowledge of cryptography, hashing techniques and peer-to-peer protocols to even put together a working system.
Modern Docker images (i.e. runtime components) and YAML files (human-readable data serialisation language) allow you to swiftly set up containers on your own machine. The simplicity of use of hardened shell scripts and pre-mounted config files is great, but it can also lead to overconfidence. “Wow, that wasn’t so difficult, we could easily run this ourselves,” devs and power users alike can think. Despite their appearance, these mini-sandboxes are not reflective of an enterprise-grade multi-org decentralised business network.
Authentication and Permissioning
In a permissioned or private blockchain context, nodes need to trust each other to communicate. This usually involves TLS certificates, IP addresses, and/or unique node identities. This is not a problem in a centralised or local deployment. Then just mount the file systems with the certs and static configuration files.
This authentication/trust paradigm becomes much more difficult in a decentralised design where nodes run on different servers and maybe cloud providers. You’re now faced with coordinating amongst parties scattered throughout the globe that don’t necessarily trust each other. The required out-of-band communication streams might be time consuming and mistake prone. Furthermore, manual configuration data transfer, such as certs, creates an attack surface for malevolent actors. By eliminating the need for cross-organizational reconciliation, a managed blockchain as a service in Malaysia decreases attack surfaces. The savings in expense and management are immediate, as production-grade consortium networks may now be securely bootstrapped in minutes rather than weeks or months.
Look for a BaaS supplier that does not undermine the integrity of the important blockchain layer trust components (keys, certificates and config definitions). These parts should be separated to the runtime processes that need them and stored securely. Some platforms even allow for extensible encryption, allowing businesses to use hardware-protected master keys to add an extra degree of organisational protection.
Along with security, look for platforms that support transparent and self-evident identity declarations. By verifying an uploaded certificate chain, other network participants can authoritatively identify their counterparts. These PKI-based proofs should ideally be weaved into the blockchain layer so that the enterprise identity trust paradigm is always present.