Business Requirements and Causes of Decentralization

CAUSE Matrix helps businesses in designing the blockchain solutions. It is a 5 factor questionnaire that business strategists must fill in to derive whether Blockchain is required or not and further identify the type of Blockchain suitable for it.

It is a way to evaluate if blockchains are required in your business application.

Based on the result of the matrix, you can identify if the business scenario really requires blockchains or not.

Mark “yes” for “collaborative workflow” when the entire flow of operations needs to be linked digitally by multiple users. For example, consider a business use case where a team of 50 HR workers runs personnel operations across a Fortune 500 company that has 50,000 employees. The company wishes to bind all activities together, connecting various aspects of personnel operations. This collaborative workflow can be on chain, thereby marking it as “Yes.”

For “assets digitized,” the entity on record is employees that may be digitized based on the data records. If assets are not digital, one has to find a way to connect the physical asset to a digital one. For example, house-key access can be done through a smartphone or a biometric key that can be used as a data asset on the ledger.

“Unknown contributors” is to evaluate if the stakeholders/users of the business process are end customers who are unknown and exploratory or known entities such as employees, business partners, or service providers. Based on that, public or private blockchains or both, forming hybrid blockchains, are used.

“Storage of state” is to recognize if the data being recorded is required to store each state or just the last state. Referring to our example, if the HR worker needs to know the entire lifecycle of an employee, all state records are crucial, and therefore using a blockchain is legit as it provides a tamperproof record of all states of an employee. Conversely, in a case where only the last case matters, a blockchain may not be needed. A simple ERP/CRM could be used.

Lastly, the factor for encryption helps to decide if end-to-end encryption is required. In a large organization, certain network information needs to be kept internal and confidential, and thus a private ledger could be used that encrypts valuable information between the relevant stakeholders only. In our example, data points such as salary need to be end-to-end encrypted between the employee and the HR department. The storage of such data is encrypted and distributed on-chain, making it difficult for a hacker to target one server to break out the information.

Business developers have to identify the area of operation that requires decentralization based on the CAUSE factors so as to decide on the type of blockchain.

Businesses that operate toward expanding services on a decentralized ledger to consumers who may be unknown end users who require no permission to join the ledger opt for a public blockchain. Businesses that operate in a B2B environment or internal to the company may utilize a private blockchain, where permission is crucial for controlled parameters.

In the case of a marketplace business case, for instance, a combination of private and public blockchain networks is required, forming hybrid blockchains. Certain information, such as retail goods listings and service listings, may be put on the public blockchain, and the users can anonymously view the data on the public blockchain ledger. However, when there is a transaction between a buyer and a seller, a private blockchain network can be formed, and the transactions may operate based on the consensus principle of the chain.

Business developers seek enterprise technology tools for deployments, especially to receive long-term support, scalability, skill availability, training, and so forth (Figure 7-1). Azure provides a wide range of enterprise support for its blockchain elements along with its other cloud services. This improves the integration capacity of the existing Microsoft framework so it can be on-cloud and on-chain wherever required.

Exercise 7-1

As a business developer, identify a business case that truly requires a blockchain. Run the use case through the CAUSE matrix and confirm suitability. Break down the use case into specific aspects, such as:

1. 1.

   Storage

    
2. 2.

   Process

    
3. 3.

   Access control

    
4. 4.

   Contracts

    
5. 5.

   Tokens

    

Write user story across each aspect based on the business use case.

This exercise further provides solution architects with tools to decide the specifics of the blockchain platform.

Solution Architecture with Respect to Operations

Use Case: Sharing Medical Health Records of Patients Across Hospitals

In cases of medical treatment, it has been observed that it is not always the same doctor or hospital treating a patient over a period of time. This may happen due to the patient relocating to a different place, a referral from the current hospital to another hospital, being in an unfortunate incident in some other city, or simply because the patient does not like the approach of the doctor. In such cases, it becomes important to have the complete medical history of the patient shared with the new hospital/doctor in order to maintain continuity of care and appropriate understanding of the patient’s illness and past treatments.

As medical records are highly personal and confidential documents, it is important to have the data available in a format that is secured, immutable, and available only to the right users. This creates a window to explore the feasibility of solving this problem using a blockchain.

