Hyperledger Fabric Architecture Design by Yeasy

This is a creation in Article, where the information may have evolved or changed.

The entire functional architecture is shown.

Includes three main components: Blockchain service (Blockchain), Chain Code Service (Chaincode), Member Rights Management (membership).

Conceptual Terminology
auditability (Audit): Under certain authority and permission, the transaction on the chain can be audited and inspected.
block (block): Represents a group of confirmed transaction information as a whole, ready to be added to the blockchain by consensus.
Blockchain (Blockchain): A list structure linked by multiple blocks, except for the first chunk, each chunk contains the hash value of the contents of the previous block.
Certificate Authority (CA): Responsible for identity rights management, also known as Member Service or identity service.
Chaincode (chain codes or chain codes): Application code on blockchain, extended from "smart contract" concept, support Golang, Nodejs, etc., run in isolated container environment.
Committer (Commit node): 1.0 a Peer node role in the architecture, responsible for checking orderer sorted transactions, selecting a legitimate trade execution and writing to the store.
Confidentiality (confidentiality): Only the trading party can see the transaction content, others cannot see without authorization.
endorser (Endorsement node): 1.0 a Peer node role in the architecture, responsible for verifying that a transaction is legitimate and willing to endorse or sign it.
Enrollment Certificate Authority (ECA, registered CA): CA responsible for membership-related certificate management.
Ledger (Ledger): Includes the blockchain structure (with all verifiable transaction information, but only the final successful trade changes the world view) and the current worldview (world). Ledger only exists in the Peer node.
MSP (Member service Provider, Member service provider): An abstract access interface for member Services that enables pluggable support for different member services.
non-validating Peer (non-authentication node): Does not participate in ledger maintenance, responds to the client's REST request only as a trading agent, and carries out some basic validation checks on the transaction, which is then forwarded to the authentication node.
Orderer (Sort node): 1.0 The Consensus service role in the schema, which is responsible for sorting the transactions seen, providing the order of global acknowledgments.
permissioned ledger (with a privileged ledger): All nodes in the network must be licensed, and non-licensed nodes cannot join the network.
Privacy (Privacy protection): The trader can hide the identity of the transaction, other members in the absence of special privileges, can only verify the transaction, and cannot know the identity information.
Transaction (TRADE): Executes a function call on the ledger. The specific function is implemented in Chaincode.
Transactor (Trader): The client initiating the trade call.
Transaction Certificate Authority (TCA, trading CA): CA responsible for maintaining transaction-related certificate management.
Validating Peer (authentication node): maintains the core node of the ledger, participates in consistent maintenance, validates and executes transactions.
World State (World view): is a key-value database that Chaincode uses to store transaction-related states.

Blockchain Services
Blockchain services provide a distributed ledger platform. In general, multiple transactions are packaged into chunks, and multiple chunks form a blockchain. Blockchain represents the historical process of changing the state machine of a ledger.

Transaction
Trading means operating around a chain code.
Trading can change the state of the world.
The main contents of the transaction include:
• Transaction type: Currently includes Deploy, Invoke, Query, Terminate four kinds;
UUID: The unique number representing the transaction;
• Chain code number Chaincodeid: The chain code for the transaction;
• Hash value of payload content: Load content can be specified when Deploy or Invoke;
• The confidentiality level of the transaction is confidentialitylevel;
• Transaction-related metadata information;
• Temporary generated value nonce: related to security mechanism;
• Trader's certificate information cert;
• Signature information signature;
metadata information;
• Time stamp timestamp.

The transaction data structure (PROTOBUF format) is defined as:

  message Transaction {enum Type {UNDEFINED = 0;        Deploy a chaincode to the network and call ' Init ' function chaincode_deploy = 1;        Call a Chaincode ' Invoke ' function as a transaction Chaincode_invoke = 2;        Call a chaincode ' query ' function chaincode_query = 3; Terminate a chaincode;    Not implemented yet chaincode_terminate = 4;    } Type type = 1;    Store Chaincodeid as bytes so it encrypted value can be stored bytes Chaincodeid = 2;    Bytes payload = 3;    Bytes metadata = 4;    string uuid = 5;    Google.protobuf.Timestamp Timestamp = 6;    Confidentialitylevel confidentialitylevel = 7;    string confidentialityprotocolversion = 8;    Bytes Nonce = 9;    Bytes Tovalidators = 10;    Bytes cert = 11; Bytes signature = n;}  

In the 1.0 architecture, a transaction includes the following information:
[Ledger] [Channel], proposal: [Chaincode,] **endorsement:[proposal hash, simulation result, signature]
endorsements:proposal Hash, simulation result, signature
function-spec:function Name, arguments
proposal: [Channel,] Chaincode,

