20

Enterprise Blockchain

In this chapter, we'll investigate enterprise blockchains. What is the standard architecture of enterprise blockchains? Why they are required? We will answer these questions, and will also try to answer the big question of why current public blockchains are not necessarily a suitable choice for enterprise use cases.

We will also introduce several enterprise blockchain platforms, including Quorum and Corda. Along the way, we'll cover the following topics:

• Enterprise solutions and blockchain
• Limiting factors
• Requirements
• Enterprise blockchain versus public blockchain
• Use cases of enterprise blockchains
• Enterprise blockchain architecture
• Designing enterprise blockchain solutions
• Blockchain in the cloud
• Currently available enterprise blockchains
• Enterprise blockchain challenges
• Corda
• Quorum
• Setting up Quorum with IBFT
• Other Quorum projects

We discussed several different blockchain types in Chapter 1, Blockchain 101, including permissioned, public, private, and consortium blockchains. Enterprise blockchains are a permissioned consortium chain type that primarily tackle enterprise requirements.

Permissioned doesn't mean private. Permissioned blockchains can also be public and allow access only to known participants. Enterprise blockchains are usually private and permissioned, and are run between consortium members. While public blockchains provide integrity, consistency, immutability, and security guarantees, they lack certain features, which makes them less suitable for enterprise usage. We'll discuss these limitations in detail shortly.

First, we'll look into what enterprise solutions are and how blockchain can fit into an enterprise. Secondly, we'll see what questions should be answered before introducing an enterprise blockchain solution to a business.

Enterprise solutions and blockchain

Enterprise solutions integrate different fragments of a business and enable it to achieve its goals by providing business-critical information to the stakeholders. Therefore, an enterprise blockchain solution should be able to achieve this outcome. Here, we'll consider the question: does blockchain fit this definition and help achieve enterprise business goals?

If a blockchain solution can integrate different facets of a business and enable it to achieve its goals, then clearly it is an enterprise solution that brings real business value. In order to find out if a blockchain is suitable for an enterprise or not, we can ask some questions. Some of these questions are listed as follows:

• How can business/enterprise processes be improved using blockchain technology?
• Do I really need an enterprise blockchain? For this, we can ask some questions to rationalize whether we need an enterprise blockchain solution or not. Does my use case:
  • Need shared data between participants?
  • Have participants from other organizations that are not necessarily trustworthy and have conflicting interests?
  • Need strict auditing? A blockchain can provide this, as it is an immutable and tamper-proof chain of records that can provide a definite audit trail of activities performed on the chain (enterprise system).
  • Need to ensure the confidentiality of transactions?
  • Need to ensure the anonymity of participants?
  • Need controlled but transparent updates to the ledger?
  • Not need a single trusted authority; instead, the decisions on the network (updates to the ledger) should be consortium member-driven and agreed between members?

If the answer to any of the preceding questions is yes, then using an enterprise blockchain solution could be a good option. Otherwise, a traditional database might give a better alternative.

In addition to the questions mentioned here, when proposing an enterprise blockchain solution, we also need to answer some other questions from a business perspective that help establish the overall vision and strategy of the implementation of the blockchain solution:

• What is the overall objective of the proposed blockchain solution? Does it align with the business goals of the enterprise? Is it a Proof of Concept (PoC) project, intended just to demonstrate an idea, or a production project with real business deliverables?
• Where would it be deployed—cloud or local hosting? Who will manage the blockchain solution once it is deployed?
• Risk management considerations—does the solution follow any established guidelines for risk management? For example, NIST 800-37 is a risk management framework that provides a process used to manage security and privacy risk for IT systems and organizations.
• Are there any other projects that this organization may have implemented already using enterprise blockchain? Can we learn from previous experiences and leverage some of the resources and best practices that may have been developed previously?

These questions should be—and are usually—asked when developing any other enterprise solution, but in relation to blockchain, these questions become even more critical due to the nascent and immature nature of enterprise blockchain technology. A clear definition of the objectives, along with clear alignment with business requirements, will result in an implementation that meets business goals. Now, the question arises regarding how blockchain solutions can be developed that can bring real business value. We'll learn later in this chapter how enterprise blockchain solutions can be designed using established architecture frameworks.

So, in summary, after answering the aforementioned questions even informally and then engaging in a formal exercise of designing an enterprise blockchain solution using an enterprise framework, we can answer the question regarding whether a proposed blockchain solution is an enterprise solution that meets business objectives. We'll cover designing enterprise blockchain solutions later in this chapter.

Next, we'll envisage some success factors that can help enterprise blockchains to become successful and adopted in the enterprise.

Success factors

There are some business-oriented factors that should be addressed for a successful enterprise blockchain solution.

Of the utmost importance is the requirement that the blockchain solution should bring some economic value and help to achieve real business goals. Moreover, enterprise solutions should be aligned with business goals.

The primary value of enterprise blockchains is in the property of being a sharable, replicable, permissioned ledger between organizations that immediately results in cost reduction by eliminating the need for data exchange. In doing so, we also eliminate the need for infrastructure and tools to support such exchanges. Also, due to the security, immutability, and auditing provided as inherent features of a blockchain, there is no need invest separately for these requirements.

Blockchain solutions that integrate easily/seamlessly with existing systems provide better value because already mature legacy systems (at least at this stage) provide a mechanism to connect with the blockchain, read its data, and save it in a known format that the enterprise is already familiar with. Moreover, just a blockchain network on its own is not entirely useful in enterprises if it is not integrated with existing back-office systems such as Enterprise Resource Planning (ERP), backend databases, record reconciliation systems, or other organization reporting tools.

An enterprise blockchain solution should be seen as a complete end-to-end enterprise solution as part of the larger enterprise architecture, instead of only a siloed blockchain network. We'll explore this topic later in this chapter, under the Designing enterprise blockchain solutions section.

Enterprise-grade governance, control, and security are also desirable features from a business perspective as they allow business stakeholders to apply already-established organization rules and policies to the blockchain. This can also help to achieve regulatory and compliance requirements.

Now, the following question arises: with the availability of many different public blockchain platforms, why has the adoption of blockchain technology in enterprises still not been fully achieved? The reason is that there are several factors that make public blockchains unsuitable for enterprise use cases. In the next section, we'll answer this question and explore why public blockchains are not quite suitable for enterprise use cases.

Limiting factors

We discussed several benefits of blockchain technology in general in Chapter 1, Blockchain 101. While all those benefits are attainable using public blockchains, several features are lacking in public blockchains, which makes them unsuitable for use in enterprise use cases. The interest in enterprise blockchain arises from these limitations in public blockchains, along with specific requirements in any business.

We'll describe some of the most common concerns next.

Slow performance

Public blockchains are slow and can process only a few transactions per second. Bitcoin processes 3-4 transactions per seconds, while Ethereum processes around 14. This low transaction rate is not suitable for businesses that usually require high transaction speed. For example, card payment businesses typically need to process thousands of transactions per second.

Lack of access governance

Public blockchains are available for anyone to join, which makes it easier for investors and cryptocurrency enthusiasts to join and helps with the network effect. However, in an enterprise, all participants must be known so that everyone knows who they are dealing with. This lack of an identification and access control mechanism makes public blockchains rather unsuitable for businesses.

Lack of privacy

Public blockchains are inherently transparent, and everything on the ledger is visible to everyone. This means anyone can easily view transaction details and participants involved in a transaction.

Probabilistic consensus

Public blockchains usually use a Proof of Work (PoW) type of consensus mechanism, which is inherently a probabilistic protocol that provides probabilistic finality. Even though the confirmations mechanism, as discussed in Chapter 6, Introducing Bitcoin, does give a certain level of confidence that a transaction is irrevocable, it is still possible that the chain may fork and transactions can be lost. This issue is particularly a concern for businesses where once a transaction commits, it is deemed final. Imagine receiving a property ownership document on a chain from someone only to discover later that the blockchain has forked, and that you are no longer the owner of the property.

To address this limitation, enterprise blockchains use deterministic consensus algorithms, which provide immediate finality.

Transaction fees

In Ethereum or other similar blockchains, the transaction fee is charged in the native cryptocurrency for each transaction execution. While this mechanism provides incentives for miners and protects against spam, there is no requirement of such an arrangement in enterprise blockchains. If an organization were to use public blockchains for their business transactions, then they'd need cryptocurrency in reserve to pay for operations on the blockchain. This extra cost might be undesirable for some businesses.

While the concerns mentioned here are considered limitations in public blockchains, based on these concerns and limitations, we can derive and define several requirements, or features, of a blockchain that will enable it to become an enterprise blockchain. In other words, the limitations in public blockchains can be seen as requirements of enterprise blockchains.

The next section talks about several features that a blockchain should possess to become suitable for enterprises.

Requirements

In addition to integrity and consistency, which are also provided by public blockchains, there are several other requirements specifically for enterprise blockchains that make them suitable for enterprise use cases. In some cases, some requirements become even stricter in enterprise blockchains compared to public blockchains. For example, in public blockchains, eventual consistency is acceptable. However, in enterprise blockchains, the moment a transaction is committed, it should immediately finalize and irrevocably become part of the global record (state). Thus, we'll begin by briefly defining integrity and consistency before introducing specific requirements for enterprise blockchains.

• Integrity: This attribute of a blockchain is provided by the use of hash functions and digital signatures, and plays a vital role in the overall security of the blockchain. Hash functions allow us to check for any data modifications, whereas digital signatures ensure that the messages that originated from a sender have not been altered.
• Consistency: This attribute of a blockchain ensures that all honest nodes agree on the same sequence of blocks. To achieve this, various mechanisms are used, such as PoW or Byzantine Fault Tolerance (BFT) consensus protocols.

Now, we'll introduce three fundamental requirements that should be met for a blockchain to become suitable for enterprises. These requirements are privacy, performance, and access governance.

Privacy

Privacy is of paramount importance in enterprise blockchains. Privacy has two facets: first, confidentiality, and second, anonymity.

Confidentiality

Confidentiality is a fundamental requirement in an enterprise. It is anticipated that, in enterprise blockchains, all transactions hide their payloads so that the amount of transactions is not revealed to anyone who is not privy to the transaction.

Types of private transaction

Private transactions can be defined as transactions that meet the privacy requirements of an enterprise use case. There are two types of private transactions, as defined by Enterprise Ethereum Alliance (EEA):

• Restricted private transactions: This type of private transaction is transmitted only to those parties on the blockchain network who are a privy to the transaction.
• Unrestricted private transactions: Under the unrestricted private transaction paradigm, private transactions are transmitted to all participants on the network, regardless of whether they are party to the transaction or not. The payload is still encrypted and confidential, but the transaction itself is broadcast to the entire network.