GHOSSTTT Protocol

Once the business team defines the vision of the Blockchain platform & specifies the type of the blockchain through the CAUSE Matrix, solution architects have to identify deeper components of design that bridge business & technology.

Thereby we coined the GHOSTTT protocol that enables solution architects to factor design touchpoints for Blockchains as follows:

• Governance required? Single-handedly, selective authority, all nodes contribute to governance, or consensus based on smart contract rules?

• High-speed transactions and concurrency? Hybrid chains of private ledgers in a smaller network mesh.

• Open/closed, permissioned or permissionless?

• Large-scale data Storage of states – Custom solutions for developing consensus across distributed servers where data is stored with copies across the private chains based on the platform mechanism.

• Storage on-chain distributed and copied? Does the state of transactions interact based on events on chain?

• Tokens required? Existing scoring mechanism? Reward program? Shortcomings? Auto-calibration of value required?

• Transactions interact with known participants – distributed ledgers, Ripple, Corda

• Trusted networks or trustless?

The solution architect’s responsibility here is to identify the right set of tools that aligns with the business as well as the developer skill set available. The GHOSSTTT protocol translates the business demands for technology decisions. After the CAUSE matrix is clarified, one has to deduce the specifics based on the GHOSSTTT protocol.

Let’s consider the GHOSSTTT protocol for the use case of sharing medical health records of patients across hospitals.

Governance

Governance in this growing digital era has brought out new challenges that may have not been factored earlier in ecosystems, enterprises & platforms. With the need to cover fair practices while storing, referring & transacting on digital platforms, governance needs to evolve. With Blockchains, Decentralized Autonomous organizations (DAO) regulation systems are introduced. This system enables the stakeholders participating to be governed by a common set of pre-defined rules agreed by all. No action out of these rules are allowed in a DAO based system. So while designing Blockchains, one must factor if any such regulatory measures have to be defined in the smart contracts to enable Autonomous Functions unbiased by any party on chain. Even unbiased to the party initiating or hosting the Blockchain.

In the medical use case explained earlier, the conditions for a healthy organ form a part of governance to maintain integrity of the process, unbiased to the medical institution provisioning the service. This is the main differentiator from a mere website hosted by the medical institution which can be manipulated, however, the records on a DAO based Blockchain cannot be tampered, maintaining the governance as desired.

High-Speed Transactions and Concurrency

Azure CosmosDB provides a low-latency, high-availability and globally distributed, multi-model database to enable such transactions as well as to run concurrent transactions in consortium networks. Similar NoSQL databases can be selected for this factor.

Medical records are generated at every instant in various parts of the world and are indexed several times from the ledger for various stakeholders. Therefore, the low latency is a crucial factor for a decentralized ledger.

Open or Closed, Permissioned or Permissionless

For health care, a lot of information is distributed openly to the stakeholders in terms of medical services, policies, and so forth. However, access to confidential information such as medical records is required to be permissioned. Therefore, the chain could be an open permissioned ledger.

For example, Azure Marketplace provides Quorum, which maintains privacy for transactions and contracts by separating the public and private data over separate networks, thus maintaining the privacy for private data and the transparency for public data.

Storage

In a distributed ledger for a blockchain platform, there are two aspects: one is the decentralized storage of state of the chain nodes, and the second is the storage of data. At this stage, one has to decide if the application is across an intranet, internet, or a shared disk with virtual node clusters.

Considering the sharing of medical records and the choice of Quorum in the preceding points, Quorum ensures the privacy of transactions and the state of transactions and not the data storage itself. Therefore, the storage of states is encrypted and can be stored in Azure’s Blob or CosmosDB or any other storage. However, for an application where the storage of data is more crucial than the transaction itself, tools such as BigChainDB, which extends to distributed storage of data, may be considered. If files are to be encrypted as is, IPFS can be considered. In cases where medical records are to be stored and transacted/shared securely, one can design Quorum to be integrated with IPFS for Azure cloud components to make sharing medical records truly safe and the storage equally vaulted across the globe.

Tokens, Transactions, and Trust

