This chapter describes the characteristics, usage scenarios, and architecture of enterprise blockchains, and illustrates three major enterprise blockchain systems in three separate sections.
Relationship Between the Enterprise Blockchain and Consortium Blockchain
for a particular purpose by following a unified authentication system, consensus mechanism, and smart contract specification for standards-based interoperability of their respective homogeneous or heterogeneous blockchain data, systems, and services.
The enterprise blockchain is a conceptual term that limits blockchain applications to enterprises. It must work on a certain blockchain platform. According to our observation, most enterprises choose the consortium blockchain technology when deciding to implement the blockchain technology. Therefore, the consortium blockchain is the main concern in this chapter. Hereinafter, the consortium blockchain and the enterprise blockchain are interchangeable.
Characteristics of Consortium Blockchains
A consortium blockchain is generally used to share data between organizations or run programs that they consent. Unlike a public blockchain that has a large number of unregistered nodes, a consortium blockchain has a limited number of participants that have been authenticated. It is also different from a private blockchain in that control over it is not granted to a single manager with the highest privilege, but rather a group of peer nodes.
In addition, a consortium blockchain is oriented towards particular scenarios, with a lot of variances from a public blockchain. In summary, it has the following characteristics:
- Identity authentication. All participants of a consortium blockchain have a unique identity. Only with such a unique identity, can a participant be granted permissions.
- Access permission. Consortium blockchains are permissioned. That is to say, a node can gain access to a consortium blockchain only when meeting certain access control conditions. In this sense, a consortium blockchain is thought of as a permissioned blockchain.
- High throughput. In some usage scenarios (such as finance) that feature high-frequency transactions, a consortium blockchain should deliver high throughputs to support massive applications.
- Low latency. In a public blockchain, such as Bitcoin, the delay caused by generation of six blocks to confirm a transaction is too long for many consortium blockchain applications, which are supposed to support fast transactions. A consortium blockchain assumes a certain degree of trust in peer nodes by performing identity authentication and access controls. It shortens the time to reach consensus by simplifying the consensus algorithm, leading to a low latency.
- Confidentiality and privacy. A consortium blockchain should ensure the confidentiality and privacy of business transactions. For example, in a supply chain network, prices may be different for different customers. If contract and transaction contents were visible to all participants, it would be very difficult to differentiate prices. Out of this consideration, some consortium blockchains add the design of channels, providing confidentiality and privacy protection for different transaction participants.
Consortium blockchains have a limited number of authenticated peer nodes, particularly suitable for decentralized multi-party enterprise applications and applicable to a wide range of scenarios, including decentralized finance, Internet of things (IoT), jurisdictional forensics, food source tracking, and identity authentication. There are loads of research papers on this topic and no further details are provided here.
Reference Architecture of Consortium Blockchains
The blockchain technology is implemented in a hierarchical architecture based on multiple supporting techniques. Some emerging blockchain technologies initially developed for public blockchains, over time, have gradually been integrated into consortium and private blockchain systems. Therefore, public, private, and consortium blockchains are basically the same in the technical stack, but the latter two have more control and management components, such as authentication and identity management, supervision, and audits.
The China Blockchain Technology and Industrial Development Forum (CBD-Forum) introduced a blockchain reference architecture (Figure 2.1) in 2017, which can also serve as the reference architecture of consortium blockchains.
In the reference architecture:
- The underlying layer provides components necessary for proper running of the blockchain system, including the storage and computation components and peer-to-peer (P2P) network.
- The core layer, as the core of the blockchain system, consists of the consensus mechanism, smart contract, cryptography-related functions, ledger records, and so on.
- The service layer, by calling functional components from the core layer, provides the access service for the user layer, including access management, node management, and ledger applications.
- The user layer provides the user function, service function, and management function.
This reference architecture is a universal one. For the purpose of manageable consortium blockchains, the architecture should have more components for development management, operations, security, and supervision and audits, which are distributed across layers of the technical stack of the reference architecture.
The development function provides components necessary for blockchain development, including the integrated development environment (IDE), test management, and build management.
The operations function provides components for blockchain system management, including policy management and exception and issue management.
The security function is used to authenticate users and nodes, encrypt communications, encrypt transactions, and control access to data, consisting of authentication and identity management, authorization and security policy management, and privacy protection components.
Real-time supervision and post-event audits are also indispensable to consortium blockchains. In practice, organizations, when implementing consortium blockchains, should keep in mind regulatory requirements for the specific industry that they are in.
To be continued.