There are many approaches to achieving privacy in enterprise blockchains and blockchain in general. These methods range from an off-chain mechanism like privacy managers (used in Quorum and some other Enterprise chains) to utilizing zero-knowledge proofs (ZKPs), trusted hardware, and secure multiparty computation (SMPC). We'll cover some of these techniques in the next chapter, Chapter 21, Scalability and Other Challenges, but in this chapter, we will mainly focus on privacy manager-based privacy, where an off-chain component is used to provide privacy services. We will discuss the privacy manager-based approach in the Quorum section later in this chapter.

Anonymity

Anonymity in enterprise blockchains might not seem a strict requirement at first, because all participants are known and identified. However, it is necessary for scenarios with some competing participants and conducting business on-chain. It could be essential, for example, that in a scenario where parties X and Y are transacting together, party Z doesn't find out which parties are transacting together. Even though the transaction values are not visible, it can still reveal details about the business that the two parties might be doing. If that information is available publicly, then other parties on the consortium chain will gain market intelligence and may try to influence that process via marketing or other methods.

Performance

Due to the high-speed requirements of businesses, enterprise blockchains must be able to process transactions at a high rate.

Scalability/speed

Performance has two facets: scalability and speed. Speed deals with how many transactions can be processed in a given amount of time. It deals with the ability of a system to handle a large volume of transactions at an acceptable speed.

On the other hand, we have the number of participants in a system. Public blockchain can support a large number of users. This is especially true in cryptocurrency blockchains such as Bitcoin and Ethereum. This is possible due to the PoW or Proof of Stake (PoS) algorithms for consensus used in these public blockchains. However, in enterprise blockchains, a different class of consensus algorithms (most commonly BFT) are used, which do not work well with a large number of nodes. This results in limiting the number of users on a consortium chain.

Here, we have to consider a tradeoff. Ideally, an enterprise blockchain should be able to perform well with a large number of users; however, with the tradeoff, enterprise blockchains should be able to process transactions at a high rate. This is what most enterprise blockchains focus on since, in many use cases, the number of nodes is not that high, and speed can be prioritized over scalability.

In public blockchains, sometimes, network congestion caused by high volumes of traffic can cause performance issues and can increase the transaction processing times. This is detrimental to enterprise DApps, which need faster transaction processing and response times. Network congestion also results in increased gas prices, which can also be a concern for businesses from a cost perspective.

Access governance

From another angle, being a permissioned blockchain, enterprise-grade access control (in the form of either a new mechanism on the chain, or control driven by an enterprise SSO already in place) is a fundamental requirement in enterprise blockchains. As all participants must be identifiable on a consortium chain, it is essential to build an access control mechanism that facilitates that process. This feature can be achieved by using enterprise-grade access control mechanisms such as Role-Based Access Control (RBAC).

The access control mechanism also can address Know Your Customer (KYC) requirements.

In addition to privacy, performance, and access governance, which are usually identified as three fundamental requirements of enterprise blockchains, there are also some other requirements that are highly desirable but can be considered somewhat optional, as they are more use case-dependent. We'll describe these next.

Further requirements

In this section we'll present some further requirements that are very useful and can increase the suitability/efficacy of enterprise blockchain solutions. We'll discuss these requirements as follows.

Compliance

A common concern is compliance. Public blockchains are not suitable for enterprise use cases due to strict regulatory and law requirements in almost all sectors such as finance, health, and government. Compliance challenges mainly include regulatory compliance, standards compliance, data sovereignty, and liability concerns. We'll define these briefly next.

Compliance with standards and regulations: Often, in enterprise use cases, compliance with a technical standard or laws is required. For example, compliance with GDPR is mandatory in the European Union and the European Economic Area. Another example is compliance with Financial Conduct Authority (FCA) regulations in the UK. Moreover, it might be necessary, in a use case, to comply with technical standards such as cryptography standards published by NIST.

Data sovereignty: Data sovereignty is a broad topic that mainly subjects data to the laws of the country in which it is located. For example, under GDPR, transferring personal data outside the EU is subject to adequacy decisions (Article 45) and the appropriate safeguards (Article 46).

As public blockchains are borderless and geographically dispersed systems, compliance with such regulations can be challenging.

Liability: In traditional business and IT systems, legal responsibility often lies with a party who provides a specific service; for example, a cloud service provider being responsible for handling data in accordance with local laws and regulations. In a decentralized public blockchain, the data is on a public blockchain, and it therefore becomes challenging to keep a single party responsible for data management or providing services. In case of malicious incidents, again, it is not possible to hold any single party responsible.

This limitation poses a significant challenge in enterprise settings where, usually, a responsible party is in control of service provision and is held accountable. From another angle, we know that, in traditional systems, in case of any problems, a legal system can help. However, in a decentralized blockchain, it can become quite challenging to blame any single party for their actions. Therefore, in enterprise blockchains, the ability to comply with regulations and law becomes a very sought-after attribute.

Interoperable

As the enterprise blockchain ecosystem evolves, the need to be able to exchange data between the disparate enterprise and public blockchains also arises. Lack of standardization also alleviates this problem; however, standardization efforts are underway, such as EEA (discussed in the Enterprise blockchain challenges section). There are also interoperability solutions being developed and available for blockchains that allow interoperability between chains, such as ION, Polkadot, and Interledger.

We will discuss interoperability further in Chapter 21, Scalability and Other Challenges.

Integration

No enterprise blockchain is an isolated end-to-end solution. It has to integrate with existing enterprise systems or other off-chain systems that are part of the whole enterprise solution to fulfil business goals. Therefore, enterprise blockchains must provide interfaces for integration. This can be as simple as providing RPC endpoints, or as complex as building blockchain-specific connectors and plugins to integrate with enterprise service bus or other legacy systems—more on this in the Enterprise blockchain architecture section.

Integration with security devices such as Hardware Security Modules (HSMs) is also quite desirable for many enterprise use cases where strict security is required, or due to regulatory or compliance requirements.

Ease of use

Usually, enterprise systems are easy to deploy and use. Deployment in enterprises easy and quick, and often relies on mature frameworks and tools such as Ansible and other proprietary tools, but this is not the case with blockchain.

Deployment of enterprise systems is a well-studied, understood, and mature area. With enterprise orchestration tools and established techniques over the years, enterprise deployment has become easy. However, blockchains are not as easy to deploy as other enterprise systems. With the availability of Blockchain as a Service (BaaS) and deployment automation tools, this is changing. However, there is still some work that needs to be done.

Monitoring

Monitoring using visualization tools plays a vital role in any enterprise solution. Without the ability to monitor and visualize a system, it is almost impossible to ensure the health of the enterprise system. It is also a desirable feature in enterprise blockchain solutions to be able to visualize the blockchain network. Monitoring a blockchain allows an administrator to keep an eye on the network's health and operations. It allows an administrator to monitor and respond to the events of interest, such as a node going down, communication link slowness, a node being unable to sync with the blockchain, and many other scenarios.

Secure off-chain computation

In some scenarios, it is desirable to be able to offload some intensive computation to off-chain systems; for example, if there is a requirement to do some computation that requires High Performance Computing (HPC) resources.

This somewhat overlaps with integration, but it's mentioned here separately because of specific security requirements that the off-chain computations must be provably correct with integrity and authenticity guarantees.

Better tools

Usually, in enterprise systems, there are many supporting tools and utilities packaged with the main product to operate the software. For example, these include administration tools, deployment tools, developer utilities, visualization tools, management tools, and end user tools. Blockchain platforms with better tooling are much desirable because of better user support. Tools such as block explorers, user administration modules, and DApps to manage smart contracts are quite useful. They are gradually becoming more mature as the whole blockchain ecosystem is growing.

Now that we understand the features of enterprise blockchains, we will present a comparison between public and enterprise blockchains to help understand the main differences.

Enterprise blockchain versus public blockchain

In this section, we'll provide a comparison between public and enterprise blockchains. Consider the table shown here, which assesses some points of comparison between the two blockchain types. This is not an exhaustive list; however, we'll touch on the most major points:

Aspect	Public chains	Enterprise chains
Confidentiality	No.	Yes.
Anonymity	No.	Yes.
Membership	Permissionless.	Permissioned via voting, KYC, usually under an enterprise blockchain.
Identity	Anonymous.	Known users.
Consensus	PoW/PoS.	BFT.
Finality	Mostly probabilistic.	Requires immediate/instant finality.
Transaction speed	Slower.	Faster (usually, should be).
Scalability	Better.	Not very scalable, usually due to consensus choice. Usually a much smaller number of nodes compared to public chains.
Regulatory compliance	Not usually required.	Required at times.
Trust	Fully decentralized.	Semi-centralized and managed via consortium and voting mechanisms.
Smart contracts	Not strictly required; for example, in the Bitcoin chain.	Strictly required to support arbitrary business functions.

The preceding table compares several key aspects of public and enterprise platforms. Next, we'll briefly consider some of the use cases of enterprise blockchains.

Use cases of enterprise blockchains

Considering the preliminary considerations, limiting factors, and requirements, which we've discussed so far, of employing an enterprise blockchain in an organization, there are several clear use cases of enterprise blockchains. Some of these standout scenarios are listed as follows:

• Payments
• Supply chain
• IoT
• Insurance
• Healthcare

Evidently, enterprise blockchains have many use cases, including but not limited to payments, insurance, KYC, and monitoring supply chains. We introduced some of these use cases throughout this book, especially in Chapter 1, Blockchain 101, and some in Chapter 19, Blockchain – Outside of Currencies. The use cases discussed in the latter chapter are also applicable to enterprise use cases, such as the Internet of Things scenario, which can be implemented in both public and private blockchains. We will cover some more use cases in the context of the latest developments in Chapter 22, Current Landscape and What's Next.

In the next section, we'll describe enterprise blockchain architecture, which can help us communicate with stakeholders, promote early design decisions, serve as a reusable model for development, build shared understanding, and understand how the system is structured.

Enterprise blockchain architecture

A typical enterprise blockchain architecture contains several elements. We saw a generic blockchain architecture in Chapter 1, Blockchain 101, and we can expand and modify that a little bit to transform it into an enterprise blockchain architecture that highlights the core requirements of an enterprise blockchain. These requirements are mostly driven by enterprise needs and use cases:

Figure 20.1: Enterprise blockchain layered architecture

We'll discuss each of these layers as follows.

Network layer

The network layer is responsible for implementing network protocols such as peer-to-peer (P2P) protocols used for information dissemination.

Protocol layer

This is the actual ledger layer, or blockchain layer, where the core consensus, transaction management, and storage elements are implemented.

Privacy layer

