Blockchain Technology Series (ii)-Fabric Architecture Introduction

Fabric is made up of the core components described in the following section. 2.1 Architecture

This architecture reference focuses on three categories: Members (membership), Blockchain (Blockchan), and chain codes (Chaincode). These categories are logical structures, rather than physically dividing different components into separate processes, address spaces, (virtual) machines.

2.1.1 Member Services

Member services provide identity management, privacy, confidentiality, and auditable services to the network. In a blockchain with no permissions, participants do not need to be authorized, and all nodes can submit transactions in the same way and assemble them into acceptable blocks, such as: they do not have a role distinction. Member Services enable the non-privileged blockchain to become a blockchain with permissions through the public key Infrastructure (PKI) and the de-centralized/consensus technology. In the latter case, an entity registration is obtained to obtain a long period of credentials that may be generated based on the entity type (Enrollment certificate enrollment certificates). Such a certificate allows the transaction certification authority (Transaction Certificate Authority (TCA)) to issue anonymous certificates during user use. Such a certificate, such as a trading certificate, is used to authorize the submission of a transaction. The transaction certificate is stored in the blockchain and authorized for the audit cluster, otherwise the transaction is not linked. 2.1.2 Blockchain Services

The blockchain service manages the distributed General ledger through the point-to-point (peer-to-peer) protocol on the HTTP/2. In order to provide the most efficient hashing algorithm to maintain the replication of world State, the data structure is highly optimized. Each deployment can be plugged in and configured with different consensus algorithms (PBFT, Raft, PoW, PoS). 2.1.3 Chain Code Service

The Chain Code service provides a secure, lightweight sandbox to execute the chain code on the authentication node. The environment is a "locked" and secure security operating system image and chain code language that includes a signed name, Go,java and node. js's runtime and SDK tiers. You can enable additional languages as needed. 2.1.4 Events

Verify that peers and chain codes can send events to applications that listen and act on the network. This is a set of predefined events that can generate customized events. Events are consumed by one or more event adapters. The adapter may then post events to other devices, such as Web hooks or Kafka. 2.1.5 Application Programming Interface (API)

The main interface of fabric is the REST API and is changed by Swagger 2.0来. API allows registered users, blockchain queries and publishing transactions. The interaction between the chain code and the heap executing the transaction and the resulting query of the transaction are regulated by the API collection. 2.1.6 Command Line Interface (CLI)

The CLI contains a subset of rest APIs that allow developers to test the chain code faster or to query the trading status. The CLI is implemented through the Go language and can be operated on a variety of operating systems. 2.2 Topologies

One deployment of fabric is a chain consisting of member services, multiple validation peers, non-validating peers, and one or more applications. Can also have multiple chains, each chain has different operating parameters and safety requirements. 2.2.1 Single-proof peer

Functionally, a non-authenticated peer is a subset of the authentication peer, and the function on the non-authenticated peer can be enabled on the authentication peer, so there is only one authentication peer on the simplest network. This configuration is typically used in the development environment: a single authenticated peer is launched during the edit-compile-debug cycle.

A single verified peer does not require consensus, and by default the Noops plugin is used to process the received transactions. This makes it possible for developers to receive returns immediately in development. 2.2.2 Multi-proof Peer

A production or test network needs to have multiple authentication and non-validating peers components. A non-authenticated peer can share the stress of validating a peer like API request processing or event handling.

A mesh network (each verifying peer needs to be connected to another authentication peer) to propagate the information. A non-authenticated peer connects to a nearby, allowing it to connect to the authentication peer. A non-verified peer is optional when the app may be connected directly to the authentication peer. 2.2.3 Multi-strand

Authentication and non-verified peer networks form a chain. You can create different chains based on different requirements, like creating different Web sites for different purposes.