Fabric structure analysis Blockchain underlying development technology virtual currency

Blockchain Enthusiast (qq:53016353)

The previous analysis program looked at the details of the analysis, so without the concept of framework, took two days to analyze the Hyperledger fabric architecture design, analysis of the program does not reference any information, such as error welcome correction, common progress.

The author has the following questions before the detailed analysis procedure:
1) How the CLI (command line) client sends a command to a peer node
2) How the peer node receives data from other nodes, how the data is processed, and how it differs from 1
3) When and how the data is fed into the consensus module
4) What is the architecture of the consensus module? Why does it look like Helper executor PBFT controller folders are handed together, save their respective handles, call each other
5) Chaincode (chain code, CC) is how to receive peer to its operation, access to the
6) How Chaincode calls the Fabric API to query the data that is written to the
7) During the read source initialization process, the peer node creates a large number of servers, and how we use these server follow-up procedures


Note: I am not very familiar with the database, Docker knowledge, as far as possible to avoid the introduction of these two parts to avoid the wrong guide readers.
The following will slowly penetrate the above-mentioned problems.


Server:




Each server role:
AdminServer: Control the fate of the node, you can delete the process where the node resides. (Start Stop GetStatus)
The Eventhubserver:peer node enables the client to listen for a specified event, such as rejection. The client needs to register the events that it cares about, trigger listeners when the event occurs.
Openchainserver: Provide ledger access interface to external, involving getblockchaininfo getblockbynumber and so on.
Devopsserver: is responsible for interfacing with the CLI client, external to the CC operation of the portal, Deploy invoke query.
Chaincodesupportserver: Responsible for communication with Shim/chaincode, Chaincode all calls to receive send will interact with the server information.
Peerserver: The server is an engine,engine that associates an internal message response implementation while creating a client communication with the surrounding peer node.
Restserver: The server is not parsed and should be related to the rest interface format.




First-class module classification:


Client: Before creating a server with its corresponding clients, can be understood as other nodes or CLI client.
Protos: Middle tier, server-to-client API interface definition
ServerProcess: Service response handler function, including each type of handlemessage.
Consensus: Consensus module, currently using PBFT Noops
Chaincode Shim: Code Shim and I understand the inconsistency, chaincodesupport should also be counted to Shim, the role of the module is to connect the peer node and Chaincode media, described in Shim can also.
Chaincode: Chain codes, applications (such as smart contracts).
DB: Data storage.
Library: There is a folder called vendor in the code, the function modules involved in the folder self-contained, such as grpcserver, etc.
The peer node information is invoked inside the Api:chaincode.
Crypto: Accompany with data encryption and decryption.
Ledger: Ledger operation.


The code uses handler trigger mode, in the tracking code program to pay attention to handler object assignment location, otherwise easy to find the wrong handlemessage, these handler processing functions named basically the same, easy to operate confusion.


Here are a few of the processes that readers should be most concerned about:
1) client executes an invoke command through the CLI
2) A node is sent to the node ViewChange command
3) Chaincode Call API Putstatus
4) Consensus process


One, the client executes an invoke command through the CLI
1) Create a devopsserver when the peer node is initialized


Serverdevops: = Core. Newdevopsserver (Peerserver)
Pb. Registerdevopsserver (Grpcserver, Serverdevops)


2) Devopsserver Set the service specification, such as Invoke Message, to invoke the _devops_invoke_handler function


var _devops_servicedesc = Grpc. servicedesc{
ServiceName: "Protos. Devops ",
Handlertype: (*devopsserver) (nil),
Methods: []grpc. methoddesc{
{
MethodName: "Login",
Handler: _devops_login_handler,
},
{
MethodName: "Build",
Handler: _devops_build_handler,
},
{
MethodName: "Deploy",
Handler: _devops_deploy_handler,
},
{
MethodName: "Invoke",
Handler: _devops_invoke_handler,
},
{
MethodName: "Query",
Handler: _devops_query_handler,
},
{
MethodName: "Exp_getapplicationtcert",
Handler: _devops_exp_getapplicationtcert_handler,
},
{
MethodName: "Exp_preparefortx",
Handler: _devops_exp_preparefortx_handler,
},
{
MethodName: "Exp_producesigma",
Handler: _devops_exp_producesigma_handler,
},
{
MethodName: "Exp_executewithbinding",
Handler: _devops_exp_executewithbinding_handler,
},
},
Streams: []grpc. streamdesc{},
}