This layer is responsible for providing one of the core features of enterprise blockchain: privacy. There are a number of ways to achieve privacy, including off-chain privacy managers, zero knowledge, and hardware assisted privacy. Hardware-based privacy is usually supported using trusted execution environments (TEEs). On the other hand, software or algorithmic privacy such as zero-knowledge proofs (ZKPs) are also quite common in enterprise blockchains.

Governance layer

This layer is responsible for providing the enterprise grade access control mechanism that controls the consortium network membership. This can either be controlled via on-chain permissioning system implemented in smart contracts, as part of the software client, or can be integrated with existing off-chain enterprise permissioning systems such as Single Sign-On (SSO) or Active Directory (AD).

Integration layer

This layer provides APIs and a mechanism used to integrate with the legacy or existing back-office systems. This can be as simple as an RPC layer providing APIs over RPC or can constitute built-in connectors and plugins for integrating with the enterprise service bus.

The integration layer is responsible for ensuring integration with back-office, legacy, and existing off-chain systems. It is not part of the core protocol but as part of the holistic view of the blockchain end-to-end solution, this layer is vital for delivering business results. While there are many techniques available, a commonly integration framework used in the enterprise environment is Apache Camel. This can also be used in blockchain solutions as it comes with the Ethereum Web3J library component.

Let's provide a quick introduction to Apache Camel, before we move onto other layers of the enterprise blockchain architecture.

What is Apache Camel?

Apache camel is an open source enterprise integration framework. It enables easy integration between various systems by utilizing enterprise integration patterns. It has hundreds of components for different systems such as databases, APIs, and MQs for easy integration between systems.

For example, Web3J connector (Apache Camel Ethereum connector) is a feature-rich connector available in Apache Camel that enables integration between Ethereum chains and other systems.

he Apache Camel Ethereum connector works with Ethereum Geth nodes, Quorum, Parity, and Ganache. It supports JSON RPC API over HTTP and IPC with implementations for different blockchain operations such as net, eth, shh, and so on. It has support for Ethereum filters and Ethereum Name Service (ENS), which can be explored further at https://ens.domains. It has support for JSON RPC API and is also a fully tested (unit and integration) solution.

A generic high-level design using Apache Camel is shown in the following diagram:

Figure 20.2: High-level design of Apache Camel, which enables blockchain integration

In the preceding diagram, we can see several enterprise blockchains connecting to Apache Camel using Apache Camel Ethereum connectors. Also, other systems connect to Apache Camel via their respective connectors. Apache Camel via connectors is responsible for integrating between all these systems. For example, it is entirely possible to use Apache Camel to take data from enterprise blockchains and store it in traditional SQL databases in the enterprise via suitable connectors.

Now, let's return to our discussion on the enterprise blockchain layers and introduce the application layer.

Application layer

The application layer, as the name suggests, consists of DApps, smart contracts, tools, and other relevant software to support enterprise use cases.

Security, performance, scalability, monitoring

On the left-hand side in the architecture diagram (Figure 20.1), security, scalability, performance, and monitoring is shown. As each layer in the enterprise blockchain benefits from and indeed requires security, scalability, and performance, this layer is shown as encompassing all layers. Monitoring also plays a vital role in any enterprise solution. Without effective visualizations in such complex networks, it is almost impossible to keep track of everything. Therefore, this layer is shown as relevant to all enterprise blockchain layers.

Now that we understand the architecture of enterprise blockchains in general, let's dive a little bit deeper into the mechanics of designing enterprise blockchain solutions. In the next section, we'll see which tools and frameworks we can use to build enterprise solutions.

Designing enterprise blockchain solutions

An isolated blockchain in an enterprise is not sufficient enough to solve business problems. In addition to choosing a blockchain platform, there are some other factors to consider while introducing a blockchain in an enterprise. On top of the list of these factors is integration with the existing back-office and legacy systems.

There are already established and mature frameworks like The Open Group Architecture Framework (TOGAF) Zachman Framework to facilitate enterprise architecture development. With the advent of enterprise blockchain technology, a question arises regarding whether we can leverage existing frameworks to address enterprise blockchain architectural needs. The answer is yes.

In the section, we'll look at TOGAF and its architecture development method (ADM), and consider how blockchain solutions can benefit from the TOGAF framework.

Without any architecture framework, it becomes quite challenging to have a holistic view of an enterprise and see how all business processes fit together. To address this challenge, we can use enterprise architecture frameworks.

The purpose of enterprise architecture frameworks is to enable an organization to execute its business strategy effectively. It allows an organization to see an organization from different perspectives, including business, information, process, and technology, and make effective business decisions to achieve business goals.

Let's now explore the popular enterprise architecture framework, TOGAF.

TOGAF

TOGAF stands for The Open Group Architecture Framework. It is developed by the Open group.

It is a framework that enables organizations to systematically design, plan, and implement enterprise solutions in businesses. It has four architectural domains.

Business architecture domain

This domain defines the business strategy, organization structure, business processes, and governance of the organization.

Data architecture domain

This domain describes structures of an organization's data assets and relevant data management resources.

Application architecture domain

This domain describes the enterprise applications, deployment blueprints, relationships, and interactions between applications, along with the relationships these applications have with business processes within the enterprise.

Technology architecture domain

This domain defines the requirements of the technical architecture implementation of the enterprise applications. This includes the description of hardware, software, middleware, and network infrastructure required for implementation of the enterprise applications.

Now, re-examining each domain with blockchain in mind, we can include blockchain at each layer and make decisions such as business requirements, the application architecture, logical and physical data assets, and finally the infrastructure required for implementing the enterprise blockchain solution.

After this basic introduction to TOGAF, let's dive a bit deeper to understand the method TOGAF uses to develop an IT architecture.

Architecture development method

TOGAF ADM is a method for developing IT architecture that meets organizational business needs. It describes the process of moving from the foundational TOGAF architecture to an organization-specific architecture. This is an iterative process with continuous requirements management, which results in the development of an architecture that is specific to an organization and addresses specific needs. Once the architecture development is complete, the architecture can be published throughout the organization to develop a common understanding.

The ADM is a tested and repeatable process for developing enterprise architectures. The process follows the following steps: establish architecture framework, develop architecture content, architecture governance, and implementation of architectures.

The ADM has nine phases and each phase can be further divided into multiple steps. The ADM is model is shown here:

Figure 20.3: ADM model

Now, we'll describe each phase in more detail.

Preliminary phase

This phase defines the groundwork of the architecture. It defines methodologies, architecture principles, the architecture scope, and assumptions about the architecture. It also defines the responsible parties for architecture delivery.

From a blockchain perspective, we can define the overall blockchain strategy in this phase.

Architecture vision

This phase validates business principles, goals, and the business strategy. It defines key business requirements, as well as a high-level description of the business value expected from the architecture work. This phase also analyzes the impact of the new architecture on other processes.

Business architecture

This phase proposes the baseline business architecture and develops a target business architecture, along with gap analysis.

In a blockchain scenario, we can define the current state architecture and target state architecture at this stage.

Information systems architecture

This phase defines the data architecture and application architecture. The data architecture includes building the baseline data architecture, data architecture description, building data architecture models, doing impact analysis review reference models, and viewpoints. Application architecture defines the baseline application architecture, builds application architecture models, and proposes applications. Both of these activities also perform gap analysis to validate the architecture being developed, as well as to find any shortfalls between the baseline architecture and the target architecture.

Similar to the business architecture, for an enterprise blockchain solution, we can define the current state architecture and target state architecture.

Technology architecture

This phase is primarily concerned with reviewing the baseline business, data, and application architecture and building a baseline description of the current technology architecture in the enterprise. It also proposes the target technology architecture.

In this phase, we can propose a target enterprise blockchain platform and the target solution.

Opportunities and solutions

This phase performs evaluations and selects various proposed target architectures. Also, an implementation strategy and plan are proposed at this stage. We can apply this to blockchain in a similar fashion, by evaluating or selecting the target architecture encompassing enterprise blockchain solutions.

When evaluating blockchain solutions, a number of features that we presented earlier in the comparison between enterprise blockchain and public blockchain can also be used; for example, confidentiality, scalability, and finality.

Migration planning

This phase creates and finalizes the comprehensive implementation plan for migrating to the target architecture from the current architecture.

Implementation governance

This phase deals with the implementation of the target architecture. A strategy to govern the overall deployment and migration is developed here. We can also perform blockchain solution testing and devise a deployment strategy during this phase.

Architecture change management

This phase is responsible for creating change management guidelines and procedures for the newly implemented target architecture. From a blockchain perspective, this phase can provide change management procedures for the newly implemented enterprise blockchain solution.

With this, we've completed our introduction to TOGAF and explored the idea that enterprise blockchain solutions should be viewed through the lens of the enterprise architecture.

The fundamental idea to understand here is that enterprise blockchain solutions are not merely a matter of quickly spinning up a network, creating a few smart contracts, creating a web frontend, and hoping that it will solve business problems. This setup may be useful as a PoC or for an incredibly simple use case but is certainly not an enterprise solution. We suggest that an enterprise blockchain solution must be looked through the lens of the enterprise architecture and regarded as a full grade enterprise solution. This is so that we can effectively achieve the business goals intended to be solved by enterprise blockchain solutions.

Next, let's explore how we could implement a blockchain business solution in an organization that has moved its operations to the cloud.

Blockchain in the cloud

Cloud computing provides excellent benefits to enterprises, including efficiency, cost reduction, scalability, high availability, and security. Cloud computing delivers computing services such as infrastructure, servers, databases, and software over the internet. There are different types of cloud services available; a standard comparison is made between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). A question arises here: where does blockchain fit in?

Blockchain as a Service, or BaaS, is an extension of SaaS, whereby a blockchain platform is implemented in the cloud for an organization. The organization manages its applications on the blockchain, and the rest of the software management, infrastructure management, and other aspects such as security and operating systems are managed by the cloud provider. This means that the blockchain's software and infrastructure are provided and maintained by the cloud provider. The customer or enterprise can focus on their business applications without worrying about other aspects of the infrastructure.

The following is a comparison of different approaches:

Figure 20.4: Cloud solutions

BaaS can be thought of as a SaaS, where the software is a blockchain. In this case, just like in SaaS, all services are externally managed. In other words, customers get a fully managed blockchain network on which they can build and manage their own DApps. Note that in the preceding diagram, under the Blockchain as a Service column, Applications have been replaced with Blockchain, as a differentiator between other cloud services and BaaS. Here, blockchain is the software (application) provided and managed by the cloud service provider. Also, note that DApps have been added on top, which are managed by the enterprise internally.

There are many BaaS providers. A few of them are listed as follows:

• AWS: https://aws.amazon.com/blockchain/
• Azure: https://azure.microsoft.com/en-gb/solutions/blockchain/
• Oracle: https://www.oracle.com/uk/application-development/cloud-services/blockchain-platform/
• IBM: https://www.ibm.com/uk-en/cloud/blockchain-platform

In the next section, we'll introduce some enterprise blockchain platforms.

Currently available enterprise blockchains

As this is a very ripe area for research, and indeed the market is very active in this space, there have been several enterprises blockchain solutions developed and made available in the last few years. Notably, the year 2019 has been called "the year of the enterprise blockchain" as many startups and enterprises focused on this area emerged.

In this section, we will not cover all these platforms in detail, but will provide a brief introduction and links to more details on these chains.

Corda

Corda is an open source distributed ledger platform intended for businesses. It supports privacy and assured identity, making it scalable and interoperable. We'll explore Corda in more detail later in this chapter.

Quorum

Quorum is an open source enterprise blockchain platform. It aims to support enterprise business needs and allows a business to achieve business goals (and unlock economic value) by leveraging blockchain technology. It addresses crucial enterprise requirements including privacy, performance, and enterprise permissioning. We will also explore Quorum in greater detail later in this chapter.

Fabric

Fabric is a Hyperledger project. It is an enterprise-grade distributed ledger that allows the development blockchain solutions with a modular architecture. It has a permissioned architecture, support modularization, pluggable consensus, and supports smart contracts.

We discussed Hyperledger and other projects under it, such as Sawtooth, in detail in Chapter 17, Hyperledger.

Autonity

Autonity is an Ethereum-based protocol. It enables permissioned, decentralized, and interoperable enterprise networks. More information can be found here: https://www.autonity.io/.

In the next section, we'll provide a comparison of three leading enterprise distributed ledger platforms.

Comparison of main platforms

In this section, we'll provide a comparison of leading enterprise blockchain platforms. We'll cover most of the desirable features of enterprise blockchains. This can be used as a reference for a quick comparison between these platforms. This comparison is based on the current implementations of these platforms available at the time of writing. However, as this is a very rapidly changing area, some features may change over time or new features might be added or improved:

Feature	Quorum	Fabric	Corda
Target industry	Cross-industry	Cross-industry	Cross-industry
Performance (approximate transactions per second, or TPS)	700 (*)	560 ()	600 (@)
Consensus mechanism	Pluggable multiple Raft, IBFT, PoA	Pluggable Raft	Pluggable, notary-based
Tooling	Rich enterprise tooling	SDKs	Rich enterprise tooling
Smart contract language	Solidity	Golang	Kotlin/Java
Finality	Immediate	Immediate	Immediate
Privacy	Yes (restricted private transactions)	Yes (restricted private transactions)	Yes (restricted private transactions)
Access control	Enterprise-grade permissioning mechanism	Membership service provides/certificate based	Doorman service/KYC. Certificate-based
Implementation language	Golang, Java	Golang	Kotlin
Node membership	Smart contract and node software managed	Via membership service provider	Node software managed using configuration files, certificate authority controlled
Member identification	Public keys/addresses	PKI-based via membership service provider, supports organization identity	PKI-based, support organization identity
Cryptography used	SECP256K1 AES CURVE25519 + XSALSA20 + POLY13050 PBKDF2 SCRYPT	SECP256R1	ED255519 SECP256R1 RSA – PKCS1
Smart contract runtime	EVM	Sandboxed in Docker containers	Deterministic JVM
Upgradeable smart contract	Possible with some patterns, not inherently supported	Allowed via upgrade transactions	Allowed via administrator privileges and auto update allowed under administrative checks
Tokenization support	Flexible—inherited from public Ethereum standards	Programmable	Corda token SDK

This comparison may also be used for the quick evaluation of these platforms and suitability for an enterprise use case.

Now that we've examined some requirements, architectures, and use cases of enterprise blockchain, let's briefly describe some of the challenges that still face this technology in practice.

Enterprise blockchain challenges

While enterprise blockchains have addressed core enterprise requirements (privacy, performance, and governance) to some extent, there are still more challenges that need to be addressed. There is significant progress being made toward solving these issues. However, there is still a lot of work required to be done to adequately address these limitations. Some of these limitations are listed as follows.

Interoperability

Blockchain solutions are built by different development teams with different targets requirements. As a result, there are now many different types of blockchains, ranging from cryptocurrency public blockchains to application-specific blockchains, which are developed for a single business application. Data exchange between these chains is a crucial concern. While blockchain networks continue to grow independently, integration and interoperability between these chains remains a big concern.

This problem also stems out from lack of standardization. If a standard specification is available, then all chains following that standard will become compatible automatically. However, what about those chains that are already deployed in production, including public chains? How do we achieve interoperability between them? Many business use cases have the requirement to get data from one organization to another or from one blockchain network to another. This is also true in the case of data exchange requirements between a public blockchain and consortium network.

Lack of standardization

Lack of standardization is a commonly highlighted concern in enterprise blockchains and generally in the blockchain ecosystem. Traditional systems are mostly developed in line with standards defined by standards bodies such as NIST FISMA standards for information security.

Standards are also essential to achieving interoperability. Several initiatives have been taken to address the challenges mentioned here and also to standardize enterprise blockchain platforms. A leading organization in this field is EEA, Saving a couple of lines here: deleted section heading and joined two small sections. Please link up the sentence on the previous page with this one: "...in this field is EEA, a standards organization run by its members that aims to develop enterprise blockchain specifications.

Compliance

There are various compliance requirements, in almost all industries—especially finance, law, and health—where strict guidelines and rules have been mandated by regulatory authorities. Enterprise systems are expected to conform to these requirements. Blockchain initially started with a different focus of building an electronic cash system with egalitarian philosophy. Still, surely enterprises have a different vision and mindset. Some of the regulations include GDPR, SOX, and PCI, which define different requirements for an enterprise to conform to. Also, compliance with technical standards such as the NIST FISMA standard for information security is necessary.

There are also jurisdiction issues. A distributed network with geographically dispersed locations may require different legal requirements to be met in various jurisdictions. For example, a specific type of cryptography may be allowed by law in the US but not in Cuba.

Business challenges

From a business perspective, cost, funding, and governance are some of the challenges that need to be met. If building and implementing an enterprise blockchain solution is prohibitively costly, then the business stakeholder might prefer traditional enterprise systems. Also, from an operational perspective, training staff to operate blockchain solutions might be a concern. We can categorize all blockchain-related costing, funding, and economics under an umbrella term that we call Enterprise Blockonomics. Enterprise Blockonomics, (blockchain economics) can be defined as a study of cost and cost models in the context of enterprise blockchains.

With that, we have covered a lot of background material and developed an understanding of the enterprise blockchain requirements, architecture, and challenges. Let's now dive into some examples of enterprise blockchain platforms. First, we'll discuss Corda and then Quorum.

Corda

Corda is not a blockchain by definition because it does not use blocks for batching transactions. Still, it is a distributed ledger, and provides all benefits that a blockchain can. Traditional blockchain solutions have the concept of transactions that are bundled together in a block, and each block is linked back cryptographically to its parent block, providing an immutable record of transactions. This is not the case with Corda.

Corda has been designed entirely from scratch with a new model for providing all blockchain benefits, but without a traditional blockchain with blocks. It was developed initially for the financial industry to solve issues arising from each organization managing its own local ledgers. This means that each organization has its own "view of truth." This situation often leads to contradictions and operational risk. Moreover, data is also duplicated at each organization, which results in an increased cost of managing individual infrastructures and complexity. These are the types of problems within the financial industry that Corda initially aimed to resolve by building a decentralized database platform. Initially, Corda only focused on financial applications but now has expanded into other areas such as government, healthcare, insurance, and supply chains.

Corda has two implementations, Corda enterprise and Corda open source. Both Corda enterprise and Corda open source are interoperable and compatible with one another, and have the same features. However, the enterprise version is more focused on enterprise requirements. It is a commercial version of the Corda platform targeting business requirements such as privacy, security, and performance. Also, it includes Corda firewall, high availability nodes and notaries, and support for hardware security modules. It provides an enterprise-grade platform for use in businesses.

The Corda platform, on the other hand, allows direct transactions between businesses. This network provides benefits such as privacy and ready sharing of data, which results in the reduction of complexity and costs.

The Corda source code is available at https://github.com/corda/corda. It is written in a language called Kotlin, which is a statically typed language targeting the Java Virtual Machine (JVM).

Architecture

The main components of the Corda platform include the Corda network, state objects (contract code and legal prose), transactions, consensus, and flows. We will explore these in more detail now.

Corda network

The Corda network is defined as a fully connected graph. It is a permissioned network that provides direct P2P communication on a "need to know" basis. Unlike other traditional blockchains/distributed ledgers, there is no global broadcast or a gossip protocol. The communication occurs directly on a point to point basis between interested parties. Peers or nodes communicate using the AMPQ serialization protocol. A service called network map service is responsible for publishing a list of peers.

A high-level architecture diagram of the Corda network is shown here, showing different components:

Figure 20.5: Corda high-level network architecture

State objects

State objects represent the smallest unit of data that constitute a financial agreement. These objects are digital documents that describe and fully capture all information about a shared agreement between parties. They are created or deleted as a result of transaction execution. State objects refer to the contract code and legal prose.

Legal prose is optional and provides legal binding to the contract. However, contract code is mandatory to manage the state of the object. It is required to provide a state transition mechanism for the node, according to the business logic defined in the contract code. State objects contain a data structure that represents the current state of the object. A state object can be either current (live) or historic (no longer valid).

For example, in the following diagram, a state object represents the current state of the object. In this case, it is a simple mock agreement between Party A and Party B where Party A has paid Party B 1,000 GBP. This represents the current state of the object; however, the referred contract code can change the state via transactions. State objects can be thought of as a state machine, which is consumed by transactions to create updated state objects:

Figure 20.6: An example state object

States define the facts regarding which the agreement is achieved.

Transactions

Transactions are used to perform transitions between different states. For example, the state object shown in the preceding diagram is created as a result of a transaction. Corda uses a Bitcoin-style UTXO-based model for its transaction processing. The concept of state transition by transactions is the same as in Bitcoin. Similar to Bitcoin, transactions can have single, multiple, or no inputs, and single or multiple outputs. All transactions are digitally signed.

Moreover, Corda has no concept of mining because it does not use blocks to arrange transactions in a blockchain. Instead, notary services are used to provide a temporal ordering of transactions. In Corda, new transaction types can be developed using JVM bytecode, which makes it very flexible and powerful.

Consensus