Block
Block package transactions to confirm the state of the world after the transaction.
The main content included in a chunk is:
• Version number: Version information of the Protocol;
• Timestamp Timestamp: Set by the block proponents;
• Trading information The root hash value of the Merkel tree: composed of the transactions included in the Block;
• World view of the Merkel tree root hash value: consists of the state value of the whole world after the transaction occurs;
• The hash value of the previous block: necessary to make up the chain;
• Consensus-related meta-data: optional values;
• Non-hash data: does not participate in the hash process, the values on each peer may be different, such as local commit time, transaction processing return value, etc.;
Note that the specific transaction information is not stored in the block.
The data structure of the chunk (PROTOBUF format) is defined as:

message Block {    uint32 version = 1;    google.protobuf.Timestamp timestamp = 2;    repeated Transaction transactions = 3;    bytes stateHash = 4;    bytes previousBlockHash = 5;    bytes consensusMetadata = 6;    NonHashData nonHashData = 7;}

An example of a real chunk content:

{"Nonhashdata": {"Localledgercommittimestamp": {"Nanos": 975295157, "seconds": 1466 057539}, "Transactionresults": [{"UUID": "7be1529ee16969baf9f3156247a0ee8e7     Eee99a6a0a816776acff65e6e1def71249f4cb1cad5e0f0b60b25dd2a6975efb282741c0e1ecc53fa8c10a9aaa31137 "}] }, "Previousblockhash": "RRNDKWUOJRMJOZ/RDD7RJD/NUUPIUBUCTQWNZG7VDI/XXCTD2MDYAMSFAZ1NTZL2/IICSUEATIZAKS6SS7FEVG        = = "," Statehash ":" tiiwrog48z4xxffipeunnpavmxnvmzkg+yfxkk3vby0zqik3l0qq5iliv85iy7u+eivhwebkbb1kb7w1ddqu5g== ", "Transactions": [{"Chaincodeid": "Ckdnaxrodwiuy29tl2h5cgvybgvkz2vyl2zhynjpyy9legftcgxlcy9jagfpbmnvzg Uvz28vy2hhaw5jb2rlx2v4yw1wbguwmhkaatdizte1mjllzte2oty5ymfmowyzmtu2mjq3ytblzthln2vlztk5ytzhmge4mty3nzzhy2zmnjvlnmuxzgvmnze YNDLMNGNIMWNHZDVLMGYWYJYWYJI1ZGQYYTY5NZVLZMIYODI3NDFJMGUXZWNJNTNMYTHJMTBHOWFHYTMXMTM3 "," payload ":" Cu0BCAESzAE Kr2dpdgh1yi5jb20vahlwzxjszwrnzxivzmficmljl2v4yw1wbgvzl2noywluy29kzs9nby9jagfpbmnvzgvfzxhhbxbsztayeoabn2jlmtuyowvlmty5njliywy5zjmxntyynddhmgvlogu3z Wvlotlhnmewytgxnjc3nmfjzmy2nwu2ztfkzwy3mti0owy0y2ixy2fknwuwzjbinjbimjvkzdjhnjk3nwvmyji4mjc0mwmwztfly2m1m2zhogmxmge5ywfhmz Exmzcaggoeaw5pdbibyrifmtawmdasawisbtiwmdaw "," timestamp ": {" Nanos ": 298275779," Seconds ": 1466057529}," type ": 1," uuid ":" 7be1529ee16969baf9f3156247a0ee8e7eee99a6a0a81 6776acff65e6e1def71249f4cb1cad5e0f0b60b25dd2a6975efb282741c0e1ecc53fa8c10a9aaa31137 "}]}

Worldview
Worldview is used to store the state variables involved in the execution of a chain code, which is a key-value database. The typical element is [Chaincodeid, Ckey]: the value structure.

To facilitate the calculation of the changed hash value, the MS Merkel tree data structure is generally used for storage. The structure of the tree is initially configured by two parameters (Numbuckets and maxgroupingateachlevel) and is determined by the hashfunction configuration to hold the key value to the leaf node. Obviously, each node must maintain the same configuration, and it is generally not recommended to change after launch.
Numbuckets: The number of leaf nodes, each leaf node is a bucket (bucket), all the key values are hashfunction scattered to each bucket, determine the width of the tree;
Maxgroupingateachlevel: Determines how many sub-nodes the hash value of each node is composed of, determining the depth of the tree.

Where the contents of a bucket are aggregated by chaincodeid and then sorted in ascending order, by saving it to the key value.
Generally, if a bucket contains m chaincodeid, for Chaincodeidi, assuming that it includes n key-value pairs, the aggregated GI content can be calculated as:

The contents of the bucket are:

Note: The + here is a concatenation of strings, not a mathematical operation.