Medical records being a highly sensitive document with respect to patient health, the credibility of the source of the medical records is highly crucial. Therefore, the DAO selected in the first stage of governance establishes the trust of an unbiased network. Having the voting mechanism on-chain for authorization boards doing the certifying makes the record more trustworthy. Transactions here may be sharing records, buying medical tests and reports, or purchasing general anonymized public data within the regulations of the chain. Here, the solution architect has to design the consortium chain, which could be a public chain within a country, region, or area, or private chains of medical doctors and patients, or private chains of enterprises and the medical records of their employees, or private networks of insurance companies and customers. The wiring of transaction networks is to be decided at this stage. Once this is designed, based on the business requirements, quantification of on-chain actions can be made. So, first decide if tokenization is required in your business use case; for example, credit ratings of a hospital/surgeon/pathologist. Credit ratings of customers for health insurance companies and so on can be incentivized on-chain with the token-economics agreed to on-chain. However, for simply maintaining a digital vault on the ledger, no tokenization is required.

Exercise 7-2. Based on The Business Case in Exercise 7-1, Answer the Outcomes of GHOSSTTT Protocol for your Use Case

When points of governance, high speed, and open networks are clear, start surveying the technology tools suitable for the pain points. In many cases, a certain combination of tools may not be readily present. That’s where the solution architect has to decide to either develop from scratch, choose an existing blockchain solution, or pick an enterprise structure of cloud-based components such as Azure for the blockchain network.

After this exercise, walk through the “21 Questions for Business- and Developer-based Decisions for a Solution Architect” table. Finalize the technology stack and architecture in iteration with Sections 1 and 3.

Application of GHOSSTTT Protocol

The next step is to stack up the layers of the GHOSSTTT protocol into a block diagram to formulate the overall process flow and architecture. For example let’s understand the architecture laid by the Azure Blockchain Workbench, as shown in Figure 7-2.

Combining the answers from the GHOSSTTT protocol and the 21-question matrix, the solution architect has to decide on either a top-to-bottom approach (customer first to backend infrastructure) or a bottom-to-top approach (backend infrastructure to customer interface). With an ecosystem such as Azure, all components of a blockchain application are covered.

For example in Figure 7-2, a top-to-bottom approach consists of the following:

• User authentication (Cell No. 17) – Azure Active Directory

• Application interface (Cell No. 20) – Xamarin apps and IoT edge devices with IoT Hub

• Data communication channels (Cell no. 12) – REST-based gateway service API, message brokers, service bus

• Consumers such as DLT (on-chain), database (off-chain), and hash storage (encrypted) consumers

• Insights – Azure Monitor and analytics

• Transaction builder and signer – Azure Key Vault

• Transaction routers and ledgers

• DLT watcher and event grid

These tools are highly reliable when customers are located across geographical areas with the means to connect over a reliable internet connect, as well as for an organization that is looking for an enterprise infrastructure of cloud components to drive the blockchain.

Revisiting the CAUSE matrix, why is a blockchain required in such a case, and not a centralized hosted system?

Because for hosting parties that develop and host such platforms, encryption is usually at the mercy of the developers or under the governance of the company hosting such a service. Therefore, such platforms have low credibility in terms of public trust on a large scale. In a blockchain network, the encryption is distributed across a network, making it difficult to decrypt by any random attacker. Also, in a blockchain mode of governance, where the process runs on a decentralized, autonomous system that can be seen as a set of pre-defined, agreed-upon rules set in a smart contract, replacing the rules ad hoc is not allowed until all members agree and validate the change of rule or until consensus is achieved on the change.

So far, we have gotten a bird’s eye view of the architecture used to form a decentralized blockchain application, along with the components that form the ledger and the support components that drive the application. Further drill-downs inside the blockchain architectures of Ethereum, Hyperledger, and so forth can be found in the next chapter.

The following is a list of top-to-bottom functional components for a decentralized application:

• Front-end components

  • Applications

  • Block explorers

  • Monitoring systems (watchers, event trigger alerts)

  • Smart contract tools

  • Definitions with Solidity and other smart contract languages

  • Auto-validators, enforcers of the contract

  • Pre-defined standards and governance

  • for tokens

  • for identity

  • for actions

• Tooling components

  • Active Directory

  • Wallets

  • Vaults

  • Data Warehouse integrations

  • Integration plugins

  • Json RPC

  • Inter-Chains

  • Oracles