The consensus model in Corda is quite simple and is based on notary services, which will be discussed in the Corda section of this chapter, under Components. The general idea is that the transactions are evaluated for their uniqueness by the notary service and, if they are unique (that is, unique transaction inputs), they are signed by consensus services as valid. There can be single or multiple clustered notary services running on a Corda network. Various consensus algorithms like PBFT or Raft can be used by notaries to reach consensus, but the core idea is to check whether a proposed transaction is a valid update for the ledger or not.

There are two types of consensus in Corda: validity consensus and uniqueness consensus.

Validity consensus

This ensures that:

• The contract of every input and output state accepts the proposed transaction
• The transaction possesses all required signatures

Note that this process doesn't just verify the proposed transaction itself. It also verifies every previous transaction in the entire chain of the transactions. In other words, it validates all transactions behind this transaction that ultimately resulted in the creation of the inputs of the proposed transactions. This is called "walking the chain".

Uniqueness consensus

This provides validity consensus over the state's validity, and consensus over state uniqueness. The first mechanism is concerned with the validation of the transaction, ensuring that all required signatures are available and the states are appropriate. The second mechanism is a means to detect double-spend attacks and ensures that a transaction has not already been spent and is unique. Uniqueness consensus is only checked by a notary service. In contrast, validity consensus is verified by each required signer before signing the transaction. This ensures that none of the input of a proposed transaction has already been spent (consumed) in another transaction.

Flows

Flows in Corda are a novel idea that allows the development of decentralized workflows. All communication on the Corda network is handled by these flows. These are transaction building protocols that can be used to define any financial flow of any complexity using code. Flows run as an asynchronous state machine, and they interact with other nodes and users. During their execution, they can be suspended or resumed as required.

CorDapps

The core model of Corda consists of state objects (data), transactions, and transaction protocols that, when combined with contract code (allowed operations), APIs, wallet plugins, and user interface components, result in constructing a Corda distributed application.

A CorDapp (Corda Distributed Application) is a distributed application that runs on a Corda network. It allows nodes on the network to reach an agreement regarding updates to the ledger. For this purpose, flows are defined that describe a routine for the node to execute.

Smart contracts in Corda are written using Kotlin and/or Java. The code is targeted at the JVM. The JVM in Corda has been modified to achieve deterministic results of the execution of JVM bytecode. There are three main components in a Corda smart contract, as follows:

• Executable code, which defines the validation logic to validate changes to the state objects.
• State objects represent the current state of a contract and can either be consumed by a transaction or produced (created) by a transaction.
• Commands are used to describe the operational and verification data that defines how a transaction can be verified.

In this section, we saw that a CorDapp is a distributed application that can be developed in Kotlin or Java and runs on a Corda network. CorDapps provide a mechanism for nodes to reach an agreement. Next, we'll explore some of the components required in the Corda network.

Components

The Corda network has multiple components. These components are described as follows.

Nodes

A node is a JVM runtime with a unique identity on the network. It has a network layer that allows interaction with other nodes and an RPC interface that will enable the node's owner to interact with it. A node hosts CorDapps and Corda services.

Nodes in a Corda network operate under a trustless model and are run by different organizations. Each node has an agreed and verified IP address. IP addresses belong to organizations who run nodes and also go through a KYC process. Nodes run as part of an authenticated P2P network and communicate directly with one another using the Advanced Message Queuing Protocol (AMQP). AMPQ is an approved international standard (ISO/IEC 19464) and ensures that messages across different nodes are transferred safely and securely. AMQP works over Transport Layer Security (TLS) in Corda, thus ensuring privacy and integrity of data communicated between nodes.

Nodes also make use of a local relational database for storage. Messages on the network are encoded in a compact binary format. They are delivered and managed by using the Apache Artemis message broker (Active MQ).

A node can serve as a network map service, notary, oracle, or a regular node. The following diagram shows a high-level view of a Corda node:

Figure 20.7: Simplified Corda node architecture

The key elements of a Corda node are:

• A Persistence layer, which consists of a vault and storage service. It is responsible for storing data in a local SQL database.
• A Network interface, which enables communication with other nodes as part of running a flow.
• An RPC interface is responsible for providing interface for interaction with the node's owner via RPC clients and/or web servers. It exposes a number of RPC operations for node and flow management, administration, and retrieving information about flows, nodes, and the network.
• A Service hub enables flows in the node to call other services (utilities in a node) such as storage and vault services.
• A CorDapp interface and provider, which allows the extending of a node with CorDapps.

Next, we'll discuss the permissioning element of Corda, which controls network membership.

The permissioning service

The permissioning service Doorman is used to provision TLS certificates for security. Participants are required to have a signed identity issued by a root certificate authority to participate in the network. Identities are required to be unique on the network. The permissioning service is used to sign these identities, and the naming convention applied to recognize participants is based on the X.500 standard. This ensures the uniqueness of the name. Doorman is responsible for performing KYC and permitting nodes to join and use the network.

Network map service

This service is used to provide a network map in the form of a document of all nodes on the network. This service publishes IP addresses, identity certificates, and a list of services offered by nodes. All nodes announce their presence by registering to this service when they first start up, and when a connection request is received by a node, the presence of the requesting node is checked on the network map first. Put another way, this service resolves the identities of the participants to physical nodes.

Notary service

In traditional blockchains, mining is used to ascertain the order of blocks. In Corda, notary services are used to provide transaction ordering and timestamping services. There can be multiple notaries in a network, and they are identified by composite public keys. Notaries can use different consensus algorithms like BFT or Raft, depending on the requirements of the applications. Notary services sign the transactions to indicate the validity and finality of the transaction, which is then persisted to the database. Notaries can be run in a load-balanced configuration to spread the load across the nodes for performance reasons. The nodes are recommended to be run physically closer to the transaction participants to reduce latency.

Due to the distributed nature of distributed ledgers, there is no exact universal time in the network. Therefore, it is always difficult to say when precisely an event occurred. In Corda, time windows can be used to assert that a transaction happened after a specific event or time. A transaction in Corda can include a time window that enforces timing restrictions on the commitment of the transaction. This means that the transaction can only be notarized and committed during the time window specified in the transaction. The notary can serve as a timestamping authority. Before notarizing a transaction, it can verify that a transaction occurred during a specified time window.

Time windows allow us to build scenarios that can indicate whether a transaction happened before an event or after a specific time. This can be useful in constructing scenarios where we can say, for example, a transaction happened after the expiry of a contract or after some event or on a specific day. It is important that a notary has an accurate and valid time feed for this function to work correctly.

Oracle service

Oracle services either sign a transaction containing a fact if it is true or can themselves provide factual data. They allow real-world feed into the distributed ledgers. Oracles were discussed in Chapter 10, Smart Contracts.

Transactions

Transactions in a Corda network are never transmitted globally but in a semi-private network. They are shared only between a subset of participants who are related to the transaction. This is in contrast to traditional blockchain solutions like Ethereum and Bitcoin, where all transactions are broadcast to the entire network globally. Transactions are digitally signed and either consume state(s) or create a new state(s).

Transactions on a Corda network are composed of the following elements:

• Input references: This is a reference to the states the transaction is going to consume and use as an input.
• Output states: These are new states created by the transaction.
• Attachments: This is a list of hashes of attached ZIP files. ZIP files can contain code and other relevant documentation related to the transaction. Files themselves are not made part of the transaction; instead, they are transferred and stored separately.
• Commands: A command represents the information about the intended operation of the transaction as a parameter to the contract. Each command has a list of public keys, which represents all parties that are required to sign a transaction.
• Signatures: This represents the signature required by the transaction. The total number of signatures required is directly proportional to the number of public keys for commands.
• Type: There are two types of transactions, namely normal and notary changing. Notary changing transactions are used for reassigning a notary for a state.
• Timestamp: This field represents a bracket of time during which the transaction has taken place. These are verified and enforced by notary services. Also, it is expected that if strict timings are required, which is desirable in many financial services scenarios, notaries should be synchronized with an atomic clock.
• Summaries: This is a text description that describes the operations of the transaction.

Vaults

Vaults run on a node and are similar to the concept of wallets in Bitcoin. As the transactions are not globally broadcasted, each node will have only that part of data in their vaults that are considered relevant to them. Vaults store their data in a standard relational database and, as such, can be queried by using standard SQL. Vaults can contain both on the ledger and off ledger data, meaning that it can also have some part of the data that is not on the ledger. Vaults keep track of spent and unspent states.

Other tools

Other important tools in Corda are described as follows.

Application firewall

This is an enterprise feature that operates like a reverse proxy and helps to run Corda behind corporate firewalls. It is an optional component that acts as a reverse proxy for Corda nodes residing behind the demilitarized zone (DMZ), which is usually the case in an enterprise.

The application firewall helps to minimize the amount of code that runs on a network's DMZ, thus reducing the attack surface. It enables secure AMQP/TLS1.2 interaction with Corda peer nodes outside the corporate network. It works as an application-level firewall for internet-facing endpoints on the Corda network.

The firewall has two components, called the bridge and the float. The bridge handles outbound connections, whereas the float handles the inbound connection. A single instance of the Corda firewall can serve multiple nodes.

Network simulator

This is a visualization tool that shows traffic between nodes and the network set up via a map service.

Node explorer

This is another visualization tool that allows us to view transaction information.

Load tester

This, as the name suggests, helps to stress test nodes under various extreme scenarios.

Transaction flow

In this section, we'll explore how, when a request is sent to a node, Corda accepts the request and responds. The flow process can be summarized as follows:

1. An HTTP request via API or RPC call is made directly to flows in Corda. This is a request to start a transaction.
2. Start a flow. Flows contain the business logic.
3. Perform initial steps such as transaction building and verification.
4. Obtain counterparty signatures.
5. Sign the transaction and check signatures.
6. Obtain notarization/finality.
7. Record the transaction and store it in persistent storage and Vaults.
8. Respond via an HTTP response through API.

This process can be visualized using the following diagram:

Figure 20.8: Node high-level flow

A CorDapp is a functional aspect of the Corda network and contains the business logic for a use case. The vault (database) is used to store states via JDBC. Corda nodes communicate using AMQP/TLS1.2. Node administrators use SSH to interact with the node. An identity certificate is issued to a node via the Doorman service, which works over HTTPS. Corda nodes discover other nodes on the network via the network map service over HTTPS. Corda nodes and the Corda firewall service make sure that a certificate is currently valid by checking CRLs, which is performed over an HTTP or HTTPS connection.

Now, let's see how we can set up a development environment to explore Corda's code base. We have not provided any specific development application but have provided links where official examples are available.

Corda development environment

The development environment for Corda can be set up easily using the following steps. The required software consists of the following:

• JDK 8 (8u131), which is available at http://www.oracle.com/technetwork/java/javase/downloads/index.html.
• IntelliJ IDEA Community edition, which is free and available at https://www.jetbrains.com/idea/download.
• H2 database platform independent ZIP, and is available at http://www.h2database.com/html/download.html.
• Git, which is available at https://git-scm.com/downloads.
• Kotlin language, which is available for IntelliJ. More information can be found at https://kotlinlang.org/.
• Gradle is another component that is used to build Corda. It is available at https://gradle.org.

Once all these tools are installed, smart contract development can be started:

• CorDapps can be developed by utilizing an example template available at https://docs.corda.net/docs/corda-os/4.5/hello-world-template.html
• Detailed documentation on how to develop contract code is available at https://docs.corda.net/.

Corda can be cloned locally from GitHub using the following command:

$ git clone https://github.com/corda/corda.git

Once entered in the operating system terminal, this command will clone the repository into a local directory named corda.

Once the repository is cloned, it can be opened in an IntelliJ development environment for further development. There are multiple samples available in the repository, such as a bank of Corda, interest rate swaps demo, and traders' demo. You may find it useful to explore these demos to understand how CorDapps are developed. These samples are available under the /samples directory, under corda, and they can be explored using IntelliJ IDEA IDE.

With this, we've completed our introduction to the Corda platform. Now, we'll cover Quorum, another popular blockchain platform, in detail.

Quorum

Quorum is an open source enterprise blockchain platform. It is a lightweight fork of Ethereum. Quorum not only benefits from the innovation and research being done in the upstream public Ethereum (Geth) project, but also many excellent enterprise features have been introduced in Quorum. These enterprise features primarily focus on providing enterprise-grade privacy, performance, and permissioning (access control).

In this section, we'll explore Quorum's architecture in detail and see a practical example of how to set up a Quorum network. First, let's take a look at Quorum's architecture.

Quorum addresses three fundamental issues in public blockchains, which makes Quorum an excellent choice for enterprise use cases:

• Privacy
• Performance
• Enterprise governance

At a high level, the Quorum architecture consists of nodes and their associated privacy managers. The Quorum node is a modified and enhanced version of public geth that supports private transactions. Quorum nodes communicate via HTTPS with privacy managers, who, in turn, are responsible for providing privacy by storing the payload in encrypted format in their local storage. These Quorum nodes maintain the public and private states separately.

Architecture

The Quorum architecture can be visualized using the following diagram:

Figure 20.9: Quorum architecture

There are a number of changes that have been made to Quorum client to make it suitable for enterprise use cases. We'll provide an overview of each of those changes here.

Enhanced P2P

This layer is modified to allow connections only between authorized nodes.

Enhanced state (private and public)

In addition to the public state trie, there is an additional Merkle Patricia state trie for the private state.

Pluggable consensus

Quorum supports multiple consensus algorithms such as IBFT, Proof of Authority (PoA), and Raft. Quorum, being an enterprise blockchain, does not need a PoW type of consensus.

No transaction fees

The pricing of gas has been set to zero as there is no need for transaction fees in consortium networks.

Private transactions

Private transactions are identified using 37 or 38 as the V value in the transaction. The transaction creation mechanism is modified to enable replacing transaction data (input) with the hash of the encrypted payload.

Modified block generation mechanism

The logic for generating blocks is modified with a new check for the global public state root instead of the global state root.

Modified block validation mechanism

Block validation logic is modified to replace the global state root check with a global state root check for public state—otherwise known as a global public state root.

Enhanced RPC API

Quorum supports additional RPC APIs that help us interact with the enhanced enterprise features of Quorum, such as permissioning and consensus mechanisms.

Now, we'll discuss privacy manager, which consists of two components: a transaction manager and an enclave.

Privacy manager

Privacy manager is an off-chain mechanism that provides transaction confidentiality. It is paired on a one-to-one basis with a Quorum node. It allows Quorum nodes to share the transaction payload securely between authorized participants. It is composed of two components: the transaction manager and the enclave.

Transaction manager

The transaction manager is responsible for:

• Storing encrypted transaction payloads
• Managing access to encrypted transaction payloads
• Propagating encrypted payloads to other transaction managers on the network
• Discovering other transaction managers on the network

Quorum has developed two transaction managers. Initially, a Haskell implementation called Constellation was made available. However, it is no longer actively developed in favor of a more feature-rich, Java-based privacy manager called Tessera. Tessera is developed in Java. It is used for storage, encryption, decryption, and propagation of private transaction data.

Enclave

An enclave is an isolated and independent element that provides cryptography services for transaction payload encryption and decryption. It can only be associated on a one-to-one basis with its own transaction manager.

In order to achieve all the desired privacy features, several cryptographic protocols and primitives have been used in the Quorum platform. We'll provide a quick overview of these in the next section.

Cryptography used in Quorum

Quorum inherits its cryptography stack from public Ethereum. It includes standard ECDSA signatures, AES CTR cryptography for wallets and DEVP2P, and Keccak256 hash functions. Privacy manager makes use of Curve25519, Elliptic-curve Diffie-Hellman (ECDH), poly1305, and Xsalsa20 cryptographic operations to provide confidentiality guarantees required by private transactions in Quorum.

Now, we'll explore how each of the main facets—privacy (confidentiality), enterprise-grade membership control (access control, and the permissioning mechanism), and performance—are achieved in Quorum.

Privacy

Quorum supports both private and public transactions. For private transactions, it uses a mechanism called private transaction manager, which is an off-chain component to facilitate the confidentiality of transactions. We will now describe how private transactions work in Quorum.

Suppose there are three parties: A, B, and C. Parties A and B are privy to a transaction, while party C is not. We'll now explore how the private transaction is generated and flows between parties and propagated on the network, while maintain confidentiality. Let's call this transaction transaction AB:

1. To begin private transaction AB, party A creates a transaction and signs it before sending it to their Quorum node, node A. The transaction is composed of a transaction payload and the public key of the intended recipient. This list of public keys of intended recipients is maintained in the PrivateFor list. It can be a single public key or multiple, depending on the requirements.

   There are two signing mechanisms in Quorum. For public transactions, an EIP55-based mechanism is used and for private transactions, an Ethereum Homestead signing mechanism is used. Transactions in Quorum can also be signed independently, without using Quorum's signing mechanism.

2. Quorum node A sends the transaction to transaction manager A for processing.
3. Transaction manager A makes an encryption request to its enclave, to encrypt the transaction payload.
4. Party A's enclave encrypts the transaction payload and sends it to transaction manager A.
5. Transaction manager A stores the transaction payload and sends it to other transaction managers; in this case, B.
6. A transaction hash is returned to Quorum node A by transaction manager A, which replaces the original transaction payload with the hash and changes the value V of the transaction to 37 or 38 to indicate that the transaction is private.
7. The transaction propagates to other nodes via the normal Ethereum P2P protocol.
8. The block that contains transaction AB finalizes and propagates on the network between all nodes (A, B, and C).
9. When the block containing the transaction is received by the Quorum nodes, they recognize the transaction as private because the V value of the transaction is either 37 or 38. If the transaction is identified as private, the Quorum nodes will inquire their respective transaction managers to figure out if they are party to the transaction or not. This is achieved by finding out that if there is an entry available in the database with the transaction hash. Here, parties A and B will have the transaction hash stored in the transaction manager, whereas party C will not.
10. The transaction managers of parties A and B make a transaction payload decryption request to their respective enclaves.
11. The enclaves of party A and B decrypt the private transactions.
12. When the transaction managers receive the decrypted payload back from their enclaves, they send this data to their respective Quorum nodes. In our example, the transaction managers of parties A and B will send the transaction payload to their respective Quorum nodes, A and B. The Quorum nodes will execute the transaction (contract) via the EVM and update their private state database accordingly. The transaction manager of party C will return a message back to its Quorum node, indicating that it is not privy to (or a recipient of) the transaction. This means that the Quorum node of party C will simply ignore the transaction.

This process can be visualized using the following diagram:

Figure 20.10: Quorum private transaction flow

Let's now expand on step 4 from the achieving privacy process, enclave encryption, as it consists of a number of substeps that are performed within the enclave.

Enclave encryption

When an enclave receives a transaction, it performs several steps to encrypt the transaction. All these steps are shown here and are performed by the enclave as part of the transaction payload encryption process:

1. Generates a symmetric key for transaction.
2. Generates two random nonces.
3. Encrypts the transaction payload and one of the nonces with the symmetric key generated in the first step.
4. Encrypts the transaction key for transactions for each recipient. For this purpose, the following steps are performed:
   1. Generates a shared symmetric key by utilizing ECDH. ECDH will use the sender's private key and the receiver's public key.
   2. Encrypts the symmetric key for transaction for each receiver separately using the newly generated shared symmetric key and the second nonce.
   3. This step will be repeated for each recipient.
5. Finally, the transaction manager receives the encrypted transaction payload, all the encrypted symmetric keys for transactions, both nonces, and the public keys of the senders and receivers.

Now, let's see how the transaction manager stores and propagates transactions to the other transaction manager. We'll now expand on step 5 of the achieving privacy process mentioned previously.

Transaction propagation to transaction managers

A transaction manager performs the following steps after it receives an encrypted response back from the enclave:

1. It generates the SHA3-512 hash of the encrypted payload received from the enclave.
2. It stores the encrypted payload, the hash and encrypted symmetric key for the transaction, both nonces, and the public keys of the sender and receiver.
3. It sends, using HTTPS, the encrypted payload, the hash, and the encrypted symmetric key for the transaction using transaction manager B's public key to transaction manager B.
4. Transaction manager A awaits an acknowledge message from transaction manager B. If acknowledgement is not received, the transaction will not be propagated to the network.

Let's now discover how the decryption process works in enclaves. This corresponds to step 11 of the achieving privacy process.

Enclave decryption

The transaction payload decryption process starts when a transaction payload decryption request is made to an enclave. The enclave performs the following steps to decrypt a payload:

1. Derives the shared symmetric key. The key derivation process works as follows:
   1. Party A, being the sender of the transaction, derives the shared symmetric key using its private key and receivers public key.
   2. Party B, being the recipient of the transaction, derives the shared symmetric key using its private key and the sender's public key.
2. Decrypts the symmetric key for transactions with the shared symmetric key, along with the encrypted payload and nonce, fetched from the database.
3. Decrypts the transaction data with the symmetric key for transactions and the encrypted data and nonce fetched from the database.
4. Finally, the decrypted private transaction data is sent to the transaction manager.

The overall process (enclave encryption, transaction manager storage and propagation to other nodes, and enclave decryption), corresponding to steps 4, 5, and 11 in Figure 20.10, can be visualized in the following diagram:

Figure 20.11: Enclave and transaction manager high-level architecture