Chain Code Service
The chain code contains all the processing logic and provides an external interface to change the world view by calling the link code interface.

Interfaces and operations
The chain code needs to implement the Chaincode interface to be called by the VP node.

type Chaincode interface { Init(stub *ChaincodeStub, function string, args []string) ([]byte, error) Invoke(stub *ChaincodeStub, function string, args []string) ([]byte, error) Query(stub *ChaincodeStub, function string, args []string) ([]byte, error)}

The types of transactions currently supported by the chain code include deployment (deploy), Invoke (Invoke), and query.

• Deployment: The VP node uses the chain code to create the sandbox, after the sandbox starts, processes the shim layer of the PROTOBUF protocol to send a register message containing Chaincodeid information to the VP node, registers it, and after the registration is completed, the VP node passes the parameters by GRPC and calls the chain code init function completes initialization;
• Call: The VP node sends a TRANSACTION message to the shim layer of the Chain Code sandbox, and the shim layer invokes the Invoke function of the chain code called by the passed parameter;
• Query: The VP node sends a query message to the shim layer of the Chain Code sandbox, and the shim layer uses the parameter called by the link code to complete the inquiry function.

Different chain codes may call and query each other.

Container
In the implementation, the chain code needs to run in the isolated container, the super-Ledger uses Docker as the default container.
The operation of the container supports three methods: Build, start, stop, and the corresponding interface is the VM.

type VM interface {   build(ctxt context.Context, id string, args []string, env []string, attachstdin bool, attachstdout bool, reader io.Reader) error   start(ctxt context.Context, id string, args []string, env []string, attachstdin bool, attachstdout bool) error   stop(ctxt context.Context, id string, timeout uint, dontkill bool, dontremove bool) error }

Once the chain code is deployed successfully, it creates a GRPC channel connected to the VP node that deploys it to accept subsequent Invoke or Query instructions.

GRPC message
The VP node interacts with the container through GRPC messages. The message basic structure is:

message ChaincodeMessage { enum Type { UNDEFINED = 0; REGISTER = 1; REGISTERED = 2; INIT = 3; READY = 4; TRANSACTION = 5; COMPLETED = 6; ERROR = 7; GET_STATE = 8; PUT_STATE = 9; DEL_STATE = 10; INVOKE_CHAINCODE = 11; INVOKE_QUERY = 12; RESPONSE = 13; QUERY = 14; QUERY_COMPLETED = 15; QUERY_ERROR = 16; RANGE_QUERY_STATE = 17; } Type type = 1; google.protobuf.Timestamp timestamp = 2; bytes payload = 3; string uuid = 4;}

When a chain code deployment occurs, the container starts sending a REGISTER message to the VP node. If successful, the VP node returns the registered message and sends the INIT message to the container, calling the Init method in the chain code.

When a chain code call occurs, the VP node sends a TRANSACTION message to the container, calling its Invoke method. If successful, the container returns a RESPONSE message.

Similarly, when a chain code query occurs, the VP node sends a query message to the container, calling its Query method. If successful, the container returns a RESPONSE message.

Member Rights Management
Through PKI-based member Rights management, the platform can limit the ability of the nodes and clients to be accessed.

There are three types of certificates, Enrollment,transaction, and TLS certificates that ensure secure communication.

• Certificate of Registration Ecert: issued to the user or node that provided the registration voucher, generally long-term effective;
• Trading Certificate Tcert: Issued to the user, control the rights of each transaction, generally for a transaction, short-term effective.
• Communication Certificate Tlscert: Control access to the network and prevent eavesdropping.

The new architecture design
Currently, the VP node performs all operations, including receiving transactions, verifying transactions, agreeing on conformance, maintaining ledger maintenance, and so on. The coupling of these features makes node performance difficult to scale.

The new idea is to decouple these functions so that each function is relatively single and easy to scale. There has been some discussion in the community.

The Fabric 1.0 is designed with the appropriate decoupling to decouple the node roles based on functionality, allowing different nodes to handle different types of workloads.

Sample work Process

• Client: The client application uses the SDK to deal with fabric, constructs a legitimate transaction proposal to submit to endorser, and collects enough endorser support to construct a legitimate transaction request to a Orderer or broker node.
• Endorser Peer: Responsible for legality and ACL permission checks (simulated transactions) on transactions from clients, by signing and returning results to the client.
• Committer Peer: Responsible for maintaining the ledger, the results of a consistent order of the batch transaction status checks, generate chunks, execute a legitimate transaction, and write to the ledger, the same physical node can simultaneously assume the role of endorser and Committer.
• Orderer: It is only the sort that gives the trader a global ranking, and generally does not need to deal with ledger and transaction content.
• CA: Responsible for the maintenance of all certificates, following the PKI.

Sample Trading Process