• Privacy and scaling components

  • Encryption

  • Hashing

  • Computing

  • Concurrency of service buses

• Core blockchain components

  • Network configuration

  • On-chain and off-chain states and storage

  • Execution of smart contracts

  • Consensus

  • for private networks

  • for public networks

• Network protocols

  • Devp2p

  • Enterprise P2p

  • RLPx wire

  • Libp2p

Azure Stack

Having an enterprise ecosystem where all third parties also align with the definitions of components meant for true decentralization, trust, and peer-to-peer networks is crucial.

Azure Stack provides a single-click deployment option for the Ethereum network wherein each member can contribute to the network. The contributing member on-chain may run a set of nodes that interact/transact with the other mining nodes on the chain. Azure lets one decide the chain topology using network virtual appliance and connection resources for single- or multi-member Ethereum consortium networks.

In an enterprise setup that works B2B (for example, NBFCs working with DSAs for loan disbursals or insurance companies working with insurance agencies), there are multiple companies working with on another. The technical implementation of this business setup requires nodes of the Blockchain communicate across different Azure accounts that belong to different businesses.

In a setup where the processes are to be decentralized within an organization, amongst different departments/employees of the same organization, the nodes of the Blockchain will be a part of the same organization subscription for Azure (cell nos. 11 and 16 of the 21-question set).

Azure provides the template for both components/members with a deployment option to run the template. For details on executing the template, see the following: https://docs.microsoft.com/en-us/azure-stack/user/azure-stack-ethereum#standalone-and-consortium-leader-deployment.

As a solution architect, one has to identify the existing templates Azure provides in its marketplace with respect to the business case, GHOSTTT protocol, and 21-question matrix.

Azure provides the following Ethereum alternatives.

Quorum: EEA Single-Member Blockchain

Quorum is an open source, permissioned implementation of Ethereum that focuses on securely processing transactions and restricts access based on the permission status of control (see Figure 7-4). Figure 7-3 highlights the essential components that power a QuorumChain. Observing the transactions of Ethereum on Quorum, we see how all of these components come alive to interact with each other in Figure 7-4.

See: https://entethalliance.org/quorum-consortium-network-in-azure-marketplace.pdf

Ethereum on Azure by Microsoft/Parity Ethereum with Proof of Authority (PoA)

This toolkit utilizes the Ethereum virtual machine with proof of authority instead of PoW (proof of work) as shown in Figure 7-5. The governance is pre-defined.

It contains the following Azure components (Figure 7-5):

• Virtual machines for running the PoA validators

• Azure Load Balancer for distributing RPC, peering, and governance DApp requests

• Azure Key Vault for securing the validator identities

• Azure Storage for hosting persistent network information and coordinating leasing

• Azure Monitor for aggregating logs and performance statistics

• VNet Gateway (optional) for allowing VPN connections across private VNets

Now that we have seen various architectures based on the variants that are outcomes of the 21-question matrix, let’s drill down deeper to a component level of understanding from a developer’s perspective and decide the suitability of the options.

Developer’s Version of Technical Component Breakdown

Most major blockchain networks that are driven by public, private, or consortium networks are largely accepted due to the source code–level transparency of the platform. This establishes trust to implement and execute, thereby making it a trustworthy source for end users.

For example, Ethereum, Hyperledger, Corda, Quorum, NEM, Stellar, and so on all have made their frameworks open source and have further extended component codes on GitHub. This kind of setup allows businesses to integrate third-party frameworks in order to formulate blockchains with better confidence, as no loopholes are missed regarding the privacy and governance on-chain. The choice of development at this stage is most crucial.

The recipe here is for the solution architect to clearly focus on the components defined in the previous section. However, on a code level, severe scrutiny has to be maintained by the developer utilizing the proposed framework. For example, the 51% Miner’s attack is one of the cases that was a loophole in Ethereum's earlier source code. However, its choice to move to proof of stake consensus ensures such attacks are avoided going forward.

Since we are focused on the developer’s version of technology tool selection for blockchains, let us consider the bottom-to-top approach (where bottom would be the back-end databases and the top would be the end users or front-end applications).

Layers of Tools

In a technology stack, every layer has specific functions, from the database end to the back end to the user interactivity in the front end. The layers of tools and the decisions based on functional components for a blockchain application are detailed next.