We've covered quite a lot of theory here, but with this, we have now completed our introduction to Quorum private transactions. Next, we'll explore how access control works in Quorum.

Access control with permissioning

As an enterprise blockchain platform, Quorum comes with an enterprise-grade access control mechanism that manages network membership for consortium members. It is implemented in smart contracts written in the Solidity language. It supports many features that a typical enterprise-grade permissioning mechanism would. It includes features to support the management of nodes, account-level permissioning, and support for voting-driven decision-making for permissioning actions.

The overall architecture of Quorum's permissioning mechanism can be visualized using the following diagram:

Figure 20.12: Quorum permissioning mechanism

This permissioning mechanism is inspired by a widely accepted industry standard called Role-Based Access Control (RBAC). It is standardized by the American National Standards Institute (ANSI) and is used in most enterprise-grade software, such as operating systems and cloud systems.

The features that Quorum's permission mechanism supports are listed here:

• Role management
• Assignment of roles to accounts (subjects)
• Permissions management
• Node management

At a fundamental level, the permissions management model supports granular control over:

• Funds transfer
• Smart contract creation
• Smart contract execution

It controls which account can transfer funds, create smart contracts, or execute smart contracts. These permissions are used to create roles, which are then assigned to accounts to enforce permissions.

Permissions are divided into two broad categories: account permissions, which control what functions an account can perform, and node permissions, which control membership of nodes on the network.

Accounts can be assigned with different roles and statuses, whereas nodes can be assigned with statuses. Statuses for accounts include several statuses such as active, inactive, suspended, and blacklisted. Nodes can be in approved, deactivated, pending approval, or blacklisted states. The access types can be read-only, transact, contract deploy, and full access.

Now that we have covered how enterprise-grade permissioning is implemented in Quorum, let's now move on to another important aspect of enterprise blockchain: performance.

Performance

Performance is a vast subject and can mean different things in different scenarios. Mostly, it is merely a measure of how many transactions a system can perform in a given interval, usually measured in transactions per second (TPS). It can also mean overall throughput of the system, quality of the service, and the ability to scale. From a business perspective, it could mean business performance. However, here, we will only deal with the TPS scenario and present some studies that have been performed to evaluate the performance of the Quorum blockchain.

The core idea behind performance enhancement in the Quorum blockchain is the usage of deterministic and fast consensus algorithms. Quorum supports various consensus mechanisms suitable for consortium networks. As compared to other public blockchain consensus mechanisms, the algorithms used in Quorum provide better performance.

Several evaluations have been made and reported regarding Quorum's performance. These studies have reported Quorum's performance to be as high as 2,500 TPS.

Now, we'll introduce the consensus mechanisms supported by Quorum.

Pluggable consensus

Quorum supports several consensus algorithms that can be plugged in, based on use case requirements. For example, if the requirement is simple crash-tolerance, users can choose Raft. If more security is required and Byzantine faults need to be handled, then users can choose IBFT. We have listed the consensus mechanisms available in Quorum here:

• Raft: A crash fault-tolerant consensus algorithm
• IBFT: A PBFT-inspired BFT algorithm
• Clique: Proof of Authority (PoA) inherited from public Ethereum

We discussed all these algorithms in detail in Chapter 5, Consensus Algorithms. You can review these topics in detail there.

Now that we have gone through several features and have built a theoretical understanding of various features of the Quorum enterprise blockchain, let's now see how we can set up a Quorum network.

Setting up Quorum with IBFT

In this section, we will set up a Quorum network with four nodes, demonstrating how an IBFT network can be set up and carry out private transactions in Quorum. These steps can be performed manually, or we can use a tool called Quorum Wizard to quickly and easily spin up a Quorum network.

We will use Quorum Wizard to set up our network.

Quorum Wizard

Quorum Wizard is a command-line tool written in JavaScript that enables users to create a local network of Quorum nodes quickly. It runs as an npm module and, as such, requires Node.js and NPM to run.

Node.js can be installed from this address: https://nodejs.org/en/.

To check the current version installed, issue the following command:

$ npm -v

This command will produce the following output, indicating the installed version of node package manager, npm:

6.14.4

This command will show the currently installed version of node:

$ node –v

This will produce an output specifying the version of node you have installed:

v12.18.0

If the expected version number is displayed after executing both of these commands, then we are all set to install Quorum Wizard, which we'll describe in the next section.

Installing Quorum Wizard

Quorum Wizard can be installed using npm install. It's an excellent tool and cuts installation time down from hours to minutes:

$ npm install -g quorum-wizard

This will show an output similar to the one shown here:

/usr/local/bin/quorum-wizard -> /usr/local/lib/node_modules/quorum-wizard/build/index.js
+ [email protected]
added 155 packages from 143 contributors in 27.897s

Once installed, we can run it with the following procedure.

Running Quorum Wizard to create a new network

We will create a 4-node IBFT network in this example. Simply run Quorum Wizard and follow the steps as prompted:

$ quorum-wizard

Running Quorum Wizard will show the following text:

Figure 20.13: Quorum wizard options

Select Simple network and select all the options by using the up and down arrow keys, as shown here. Press Enter after a choice is made, which will move us on to the next question in Wizard:

Simple Network
? Would you like to generate bash scripts, a docker-compose file, or a kubernetes config to bring up your network? bash
? Select your consensus mode - istanbul is a pbft inspired algorithm with transaction finality while raft provides faster blocktimes, transaction finality and on-demand block creation istanbul
? Input the number of nodes (2-7) you would like in your network - a minimum of 4 is recommended 4
? Which version of Quorum would you like to use? Quorum 2.6.0
? Choose a version of tessera if you would like to use private transactions in your network, otherwise choose "none" Tessera 0.10.2
? Do you want to run Cakeshop (our chain explorer) with your network? Yes
? What would you like to call this network? 4-nodes-istanbul-tessera-bash

Once all the options have been selected, as shown in the preceding code snippet, the tool will download and install dependencies. This process will produce an output similar to the one shown here. For brevity, the full output is not shown:

Downloading dependencies...
.
.
Building network directory...
Generating network resources locally...
Building qdata directory...
Writing start script...
Initializing quorum...
Done

Finally, the output shown here is produced, indicating the success of the operation:

Quorum network created
Run the following commands to start your network:
cd network/4-nodes-istanbul-tessera-bash
./start.sh
A sample simpleStorage contract is provided to deploy to your network
To use run ./runscript.sh public-contract.js from the network folder
A private simpleStorage contract was created with privateFor set to use Node 2's public key: QfeDAys9MPDs2XHExtc84jKGHxZg/aj52DTh0vtA3Xc=
To use run ./runscript private-contract.js from the network folder

Now, change to the 4-nodes-instabul-tessera-bash directory, as shown here, and start the network:

$ cd network/4-nodes-istanbul-tessera-bash
$./start.sh

This will produce an output similar to the one shown here. Some of the output has been truncated for brevity:

Starting Quorum network...
.
.
.
All Tessera nodes started
Starting Quorum nodes
Starting Cakeshop
Cakeshop started at http://localhost:8999
Successfully started Quorum network.

And that's it! We now have a Quorum network with four nodes running on the IBFT protocol. We can also visualize the network using Cakeshop, which we'll describe next.

Cakeshop

Cakeshop is a powerful visualization and administration tool with different features such as node management, block explorer, and contract management. Cakeshop is installed as part of the Quorum Wizard network creation process. Once the network runs successfully, we can browse to http://localhost:8999, where Cakeshop runs.

Cakeshop is shown in the following screenshot:

Figure 20.14: Cakeshop

Now, let's do an experiment to see how private transactions can be created and run on the Quorum network. Quorum Wizard has already created the relevant scripts.

Running a private transaction

In this section, we will explore how private transactions can be created and executed on a Quorum network.

1. From within the 4-nodes-instabul-tessera-bash directory, run the command shown here:

   $ 4-nodes-istanbul-tessera-bash ./runscript.sh private_contract.js
   

   Once the preceding command runs, it will produce an output similar to the one shown here, indicating that the transaction has been sent and that a transaction hash 0xa58ec5e7466129a5d09fba73639c574f1a174275e62d277396b141cc79456bf4 has been produced:

   Contract transaction send: TransactionHash: 0xa58ec5e7466129a5d09fba73639c574f1a174275e62d277396b141cc79456bf4 waiting to be mined...
   True
   

Here, we have basically executed a private transaction and deployed a private smart contract that is only visible to Node 1 and Node 2. Nodes 3 and 4 are not party to this transaction and they shouldn't be able to view the contents of the code or the values (state) of the contract. We will demonstrate in this example that this is indeed the case.

Next, we'll attach Geth to each node, as shown using the commands in the following sections, and run the console commands as shown in the examples for each node.

Node 1

In order to interact with geth via IPC, enter the following command in the operating system's Terminal. This will open the Geth JavaScript console, where users can interact with the blockchain using several methods exposed by Geth:

$ geth attach qdata/dd1/geth.ipc

Once the geth console is open, enter the following command, which declares a variable named abi:

> var abi = [{"constant":true,"inputs":[],"name":"storedData","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"x","type":"uint256"}],"name":"set","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"get","outputs":[{"name":"retVal","type":"uint256"}],"payable":false,"type":"function"},{"inputs":[{"name":"initVal","type":"uint256"}],"payable":false,"type":"constructor"}];

Now, create a new contract instance using the command shown here. We can use this object to access all methods and events of the contract:

> var simpleContract = eth.contract(abi)

Next, we use the instance object created previously to get a complete abstraction of our contract by using the command shown here:

> var simple = simpleContract.at("0x9d13c6d3afe1721beef56b55d303b09e021e27ab")

Now, we can use the simple object to access all the methods in our smart contract. In the following example, we're using the get() method to return the stored value in our contract:

> simple.get()
42

This command outputs 42, which is our stored value.

Note that after each statement we enter in the geth console, except the last statement, simple.get(), we also see that a message of Undefined is displayed. Simply ignore this; it is just a standard way in JavaScript of indicating uninitialized variables, non-existent object properties, or other similar scenarios.

Node 2

Similar to Node 1, open the geth console for Node 2 using the command shown here:

$ geth attach qdata/dd2/geth.ipc

As we did for Node 1, in the geth console, enter the following commands:

> var abi = [{"constant":true,"inputs":[],"name":"storedData","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"x","type":"uint256"}],"name":"set","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"get","outputs":[{"name":"retVal","type":"uint256"}],"payable":false,"type":"function"},{"inputs":[{"name":"initVal","type":"uint256 "}],"payable":false,"type":"constructor"}];
> var simpleContract = eth.contract(abi)
> var simple = simpleContract.at("0x9d13c6d3afe1721beef56b55d303b09e021e27ab")
> simple.get()
42