3) where the _devops_invoke_handler function is in the Protos module, which is responsible for transmitting the client access information to the corresponding server module


Func _devops_invoke_handler (SRV interface{}, CTX context. Context, Dec func (interface{}) error) (interface{}, error) {
In: = new (Chaincodeinvocationspec)
If err: = Dec (in); Err! = Nil {
return nil, err
}
Out, err: = srv. (Devopsserver). Invoke (CTX, in)
If err! = Nil {
return nil, err
}
Return out, Nil
}


4) processing in the DevOps server-side code of the function


Func (d *devops) Invoke (CTX context. Context, Chaincodeinvocationspec *PB. Chaincodeinvocationspec) (*PB. Response, error) {
Return D.invokeorquery (CTX, Chaincodeinvocationspec, ChaincodeInvocationSpec.ChaincodeSpec.Attributes, True)
}


5) Thin Invokeorquery code, D.coord is Peerserver object, Executetransaction is the corresponding engine implementation method


Func (d *devops) invokeorquery (CTX context. Context, Chaincodeinvocationspec *PB. Chaincodeinvocationspec, attributes []string, invoke BOOL] (*PB. Response, error) {

RESP: = d.coord.executetransaction (Transaction)
}


6) This request is encapsulated into a transaction struct, which is processed in Peerserver.


Func (P *impl) executetransaction (transaction *PB. Transaction) (Response *pb. Response) {
If P.isvalidator {
Response = P.sendtransactionstolocalengine (transaction)
} else {
Peeraddresses: = P.dischelper.getrandomnodes (1)
Response = P.sendtransactionstopeer (Peeraddresses[0], transaction)
}
return response
}


7) Thinking that the final transaction is to be handed over to the consensus to deal with, then how to pass it. Just below the p.engine.processtransactionmsg, where "P" refers to Peerserver,engine is the engine that was specified when the Peerserver was created, And the engine of the handler implementation in the consensus, in the implementation of the Enginehandler process to load the PBFT algorithm. So the implementation of the PROCESSTRANSACTIONMSG function is in the Consensus module engine code. This solves the question raised at the beginning 3).


Func (P *impl) sendtransactionstolocalengine (transaction *PB. Transaction) *PB. Response {

PEERLOGGER.DEBUGF ("Marshalling transaction%s to send to local engine", transaction. Type)
Data, err: = Proto. Marshal (transaction)
If err! = Nil {
Return &PB. RESPONSE{STATUS:PB. Response_failure, MSG: []byte (FMT. Sprintf ("Error sending transaction to local engine:%s", err)}
}

var response *pb. Response
Msg: = &PB. MESSAGE{TYPE:PB. Message_chain_transaction, Payload:data, Timestamp:util. Createutctimestamp ()}
PEERLOGGER.DEBUGF ("Sending message%s with timestamp%v to local engine", MSG. Type, Msg. Timestamp)
Response = p.engine.processtransactionmsg (msg, transaction)

return response
}


8) From here onwards into the consensus internal processing, where the consensus module is analyzed separately.


Func (Eng *engineimpl) processtransactionmsg (msg *PB. Message, TX *pb. Transaction) (Response *pb. Response) {
ERR: = ENG.CONSENTER.RECVMSG (msg, Eng.peerEndpoint.ID)
}


Drawing illustrates the above process:



What is not reflected in this figure is that when DevOps server is created, the Peerserver object is passed as a construction parameter, and the process of peerserver creation is the process of creating the engine and the process of loading engine-handler. And Engine-handler is implemented in the consensus module. It's a bit abrupt to jump directly from a devops Server into the consensus module in the diagram.