• Network peer-to-peer

• Core blockchain frameworks

• Privacy and scaling components

• Tooling elements

• Front-end elements

Network P2P Libraries

The following are some useful libraries:

1. a.
   Libp2p provides the package to set up peer networks. However, due to the developer alignment of language, it also has language implementation, such as the following:

   1. i.

      Go P2p

       
   2. ii.

      Kotlin-based P2P

       
   3. iii.

      Js-Lib p2p

       
   4. iv.

      Rust Lib p2p

       
    

1. b.
   Noise: P2P networking stack for developing decentralized applications and cryptographic protocols written in Go. This is used in Perlin Wavelet Network.

   1. i.

      Ref: https://github.com/perlin-network/noise

       
    

1. c.
   In Ethereum:

   1. i.

      RLPx transport protocol: a TCP-based transport protocol used for communication among Ethereum nodes

       
   2. ii.

      Kademlia DHT (distributed hash table) provides peer selection during lookup, joining the network. The protocol contains four RPC—Ping, Store, Find Node, and Find Value.

       
    

1. d.
   In Quorum (which is available on the Azure Marketplace)

   1. i.

      Network permissioning is a feature that controls which nodes can connect to a given node and also to which nodes the given node can dial out. Currently, it is managed at the individual node level by the --permissioned command-line flag when starting the node.

       
    

1. e.
   In the Ethereum Blockchain network on Azure:

   1. i.

      The chain topology is deployed using the network virtual appliances (NVA).

       
   2. ii.

      NVAs maintain high availability behind load balancers and peer node servers, thus providing a fault-tolerant ecosystem

       
   3. iii.

      NVA IP addresses are used on-chain for a multi-node chain instead of the peer node’s actual IP address, thus making it difficult to hack into a peer-to-peer environment.

       
    

1. f.

   Hyperledger Fabric:

    

As we observe in Figure 7-6, the peer-to-peer network in Hyperledger Fabric runs on the chaincode defined by the network. This makes it flexible as well as focused on the purpose of the chain, along with the certificate authority issued by the participating organizations in a multi-node, multi-organization scenario.

Core Blockchain Frameworks

This section focuses on the components found inside the blockchain and not the elements around it. For example, it covers the consensus type, the network design for on-chain and off-chain activities, the logic of governance, and so on. The three main aspects are storage/ledgerarrangement, execution, and consensus (Figure 7-7).

1. a.
   Microsoft Confidential Consortium Framework (CCF)

   

   1. i.

      A framework to build secure, highly available, and performant applications that focus on multi-party computations and data

       
   2. ii.

      It is not a blockchain itself, but enables the core components of a blockchain with the distributed ledgers, multi-party computing, and cryptography.

       
   3. iii.

      The framework provides a TEE (trusted execution environment) wherein the code and data are locked with confidentiality and integrity in a secure place.

       
   4. iv.
      It provides an Open Enclave SDK for developers to integrate in a TEE form for genuine decentralization and integrity of in-chain logic and data, as shown in Figure 7-8.

      

       
   5. v.

      Usually while developing the consensus of any blockchain, the hard forks are kept limited and may not be changed ad hoc by the host unless accepted by all members. Therefore, the Open Enclave SDK provisions for that development credibility and stability. This makes the blockchain platform unbiased regarding the host/developer behind the platform once it is deployed on such a framework.

       
   6. vi.

      Six prime elements of this framework are the following (Figure 7-8):

       

   1. 1.

      Hardware – SGX-enabled Azure Confidential Compute

       
   2. 2.

      Ledger – An append-only ledger provides encryption of the private data and serialization of the public data with a key-value pair store. The data is replicated on all nodes as the leader commits the transaction. The replication process currently uses Raft as the consensus algorithm.

       
   3. 3.

      Encryption – GCM (Galois/Counter Mode) by a key shared by all nodes for private data on-chain.

       
   4. 4.

      Governance – CCF allows its members to submit policies/proposals, which must be accepted by a quorum of members to be executed. The quorum is defined as a Lua script in the genesis transaction. Common governance operations include adding a new user, member, or version of the CCF code.

       
   5. 5.

      Key-Value Store structure of storing on-chain data, maps (tables), and transactions – It includes serialization and encryption. Also extends Key-Value Store APIs.

       
   6. 6.

      Recovery – CCF ensures recovery in case of extreme network failure where some transactions might not be copied in entirety. The restoration also occurs in true decentralized forms that must be accepted by all stakeholders involved in the loss of transaction data.

       
    