Much like Node 1, the final command outputs 42, which is our stored value.

Node 3

Again, similar to Node 1, open the geth console for Node 3 using the command shown here:

$ geth attach qdata/dd3/geth.ipc

In the geth console, enter the following

> var abi = [{"constant":true,"inputs":[],"name":"storedData","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"x","type":"uint256"}],"name":"set","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"get","outputs":[{"name":"retVal","type":"uint256"}],"payable":false,"type":"function"},{"inputs":[{"name":"initVal","type":"uint256 "}],"payable":false,"type":"constructor"}];
> var simpleContract = eth.contract(abi)
> var simple = simpleContract.at("0x9d13c6d3afe1721beef56b55d303b09e021e27ab")
> simple.get()
0

Note that the value returned is 0, which indicates that Node 3 cannot access the value of 42, which is expected as Node 3 is not privy to the transaction.

Node 4

Finally, we open the geth console for Node 4 using the command shown here:

$ geth attach qdata/dd4/geth.ipc

In the console, enter the following command as we did for nodes 1, 2, and 3:

> var abi = [{"constant":true,"inputs":[],"name":"storedData","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"x","type":"uint256"}],"name":"set","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"get","outputs":[{"name":"retVal","type":"uint256"}],"payable":false,"type":"function"},{"inputs":[{"name":"initVal","type":"uint256 "}],"payable":false,"type":"constructor"}];
> var simpleContract = eth.contract(abi)
> var simple = simpleContract.at("0x9d13c6d3afe1721beef56b55d303b09e021e27ab")
> simple.get()
0

As expected, Nodes 3 and 4, which are not party to the transaction, will see 0 as the transaction value. On the other hand, Nodes 1 and 2 are able to see the transaction value, which is 42.

In the next section, we'll see how we can use Cakeshop to view the transactions and other relevant blockchain data. Remember, as we discussed earlier in this chapter, we need to monitor and visualize enterprise blockchain networks. Cakeshop fulfills that need.

Viewing the transaction in Cakeshop

In Cakeshop, we can see this transaction and relevant attributes. We simply browse to chain explorer and enter the transaction hash "0xa58ec5e7466129a5d09fba73639c574f1a174275e62d277396b141cc79456bf4" from step 1 of this process. Cakeshop will display the status of the transaction, block ID, block number, contract address, and several other attributes, which makes it easy to explore the transaction process in detail:

Figure 20.15: Cakeshop chain explorer

Further investigation

We can also see the transaction receipts and contract code using the geth console.

For this, we attach to geth using the following command:

$ geth attach

We will do this on each node, as follows.

Node 1

First, we open the geth console using the following command on Node 1:

$ geth attach qdata/dd1/geth.ipc

When the geth console opens, enter the following statement, which uses the transaction hash from our first step of contract deployment:

> eth.getTransaction("0xa58ec5e7466129a5d09fba73639c574f1a174275e62d277396b141cc79456bf4")

The output shown here will be displayed:

{
  blockHash: "0x92837fb132b07c80058abddc1da85b6018e55aa833359aa30b6af676e72972d5",
  blockNumber: 418,
  from: "0xed9d02e382b34818e88b88a309c7fe71e65f419d",
  gas: 4700000,
  gasPrice: 0,
  hash: "0xa58ec5e7466129a5d09fba73639c574f1a174275e62d277396b141cc79456bf4",
  input: "0x6d99da7776195f534b48d53e8a2e94231299d38967a874115fe329b0a8a236e83258 b04187674022ab7bb79847e45d02d266009ccb37a1011967e77da12b152b",
  nonce: 2,
  r: "0x3ca297d21fed45e3701d2e3ed9d4e3a144c1350ea5b981005ff734efc8467967",
  s: "0x6233d5d65445ae258e7c04efd085f1cdba42ca5f63c9982b4db779d45d098bae",
  to: null,
  transactionIndex: 0,
  v: "0x26",
  value: 0
}

In the preceding output, we can see that the V value is 0x26 in hexadecimal, which means 38 in decimal. This value of 38 indicates that the transaction is private.

Also, notice the input field, which is the encrypted payload of the transaction.

Similarly, we can get the transaction receipt of this transaction by issuing the call shown here:

> eth.getTransactionReceipt("0xa58ec5e7466129a5d09fba73639c574f1a174275e62 d277396b141cc79456bf4")
{
  blockHash: "0x92837fb132b07c80058abddc1da85b6018e55aa833359aa30b6af676e72972d5",
  blockNumber: 418,
  contractAddress: "0x9d13c6d3afe1721beef56b55d303b09e021e27ab",
  cumulativeGasUsed: 0,
  from: "0xed9d02e382b34818e88b88a309c7fe71e65f419d",
  gasUsed: 0,
  logs: [],
  logsBloom: "0x000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000",
  status: "0x1",
  to: null,
  transactionHash: "0xa58ec5e7466129a5d09fba73639c574f1a174275e62d277396b141cc79456bf4",
  transactionIndex: 0
}

We can see in the output that the status is 0x1, indicating the success of the transaction. As we need to get the code of this transaction (smart contract), we need the contract address, which we can see in the contractAddress field. We copy that address into the RPC call shown here to fetch the code for this contract:

> eth.getCode("0x9d13c6d3afe1721beef56b55d303b09e021e27ab")
"0x60606040526000357c010000000000000000000000000000000000000000000000 0000000000900463ffffffff1680632a1afcd914605157806360fe47b114607757806 36d4ce63c146097575b600080fd5b3415605b57600080fd5b606160bd565b60405180 82815260200191505060405180910390f35b3415608157600080fd5b6095600480803 590602001909190505060c3565b005b341560a157600080fd5b60a760ce565b604051 8082815260200191505060405180910390f35b60005481565b806000819055505b505 65b6000805490505b905600a165627a7a72305820d5851baab720bba574474de3d09d beaabc674a15f4dd93b974908476542c23f00029"

As we can see in the preceding output, the contract code is visible as bytecode in hex.

Node 2, which is privy to the transaction

Similarly to Node 1, open the geth console on Node 2 using the command shown here:

$ geth attach qdata/dd2/geth.ipc

In the geth console, enter the following statement. This method takes the address of the smart contract and returns the compile smart contract code (bytecode):

> eth.getCode("0x9d13c6d3afe1721beef56b55d303b09e021e27ab")

The following output shows the bytecode of our contract at address "0x9d13c6d3afe1721beef56b55d303b09e021e27ab":

"0x60606040526000357c010000000000000000000000000000000000000000000000 0000000000900463ffffffff1680632a1afcd914605157806360fe47b114607757806 36d4ce63c146097575b600080fd5b3415605b57600080fd5b606160bd565b60405180 82815260200191505060405180910390f35b3415608157600080fd5b6095600480803 590602001909190505060c3565b005b341560a157600080fd5b60a760ce565b604051 8082815260200191505060405180910390f35b60005481565b806000819055505b505 65b6000805490505b905600a165627a7a72305820d5851baab720bba574474de3d09d beaabc674a15f4dd93b974908476542c23f00029"

As expected, the code is also visible on Node 2, as Node 2 is party to the transaction.

Node 3, which is not privy to the transaction

Now, we open the geth console on Node 3:

$ geth attach qdata/dd3/geth.ipc

In the console, enter the following statement with the address of our smart contract:

> eth.getCode("0x9d13c6d3afe1721beef56b55d303b09e021e27ab")

This will show the output shown here:

"0x"

This output indicates that the contract code is only available on the nodes that are party to the transaction. The contract code is not available on other nodes that are not a party to the transaction.

This experiment demonstrates that the contract is only available on the nodes that are party to the transactions. First, we deployed our private contract from Node 2 with Node 1 as a participant and used the geth console to interact with the contract. We saw that the value 42 is only available on the nodes that are party to the transaction. Also, we further experimented and noticed that not only the value, but the smart contract code, is only available on the nodes that are party to our private contract (transaction).

This network is now available for further experiments. You can create your own private contracts with different nodes as parties. You can also explore how other methods such as debug_traceTransaction behave when interacting with private contracts. This network can also be used to build some PoCs for an enterprise DApp.

After this quick experiment of demonstrating how private transactions work in Quorum, let's explore other Quorum projects. As mentioned earlier, Quorum is a feature-rich platform and is under continuous improvement and development. As a result, new features and projects are introduced regularly. Some of the other projects under Quorum are listed here, along with brief descriptions.

Other Quorum projects

Some of the projects and features are listed here.

Remix plugin

This is a plugin for the popular Remix IDE, which supports private smart contracts on the Quorum blockchain. More information on this is available here: https://docs.goquorum.consensys.net/en/latest/Reference/RemixPlugin/Overview/.

Pluggable architecture

Quorum supports a pluggable architecture that allows us to add new features to the Quorum client as plugins. This approach allows us to keep the core Quorum services separate from the new features, which allows greater modularity and extensibility without modifying the core client. More information on this feature is available here: https://docs.goquorum.consensys.net/en/latest/Concepts/Plugins/Plugins/.

Quorum is a large project with many excellent enterprise features. It is not possible to cover all of them in this chapter. However, the material provided should get you started with Quorum blockchain setup, plus an understanding of the concept of private transactions.

Quorum has been used in many industries for different projects, including finance, supply chain, healthcare, media, and government sectors. A couple of example uses are:

• Tracking luxury goods: https://www.coindesk.com/louis-vuitton-owner-lvmh-is-launching-a-blockchain-to-track-luxury-goods
• Post trade processing platform: https://cointelegraph.com/news/oil-trading-blockchain-platform-vakt-launches-with-shell-bp-as-first-users

Quorum is also available on different cloud platforms, including:

• Azure: https://azuremarketplace.microsoft.com/fi/marketplace/apps/enterprise-ethereum-alliance.quorum-demo?tab=Overview
• Kaleido: https://www.kaleido.io

Summary

In this chapter, we started with an introduction to enterprise solutions and blockchain. We saw some limiting factors in public chains that make then unsuitable for enterprise use cases. We also looked at some requirements that, when met, will make a blockchain suitable for enterprise use cases.

We also covered how to design enterprise blockchain solutions and made a case to see the enterprise blockchain solutions in the context of the enterprise architecture. Next, we explored cloud computing and the definition of Blockchains as a Service. We briefly looked at the efforts being made to standardize enterprise Ethereum specifications. The last sections of this chapter covered enterprise blockchain platforms, including Quorum and Corda, and finally we set up an IBFT network using Quorum to demonstrate how privacy is achieved using Quorum.

In the next chapter, we will introduce scalability, security, and other challenges that blockchains face, how many of these limitations are being addressed, and what the future holds for the blockchain technology.