1. b.
   Frameworks for Ethereum: Truffle:

   1. i.

      Defined as a development environment, testing framework, and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier.

       
   2. ii.

      Microsoft’s Visual Studio Code IDE provides Truffle Services along with Azure Cloud Services for an enhanced DevOps experience to develop and deploy Ethereum.

       
   3. iii.

      This framework has three main elements:

       

   1. 1.

      Truffle for smart contract development

       
   2. 2.

      Ganache for blockchain deployment for test environments

       
   3. 3.

      Drizzle – a redux store for fresh chain data for transaction execution and state of smart contract testing on the front end

       

   1. iv.

      Key takeaways for developers:

       

   1. 1.

      Ethereum developers can build logical smart contracts, deploy, and execute.

       
   2. 2.

      Mocha and Chai JS–based automated testing tools ensure proper coverage of smart contract codes.

       
   3. 3.

      Truffle supports JavaScript, SASS, ES6, and JSX, thereby allowing creativity of visuals as well as client-side contract actions.

       
   4. 4.

      Build management and pipelining

       
    

1. c.

   Other frameworks such as Fabric, Sawtooth, Burrow, Iroha, or Indy provide crypto-agnostic options.

    

Privacy and Scaling Components

This section identifies the tools used for data privacy and details the components that can be used to scale towards better privacy measures on a blockchain platform.

1. a.
   Encryption

   1. i.

      Azure Media Services dynamically encrypt your content with AES 128-bit clear encryption keys.

       
   2. ii.

      Azure Storage automatically encrypts your data when persisting it to the cloud.

       
   3. iii.

      Azure Blockchain Service compiles these into secure encrypted components inside isolated virtual networks, making it difficult for a random hacker to identify the exact source of the data.

       
   4. iv.

      Data disks are encrypted by Azure Disk Encryption.

       
   5. v.

      Shared Access Signatures provide access on-chain for public assets.

       
   6. vi.

      For the blockchain quorum, Constellation provides a peer-to-peer message exchange system. It provides every node with key-generation capabilities and maintains a directory based on the privacy level of public or private networks.

       
    

1. b.
   Hashing

   1. i.

      Azure provides a serverless environment for such dynamic functions with the help of Azure logic apps and Flow.

       
   2. ii.

      Hashing may be implemented while onboarding digital assets on-chain with a hashed version of data and metadata.

       
    

1. c.
   Concurrency of Service Buses

   1. i.

      Microsoft Azure Service Bus is a fully managed enterprise integration message broker.

       
   2. ii.

      The service bus includes the queuing mechanisms, topic, and subscriptions.

       
    

Tooling Elements

1. a.
   Wallets

   1. i.

      Ethereum blockchain interacts with several client-side wallets, such as Metamask, Ledger Nano X, Jaxx, etc., available for smartphones, other hardware, and desktop. These wallets are to transact on-chain.

       
   2. ii.

      Hyperledger extends four types of wallets—File, In-Memory, HSM, and Database.

       
    

Front-end Elements

1. a.
   Applications

   1. i.

      Truffle framework in the preceding list extends several front-end tools for smart contract deployments.

       
   2. ii.

      Similarly, the Hyperledger Playground console provides a front end to visualize the transactions on-chain. The Hyperledger Composer Playground provides a user interface for the configuration, deployment and testing of a business network.

       
   3. iii.

      Mobile development for Android and IOS on Xamarin and Azure help enhance wallet development on edge devices.

       
    

1. b.
   Block Explorers

   1. i.

      With the amalgamation of all cloud components in the same ecosystem, a block explorer can be developed based on the transaction watchers and event grids on Azure.

       
   2. ii.

      This would show the true status of the number of transactions, value of blocks, etc.

       
    

So far, we have covered the individual components of the blockchain stack for developer implementations and customizations. Let us further explore blockchain as a service tools for rapid deployments on Azure.